IPSec: Router and VPN Client for Public Internet on a Stick with NVI

From Internetworkpro

This page or section provides device configuration instructions

Please note that the information on this page has not been checked for accuracy and is not intended as a replacement to documentation. Please ensure you understand your desired objectives before attempting to apply any examples listed.
See more examples at Category:Configuration

This page or section provides VPN Configuration examples

The collection of articles under the VPN Category help to describe simple and complex VPN setups. These are often confusing and complicated so the Internetworkpro Wiki is attempting to create examples for many VPN setups - Site to site, remote access, automatic, one-way, ipsec, pptp, gre, vpdn, easyvpn, ssl, etc. Please ensure you understand your desired objectives before attempting to apply any examples listed. Guidance can be provided on irc://freenode.net/cisco
See more examples at Category:Configuration
See more VPN configuration at Category:VPN

[edit] Problem

For Cisco VPN Clients, you want that all the traffic - including Internet traffic - to pass through the VPN tunnel to the VPN headend (the router) and from there to the Internet.

Cisco has a configuration example for this (see below), but it is a little complicated, because it relies on an additional loopback interface and policy based routing. Because of changes in IOS 12.4 (set interface not supported for non-P2P interfaces anymore), you might run into trouble on broadcast interfaces and therefore need to tweak the route-map configuration with set ip next-hop and additional routes. Worst case is that this will not function together with NAT due to the fact that a routing and NAT decision is made only once.

[edit] Solution

In my opinion, there is a cleaner way of configuring this behavior with NVI (NAT Virtual Interface). There are no inside/outside domains anymore - and the router now does route lookup twice, one before the NAT decision, and then another lookup to forward the packet.

For the scenario described above, this means that no loopback interfaces and PBR is required anymore.

To configure NVI, replace the ip nat inside|outside interface statement with ip nat enable. In addition, your nat config statements will look different, there are no inside and outside keywords anymore.

[edit] Config and Reference

[EZVPN client crypto config omitted] 
!
interface FastEthernet0/0
 desc ** Outside **
 ip address 172.31.254.1 255.255.255.0
 ip nat enable
 crypto map clientmap
!
interface FastEthernet0/1
 desc ** Inside **
 ip address 192.168.1.254 255.255.255.0
 ip nat enable
!
!-- IP Pool for VPN clients
ip local pool vpnclient-pool 192.168.2.1 192.168.2.255
!
!-- Translate only what gets permitted in the ACL; overload (PAT) it to the external interface
ip nat source list ACL_NAT interface FastEthernet0/0 overload
!
ip access-list extended ACL_NAT
  !-- do not translate traffic between the VPN clients and the inside
  deny ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
  !-- translate the inside and the VPN clients for every other destination
  permit ip 192.168.1.0 0.0.0.255 any
  permit ip 192.168.2.0 0.0.0.255 any
!

[edit] Caveats

Note the difference in the syntax, NVI is configured with "ip nat" opposite to traditional nat "ip nat [inside|outside]".
Some of the NVI config statements do not support route-maps for granular translation control.
In general, you will loose some visibility/flexibility/granularity, because you dont tell explicitly: "this net is inside" etc.