Which VPN tunnel matches my traffic?

When we manage a VPN concentrator with thousands of active tunnels, we might face conflicts between crypto maps. This is not so easy to realize and we might spend a lot of time before we figure out that another tunnel is forwarding our traffic.

Here are the steps that I would use to check which tunnel matches my packets.

Redirecting HTTP (TCP/80) requests to the WebVPN portal

After completing a WebVPN setup, the users access the SSL VPN portal using a web browser and going to https://fw_ip_address (or a URL mapped to the firewall address). However users are not network experts and sometimes they will forget the "https://" or even use "http://" and the ASA will reject the connection attempt.

If we want to avoid users crying about timeout pages on their browsers, we can redirect HTTP requests to the TCP port in use for the WebVPN with the following command:

asa(config)# http redirect outside http

These are the HTTP messages that we see in the wire:

Browser to ASA
GET / HTTP/1.1
Host: 192.0.2.1
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:38.0) Gecko/20100101 Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

ASA to Browser
HTTP/1.0 302 Temporary moved
Content-Length: 0
Cache-Control: no-cache
Pragma: no-cache
Connection: Close
Date: Tue, 23 Aug 2016 20:54:22 GMT
Location: https://192.0.2.1/

It doesn't matter if we are using TCP port 443 or any other for the SSL VPN portal, the ASA will redirect the browser to the right location.

debug menu

ASA command reference page does not include a detailed explanation for the debug menu command, therefore I collected the details from a device CLI. It's not recommended to use this command without TAC supervision, but some of them are really useful (check debug menu ssh). Some options might not be available on the OS version that you are running.

Enabling jumbo frames on Cisco ASA (MTU size higher than 1500)

If you want to increase the MTU size for a specific interface (enable support for jumbo frames), you need to implement the changes described bellow, but first you should check the supported models and prerequisites on Cisco ASA Configuration Guide. Note that a reboot is required

Jumbo frames should be enabled to receive packets more than 1500 MTU (this command will take effect after the running-config is saved and the system has been rebooted):
jumbo-frame reservation

TCP MSS needs to be adjusted to pass large TCP segments:
sysopt connection tcpmss bytes

Set MTU size:
mtu interface_name bytes

Analyzing logs to filter traffic that hits an access list entry

If you have a generic access rule and you want to make it more specific, you can use logs to help you on filtering sources, destinations and/or services that hit the rule.

By default, ASA only logs denied packets (message %ASA-4-106023), but we can use the log option to enable logging for specific rules.

Log messages %ASA-6-106100 and access list entries hash codes are helpful to find out what traffic matches an specific rule. Let's use the following ACL as an example:

asa# sh access-list
access-list inside line 1 extended permit tcp any any eq www log informational interval 300 (hitcnt=1) 0xaa22f669
access-list inside line 2 extended permit object-group services any any log informational interval 300 0x3d0397cc
 access-list inside line 2 extended permit icmp any any log informational interval 300 (hitcnt=0) 0x55873f33
 access-list inside line 2 extended permit tcp any any eq telnet log informational interval 300 (hitcnt=1) 0x44b661f2

The ACL has two rules and log option is enabled on both. One is a single rule and the other one uses an object-group for service definition. Note that we have a hash code for each rule, but we also have one hash code for every group member (expanded rule elements).

If we want to filter logs that match the first rule, we use the following command:

!access-list inside line 1 extended permit tcp any any eq www:
asa# sh log | i 106100.*0xaa22f669
Mar 03 2016 01:11:21: %ASA-6-106100: access-list inside permitted tcp inside/10.0.0.10(48338) -> outside/192.0.2.2(80) hit-cnt 1 first hit [0xaa22f669, 0x0]

This is a single rule, thus only one hash code is present in the log message.

If we want to find out what traffic matches the second rule, we can filter for one specific object member or the group ACE:

!access-list inside line 2 extended permit tcp any any eq telnet:
asa(config)# sh log | i 106100.*0x44b661f2
Mar 03 2016 01:12:09: %ASA-6-106100: access-list inside permitted tcp inside/10.0.0.10(44036) -> outside/192.0.2.2(23) hit-cnt 1 first hit [0x3d0397cc, 0x44b661f2]

!access-list inside line 2 extended permit object-group services any any:
asa# sh log | i 106100.*0x3d0397cc
Mar 03 2016 01:32:04: %ASA-6-106100: access-list inside permitted tcp inside/10.0.0.10(37284) -> outside/192.0.2.2(23) hit-cnt 1 first hit [0x3d0397cc, 0x44b661f2]
Mar 03 2016 01:32:54: %ASA-6-106100: access-list inside permitted tcp inside/10.0.0.10(64900) -> outside/192.0.2.2(21) hit-cnt 1 first hit [0x3d0397cc, 0x7a45343d]

Based on these log messages, we could replace the existing generic ACEs with more specific rules.