http behind firewall

[suthomas1]

Hello All,

Two days ago, we changed our old 525 with asa 5520 ( ver 8.2 ). Configuration is the same, except the version. It even retains the same global interface and static public ip address as the old device.

All worked well during that period.

Yesterday, one of the http applications , not tested other day, was found not to be working. To test, we switched back to the old 525 , however nothing was working when we did that.

Does the static statement which actually does the translation for this application carry any arp problems or so.

how can i check this problem.

thanks.

[ajay chauhan]

Hi,

1st- You need to check if the application is up on server.

2nd - proper nat statement is configured.

3rd- outside ACL does allow port http .

4th- you can run packet-tracer for quick check if ASA is causing any issue.

5th- you can also run packet capture for details.

Thanks

Ajay

[suthomas1]

thanks, i will check these.

Related to these, since there is a static statement for the application,

static ( app, out) 210.18.155.38 10.85.5.5

here 10.85.5.5  is the private ip of the application. Apart from this the firewall wan interface has an ip of 210.18.155.35. The interface ip will be arp'd on the upstream device which was cleared before connecting the new device.

My question is , will 210.18.155.38 ip which is used by the application, will that also have arp issues if the device is changed often to test.

Thanks.

[ajay chauhan]

Ok if you feel its arp issue then remove the static statement and put it back it will update arp next in router.

[suthomas1]

Hi,

On the new asa, the packet trace shows the reason as : Slowpath security checks failed.

I read the cisco documents for this, but there is no clear indication on how to resolve this. I've verfied no external rogue users are using it.

Please help.thank you all.

[ajay chauhan]

Well here is what i found- would you mind posting full configuration.

Name: sp-security-failed

Slowpath security checks failed:

    This counter is incremented and packet is dropped when the security appliance is:

    1) In routed mode receives a through-the-box:

       - L2 broadcast packet

       - IPv4 packet with destination IP address equal to 0.0.0.0

       - IPv4 packet with source IP address equal to 0.0.0.0

    2) In routed or transparent mode and receives a through-the-box IPv4 packet with:

       - first octet of the source IP address equal to zero

       - source IP address equal to the loopback IP address

       - network part of source IP address equal to all 0's

       - network part of the source IP address equal to all 1's

       - source IP address host part equal to all 0's or all 1's

    3) In routed or transparent mode and receives an IPv4 or IPv6 packet with same source
and destination IP addresses

Recommendation:

    1 and 2) Determine if an external user is trying to compromise the protected network.
Check for misconfigured clients.

    3) If this message counter is incrementing rapidly, an attack may be in progress. Use
the packet capture feature to capture type asp packets, and check the source MAC address
in the packet to see where they are coming from.