In the previous articles, we have focused on building VPN tunnels between the Cisco ASA and a Cisco router. We took an in-depth look at the two IKE phases (IKE phase 1 and 2) and also considered the different modes in these phases, including Aggressive Mode, Main Mode and Quick Mode. We also considered two different authentication methods; Pre-shared keys and RSA signatures.

In this article, we will be looking at VPN traffic filtering. We will fall back to our default network diagram/configuration using pre-shared keys.

Question 1: Why is VPN traffic not subject to access list check?

The first question we want to address is “Why is VPN traffic not subjected to an access-list check?” Let me first establish some things. I have brought up the VPN tunnel and I can ping from the IOS router to the host behind the ASA as shown below.

Now, if we go back to the basics of the Cisco ASA, this connection should not be permitted by default because traffic is flowing from a lower security level interface (the IOS router is on the outside interface with security level of 0) to a higher security level interface (the host is connected on the inside interface of the ASA on a security level of 100). As shown below, I have not applied an access-list on the ASA to permit this connection. The only access-list on the ASA is the one matching VPN interesting traffic.

Why then is this traffic passing through unhindered? It is because of a default command on the ASA: sysopt connection permit-vpn. Keep in mind that this command is in the default configuration and will not show up in your normal running configuration. For example, if you issue “show run sysopt“, you will not see it.

However, if you issue the “show run all sysopt” command, it will show up.

Let’s take a look at the help for this command and see what it actually does.

It answers the question we are addressing in this section; this default configuration exempts VPN traffic from access check. What happens if we remove it?

Let’s ping again from the IOS router.

Notice that even though the VPN tunnel is still up, the ping traffic now fails. This is because VPN traffic is now subjected to an access check and since the connection is not explicitly allowed, it will be dropped. It is a good thing to leave that setting turned on; which brings us to our next question.

Question 2: Is it then possible to restrict VPN traffic without tampering with the default configuration?

Luckily for us, yes, there is another way. However, before we can look at this method, we must first consider group policies. If you remember, in the first article about Cisco ASA VPN series, we introduced group policies as a set of user-oriented attribute/value pairs for IPSec connections. By configuring and applying group policies, you have more flexibility over VPN tunnels.

In that article, we also mentioned that there is a default group policy called “DfltGrpPolicy”. We can view that group policy using the “show run all group-policy” command. It is quite long but I will paste a snippet here:

Notice that because it is a default configuration, issuing the show run command without the “all” command will not show anything. At this point, I want to show you that the tunnel-group we configured automatically uses the default group policy because we did not explicitly configure another group policy for it.

This is also an implicit (default) configuration and it also would not show up if you don’t add the “all” keyword to your show run command. This tells us that our tunnel-group uses the settings in the default group policy. This default group policy is made very generic and it may not be suitable for your purposes. In that case, you have two options: edit the default group policy or create your own.

The cool thing about group policies (and connection profiles on the ASA in general) is that you don’t have to configure all attributes: any attribute you do not explicitly configure in your group policy will be inherited from the default group policy.

To answer our question then, we can use an attribute (vpn-filter) under the group policy configuration and apply this group policy (if it is not the default group policy) to our tunnel group.

Let’s assume, for testing purposes, that we want to block all ICMP traffic through our tunnel but allow every other traffic (including Telnet). We will create a new group policy and set the vpn-filter attribute under this group policy and then apply this new group policy to our tunnel group.

Before we do that, let’s make sure we can both ping and open a telnet connection through the tunnel.

Cool! We can perform both operations. Now, let’s get to work. First, we create the access-list that denies ICMP and permits all other traffic. (Remember that ACLs have an implicit deny-all at the end so we must explicitly permit all other traffic.)

Now, we will configure our group policy. Group policies can be internal (locally define attribute values) or external (attribute values are downloaded from an external server such as a RADIUS server). We will define the group policy locally on the ASA.

Now that we have defined the group policy, we have been given an additional option to configure the attributes, which puts us into group-policy attributes mode.

We can now set the ‘vpn-filter‘ attribute under this group policy. Notice that there are two options: none (no ACL) and value (assign an ACL).

Hint: If you don’t add the “value” keyword before typing the value, you will get an error. I usually forget!

That’s all. We can now attach this group policy under the general attributes of the tunnel group.

Another hint: The “?” command is a life-saver. I sometimes go under the ipsec-attributes looking for the default-group-policy option.

Now we can test whether our configuration works. First, we’d ping from the router to the host; this should fail.

Fear not. We need to first clear the current VPN session. This tells us that a change on the group policy will take effect only at the start of a new VPN session.

Now, let’s try again.

Just to make sure the connection was not deceiving me (perhaps the VPN tunnel was still being set up); I’d issue the ping again.

Great, I was not being teased by a Cisco ASA box. We can also view the ACL hit count on the ASA.

Cool! So it works. Let’s stop here (while we have everything working).


This actually brings us to the end of this series about VPN on the Cisco ASA. In this article, we have looked at the default setting on the ASA that explicitly allows VPN traffic to bypass access list checks i.e. sysopt connection permit-vpn. For pre-7.0 ASA software versions, this command was turned off by default so it had to be explicitly enabled.

We also touched group policies and saw how we could still apply traffic filtering to a VPN connection by setting the ‘vpn-filter‘ attribute under the group policy and then attaching that group policy to the tunnel group. We only scratched the surface of group policies and perhaps in a “VPN on the ASA Advanced” series, we will look at this feature in more detail.

I hope you have found this article and the entire series worth your while and I look forward for more articles here.

Reference and helpful resource: