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.

Dynamic NAT and no matching global

The ASA translates an address when a NAT rule matches the traffic. If no NAT rule matches, processing for the packet continues. A single dynamic NAT overload rule is created with the following commands:

nat (inside) 1 192.168.0.0 255.255.255.0
global (outside) 1 interface

Therefore any packet coming from 192.168.0.0/24 and going to the Internet, is translated to the outside interface address.

However, ASA 8.2 adds the following entries to the NAT table when you multiple active interfaces and a nat statement is defined:

match ip inside 192.168.0.0 255.255.255.0  outside any
    dynamic translation to pool 1 (192.0.2.1 [Interface PAT])
match ip inside 192.168.0.0 255.255.255.0  DMZ any
    dynamic translation to pool 1 (No matching global)
match ip inside 192.168.0.0 255.255.255.0  Guest any
    dynamic translation to pool 1 (No matching global)

It creates translation conditions for all the active interfaces, but if global statements are not defined for all of them, packets will be dropped due to "no matching global". In other words, the translation rule is not complete and the ASA cannot process the packet.
Then, if we have traffic going to networks connected to the other interfaces and translations are not required, we must create additional rules to handle exceptions (NAT exempt or NAT 0 or NONAT rules).

ASA 8.3 and later releases do not create those additional translation conditions, then NAT exempt rules for other interfaces are not required. This is a NAT table on new releases for the scenario described above:

1 (inside) to (outside) source dynamic net-192.168.0.0-24 interface

ASA 9.x features that will make you upgrade today

The latest ASA releases brought many interesting features and some of them might be really useful.

Summarization tricks

Route summarization is something really basic, but it is always useful. We can optimize ACLs with using some summarization tricks!

Site-to-Site VPN in multiple context mode (ASA 9.x)

Before configuring a Site-to-Site VPN in a multiple context mode ASA, you must assign VPN resources to the context. By default, no VPN site-to-site tunnels are allowed and you must manually configure a resource class to allow any VPN sessions, otherwise you will see the message "Tunnel Rejected: The maximum tunnel count allowed has been reached" in IKE debug outputs.

arp permit-nonconnected

You have a NAT block on your firewall but it is not a directly connected subnet. It used to work, but after upgrading to 8.4 it doesn't work anymore. What happened?

Route-based IPsec VPN with OSPF

Some time ago, I wrote an article explaining how to setup a route-based VPN on an ASA. The reader wintermute000 asked me if would be possible to use dynamic routing instead of adding static routes for any subnet that we want to be reached through the VPN tunnel. I told him it is possible, and now I'm going to show how.

NAT Exemption for intra-interface traffic

Both sites A and B have IPsec L2L tunnels to HQ ASA. Remote users send traffic to the Web through the VPN tunnels and also communicate with each other.

HQ ASA has dynamic PAT rules to translate traffic coming from remote sites using the outside interface IP address before routing the traffic to the Web. It is also configured to allow intra-interface traffic:


nat (outside) 1 10.2.2.0 255.255.255.0
nat (outside) 1 10.3.3.0 255.255.255.0
nat (inside) 1 0 0
global (outside) 1 interface
same-security-traffic permit intra-interface


For traffic coming from a higher security level interface to a lower one (outbound traffic), you don't need to create a rule to exempt returning traffic from NAT:

Source: 172.16.1.0/24 (inside)
Destination: 10.2.2.0/24 (outside)

access-list inside-nonat permit ip 172.16.1.0 255.255.255.0 10.2.2.0 255.255.255.0
nat (inside) 0 access-list inside-nonat

However, if source and destination are routed through the same interface, you need to create two ACEs, otherwise returning traffic would match the PAT rule:

Changing ISP through the outside interface

Sometimes the only way to get in to the firewall management console is through outside interface. If you have no console connection or management access to an internal interface, and you need to change the external IP address (the same used to SSH), then you have to setup SLA Monitor to recover management access after changing the external IP address.

Route-based IPsec VPN on ASA

IOS (and some appliances from other vendors) has a feature called VTI (virtual tunnel interface) that can be used to setup route-based IPsec VPNs. Therefore we just need to create a static route to reach the remote networks, without update the encryption domain (proxy ACL).

ASA doesn't support tunnel interfaces, however we still can setup route-based IPsec VPNs and that is what I am going to show.

What is the reason for the log %ASA-6-106015?

When the ASA receives a packet it checks the conn table and whether a connection entry is found for that packet, it is handled by the Fast Path and bypass the ACLs. It is true for any packet that doesn't require application inspection, otherwise it is handled by session management path or control plane path.


So what if you see the following logs:

Feb 20 2012 08:15:08: %ASA-6-302013: Built outbound TCP connection 7985447 for outside:192.168.0.35/80 (192.168.0.35/80) to inside:10.0.0.20/45494 (192.0.2.20/45494)
Feb 20 2012 08:15:38: %ASA-6-302014: Teardown TCP connection 7985447 for outside:192.168.0.35/80 to inside:10.0.0.20/45494 duration 0:00:30 bytes 0 SYN Timeout
Feb 20 2012 08:15:54: %ASA-6-106015: Deny TCP (no connection) from 192.168.0.35/80 to 192.0.2.20/45494 flags SYN ACK  on interface outside

Disabling idle timeout for specific traffic

The ASA enforces a timeout for idle connections and the default value is one hour for TCP connections. It helps to save resources and avoid overloads, but it can also crash some applications. We can disable this feature at all, but it is not a good idea as it can impact the firewall performance. Thus the best thing to do when you are running some application which you expect to have idle connections for long time is disabling the idle control for that traffic only. We can do that with Advanced Connection Settings.

How to configure MS Internet Explorer proxy settings for a Cisco VPN client

Add the proxy settings to the group policy:

asa(config)# group-policy RA_Policy internal
asa(config)# group-policy RA_Policy attributes
asa(config-group-policy)# msie-proxy server value 192.0.2.200:8080
asa(config-group-policy)# msie-proxy method use-server
asa(config-group-policy)# msie-proxy local-bypass enable
asa(config-group-policy)# msie-proxy except-list value intranet.example.com

Then assign the group policy to the tunnel group:

asa(config)# tunnel-group RA_VPN type remote-access
asa(config)# tunnel-group RA_VPN general-attributes
asa(config-tunnel-general)# default-group-policy RA_Policy

asa(config)# end

asa# wr mem

DNS Filtering

If you don't have a web filtering system, you can prevent users from accessing some web sites using HTTP inspection on ASA/PIX. However, it won't work whether they use HTTPS. So what?

Routing non-contiguous subnets on ASA (without VLSM)

How to route traffic between the wireless LAN and the internal 10.20.20.0/24 network without using VLSM?

Basic anti-spam on ASA

If you want to perform basic anti-spam to block spammers based on domain names, the following policy can help you: