IPsec Site-to-Site with NAT
-
And how do you source connections from that address?
-
They are just setup as Virtual IPs on the WAN interface. Browsing to one that hasn't been setup yet with 1:1 nat takes you to the pfSense login page (https://54.39.70.254/), and those addresses reply to ICMP requests, so I know that part is good.
-
Well whatever is set up on WAN has nothing to do with the IPsec NAT.
That configures what happens to the NAT in the tunnel itself.
When the other side connects to 172.21.69.1 what do you want to happen?
Specifically, what connecting to what is not working?
-
I want to be able to connect to say, 54.39.70.254 in a web browser, and have it show content from 172.21.0.11. From my understanding, I'd need source NAT for the incoming traffic, and a 1:1 NAT for traffic for External IP>Internal Host IP.
-
jf5264835 less than a minute ago
I want to be able to connect to say, 54.39.70.254 in a web browser,
Connect to that from where?
-
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