cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2968
Views
9
Helpful
5
Replies

asa 106001 error most likely due to interface subnetting issue..

will
Level 3
Level 3

Hi, I have a slew of 106001 messages coming into ASA log, from the outside interface. it appears like most of them are for standard traffic, such as TCP 80/443. i suspect these messages are from clients on the inside who have initiated connections to the internet, but then the client abruptly terminates application of something similar. Server side finally issues a close connection, reset or something else. Here is an example, with the ASA address being 1.1.1.195 (changed to protect the innocent ).

2Sep 17 201216:38:30106001208.85.46.21801.1.1.19521936Inbound TCP connection denied from 208.85.46.21/80 to 1.1.1.195/21936 flags RST ACK on interface BORINETFW


The reason - I think - these messages are being generated en masse is because of a peculiar subnetting design, whereby the asa outside interface is:

1.1.1.228 255.255.255.240  (subnet range is 1.1.1.224-.239)

the nat IP on the outside interface is 1.1.1.195. The outside router routes 1.1.1.192 /28 to the firewall. Hence the NAT ip is outside of the range of the firewall interface. This is a design used to aggregate multiple other firewalls into the same subnet, but have each firewall's working range of IP's be in a different chunk of the 1.1.1.0/24 space.

Another theory is that the NAT ip for clients is different than the actual interface IP, so that is behaving differently. For example, once the xlate times out, the IP used for the xlate is no longer active and any return packets to the interface would also error out - be refused. If the xlate was using the interface IP, that it would always respond in some way?

Any ideas, or ways to deal with this? I can bump 106001 down to notification (5) or informational (6) level. But it seems worthy to keep them in case there is a real problem.

thx in advance,

Will

5 Replies 5

Julio Carvajal
VIP Alumni
VIP Alumni

Hello Will,

What version are you running?

If you are running any version lower than 8.4.3 then you will be fine regarding to the subnet design as the ASA will proxy arp any NAT ip being used.

The logs look normal so it will depends on you if you would like to keep receive them or not, you could change the severity level as you suggested but that will depend on you.

Regards,

Julio

Any other question..Sure.. Just remember to rate all of my answers.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

hi julio, i am running asa 8.2.5. Will eventually upgrade to 8.4.4 or higher. I believe i can configure that version to proxy arp for the NAT ip as well, correct? I hope there are no problems lurking? Also, why would cisco make this a critical level alert (ASA-2)? Seems like with the volume of these and the fact that they are insignificant, i could ignore them. Still dont know exactly what is causing this: different subnets or the different NAT ip than interface primary ip?

Hello Will,

No, on asa 8.4.3 and higher versions they ASA will not proxy arp any ip address that is not attached to it's interface. To make this work you could point a static route to that ip address poinging to the ASA MAC add. on the modem

Right now you are getting this messages because the ASA has no entry  on it's stateful table for that particular connection. As simple as that. He is doing it's job.

The connection was already closed for this connection:

Inbound TCP connection denied from 208.85.46.21/80 to 1.1.1.195/21936 flags RST ACK on interface BORINETFW

And the ASA received a RST ACK packet so he drop it.

Any other question..Sure.. Just remember to rate all of my answers.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

hi julio, thx for answers, that helps. I have duplicated this with an external website using my internal machine to NAT to outside. It seems like when i close my browser for the website, it issues a FIN to the website. the website issues a FIN ACK back. but by the time the FIN ACK reaches the firewall's NAT IP, it has closed the connection. is there a way to leave this connection open a bit longer, like 5 seconds, in the hope that it would eliminate the bulk of these messages? thx again, Will

Hello Will,

Sure, My pleasure to help

hmm nope! that is how the ASA algorithm works. He will close it inmediatly for security purposes.

That is why you should consider to keep monitoring those messages or ignore them I would say all the syslog messages related to connection being denied by the ASA are important so I would keep them but I will send them to a syslog server That for sure..

If you do not have any other question please mark the question as answered,

Regards,

Julio

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: