Here you are very typical architecture. Local Internet access and site to site VPN at the same router – easy case. To deploy this kind of configuration almost always we have to engage IPSec VPN and NAT at one platform. What does NAT imply for IPSec – let’s answer this question.
First we have to take a look at Cisco IOS order of operations. NAT is before encryption, what is means that traffic that needs to be encrypted will be first NATed then encypted. Mostly our crypto ACL that defines interesting traffic for encyption matches our source inside LAN subnet and remote end subnet IP. Once we add default NAT configuration, IPSec will not work properly. Traffic will never match crypto ACL because first will be translated and source IP will change (depends on NAT configuration) to outside interface IP or to dynamic IP defined in NAT pool.
To resolve this issue we have to exclude traffic that needs to be encrypted from NAT translation. Here you are quick configuration example how to proceed.
Traffic from subnet 10.0.1.0/24 to 10.0.3.0/24 needs to be encrypted. Remaining traffic from 10.0.1.0/24 to Internet needs to be translated to outside interface IP.
Define two ACLs. First needs to match VPN traffic (you can leverage of course crypto ACL that is already used by IPSec crypto map), second will define NAT traffic. Then create route map with two statements, in first statement we have to use deny key word and match crypto ACL, second permit statement will match NAT ACL. Route map has to be assigned under to ip nat inside configuration that describes traffic that will be translated. That’s all. Here you are how it looks like from configuration perspective.
ip access-list extended NAT
permit ip 10.0.1.0 0.0.0.255 any
ip access-list extended VPN
permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255
route-map NAT deny 10
match ip address VPN
route-map NAT permit 20
match ip address NAT
ip nat inside source route-map NAT interface FastEthernet0/0 overload
ip nat outside
crypto map MAPA