5510 5520 internet problems

Unanswered Question
Jul 26th, 2012
User Badges:

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Adam Hudson Thu, 07/26/2012 - 16:05
User Badges:

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.

Adam Hudson Thu, 07/26/2012 - 16:21
User Badges:

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

Adam Hudson Thu, 07/26/2012 - 16:44
User Badges:

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?

Adam Hudson Thu, 07/26/2012 - 18:26
User Badges:

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?

Adam Hudson Thu, 07/26/2012 - 18:27
User Badges:

Pulled the access-list off the inside interface. Pulled off nat-control. No change.

Adam Hudson Thu, 07/26/2012 - 18:49
User Badges:

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.

Adam Hudson Thu, 07/26/2012 - 19:27
User Badges:

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.

Adam Hudson Thu, 07/26/2012 - 19:33
User Badges:

Applied "permit icmp any any" ACLs to both interfaces. No change, definately not the ACLs then.

Adam Hudson Thu, 07/26/2012 - 20:17
User Badges:

Attempting to put the old one back in place now. No luck with the new one.

Adam Hudson Thu, 07/26/2012 - 20:36
User Badges:

Old Firewall back in. Internet working. RDP and Email aren't working now though.

mvsheik123 Fri, 07/27/2012 - 02:04
User Badges:
  • Gold, 750 points or more

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

nkarthikeyan Fri, 07/27/2012 - 03:33
User Badges:
  • Gold, 750 points or more

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

Adam Hudson Fri, 07/27/2012 - 13:31
User Badges:

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.

Actions

This Discussion

Related Content