Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Slow response to network requests after ASA Install

I am attempting to cut over to an ASA 5520 from an old linux firewall. I have two other sites running the ASAs but I keep having problem after problem with this last site (mainly user error issues and I wouldn't be surprised if I end up at fault for this as well).

I cut over this evening and traffic is flowing, however, HTTP requests are very slow (oddly enough, except to cisco.com - I digress). Anyhow, any web page I attempt to view takes a very long time to load, but it does eventually load. When I say it takes a long time, it is taking more than a min to load a page (we have a 6 meg connection)

Background on network setup:

4 Data T1s bundled on a 3600 Series Router provide internet access.

Linux firewall replaced with ASA 5520

Internal LAN is a 6509 with several VLANs all routable to one another. The MSFC have a default route to the ASA. The ASA has a default route to the 3600 for outside traffic.

Upon shutting down the old Linux firewall I cleared the ARP tables on the 3600 to ensure it was talking to the ASA.

The interesting thing is that pings and trace routes all have decent response times, so I don't think there is actually a packet loss or latency issue, but HTTP requests take for ever.

I have several hosts on my lan that have static mappings for various services like DNS, Mail, etc. The rest of the traffic is going out a Global PAT rule as shown in the config attached.

The following message is scrolling through the logs repeatedly, but I cannot find anything that would be causing the issue and because its 0.0.0.0 I am not sure where to start trying to find the culprit.

Error in Log:

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

1 REPLY
New Member

Re: Slow response to network requests after ASA Install

Ok, I solved my problems. Yes there were 2.

First problem was my internal DNS server forwards unknown requests to my primary external DNS server. The problem was that the primary external DNS server had a default gateway of my old firewall that had been shut down. Don't ask - I blame the linux guys. HAHA! After fixing this and restarting DNS on my internal DNS server, HTTP requests (and thus DNS queries were performing normal and pages loading quickly).

2nd problem relates to the error:

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

%ASA-2-106017: Deny IP due to Land Attack from 0.0.0.0 to 0.0.0.0

This was being caused because I had not completed my configuration of failover and I was missing the last line of the below config entires:

failover

failover lan unit secondary

failover lan interface lanfo GigabitEthernet0/3

failover link stateful GigabitEthernet0/2

failover interface ip lanfo 10.2.0.1 255.255.255.0 standby 10.2.0.2

failover interface ip stateful 10.1.0.1 255.255.255.0 standby 10.1.0.2

because the last line was missing, I believe the interfaces were broadcasting 0.0.0.0 to one another causing the FW to log the error.

502
Views
0
Helpful
1
Replies
CreatePlease to create content