Select VPN Traffic for Cisco EZVPN

The EZVPN configuration used in the previous article forwards all incoming traffic on the VPN inside interface out to the VPN tunnel. This might be less than ideal, but discussing with Cisco TAC I found out that there is no way around it. In this article I will show how to use a second router to avoid this limitating factor and forward to the VPN only required traffic. We are originating the traffic from our fixed location and we trust(?) our ISP not to snoop, we will forward to the VPN only the traffic that will need to appear as originating from the VPN server IP.

The first question to ask ourselves is: “Why avoid sending all traffic to the VPN?”
The simple answer is performance. If we send the traffic to the VPN you need to add overhead to the packet for the ESP and/or AH headers and, using tunnel mode, an entirely new IP header. Additional illustrated details on how the IPSEC works can be found in An Illustrated Guide to IPsec by Steve Friedl. Also the different routing between your end and the VPN end might affect performance: longer routing/higher number of hops different congestion along the path …..

1615 Down 382 Up
1033 Down 314 Up

Comparative Speed Test ISP&VPN

For example these are the resulting speed test using my ISP and VPN provider.
It shows a big difference that factors in the overhead, the different routing the longer path and all of the encapsulation encryption and decryption operations that are involved in the packet handling. So for less valuable traffic we do not want to clog the VPN but use the ISP pipe directly.

And (unfortunately) here comes the sore spot of the Cisco EZVPN: the ease of configuration means (a bit of) lack of flexibility. There is no way to select what traffic goes into the VPN:

  • If it comes in from the EZVPN inside interface(s) it will go out to the tunnel;
  • If not it will be routed normally.

I did try to go around this even creating loopback interfaces as EZVPN inside interfaces and policy routed traffic to them but to no avail. Finally I opened a Cisco TAC case and the Cisco Customer Engineer confirmed that it was not supposed to work and so it does not!

The business case

Why do we need to use a router to connect a network to the VPN? We could use a client on the computer and this very easily solves the problem. You can switch it on or off at will with a few mouse clicks when you need the VPN and when not. The essence of the problem is exactly that: you need to connect a device having no VPN support. For example think of:


  • Apple TV (or Roku for the matter) connecting to an ISP without a US IP can still access Netflix or Hulu plus
  • Wii console is able to access US services (like Hulu Plus or US/otgher location only Wii channels)
  • Purchase movies or other goodies from your WebTV application no matter where your ISP is located.

Network Setup

Once you have recognized the need to use a router to connect to your VPN provider (i.e. you need to connect devices without native VPN support), how you implement the routing depends on what you are trying to achieve and what equipment you have.

Networking Options


You could:
  1. Establish 2 networks (physical or VLAN based) with different Internet access (directly through ISP or via VPN provider);
  2. Establish a single network and route out based on source/destination addresses and protocol (this require, to my knowledge 2 routers)
Solution 1 requires two networks (wired or wireless) and you connect you equipment based on where the traffic should go. Solution 2 would save on the networking equipment (access spots/cabling) and requires one more router. I choose solution 2 at home but the two require pretty much the same config, which I will illustrate below.

IP traffic: where to where?

Seeing connections to Akamai servers is clear indication of your content provider using content delivery strategies designed to distribute the load and the location of the content across the Internet. In such case it is very difficult to guess to which address your traffic will be routed. The easiest way to address the issue is to reverse the prospective: route all traffic based on the device originating the traffic (known IP of your Apple TV) and not its destination (unknown repository of your content).

Routing based on source IP rather than destination might end up sending some extra traffic to the VPN but ensures that the desired traffic is all routed to the VPN. Computers will use their VPN clients when necessary. Also this solution is flexible since you can have multiple selection criteria: both source and destination, and obtains the best of both worlds. You would be routing the known destinations automatically for all computers/devices on the network and all the traffic of the NON-VPN capable devices through the VPN. Leaving to the computers to set up their VPN tunnel when needed.



Network diagram

VPN Network LayoutVPN Network with NAT router

Network Diagram with VPN & NAT

The two diagrams to the right have the same overall functionality. The (lower) one with the NAT router allows traffic originating on the other inside network also to be sent out to the VPN Tunnel. When traffic is sent to the destination server (the lower one) is either sent encapsulated and encrypted to the VPN server (left of picture green path) and then decrypted and sent to destination or being sent directly to destination (unencrypted blue path). The difference between the two pictures is how the traffic is selected and sent out to the tunnel or the Internet. In the top one we establish 2 networks and just route out based on source network, in the bottom picture we use a second router to re-route traffic coming from the other inside network to the EZVPN inside network forcing the access router to send it to the VPN. This is achieved by:

  1. Set the computers to use the access router as their default gateway (router);
  2. Configure the access router to use the outside Internet interface as its default route (this is also required for the EZVPN to work, as indicated in a previous post);
  3. (Optional) Policy Route traffic, meant for the VPN, from the other inside network to the NAT Router using the next hop set clause;
  4. (Optional) Setup the NAT router to get its VPN inside address via DHCP, use the EZVPN inside interface address of the access router as default gateway, and NAT the packets incoming from the other router using the obtained DHCP address.
You can implement the last two steps only if you have a spare router (even old/low class as long as it has 2 interfaces or supports inter VLAN routing: you can get a nice 1721, which is what I use on eBay for 20 USD) to do the NAT part. Since all of this heavily involves default routing and multiple hops between same networks, I found it difficult to make it work on a single router (you cannot have more than one interface of a router in each network). If you figure a way to do it please let me know.
Step 1 and 2 is all you need to implement a scenario in which some equipment goes out to the VPN and some traffic goes out to the ISP directly. It is only a matter to select the network you connect to. Adding the additional router allows you to create a single network and route out according to you selected parameters:
  • Source IP (i.e. you select what equipment is routed out)
  • Destination IP (i.e. you select what services are routed out)
  • Any other parameter that can be used to select traffic in an Access-List and PBR

IOS configuration

Router Topology

Router Topology

It’s now time to sum it up and see all of the above come together. I am going to use a 1921 router and one of its GigaBit Ethernet, configured with VLANs and a 1721 also configured with VLANs to route and NAT.

Prerequisites

  • Router 1921 has internet connectivity on interface Dialer0 with public IP address
  • Router 1921 is configured for EZVPN);
  • The involved routers have a feature set supporting VLAN Routers are interconnected by VLAN able switches.

Process

While configuring the VPN we have defined an IP pool. This Pool provides the IP address space for the clients on the EZVPN Interface. We would also need an IP pool for clients on the inside interface:

Cisco 1921
ip dhcp pool easy_vpn
 network 192.168.135.0 255.255.255.0
 dns-server 192.168.128.21 192.168.1.1
 default-router 192.168.135.7
ip dhcp pool Net129
 network 192.168.129.0 255.255.255.0
 dns-server 192.168.128.21 192.168.1.1
 default-router 192.168.129.7

In the above code snippet both pools assign the default router as the 1921 router. They allocate address space in the networks of the two interfaces that are the EZVPN inside and the other inside interface. This (together with the default routing pointing to the Dialer 0 and the EZVPN setup) will cause the router

  • to send out of the VPN interface all the traffic incoming in the GigabitEthernet 0/1.5 Interface
  • to send out of the Dialer 0 Interface all traffic coming in the GigabitEthernet 0/0.2 Interface.
The following is the configuration on the 1921 Interfaces and NAT statements:

Cisco 1921 – Interface and NAT config.
interface GigabitEthernet0/1
 no ip address
 duplex auto
 speed auto
 
interface GigabitEthernet0/1.5
 encapsulation dot1Q 5
 ip address 192.168.135.7 255.255.255.0
 ip tcp adjust-mss 1400
 crypto ipsec client ezvpn witopia_IAD inside
 
interface GigabitEthernet0/0
 no ip address
 duplex auto
 speed auto
 
interface GigabitEthernet0/0.2
 encapsulation dot1Q 2
 ip address 192.168.129.7 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1400
 ntp broadcast
 
ip nat inside source route-map RM-nat-todialer0 interface Dialer0 overload

route-map RM-nat-todialer0 permit 200
 description NAT route translating Internet traffic
 description traffic to 192.168.1.x and local is negated
 match ip address 101
 
access-list 101 remark used in RM-nat-todialer0 to NAT traffic out of Di0
access-list 101 deny   ip 192.168.128.0 0.0.3.255 192.168.131.192 0.0.0.15
access-list 101 deny   ip 192.168.128.0 0.0.3.255 192.168.131.224 0.0.0.15
access-list 101 deny   ip 192.168.128.0 0.0.3.255 192.168.144.0 0.0.0.255
access-list 101 deny   ip 192.168.128.0 0.0.3.255 192.168.1.0 0.0.0.255
access-list 101 permit ip 192.168.128.0 0.0.3.255 any
access-list 101 deny   ip any any

This completes steps 1 and 2 and establishes the top configuration rappresented in the network diagram above. A brief explanation of the configuration:

  • For each interface we configure the physical parameters under the actual interface and then the VLAN parameters of the logica interface (.5 and .1)
  • We need also to configure the TCP Maximum Segment Size to avoid problems when the packets are encapsulated (PPPoE, IPSec, etc);
  • The next line will implement Policy Based Network Address Translation using as external IP address the one assigned to the Dialer 0 Interface
  • The NAT and the associated access-list are defined

Why do we use route-map based NAT? This is because whenever a translation is created based on a route map the router will create a full entry, which in turn, will avoid some issues using multiple NAT pools which is what we are going to do in a short while and also what the router does behind the scenes with the EZVPN config.


Configure the second router

To create the setup in the lower picture we need to add the second router and configure it to re-route the interesting traffic. Let’s see what we need in the 1721:

Cisco 1721 – Interface, route and NAT config.
!
interface FastEthernet0
 no ip address
 speed auto
 full-duplex
!
interface FastEthernet0.1
 encapsulation dot1Q 1 native
 ip address 192.168.128.10 255.255.255.0
 ip nat inside
 ip virtual-reassembly
!
interface FastEthernet0.5
 encapsulation dot1Q 5
 ip address dhcp
 ip nat outside
 ip virtual-reassembly
!
ip route 0.0.0.0 0.0.0.0 192.168.135.7
!
ip nat inside source list 100 interface FastEthernet0.5 overload
!
access-list 100 permit ip 192.168.129.0 0.0.0.255 any

This configuration causes any traffic incoming to the 1721, to be routed out (default routing) interface Fa0.5 which receives its IP address via DHCP and therefore out of the pool of the EZVPN client config. NAT is configured on that interface and so that traffic will be NATted to an EZVPN Pool address.

Finally we need to add Policy based routing to the 1921 so incoming traffic can be sent, based on match clauses, out to the 1721.

Cisco 1921 – PBR for rerouting
interface GigabitEthernet0/0.2
 encapsulation dot1Q 2
 ip address 192.168.129.7 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip tcp adjust-mss 1400
 ip policy route-map RM-tovpn
  ntp broadcast
!
route-map RM-tovpn permit 90
 description Applied to GigaEth 0/0.2
 description Matches traffic to be sent to Witopia VPN
 match ip address AC-tovpn2
 set ip next-hop 192.168.128.10
!
ip access-list extended AC-tovpn2
 remark Used in route map RM-tovpn applied to GigabitEth 0/0.2 (129)
 remark matching traffic is sent to 192.168.128.5 to Witopia VPN
 deny   ip 192.168.128.0 0.0.3.255 192.168.128.0 0.0.3.255
 deny   ip 192.168.128.0 0.0.3.255 192.168.1.0 0.0.0.255
 permit udp 192.168.128.0 0.0.3.255 10.0.0.0 0.255.255.255 eq domain
 permit ip 192.168.128.0 0.0.3.255 10.0.0.0 0.255.255.255
***add any permit for special handling (send to VPN) here
 permit ip 192.168.129.32 0.0.0.15 any
*** this line will match ip from 32 to 47 and forward them to the VPN
 deny   ip any any

This last bit of the configuration adds PBR to the GigabitEthernet Interface Gi0/0.2 and then the Route map matches the traffic in the access list AC-tovpn2 and sets the next hop as the 1721, which is configured to send it back to the 1921, after NAT. As indicated in the inline comment the

permit ip 192.168.129.32 0.0.0.15 any

statement matches any ipaddress in the range 192.168.129.32-47. So any device that has an IP in that range will be sent out via VPN.

This concludes this long article, but I hope I showed what a bit of configuration can achieve on dedicated hardware and why using a full routing platform has a lot of advantages, even if it requires a bit of digging in the docs.

Hope I hear from you with some improvements to my config 🙂

About Fabio

Love of technology and flying have been the drivers of my life, more about me.
Tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

Couldn't connect to server: Connection timed out (110)