Site to Site IPSec with NAT peer

[jwsi]

Hi there,

I'm currently trialling an IPSec based VPN in a site to site environment with the intention of it eventually replacing my current OpenVPN based configuration to improve performance on pfSense devices.

I have two pfSense devices (XG1541 and XG7100) one which has a public IP and another sat behind multiple layers of NAT on a 4G cellular network.

I have so far set up the XG1541 to act as the IPSec responder and the XG7100 IPSec initiator. I have successfully managed to get IKE Phase 1 up and running fine by using dynamicDNS and RSA based certs. I then attempted to get Phase 2 up and running using a VTI based design. I have managed to configure Phase 2 such that the XG7100 (behind layers of NAT) reports the tunnel as up, but the XG1541 reports the tunnel as down (using the WebGUI widget for this reporting).

Upon inspection of the logs I see on both sides that the CHILD_SA has been installed on both the XG1541 and the XG7100 implying that Phase 2 has been established correctly. In addition, when performing packet captures on the XG1541, pings to the VTI address are being recorded when originating from the XG7100, but replies are not arriving back at the XG7100. In essence it appears I've made a one-way tunnel :P

I have tried to be sensible with the VTI setup (coming from an OpenVPN background though) and have used a /30 subnet and defined the appropriate interfaces with allow all rules on the IPSec rules tab for now.

Is there something that I could be doing wrong or is this sadly a consequence of IPSec and NAT?

(Below are the ipsec statusall logs for the XG1541)

Status of IKE charon daemon (strongSwan 5.7.1, FreeBSD 11.2-RELEASE-p10, amd64):
  uptime: 17 minutes, since Oct 29 19:58:09 2019
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 6
  loaded plugins: charon unbound aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf curve25519 xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock counters
Listening IP addresses:
  REDACTED
Connections:
   bypasslan:  %any...%any  IKEv1/2
   bypasslan:   local:  uses public key authentication
   bypasslan:   remote: uses public key authentication
   bypasslan:   child:  REDACTED PASS
     con1000:  REDACTED  IKEv2, dpddelay=10s
     con1000:   local:  [REDACTED] uses public key authentication
     con1000:    cert:  REDACTED
     con1000:   remote: [REDACTED] uses public key authentication
     con1000:    ca:    REDACTED
     con1000:   child:  0.0.0.0/0|/0 === 0.0.0.0/0|/0 TUNNEL, dpdaction=clear
Shunted Connections:
   bypasslan:  REDACTED PASS
Security Associations (1 up, 0 connecting):
   bypasslan[4]: ESTABLISHED 103 seconds ago, REDACTED[REDACTED]...REDACTED[REDACTED]
   bypasslan[4]: IKEv2 SPIs: fec1a379465af7f4_i 6f5faaf8aeb8a199_r*, public key reauthentication in 2 hours
   bypasslan[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
   bypasslan{3}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: cec8d761_i c9b7eeb0_o
   bypasslan{3}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 43 minutes
   bypasslan{3}:   REDACTED

[Konstanti]

@jwsi
Hello
It is necessary to see the log and settings of phase 1 and 2
If you configure the VTI correctly, the output of the ipsec statusall command should be as follows

Connections:
   bypasslan:  %any...%any  IKEv1/2
   bypasslan:   local:  uses public key authentication
   bypasslan:   remote: uses public key authentication
   bypasslan:   child:  10.3.100.0/24|/0 === 10.3.100.0/24|/0 PASS
     con1000:  10.3.100.1...10.3.100.100  IKEv2, dpddelay=10s
     con1000:   local:  [pfsense.synology] uses pre-shared key authentication
     con1000:   remote: [freeb.synology] uses pre-shared key authentication
     con1000:   child:  0.0.0.0/0|/0 === 0.0.0.0/0|/0 TUNNEL, dpdaction=restart
     con2000:  10.3.100.1...10.3.100.101  IKEv2, dpddelay=10s
     con2000:   local:  [pfsense.synology] uses pre-shared key authentication
     con2000:   remote: [centos.synology] uses pre-shared key authentication
     con2000:   child:  0.0.0.0/0|/0 === 0.0.0.0/0|/0 TUNNEL, dpdaction=restart
Shunted Connections:
   bypasslan:  10.3.100.0/24|/0 === 10.3.100.0/24|/0 PASS
Security Associations (2 up, 0 connecting):
     con2000[67]: ESTABLISHED 3 hours ago, 10.3.100.1[pfsense.synology]...10.3.100.101[centos.synology]
     con2000[67]: IKEv2 SPIs: 418c91f766d1b7f9_i* d1173e2dd93da5ee_r, pre-shared key reauthentication in 3 hours
     con2000[67]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
     con2000{572}:  INSTALLED, TUNNEL, reqid 2000, ESP SPIs: cd7ec3b4_i cb7197a4_o
     con2000{572}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 211416 bytes_o, rekeying in 25 minutes
     con2000{572}:   0.0.0.0/0|/0 === 0.0.0.0/0|/0
     con1000[65]: ESTABLISHED 6 hours ago, 10.3.100.1[pfsense.synology]...10.3.100.100[freeb.synology]
     con1000[65]: IKEv2 SPIs: 7d7ded4e5a81cee6_i 951437062d3c2ebd_r*, pre-shared key reauthentication in 69 minutes
     con1000[65]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
     con1000{573}:  INSTALLED, TUNNEL, reqid 1000, ESP SPIs: c3c8c199_i c8b9b615_o
     con1000{573}:  AES_CBC_256/HMAC_SHA2_256_128/MODP_2048, 0 bytes_i, 205160 bytes_o, rekeying in 27 minutes
     con1000{573}:   0.0.0.0/0|/0 === 0.0.0.0/0|/0

and ifconfig

ipsec1000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
	tunnel inet 10.3.100.1 --> 10.3.100.100
	inet6 fe80::a00:27ff:fe02:c8c1%ipsec1000 prefixlen 64 scopeid 0x7 
	inet 10.6.106.1 --> 10.6.106.2 netmask 0xfffffffc 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	reqid: 1000
	groups: ipsec 
ipsec2000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
	tunnel inet 10.3.100.1 --> 10.3.100.101
	inet6 fe80::a00:27ff:fe02:c8c1%ipsec2000 prefixlen 64 scopeid 0x8 
	inet 10.7.107.1 --> 10.7.107.2 netmask 0xfffffffc 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
	reqid: 2000
	groups: ipsec 

[jwsi]

So I managed to fix it in the end, seemed the issue was the IKEv2 P1 connection on the XG1541's side. I added the public IP as an attribute in the RSA cert and it seemed to then hookup fine - weird how there was no report of this failure though...

James.