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

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?

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?

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

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.

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.

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

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

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

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

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

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.

Mark this one closed, however that happens.