ASA IPsec VPN filters explained

There is a standard ACL that we use to control the ingress and egress traffic of an interface on the ASA firewall. When it comes to IPsec VPN there are vpn-filter ACLs that can be used additionally (or instead) to control the traffic on a more granular basis.

Problem

How does a vpn-filter (VPN filter ACL/VPN filter access list ) works and how it is different from a standard ACL.

Solution description

The way the ASA is processing and applying the standard ACL is different from how vpn filter ACL (vpn-filter ACL) work.

Normally when defining the VPN filter ACL rules you will specify them in this format:

access-list <acl-no> <permit/deny> ip <remote network> <local network>

where,
 - local network are the FW local segments or segments we want a VPN client to have access to
 - remote network is the network the VPN traffic (or the VPN user traffic) is coming from

Below are some extracts from available documentation I found:

Description from various documentation links:

• PIX/ASA 7.x and Later: VPN Filter (Permit Specific Port or Protocol) Configuration Example for L2L and Remote Access

When you construct the ACLs for use with the vpn-filter feature the ACLs are constructed with the post-decrypted traffic (inbound VPN traffic) in mind. However, they are also applied to the traffic originated in the opposite direction.

• Configuring Tunnel Groups, Group Policies, and Users from Cisco ASA 5500 Series Configuration Guide using the CLI, 8.3

A vpn-filter command is applied to post-decrypted traffic after it exits a tunnel and pre-encrypted traffic before it enters a tunnel. An ACL that is used for a vpn-filter should NOT also be used for an interface access-group. When a vpn-filter command is applied to a group policy that governs Remote Access VPN client connections, the ACL should be configured with the client assigned IP addresses in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.

When a vpn-filter command is applied to a group-policy that governs a LAN to LAN VPN connection, the ACL should be configured with the remote network in the src_ip position of the ACL and the local network in the dest_ip position of the ACL.

• vpn-filter from Cisco ASA 5500 Series Command Reference, 8.2

By design, the vpn-filter feature allows for traffic to be filtered in inbound direction only. The outbound rule is automatically compiled.

• VPN-Filter v Interface ACLs on ASA 5525

What you also have to consider especially with L2L VPN Filter ACL is that their format is different from interface ACL and Client VPN Filter ACL.

In the L2L VPN Filter ACLs you ALWAYS define the source address as the "remote network". This creates every now and then confusion on how the rules should actually look like. I also potentially allows more traffic than you want as the single ACL rule is bidirectional.

• ASA unidirectional VPN tunnel

The ASA has this strange little thing called a filter list.  It is basically an acl that works in both directions for vpn traffic.  The challenge is that it is one acl that works in both directions.  So the granularity is limited a bit, but you can control things based on the tcp/udp port.

• VPN-filter question in 8.2.3 or 8.3.2

Well firstly the group-policy and hence the vpn-filters will take effect only after tunnel comes up. So you would not be able to restrict what traffic brings up the tunnel using vpn-filters.

Conclusion and things to remember 

1. The vpn-filters work on top of crypto domain; you need to first define an interesting traffic to bring tunell up in crypto domain and later it can be more filtered by the VPN filters
2. Single VPN filter ACL is stateful (once a rule allows the traffic through the return traffic will be allowed as well)
3. But for every single VPN filter ACL the ASA engine will create another implicit ACL rule; the 2th rule will permit the other peer to initiate traffic and sent it over VPN tunnel
4. You define the vpn-filter rule from the remote FW perspective; on our FW the vpn filter inspect the ingress traffic; once the decrypted packet enters FW and is encrypted the src and destination and ports are checked by our filter
5. VPN filters are not checking egress VPN traffic (how to inspect an encrypted traffic any way)
6. The FW incoming traffic on its local networks is controlled by the implicit VPN filter rules
7. In another words the vpn filter control explicitly packets AFTER they are decrypted by the FW and the implicit FW rules control the traffic BEFORE it enters the tunnel; even if you want to filter only the traffic BEFORE it enters the VPN you need to specify the explicit AFTER VPN filter instead
8. The vpn filter control the in and out VPN traffic in the same time; you can't have 2 VPN filters configured 
9. Changes to the VPN filter using DENY statements take affect immediately
10. Changes to the VPN filter using the PERMIT statements requires the tunnel to be restarted

References

1. http://www.alfredtong.com/cisco/cisco-asa-vpn-filter-tips-and-misc/
2. http://netribe.blogspot.co.uk/2009/03/these-cisco-asa-vpn-filters-could-trip.html