cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1363
Views
0
Helpful
3
Replies

No ACL deny logs for Traffic not matched by Static Object NATs and ACL. Need Help.

John R
Level 1
Level 1

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

3 Replies 3

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 select a correct answer and rate helpful posts

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

nkarthikeyan
Level 7
Level 7

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

 

 

Review Cisco Networking for a $25 gift card