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)
- 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.
- Create a route map that matches based on the access list.
- 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 192.168.0.0 0.0.0.255 10.10.0.0 0.0.255.255 ! ! NAT all other traffic permit ip 192.168.0.0 0.0.0.255 any exit route-map static-nat match ip address static-nat exit ! ip nat inside source static tcp 192.168.0.1 25 Dialer 1 25 route-map static-nat reversible ip nat inside source static tcp 192.168.0.1 25 xx.xx.xx.xx 25 route-map static-nat reversible
- 'xx.xx.xx.xx' is the external IP address
- 192.168.0.0/24 is the internal private network
- 10.10.0.0./16 is the network at the far end of the IPSec tunnel
- 192.168.0.1 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.