IPsec Site-to-Site with NAT
-
If you are talking about connections coming into WAN then out over the IPsec to a server across the tunnel then that is not the correct method.
You would need to set the source on the phase 2 to Network 0.0.0.0/0 with a NAT to Address 54.39.14.0 to make that traffic interesting to IPsec. The WAN external 1:1 address in that case would be 54.39.70.254, not 54.39.70.0.
-
Anywhere. Public IP address, so basically anywhere,anytime.
-
When a connection attempt comes into WAN, the 1:1 NAT translates the destination address. When the connection goes out the IPsec tunnel the NAT there translates the source address.
-
So I'd want the P2 to be like this?
-
It has to be to have a hope of the traffic being put into IPsec at all.
OpenVPN is much more flexible in this regard, but IPsec might be able to be coerced to work.
-
ICMP comes in and gets NATed, but nothing goes through the IPsec tunnel.
Time to try OpenVPN?
-
That does not look like the traffic is being picked up by the traffic selectors after the NAT happens. It looks like it is just going back out the WAN.
I was expecting you to be pinging .254 from the outside, not .0
-
I was using the .254 as an example, been primarily trying things with just the .0.
-
What is the output of
swanctl --list-sas?? -
con1000: #156, ESTABLISHED, IKEv1, 07efff97c8376e52_i* 1270ead44af08916_r local '167.114.185.196' @ 167.114.185.196[4500] remote '76.31.172.16' @ 76.31.172.16[4500] AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048 established 38s ago, reauth in 27959s con1000: #70, reqid 6, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048 installed 38s ago, rekeying in 2759s, expires in 3562s in c91e225c, 0 bytes, 0 packets, 38s ago out ca6a137a, 0 bytes, 0 packets local 54.39.14.0/32|/0 remote 172.21.0.0/24|/0 -
Well, doesn't matter now, I got it properly working using OpenVPN, took all of an hour including coffee time, vs IPsec which has been weeks in the making. Thank you for steering me into the light @Derelict
