VPN established, but failed to forward traffic via VPN with source and destination NAT.

[Roy_Tam]

Recently we are migrating the internet VPN tunnel from CP1430 to CP6600 due to EoL. Firewall log is attached, showing the source and destination NAT is done. The connection was encrypted.  But it failed to connect to the destination. Opened the TAC SR, but still not able to fix the problem. May I have a help from anyone...?

===========================================

NAT:
Original Source: internal private IP
Original Destination: our public IP_1

Translated Source: our public IP_2
Translated Destination: External party's private IP
*public IP_1 and public IP_2 are different subnet

Encryption Domain:
Center Gateways (Our side): public IP_2
Satellite Gateways (External party): our public IP_1 & External party's private IP

Ran the fw monitor, see the traffic from internal to the public IP_1. But are unable to see the traffic after the translation.

> fw monitor -e "accept host(our public IP_1) or host(our public IP_2);" -m iO

[vs_0][fw_0] eth1:i[44]: internal private IP -> public IP_1 (TCP) len=60 id=48107 TCP: 19189 -> 28161 .S.... seq=2cf0285d ack=00000000
[vs_0][fw_2] eth1:i[44]: internal private IP -> public IP_1 (TCP) len=60 id=48274 TCP: 19475 -> 28161 .S.... seq=2d2bb491 ack=00000000
[vs_0][fw_1] eth1:i[44]: internal private IP -> public IP_1 (TCP) len=60 id=17132 TCP: 46560 -> 28161 .S.... seq=49f63204 ack=00000000
[vs_0][fw_1] eth1:i[44]: internal private IP -> public IP_1 (TCP) len=60 id=30396 TCP: 46562 -> 28161 .S.... seq=ec481354 ack=00000000

Troubleshoot I did:
1. Removed public IP_1 or External party's private IP from the encryption domain, but still got the issue.
2. Moved public IP_1 from Satellite Gateways's encryption domain to Center Gateways's encryption domain, but not working.
3 Added a static route that pointing public IP_1 to the internet gateway address, failed to work.

[PhoneBoy]

You should look at all the chains in fw monitor, not just i and O.
You might also want to see if the traffic is getting dropped using something like: fw ctl zdebug + drop | grep '1.2.3.4' 

[Duane_Toler]

NAT via VPNs adds complexity.  Are you sure you REALLY need it?  (sometimes you do, but be certain that you do).

The VPN domain group for your gateway should include the IP (or subnet) for "our public IP_2" [the post-translation address] as well as your internal Private  IP.  The VPN domain group for the peer gateway should include the IP (or subnet) for "External party's private IP". 

The access rule should reflect only your internal private IP and the external party private IP; NOT the NAT translations.

Be sure your IPsec SA is indeed established to include the translated source IP.  Use "vpn tu tlist" on the gateway to see the VPNs and the traffic selectors ("My TS" for your side, and "Peer TS" for the remote side) .

Check the VPN community Advanced properties and be sure "Disable NAT..." is unchecked.

You may also need to verify how your gateway is applying NAT.  Visit "Global Properties" - NAT - be sure "translate destination on client side" is selected for both Automatic and Manual NAT.

Install policy and test it again.  That should get you going.

Like I said... it's complex.  Are you CERTAIN  that you REALLY need it?

[Roy_Tam]

Hi Duane, thanks for your reply. Yes, the NAT is required.... as the destination is the private address, we do not expect to be advertised within our internal network due to the IP conflict...

I will review your instruction on my firewall. 🙏

[Duane_Toler]

Ok sounds good.  Then you need it.  Just had to ask. 🙂 
If you have an overlap/conflict situation then there's another item to consider:  Is the remote end also doing a reverse NAT?

You also need to have a NAT rule for the reverse, if they ever initiate connections to you.   The two of you will share an "interim NAT" between the two VPN gateways.

You:  192.168.0.0/16

(NAT for your side: 172.16.0.0/16;

NAT for their side: 172.17.0.0/16)

Them: 192.168.0.0/16  [conflict with your network]

You'll never see/use their 192.168.0.0/16 in this case.  All of your connections to them must be sent to destination 172.17.0.0/16, and you will source NAT yourself to 172.16.0.0/16.  When they receive the packet, they will need to un-NAT connections with Source 172.16.0.0/16 and Destination 172.17.0.0/16, and translate the destination back to their 192.168.0.0/16, but NOT translate the source; they will only see you as 172.16.0.0/16.

Hope that makes sense, and hopefully that's what you have configured.

If you have DNS names involved... heh, good luck. 🙂  DNS names also need to be re-written somewhere to resolve to the shared NAT space. This gets *really* complex (Do you use HOSTS files? Setup a fake authoritative DNS server? Conditional zone?).