Site to Site IPSec with NAT peer
-
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
-
@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 followsConnections: 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
-
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.