09-17-2012 01:50 PM - edited 03-11-2019 04:55 PM
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 ).
2 | Sep 17 2012 | 16:38:30 | 106001 | 208.85.46.21 | 80 | 1.1.1.195 | 21936 | Inbound 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
09-17-2012 03:45 PM
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.
09-17-2012 03:50 PM
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?
09-17-2012 04:02 PM
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.
09-17-2012 04:42 PM
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
09-17-2012 04:48 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide