NAT over VPN Issue

[Mohammedomar05046]

Hi colleagues
I need your supports on this scenario, I have made site to site IPsec vpn configuration with remote office, this office send some traffic to specific system (system A) in my network which has ip 192.168.1.30, and i want this traffic go through other system (system B IP 172.10.110.27), so this system will receive the traffic from remote office and send it to system A and then recieve reply from system A and send back to FW where vpn configuration done. but i need all of this scenario happened in transparent so remote offic just send to system A IP without make any modification or know about this change.

I tried to configure destination NAT in the incoming interface ( NAT source IP: remote office host IP, Destination IP:192.168.1.30 , Translated destination:172.10.100.27) everything goes smootly but in return when system B send the reply that recieved from A  to remote office the routing happened and IPsec encapsulation done before NAT (source IP not change to be system A 192.168.1.30) so get SPI related to 172.10.100.27 not to desired one 192.168.1.30

from remote office they recievd packet with desired IP details (source IP:192.168.1.30, destination IP:remote office host IP) but  with different SPI not belongs to source subnet in VPN ACL

can you help to establish these scenario with any solution.

Thanks in advance

[MHM Cisco World]

Can you draw the topology ?

[Mohammedomar05046]

 this is the topology i have added 172.10.100.27 in ACL so in return traffic routed through VPN tunnel

[balaji.bandi]

I do not believe it works as you expected. Since you already have 192.168.10.30 IP address in the network.

instead you can use any other IP to NAT (which is not used in the network)

example :

Source :

192.168.10.10

Destination :

192.168.20.30

Translated to 172.10.100.27

or if you added intresting traffic remote site to access 172.10.100.27 - you do not need NAT at all.

is this make sense ? or am i miss understood the requirement.

[Mohammedomar05046]

system B should be transparent and I don't want other office send traffic to system B directly (172.10.100.27) 

the remote office should not know about system B in middle,

the normal traffic flow from remote office host IP sends traffic to system A using IPsec Tunnel, and know i need to proxy all traffic and should be handled by system B (works as proxy system)

and in future in case system B removed change will be in my site and easy to recover normal traffic flow

[balaji.bandi]

If you want to traffic to go to A and A need to route B, setup a reverse proxy. not sure what traffic we are considering here, if http/https you can do.

But still you have overlap IP between sites,  that need to resolved with NAT.

[Mohammedomar05046]

the traffic is SMPP,  i just want redirecting traffic and allowed changes only in FW

when i used NAT the packet received from remote office (source IP 193.10.10.10 destination IP 192.168.10.30) and once entered the fw NAT applied so packet became (source IP 193.10.10.10 destination IP 172.10.100.27) so based on routing sent to system B

then system B handled the traffic and sent directly to system A with following details (source IP 172.10.100.27 destination IP 192.168.10.30) then System A reply to B (system B can correlate replay of any request) then B sent this reply to real source which is remote office with packet (source IP 172.10.100.27 destination IP 193.10.10.10) and sent directly to FW 

and based on ACL (source IP 172.10.100.27 destination IP 193.10.10.10) this packet encapsulated and SPI assigned (SPI of 172.10.100.27 subnet)

the issue occured after NAT where source IP changed and packet became ( source IP 192.168.10.30 destination IP 193.10.10.10 with SPI related to 172.10.100.27)  so in the other side (remote office ) error message dispalyed as below:

The decapsulated inner packet doesn't match the negotiated policy in the SA. The packet specifies its destination as 193.10.10.10, its source as 192.168.10.30, and its protocol as icmp. The SA specifies its local proxy as 193.10.10.10/255.255.255.255/ip/0  and its remote_proxy as 172.10.100.0/255.255.255.224/ip/0.