In an earlier article, I discussed filtering traffic inside VPN tunnels on the Cisco ASA using the vpn-filter command. In this article, we will discuss how this can be done on Cisco IOS routers, comparing earlier versions of the Cisco IOS and the newer IOS versions.
Prior to IOS 12.3(8)T
Before IOS 12.3(8)T, VPN traffic was subjected to the ACL check on the outside interface in the following ways:
Just before encryption, traffic to be encrypted (still in clear-text) is checked against the outbound access list on the outside physical interface.
Just after decryption, traffic from the VPN tunnel (in clear-text) is checked against the inbound access list on the outside physical interface.
This means that, prior to IOS version 12.3(8)T, if we had an ACL on the outside physical interface, the traffic to be protected by the VPN also needed to be explicitly permitted in such ACL. This is similar to using the sysopt connection permit-vpn command on the ASA. You can refer to this document for an example of an L2L VPN configuration on such older IOS.
IOS 12.3(8)T and Beyond
With the newer versions of the Cisco IOS, there are changes to how VPN traffic is subjected to the ACLs on the outside interface:
The clear-text VPN traffic (just before encryption and just after decryption) does not need to be explicitly allowed on the ACLs applied on the outside interface anymore.
However, encrypted VPN traffic (ESP or AH) must still be allowed on the outside interface ACLs.
You can now apply ACLs under the crypto-map to check clear-text VPN traffic.
These changes are similar to how the ASA handles VPN traffic with the default no sysopt connection permit-vpn and vpn-filter commands. The diagrams below, available from Cisco, explain how VPN traffic is checked by the various ACLs on these newer IOS versions:
Let’s use the diagram below to illustrate this concept. In our example, we want to create a VPN tunnel between SITEA-RTR and SITEB-RTR to protect traffic between 10.1.1.0/24 and 10.2.2.0/24:
The GNS3 topology is as shown below:
The basic configuration for L2L VPN on routers SITEA_RTR and SITEB_RTR is as follows:
hostname SITEA_RTR ! crypto isakmp policy 10 encr 3des hash md5 authentication pre-share ! crypto isakmp key cisco address 192.0.2.2 ! crypto ipsec transform-set MYSET esp-3des esp-md5-hmac ! crypto map MYMAP 10 ipsec-isakmp set peer 192.0.2.2 set transform-set MYSET match address VPNACL ! interface FastEthernet0/0 ip address 203.0.113.2 255.255.255.252 crypto map MYMAP ! interface FastEthernet0/1 ip address 10.1.1.1 255.255.255.0 ! ip route 0.0.0.0 0.0.0.0 203.0.113.1 ip route 10.2.2.0 255.255.255.0 FastEthernet0/0 192.0.2.2 ! ip access-list extended VPNACL permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
hostname SITEB_RTR ! crypto isakmp policy 10 encr 3des hash md5 authentication pre-share ! crypto isakmp key cisco address 203.0.113.2 ! crypto ipsec transform-set MYSET esp-3des esp-md5-hmac ! crypto map MYMAP 10 ipsec-isakmp set peer 203.0.113.2 set transform-set MYSET match address VPNACL ! interface Loopback0 ip address 10.2.2.2 255.255.255.0 ! interface FastEthernet0/0 ip address 192.0.2.2 255.255.255.252 crypto map MYMAP ! ip route 0.0.0.0 0.0.0.0 192.0.2.1 ip route 10.1.1.0 255.255.255.0 FastEthernet0/0 203.0.113.2 ! ip access-list extended VPNACL permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255
Now let’s assume that we only want to allow specific traffic to flow through the VPN tunnel. For example:
Host 10.1.1.10 should be able to open telnet connections to the 10.2.2.0/24 network.
Host 10.2.2.2 should only be allowed to open web connections to 10.1.1.10.
ICMP should be allowed in both directions
All other traffic should be denied and logged.
What we will do is create ACLs on SITEA_RTR to fulfill these requirements and then apply those access lists under the crypto map using the set ip access-group command. What makes this command better than the vpn-filter command that is available on the Cisco ASA is that it can be applied in any direction: inbound, outbound or both.
ip access-list extended CRYP_MAP_ACL_OUT permit tcp host 10.1.1.10 10.2.2.0 0.0.0.255 eq 23 permit icmp 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255 permit tcp host 10.1.1.10 eq 80 host 10.2.2.2 deny ip any any log ! ip access-list extended CRYP_MAP_ACL_IN permit tcp host 10.2.2.2 host 10.1.1.10 eq 80 permit icmp 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255 permit tcp 10.2.2.0 0.0.0.255 eq 23 host 10.1.1.10 deny ip any any log ! crypto map MYMAP 10 ipsec-isakmp set ip access-group CRYP_MAP_ACL_OUT out set ip access-group CRYP_MAP_ACL_IN in
Notice what I did in the ACLs, especially if you are applying ACLs in both directions: you need to think of the return traffic because these ACLs are stateless. For example in the CRYP_MAP_ACL_OUT access list, I permitted the return HTTP traffic from 10.1.1.10 to 10.2.2.2. Also, in the CRYP_MAP_ACL_IN access list, I permitted the return telnet traffic from 10.2.2.0/24 to 10.1.1.10.
Let’s test out our configuration. Keep in mind that any IP traffic from 10.1.1.0/24 to 10.2.2.0/24 will bring up the IPsec tunnel; the crypto map ACLs will only take effect after the tunnel is up. So if we open an HTTP connection from 10.1.1.10 (SITEA_LAN) to 10.2.2.2, which is not allowed by the crypto map ACL, the connection will be denied but the tunnel will still be brought up:
If we check SITEA_RTR, we will see that the VPN tunnel was brought up, but the ACL applied on the crypto map denied the connection:
With the tunnel up, we can test the other requirements that we have. First we will check that 10.1.1.10 can open a telnet connection to 10.2.2.2.
When we check the counters on the access list, we see that telnet traffic permitted:
Next we will check that 10.2.2.2 can open an HTTP connection to 10.1.1.10:
We can also see the counters increase on the crypto map ACL applied on SITEA_RTR:
Finally, we can test ICMP between the protected subnets:
We already saw that other traffic is not permitted when we tested the HTTP connection from 10.1.1.10 to 10.2.2.2 that brought up the VPN tunnel.
Before we end this article, I will like to show you that encrypted packets (ESP or AH) still need to be permitted on the ACLs applied on the outside physical interface. For example, I will deny ESP packets on the Fa0/0 interface of SITEA_RTR and we will see that even the ICMP traffic that was working before is now denied.
ip access-list extended PHYS_OUT_INT_OUT deny esp any any permit ip any any ! interface FastEthernet 0/0 ip access-group PHYS_OUT_INT_OUT out
Now if I ping again between the hosts, the traffic will not go through:
In this article, we have looked at how interface ACLs affect VPN traffic in pre- and post- Cisco IOS 12.3(8)T. We have also seen how to filter traffic inside site-to-site VPN tunnels on Cisco routers using the set ip access-group command available in Cisco IOS 12.3(8)T and later. This command can be set in the inbound direction, outbound direction or both.
I hope you have found this article informative.
Crypto Access Check on Clear-Text Packets: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dplane/configuration/15-mt/sec-ipsec-data-plane-15-mt-book/sec-crypto-ac-clrtxt.html