One of our Customers has a corporate network at three different locations. Let's assume:

  • location A:
  • location B: and
  • location C:

At each location a Cisco ASA creates a VPN to the others. Location A also establishes a L2TP-Tunnel to connect a remote PC which shall access some IP addresses in network B. The IP of the remote PC ( is assigned via a virtual IP pool when the PC is establishing an L2TP connection.

This part is pretty good setup. The Laptop can only access the predefined IP addresses in network B and no others due to our ACLs.

But the PC can access ALL networks on location A - the location where it's L2TP-Tunnel ends up. We also created ACLs for ingoing and outgoing interfaces. But my thought is, since the virtual IPs are something internal of the ASA, you cannot put any ACL on it.

So the question is: How can I deny the acces from the remote PC ( to location A ( (and keep the connection to location B active (

  • It sounds like you need a vpn-filter in your group-policy. See cisco.com/c/en/us/support/docs/security/… – hertitu Apr 21 '18 at 6:48
  • This vpn-filter looks like an usual access-list. But these don't work in this case. Or am I wrong? – Phil Apr 23 '18 at 7:23
  • I see now that the doc referred to is not really clear , sorry. After specifying the accesslist you need to apply it in the group-policy using the vpn-filter command. Maybe have a look at this : cisco.com/c/en/us/support/docs/security/… – hertitu Apr 25 '18 at 21:07
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 25 '18 at 8:22

There are at least three ways I can think of to fix this issue, and I would attempt a solution in the following order:

  1. Craft your NAT statements differently (or remove the applicable NAT) so that the VPN clients do not have a static NAT when talking with location A. This would effectively cause the traffic to get NATted and would break it.
  2. Apply the vpn-filter command to the group policy of the tunnel. This ACL only gets evaluated in the inbound direction, when traffic arrives from the client. It doesn't affect traffic going out to the client.
  3. Change the default way the ASA handles encrypted traffic, and use your regular ACLs to do the job.

Specifically to number 3, here are some more details:

By default, a Cisco ASA will treat any successfully decrypted VPN traffic (any tunnels that it terminates) as inherently trusted, akin to security level 100 (but the traffic doesn't really have a security level). What I would do in your situation is disable that default behavior so the VPN traffic is subject to all normal ACLs just like normal traffic. To do this, there are 3 steps:

  • Add ACEs to the outside ACL that permit the VPNs to build. This would include permitting ISAKMP (udp 500 and 4500) and ESP (IP proto 50).
  • Add ACEs to the outside ACL that permit the traffic within the tunnels to flow. This would include permitting to reach
  • Issue the no sysopt connection permit-vpn command, which disables the default behavior of trusting all decrypted VPN traffic.

You should definitely test this solution in the lab before implementing it so that you're comfortable with how it works, and so that you make sure you've got all your ACLs covered.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.