In this article, we will consider a scenario where AnyConnect VPN will be configured on a Cisco IOS router on which the Zone Based Policy Firewall (ZBF) is also enabled. To find out more about the IOS Zone Based Policy Firewall, you can refer to these two articles on the Intense School site: Zone Based Firewall and Zone Based Firewall (2).
The default configuration of AnyConnect on Cisco IOS routers presents interoperability problems between AnyConnect VPN and ZBF. The issue is that when ZBF is enabled on a router, any interface that is not part of a security zone cannot communicate with other interfaces that are members of security zones. However, the virtual interface for AnyConnect VPN connections (Virtual-Access1 when one WebVPN context is defined) cannot be configured and therefore, cannot be assigned to a security zone. This presents a problem: AnyConnect VPN users cannot connect to any device in a zone.
CCNA Training – Resources (Intense)
Note: In previous IOS versions, the virtual interface for AnyConnect VPN used to be SSLVPN-VIF0. The “0” increases as you add more WebVPN contexts.
Let us try to replicate this problem using the lab setup below before we consider the solution to it.
We will create two security zones on the AnyConnect router: inside and outside. We will allow only HTTP and HTTPS from the outside to the inside zone and inspect TCP, UDP and ICMP from the inside to the outside.
The configuration on the router including ZBF and AnyConnect VPN is as follows:
aaa new-model aaa authentication login webvpn local ! username cisco secret cisco ! zone security inside zone security outside ! interface FastEthernet0/0 ip address 184.108.40.206 255.255.255.0 zone-member security outside ! interface FastEthernet0/1 ip address 192.168.10.1 255.255.255.0 zone-member security inside ! ip local pool ANYCONNECT_POOL 192.168.10.51 192.168.10.60 ! ip http server ip http secure-server ! webvpn gateway AnyConnect_RTR ip address 220.127.116.11 port 443 ssl trustpoint TP-self-signed-4279256517 inservice ! webvpn install svc disk0:/webvpn/anyconnect-linux-3.1.08009-k9.pkg sequence 1 ! webvpn context Anyconnect ssl authenticate verify all ! policy group AnyConnectPolicy functions svc-enabled svc address-pool "ANYCONNECT_POOL" netmask 255.255.255.0 svc keep-client-installed svc split include 192.168.10.0 255.255.255.0 ! default-group-policy AnyConnectPolicy aaa authentication list webvpn gateway AnyConnect_RTR inservice ! class-map type inspect match-any CMAP_INSIDE_TO_OUTSIDE match protocol tcp match protocol udp match protocol icmp class-map type inspect match-any CMAP_OUTSIDE_TO_INSIDE match protocol http match protocol https ! policy-map type inspect PMAP_INSIDE_TO_OUTSIDE class type inspect CMAP_INSIDE_TO_OUTSIDE inspect class class-default drop policy-map type inspect PMAP_OUTSIDE_TO_INSIDE class type inspect CMAP_OUTSIDE_TO_INSIDE inspect class class-default drop ! zone-pair security ZP_INSIDE_TO_OUTSIDE source inside destination outside service-policy type inspect PMAP_INSIDE_TO_OUTSIDE zone-pair security ZP_OUTSIDE_TO_INSIDE source outside destination inside service-policy type inspect PMAP_OUTSIDE_TO_INSIDE
If we check the interfaces on the router, we will see that Virtual-Access1 interface that I mentioned:
Like I said, this virtual interface is not configurable (because there is no associated Virtual-Template interface):
Just to confirm that AnyConnect VPN users will not be able to connect to the inside network (e.g. 192.168.10.100), I will connect using the AnyConnect VPN client.
Now if I try to ping the 192.168.10.100 IP address from the VPN user, I will not get a reply even though the router can successfully ping that IP address.
If we turn on logging for firewall-dropped packets using the command ip inspect log drop-pkt, we will see the reason why the ICMP from the VPN user failed: “One of the interfaces not being cfged for zoning”.
So how do we fix this problem? We do this by creating a virtual-template interface and referencing it under the WebVPN context. Since this virtual-template interface is like any normal interface, it can be configured with several features including making it a member of a security zone.
The following configuration is what we need to make this work:
interface Virtual-Template1 ip unnumbered FastEthernet0/1 zone-member security inside ! webvpn context Anyconnect no inservice virtual-template 1 inservice
Hint: It seems there is a bug on some Cisco IOS versions that does not let the virtual-template work when applied to the WebVPN context; the SSLVPN-VIF0 or Virtual-Access1 interface continues to be used. Some IOS versions seem to work after reloading so try that; however, some don’t. I used IOS version 15.1(4)M10 and although it works, I needed to reload it.
Note: The bug link is merged incorrectly to another bug. To correctly view the details of the bug, go to the bug search main page, and type “sslvpn zbfw” in the search box. Then hover over bug CSCto91117 to view the details.
To test this configuration, I will disconnect from the VPN session and connect again.
If I check the router’s IP routing table, we will see that another virtual-access interface (not Virtual-Access1) has been cloned from the virtual-template for this VPN session and there is a static route through that interface:
Finally, if we try to ping from the VPN user, the ping is now successful:
In this configuration, we put AnyConnect VPN users in the same security zone as the internal network. However, it is also possible to create another zone for VPN users and then configure policies between the VPN zone and the internal zone.
Below is an example configuration that allows only SSH from the VPN zone to the internal (inside) zone.
zone security vpn ! class-map type inspect match-all CMAP_VPN_TO_INSIDE match protocol ssh ! policy-map type inspect PMAP_VPN_TO_INSIDE class type inspect CMAP_VPN_TO_INSIDE inspect ! zone-pair security ZP_VPN_TO_INSIDE source vpn destination inside service-policy type inspect PMAP_VPN_TO_INSIDE ! interface Virtual-Template1 zone-member security vpn
I will disconnect and reconnect for the configuration to take effect. I will first try to ping that address but since ICMP is not allowed in the policy, the ping will fail. Next I will try to open an SSH connection and since that is allowed, then I should be able to connect:
This brings us to the end of this article where we have discussed the issue faced on routers that have both AnyConnect VPN and IOS Zone Based Policy Firewall configured. To resolve this issue, we configured a Virtual-Template interface and attached it under the WebVPN context.
I hope you have found this article insightful.
References and Further reading
- AnyConnect VPN Client on IOS Router with IOS Zone Based Policy Firewall Configuration Example: http://www.cisco.com/c/en/us/support/docs/security/anyconnect-vpn-client/111891-anyconnect-ios-zbpf-config.html