07-26-2012 03:42 PM - edited 03-11-2019 04:35 PM
Switching out a 5510 as our primary firewall with a 5520. I've essentially copied the working config from the 5510, and put it on to the 5520, making small changes where necessary. Plug everything. I cannot get out to the internet.
Facts:
-All interfaces have no shut on them
-No machine can ping out to the internet gateway
-All machines can ping out to the inside interface of the firewall
-It's not a problem with the internet because I can take a laptop, enter in our outside interface information, plug it into the internet gateway, and I can get out to the internet just fine.
What's going on with my device?
Attached is a sanitized config.
07-26-2012 04:05 PM
I've also attempted to power cycle the internet gateway eventhough it's working. Pinging on the local LAN works fine by name (not even to my 2 remote sites who communicate with this site via other means) so DNS is not an issue. Just attempted to shut the outside interface off for a minute or two, then bring it back up. Not hopeful for that "fix" to work.
07-26-2012 04:21 PM
Packet Tracer statements:
OUTSIDE INT TO INTERNET GATEWAY
SiteA-Firewall# packet-tracer input outside icmp 73.13.198.210 0 0 73.13.198.209
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 73.13.198.208 255.255.255.240 outside
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
INSIDE INT TO INSIDE NETWORK
SiteA-Firewall# packet-tracer input inside icmp 11.255.1.1 0 0 11.2.1.29
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 11.2.1.0 255.255.255.0 management
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: management
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
Mini-rant: This is why I don't trust packet tracer statements by themselves because I know for a fact the inside interface can ping to that computer's IP address. Proof:
SiteA-Firewall# ping 11.2.1.29
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 11.2.1.29, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
So unless I misunderstand how to word them, I'm not sure why the packet-tracer command is even in the hardware.
/Mini-rant over
07-26-2012 04:44 PM
All relevant interfaces are up and up.
Tried pulling the ACL attached to the outside interface completely off. Pings still did not go through. Tried just putting in the line that permits pings. Pings still did not go through. So I'm guessing from that it's not a ACL issue.
Any suggestions?
07-26-2012 06:26 PM
Started pinging the internet gateway from a normal network PC, the email server, and the RDP server.
Ran these commands for a capture:
capture cap1 access-list captest1 interface outside
access-list captest1 extended permit ip host 73.13.198.209 host 73.13.198.210
access-list captest1 extended permit ip host 73.13.198.210 host 73.13.198.209
access-list captest1 extended permit icmp host 73.13.198.210 host 73.13.198.209
access-list captest1 extended permit icmp host 73.13.198.209 host 73.13.198.210
SiteA-Firewall# sh capture cap1
1: 20:51:23.284958 73.13.198.210 > 73.13.198.209: icmp: echo request
2: 20:51:28.292755 73.13.198.210 > 73.13.198.209: icmp: echo request
3: 20:51:33.284958 73.13.198.210 > 73.13.198.209: icmp: echo request
4: 20:51:38.295227 73.13.198.210 > 73.13.198.209: icmp: echo request
5: 20:51:43.284988 73.13.198.210 > 73.13.198.209: icmp: echo request
6: 20:51:48.292801 73.13.198.210 > 73.13.198.209: icmp: echo request
7: 20:51:53.285080 73.13.198.210 > 73.13.198.209: icmp: echo request
8: 20:51:58.292862 73.13.198.210 > 73.13.198.209: icmp: echo request
9: 20:52:04.349225 73.13.198.210 > 73.13.198.209: icmp: echo request
10: 20:52:09.291351 73.13.198.210 > 73.13.198.209: icmp: echo request
11: 20:52:14.283569 73.13.198.210 > 73.13.198.209: icmp: echo request
12: 20:52:19.291336 73.13.198.210 > 73.13.198.209: icmp: echo request
13: 20:52:24.283600 73.13.198.210 > 73.13.198.209: icmp: echo request
14: 20:52:29.291504 73.13.198.210 > 73.13.198.209: icmp: echo request
15: 20:52:34.283691 73.13.198.210 > 73.13.198.209: icmp: echo request
16: 20:52:39.291473 73.13.198.210 > 73.13.198.209: icmp: echo request
17: 20:52:44.299300 73.13.198.210 > 73.13.198.209: icmp: echo request
18: 20:52:49.291504 73.13.198.210 > 73.13.198.209: icmp: echo request
19: 20:52:54.299300 73.13.198.210 > 73.13.198.209: icmp: echo request
Killed all pings. Started pinging from the normal network PC:
20: 20:53:18.764746 73.13.198.210 > 73.13.198.209: icmp: echo request
21: 20:53:23.300948 73.13.198.210 > 73.13.198.209: icmp: echo request
22: 20:53:28.293212 73.13.198.210 > 73.13.198.209: icmp: echo request
23: 20:53:33.301025 73.13.198.210 > 73.13.198.209: icmp: echo request
24: 20:53:38.293258 73.13.198.210 > 73.13.198.209: icmp: echo request
25: 20:53:43.301116 73.13.198.210 > 73.13.198.209: icmp: echo request
Killed the normal PC ping, started pinging from Email server: nothing
Killed the email server ping, started pinging from RDP server: nothing
What does this tell me? Pings seem to be going through in some form. And that I'm going to have problems getting the E-Mail and RDP servers working even if I get the internet working.
Thoughts?
07-26-2012 06:27 PM
Pulled the access-list off the inside interface. Pulled off nat-control. No change.
07-26-2012 06:49 PM
Trace routes from PC, Email server, and RDP server all stop at the router. But again, they can all ping the inside interface of the firewall.
07-26-2012 07:27 PM
I'm going to try switching the outside interface to another port on the firewall. If no one else has any suggestions by then and it doesn't work, I need to switch out to the old firewall and get it working for tomorrow.
07-26-2012 07:33 PM
Applied "permit icmp any any" ACLs to both interfaces. No change, definately not the ACLs then.
07-26-2012 08:17 PM
Attempting to put the old one back in place now. No luck with the new one.
07-26-2012 08:36 PM
Old Firewall back in. Internet working. RDP and Email aren't working now though.
07-27-2012 02:04 AM
When you replace the Firewall, do 'clear arp' (or reload) on both upstream & downstream neighbors connected to firewall. As long as your config is fine- that should work.
hth
MS
07-27-2012 03:33 AM
Hi Adam,
Your inside interface is having the below configuration
nameif inside
security-level 100
ip address 11.255.1.1 255.255.255.252
!
which has the /30 subnet. If this is the case the you will be having the core switch which will be your default gateway for your enduser machine.
Also I do see your SMTP/RDP in inside segment which needs to be routed locally. If this comes in to firewall then we need to do hairpinning. But you local address of smtp and rdp sits in 11.2.1.0/24 where you have your management vlan. You need to have the routes for inside zone as well specific to the subnets. So we need to shape it in such a way to work it.
Best thing you can do a compare configuration using compare it tool which is a free ware available.
Please do rate for the helpful posts.
By
Karthik
07-27-2012 01:31 PM
This was one strange night. After talking to our monitoring company for several hours, Cisco TAC for several more hours, then our ISP for a few more hours into the early morning it looks like
1) I had a management interface that had an IP from the inside network so the ASA tried to divert inside traffic through that management interface
2) There was something wrong with the ISP's arp cache that wasn't resolving our static mapped addresses correctly.
07-27-2012 01:32 PM
Mark this one closed, however that happens.
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