Personal tools
You are here: Home Networking Cisco IOS Static Network Address Translation (NAT) in the context of a 'crypto map' based IPSec tunnel

Static Network Address Translation (NAT) in the context of a 'crypto map' based IPSec tunnel

How to overcome static NAT entries acting on traffic for IPSec tunnels

When using 'crypto map' based IPSec tunnels, static NAT entries (pinholes) are applied to IPSec tunnel traffic. Most often this is return traffic to the IPSec tunnel.

I found two possible workarounds for this issue:

Using tunnel interfaces has several advantages, however I had difficultly getting them to interoperate with OpenSwan.

Applying a route-map to the static NAT entries is straightforward, with the exception that the format with an interface, rather than an IP address is not supported (IOS 12.4.18 on a 800 platform). Thus this workaround will only work if you have a static address on the outside interface (Dialer 1 in my example)



  1. Create an access-list. This should be exactly the same as the main NAT access list. Note: I have named it in the positive, in that the access list describes those addresses which the static NAT entries are to be translated.
  2. Create a route map that matches based on the access list.
  3. Use the 'route-map static-nat' modifier on the static nat entries. 
ip access-list extended static-nat
  ! Do not NAT ipsec traffic 
  deny ip
  ! NAT all other traffic
  permit ip any

route-map static-nat
  match ip address static-nat

! ip nat inside source static tcp 25 Dialer 1 25 route-map static-nat reversible
ip nat inside source static tcp 25 xx.xx.xx.xx 25 route-map static-nat reversible


  • 'xx.xx.xx.xx' is the external IP address
  • is the internal private network
  • is the network at the far end of the IPSec tunnel
  • is the example address for the port 25 pinhole


Note: As described above, the form with an interface (commented out in the example above) is not supported on the 800 platform with IOS 12.4.18.



Document Actions