Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Site to Site IPSec with NAT peer

    Scheduled Pinned Locked Moved IPsec
    3 Posts 2 Posters 296 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • jwsiJ
      jwsi
      last edited by

      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
      
      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @jwsi
        last edited by

        @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 
        
        1 Reply Last reply Reply Quote 0
        • jwsiJ
          jwsi
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.