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
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 :)
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
Please remember to rate and select a correct answer
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.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...