09-07-2010 01:05 PM - edited 03-11-2019 11:36 AM
Hello.
I'm having a problem here with this 5510. I've got the ADSL connection up and running and I can ping internet IPs from the 5510. The problem is that I have a PC connected on the LAN side of the 5510 and that is unable to ping any internet IPs. I can ping the 5510's LAN IP from the PC but the packets aren't being forwarded over to the WAN interface for some reason. I can't ping the WAN IP of the 5510 either.
Can anyone share some insight? I've attached the configuration of the 5510 before setting up PAT as per this document --->> http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b1ee95.shtml
Thanks in advance.
Solved! Go to Solution.
09-07-2010 01:12 PM
Hi Felix,
To provide Internet through the ASA, normally you do the following:
nat (inside) 1 0 0
global (outside) 1 interface
To be able to PING you also add:
policy-map global_policy
class inspection_default
inspect icmp
If the ASA has a private IP on its public interface, I assume the DSL is doing NAT for that IP (since you can PING internet from the ASA).
You can try the above and check the results.
Federico.
09-07-2010 01:50 PM
Do the following test.
Can you PING the default gateway of the ASA from the inside computer?
Check the ''sh xlate'' and see if it's building the translation.
Also can do:
packet-tracer input inside tcp x.x.x.x 1024 198.133.219.25 80 (x.x.x.x is the inside IP of the computer)
This will show the results of attempting a connection on TCP port 80 to IP 198
Federico.
09-07-2010 03:32 PM
Hey Bro
Can you
"logging enable"
"logging buffered 7"
run the ping from the LAN host and then do a "sh logg", we are looking for the icmp connection being built along with the xlate as the others pointed out.
It sounds like the default gateway of your hosts might be screwed...
cheers ears
09-08-2010 05:14 AM
Hi Felix,
I agree with Golly and the others--it looks like the problem may be with your default gateway/routing. Are you sure the 'show route' output looks correct? It looks like the ASA is allowing the ICMP traffic and taking the correct translation.
To confirm this, you can setup packet captures for ICMP traffic on the outside interface of the ASA:
https://supportforums.cisco.com/docs/DOC-1222
My guess is that you'll see the echo request headed out toward the Internet, but nothing coming back in.
Hope that helps.
-Mike
09-07-2010 01:12 PM
Hi Felix,
To provide Internet through the ASA, normally you do the following:
nat (inside) 1 0 0
global (outside) 1 interface
To be able to PING you also add:
policy-map global_policy
class inspection_default
inspect icmp
If the ASA has a private IP on its public interface, I assume the DSL is doing NAT for that IP (since you can PING internet from the ASA).
You can try the above and check the results.
Federico.
09-07-2010 01:15 PM
Hey Federico. Thanks for the response.
I'm using version 8.3 so the global command doesn't exist in this version of the OS anymore and nat is implemented differently.
I'll add the inspect icmp and let you know what happens.
09-07-2010 01:22 PM
Same concept applies.
Just check the new NAT syntax:
https://supportforums.cisco.com/docs/DOC-9129
Federico.
09-07-2010 01:46 PM
09-07-2010 01:50 PM
Hi Felix,
Can you check the output of this command:
packet-tracer in lan icmp 192.168.5.x 8 0 4.2.2.2
That should help narrow down the problem.
-Mike
09-07-2010 01:51 PM
Also, double check the output of 'show route' to make sure your default gateway is being set by PPPoE correctly.
-Mike
09-07-2010 01:50 PM
Do the following test.
Can you PING the default gateway of the ASA from the inside computer?
Check the ''sh xlate'' and see if it's building the translation.
Also can do:
packet-tracer input inside tcp x.x.x.x 1024 198.133.219.25 80 (x.x.x.x is the inside IP of the computer)
This will show the results of attempting a connection on TCP port 80 to IP 198
Federico.
09-07-2010 02:10 PM
This is the result of the packet trace:-
Result of the command: "packet-tracer input lan icmp 192.168.5.1 8 0 4.2.2.2"
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 wan
Phase: 2
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 3
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 4
Type: NAT
Subtype:
Result: ALLOW
Config:
object network Inside
nat (lan,wan) dynamic interface
Additional Information:
Dynamic translate 192.168.5.1/0 to 69.73.200.137/34850
Phase: 5
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 48, packet dispatched to next module
Result:
input-interface: lan
input-status: up
input-line-status: up
output-interface: wan
output-status: up
output-line-status: up
Action: allow
09-07-2010 02:12 PM
This is the result of the show route command:
Result of the command: "show route"
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is 216.110.96.1 to network 0.0.0.0
C 192.168.15.0 255.255.255.0 is directly connected, Management
C 192.168.5.0 255.255.255.0 is directly connected, lan
S* 0.0.0.0 0.0.0.0 [1/0] via 216.110.96.1, wan
Thanks for all the responses so far! I really appreciate it.
09-07-2010 03:32 PM
Hey Bro
Can you
"logging enable"
"logging buffered 7"
run the ping from the LAN host and then do a "sh logg", we are looking for the icmp connection being built along with the xlate as the others pointed out.
It sounds like the default gateway of your hosts might be screwed...
cheers ears
09-08-2010 05:14 AM
Hi Felix,
I agree with Golly and the others--it looks like the problem may be with your default gateway/routing. Are you sure the 'show route' output looks correct? It looks like the ASA is allowing the ICMP traffic and taking the correct translation.
To confirm this, you can setup packet captures for ICMP traffic on the outside interface of the ASA:
https://supportforums.cisco.com/docs/DOC-1222
My guess is that you'll see the echo request headed out toward the Internet, but nothing coming back in.
Hope that helps.
-Mike
09-08-2010 05:22 AM
Ok. I'll do some tests with the tool and post the results.
09-07-2010 06:42 PM
Hello,
Your firewall seems to be sending data outside fine. What is the DNS server
you are using for your hosts? Please try using 4.2.2.2 as your DNS server
and see if that helps.
If you want to check ping connectivity, please try the following command:
icmp permit any echo-reply outside
Hope this helps.
Regards,
NT
09-08-2010 05:05 AM
Setting the DNS on the host to 4.2.2.2 didn't help. The host still can't ping anything outside.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide