06-05-2014 02:22 AM - edited 03-11-2019 09:17 PM
I start noticing that I do not see any denied traffic coming in on my ACL. To better explain, lets say I have this config.
### Sample Config ###
!
object network webserver
host 192.168.1.50
nat (dmz, outside) static X.X.X.X service tcp www www
!
access-list inbound extended permit ip any4 object webserver eq www
!
If I generate a traffic from the outside let's say a traffic that is trying to access X.X.X.X via TCP Port 8080 which obviously does not have any NAT entry to it going to my DMZ, I don't see the ACL denies it anymore but instead comes back with a Drop Reason: (nat-no-xlate-to-pat-pool) . On the packet trace I got this. (Below) it seems that does not even hit the ACL as there is no xlate found for it, at least to what the drop reason says.
Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
MAC Access list
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 Outside
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: (nat-no-xlate-to-pat-pool) Connection to PAT address without pre-existing xlate
Before, using a regular Static PAT on ASA Versions 8.2(5) below, I could get the deny logs (ASA-4-106023). Generally, I use these logs, and are quite important for us specially during auditing.
My question is how can I generate logs for these type of dropped traffic on the ASA 9.1 Version?
Any comments/suggestions are gladly appreciated :)
Regards,
John
06-05-2014 03:26 AM
I believe, but am not 100% sure, that the reason you are not seeing the ACL drop but a no NAT matched is because of the changes from 8.2 to 8.3 in the order of how things are done. In 8.3 and later you need to secify the real IP address when allowing packets in, and this is because NAT happens before the ACL is matched. So since there is no match on the NAT the packet is dropped then and there, never reaching the stage where ACLs are checked.
As to seeing drops in the ACL log...You might want to try adding an ACL that matches the NATed IP...but I don't think you will have much success with that either. My guess is that there is no way around this...at least no way I know of.
--
Please remember to select a correct answer and rate helpful posts
07-24-2014 11:26 PM
Hi Marius
Thanks for your reply.
Yes it seems like the order on how things gets done changed between 8.2 and 8.3.
In 8.3, you need to have the translation before it hits your ACL. I just placed a single Port Forwarding Auto-NAT to the IP I wand and now I can see hits on the ACL. It works like a honey pot right now where I can collect some Internet User Activities for Analysis.
I'm not sure if this is the way moving forward though and if this is the recommended workaround for this requirement.
I hope someone from Cisco can help us out if there is a better way with this.
Regards,
John
07-25-2014 02:53 AM
Hi John,
If you are presently using 9.1.x asa version, then this might be a bug.
CSCun95075
ASA drops packet due to nat-no-xlate-to-pat-pool after removing NAT rule
Also suggested to use a different object statements for NAT and ACL....
object network webserver
host 192.168.1.50
nat (dmz, outside) static X.X.X.X service tcp www www
!
object network webserver-acl
host 192.168.1.50
access-list inbound extended permit ip any4 object webserver-acl eq www
!
Regards
Karthik
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: