This blog posting is building off of my previous post on ACL debugging. I am not going to go into a lot of detail for the topics covered in that blog post, so go back and take a read if you need to brush up on Cisco ASA logging.
VPN-Filtering can be hard to troubleshoot. VPN-filters are not intuitive for most Cisco folks, as the order of the source and destination fields in the ACLs are not the same as a normal ACL. That is, the remote side of the VPN tunnel is ALWAYS placed in the first IP/Subnet field (The source address in most Cisco ACLs). I swear that I’m not making this up! Feel free to take a good look at this documentation to verify that this is true.
So, other than watching hit counters, how do we know which ACL (if any) is being hit by a VPN-filter? Building off of the previous blog posting on ACL debugging, this is pretty easy to do.
At this point, generate traffic for the VPN. If the traffic matches one of your VPN-Filter rules, you should see a syslog message. I saw this:
Here we see that the remote IP address of 192.168.0.101 tried to contact a server on our side at 10.26.26.102 on TCP port 22 and the packet was permitted/allowed by access-list 110 (The VPN-filter). Additionally, we can even see WHICH ACE allowed this traffic. Notice the hex number at the end of the log message: 0x4976b668.
Grep the ACL for that hex number using the show access-list command (NOTE: NOT “show run access-list”).
access-list 110 line 1 extended permit ip any any (hitcnt=1279) 0x4976b668
Clean up – While in your session, you can turn the ssh logging messages on and off “at will” with
These syslog messages are at the Priority/Level: ERROR. So, depending on how you are logging and at what level, you may wish to remove the log keyword from your ACL. Again, this can be done without removing or otherwise interrupting any network flows. To remove the LOG keyword, modify each ACL with “LOG default”:
And, if you wish, stop the ssh session from monitoring the logging list:
Commands without comment: