ASA VPN-Filter with L2L Tunnels

[rmeans]

I need assistance understanding the how the vpn-filter command is applied to tunneled traffic.  Until recently, I was under the impression the vpn-filter command (applied in a group-policy) provided inbound access control (outside to inside) to VPN traffic after decryption.  Recently, I modify one of my VPN connections (added a phase 2 access-list entry) which causes me to question how the vpn-filter works.

Example -

original vpn connection - my side hosted the server and the clients were on the other side.  My vpn-filter rule allowed the clients to come to my server.

addition - (above original setting still in place) - the other side is now hosting a server and my side has clients.

Without any vpn-filter changes I experienced:  phase 2 tunnel built but no encryption or decryption packets and no syslog errors.

Using packet-tracer I discovered an access-list (subtype vpn-user) was blocking access.  "vpn-user" must be a Cisco term because it is not in my config.  I added an entry to my vpn-filter acl allowing their server to talk to my clients.  The addition to the vpn-filter allowed the tunnel began working.

I would have thought

the vpn-filter acl would have been stateful and not required an entry

or

the without the vpn-filter acl, the phase sa would have shown encryption/decryption and maybe a acl deny message in the syslog.  Basicly the traffic is encrypted, comes back from server, decrypted then dropped by access policy.

Any have any further explanation or documentation?

Thanks

Rick

[Federico Coto Fajardo · Accepted solution]

Rick,

The problem is that the ACL applied with the vpn-filter is not stateful.

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.

Caution should be used when constructing the ACLs for use with the  vpn-filter feature. The ACLs are constructed with the post-decrypted  traffic in mind. However, ACLs are also applied to the traffic in the  opposite direction. For this pre-encrypted traffic that is destined for  the tunnel, the ACLs are constructed with the src_ip and dest_ip positions swapped.

More information here:

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/vpn_groups.html

Hope it helps.

Federico.

[spoofneted]

Thanks very much for this - life saver!

I had the same issue, which was made more confusing as the Crypto Map that matches the traffic to be encapsulated needed to be specified in the "Normal" way, where the ACL Src is the actual Local Network.

The fix for me (bizarre Cisco logic) was:

• IPsec VPN configured on outside interface
• Crypto Map matching Local Encryption Domain (inside) as Src / Remote Encryption Domain (other side of IPsec) as Dst
• VPN Filter (Group Policy ACL) matching Remote Encryption Domain (other side of IPsec) as Src / Local Encryption Domain (inside) as Dst

The discord between direction in Crypto Map (to match traffic into IPsec) and VPN Filter (Group Policy, as ASDM calls it) is senseless.