Site-to-Site VPN

Unanswered Question
Jan 22nd, 2010


We are having a Static NAT configured on 1800 router for two hosts. Viz -a.b.c.d and p.q.r.s. for Public_Addr1, and Public_addr2. With this we are able to access these hosts from internet without any problem. Currently no firewall feature is not used, so WAN to LAN access is allowed.

Next, we plant to set up a  setup a site-to-site VPN for these two hosts with remote site hosts. Now if we configure this site-to-site VPN, then is there a possibility that our static NAT for these two hosts would not work from all the places?  This will lead us to loosing the connectivity to those hosts except from the VPN locations.

Another problem is second location can access our hosts a.b.c.d and p.q.r.s not by these private address but some totally different private address

say a1.b1.c1.d1 and p1.q1.r1.s1. So if these hosts tries to communicate with "Other side VPN"   hosts, then we need to NAT these first ( a1.b1.c1.d1, p1.q1.r1.s1 ) and then send it for encryption.

Here are the cases

Case 1. If host a.b.c.d tries to  access internet --> Then source NAT it to Public_Addr1 and then send to WAN interface of router

Case 2. If host a.b.c.d tries to access "Other side VPN" host then source NAT it with a1.b1.c1.d1 and then send the packet to Encryption Process

             Where it will be encrypted in tunnel mode and will be sent to the WAN link with other end VPN tunnel public address as destination address.

         If , [[ a.b.c.d ( Src) --and Other_Side_VPN (Dest) ] ] ----> then  NAT source address  [ [ a1.b1.c1.d1 ( Src)-- and Other_Side_VPN (Dest)] ] ---

           --------> then encrypt this packet ------> wrap it with ESP header to Other_end_VPN_Public address ---> WAN link.

         Access-list in crypto map will have source address as a1.b1.c1.d1 and target address as "other_Side_VPN hosts".

Can it be done , do we have something like nat (0) in firewall which excludes the NAT process?  But here in our case it is a two step process

Changing the soure IP to another source IP and then encrypting the packet.

Please share the experience.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Giuseppe Larosa Fri, 01/22/2010 - 07:21

Hello Subodh,

what works in this case is to configure NAT using additional route-map to check if traffic is betwern hosts and internet (to be natted) or it is between the VPN (do not NAT).

ip nat inside source static local-ip global-ip route-map ConditionalNAT

route-map ConditionaNAT

match ip address 111

access-list 111 deny ip host local-ip  remote-vpn-subnet rem-vpn-wildcardamsk

access-ist 111 permit ip host local-ip any


to be noted as reported by others the route-map is available only if you are not doing port static NAT

if there were no need for static entries the ACL for NAT would be an extended ACL denying traffic between local and remote site VPN subnets.

Another point to be considered is that NAT is triggered by a packet that need to go to a NAT inside to a NAT outside interface or viceversa.

if the VPN is built using GRE over IPSec you have an addtional logical interface (the tunnel GRE ) that doesn't has a NAT configuration on it and this can help too.

Hope to help


bapatsubodh Fri, 01/22/2010 - 10:16


I did as per the suggestion but I ran into following problems.

location A source IP address :

The address to which needs to be source NATed  while accessing Loaction B is

Location B address : .

That means when pings to ( location B),  source address needs to be changed to

so packet becomes [ ( src: 172.16.1.) , (Dest - ]  this packet is then encrypted

crypto map access-list is permit icmp / ip  from host  to destination host

I have defined following access lists and nat translations

CASE : 1 :

access-list 101 permit icmp host host

access-list 101 permit ip host host

ip nat pool

ip nat pool ca prefix-length 24 ( this is a single host )

ip nat inside source list 101 pool ca ( overload and reversible )

when I used this configuration , I was able to ping from location A to location B

that is ping source was working ok. But from location B if I ping sou it gave me UUUUU responce.

I configured overoload as well as reversible but still UUUUU and not !!!!!.


Then I replaced nat by route map

route-map abcd permit 10

mat ip addres 101

and then i used it for nat statement with route map as follows

ip nat inside source  static route-map abcd

With this I got ping responce from both the locations.

Location A : ping sou working ok

Location B : ping sou working ok

Can I know what is wrong with CASE 1: nat configuration with list and how is it working CASE 2: with route-map ?



Giuseppe Larosa Fri, 01/22/2010 - 14:16

Hello Subdoh,

the scenario is more complex for the presence of the crypto map.

However, I think the difference is that in second case using the static keyword you allow translations that starts from outside to inside:

The following example shows how to configure route map R1 to allow outside-to-inside translation for static NAT:

ip nat inside source static route-map R1 reversible
ip access-list extended ACL-A
 permit ip any

route-map R1 permit 10
 match ip address ACL-A

! this is in the usage guidelines of NAT command reference

In your first configuration you use a NAT pool and not the static keyword.
To see if this is true you could try to use the route-map without the static keyword combined with the NAT pool.
I would expect that there are still problems when starting the ICMP from other side.

Hope to help


This Discussion