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 …..
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.
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.
- Establish 2 networks (physical or VLAN based) with different Internet access (directly through ISP or via VPN provider);
- Establish a single network and route out based on source/destination addresses and protocol (this require, to my knowledge 2 routers)
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 diagramThe 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:
- Set the computers to use the access router as their default gateway (router);
- 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);
- (Optional) Policy Route traffic, meant for the VPN, from the other inside network to the NAT Router using the next hop set clause;
- (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.
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 configurationIt’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.
- 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.
ProcessWhile 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.
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 🙂