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

    IPSec site-to-site between PFSense and USG rekey issue

    Scheduled Pinned Locked Moved IPsec
    6 Posts 3 Posters 5.1k 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.
    • E
      eragons
      last edited by eragons

      Hi,

      I have successfuly connected PF Sense 2.4.4 to Unifi Security Gateway PRO (4.4.29.5124212).

      Communication between networks works until 3600 seconds defined in Phase 2 elapse... Then I found this error on IPSec log:

      CHILD_SA ESP /0dxcdbd4bb6/80.211.xxx.xxx not found for rekey.

      Tunnel shows as connected on PFSense, but there is no communication anymore. I have to manually disconnect and connect in PFSense GUI, then it works again for hour.

      Does anyone know what may cause these issues please?

      My settings in PFSense Phase 1 is:

      General Information:

      Key Exchange version: IKEv2
      Internet protocol: IPv4
      Interface: WAN
      Remote gateway: 80.188.xxx.xxx

      Phase 1 Proposal (Authentication):

      Authentication Method: Mutual PSK
      My identifier: my IP adress
      Peer identifier: Peer P adress

      Phase 1 Proposal (Encryption Algorithm):

      Algorithm: AES
      Key length: 256 bits
      Hash: SHA1
      DH Group: 14 (2048 bit)

      Lifetime: 28800

      Advanced options:

      MOBIKE: Disable
      Dead Peer Detection: checked
      Delay: 10
      Max failures: 5

      In Phase 2 is:

      General Information:

      Mode: Tunnel IPv4
      Local Network: Lan Subnet
      NAT/BINAT translation: None
      Remote Network: Network 10.20.11.0/24

      Phase 2 Proposal (SA=Key Exchange):

      Protocol: ESP
      Encryption Algorithms: AES 256 bits
      Hash Algorithms: SHA1
      PFS key group: 14 (2048 bit)
      Lifetime: 3600

      Advanced Configuration:

      Automaticall ping host: 10.20.11.1


      Ubiquiti side:

      Remote Subnets: 10.20.1.0/24
      Route Distance: 10
      Peer IP: 80.211.xxx.xxx
      Local WAN IP: 80.188.xxx.xxx
      Pre-shared key: 15 char key
      IPSec Profile: Customized

      Key Exchange Version: IKEv2
      Encryption: AES-256
      Hash: SHA1
      DH Group: 14
      Enable perfect forward secrecy unchecked
      Dynamic routing unchecked

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        In IKEv2 the initial "Phase 2" tunnel is established using material from the initial IKE establishment.

        When you fail to rekey after the 3600 seconds that likely means you have a mismatch in the Phase 2 settings.

        It looks like you have PFS enabled on the pfSense side and disabled on the ubiquiti side:

        | Enable perfect forward secrecy unchecked

        But it doesn't look like you included the "Phase 2" information from the ubiquiti. Not very familiar with those.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 1
        • E
          eragons
          last edited by eragons

          It looks stable now.

          Thank you for this. About Unifi phase 2, thats everything what can I config in GUI.

          Here is what I found in config files over SSH:

          left=80.188.xxx.xxx
          right=80.211.xxx.xxx
          leftsubnet=10.20.11.0/24
          rightsubnet=10.20.1.0/24
          ike=aes256-sha1-modp2048!
          keyexchange=ikev2
          reauth=no
          ikelifetime=28800s
          esp=aes256-sha1!
          keylife=3600s
          rekeymargin=540s
          type=tunnel
          compress=no
          authby=secret
          auto=route
          keyingtries=%forever

          T 1 Reply Last reply Reply Quote 0
          • T
            timboau 0 @eragons
            last edited by

            @eragons Hi did you get this working and re-connecting?

            I'm experiencing the same issue.

            I can see there is a rekey margin - did you add this to pfsense?

            E 1 Reply Last reply Reply Quote 0
            • E
              eragons @timboau 0
              last edited by eragons

              @timboau-0 Hi, nothing about rekey margin in pf sense. After application of this:

              "It looks like you have PFS enabled on the pfSense side and disabled on the ubiquiti side:
              | Enable perfect forward secrecy unchecked"

              It started to work. For sure I have configured script written by John Skinner that pings some devices on Unifi side to ensure vpn is working. If not, it restarts VPN service on pf sense side.

              1. In PFSense
              sudo vi /etc/crontab
              
              Insert the following line after the embedded system lines
              
              * * * * * root /etc/restart_ipsec.sh
              
              OR
              
              webGUI >> Diagnostics >> Edit File: /etc/crontab
              * * * * * root /etc/restart_ipsec.sh
              
              (look at look at GUI >> Diagnostics >> Command Prompt: "ps ax | grep mpd")
              2. restart cron
              webGUI >> Diagnostics >> Command Prompt:
              killall cron ; cron
              
              3. Save this scipt to /etc/restart_ipsec.sh
              
              #!/bin/sh
              
              # This script was designed to run on pfSense 2.3.x, as a cron job using the "Cron" package,
              # It will run a command if all three hosts listed fail to reply to pings.
              # 2017 John at John Skinner dot net
              
              # THE PING SECTION
              # The section below pings three different hosts, once each,
              #  and saves the results for each as separate variables
              #  (number one "1" for sucsessful responce, and zero "0" for failed responce)
              # In the block below, make sure to edit your local IP address and the host IP addresses for your situation
              # The local IP address is after the "-S", and the host you want to ping is the second IP address
              
              RESULTS1=$(/sbin/ping -c 1 -S 10.20.1.1 10.20.11.116 | /usr/bin/grep icmp | /usr/bin/wc -l)
              RESULTS2=$(/sbin/ping -c 1 -S 10.20.1.1 10.20.11.21 | /usr/bin/grep icmp | /usr/bin/wc -l)
              RESULTS3=$(/sbin/ping -c 1 -S 10.20.1.1 10.20.11.117 | /usr/bin/grep icmp | /usr/bin/wc -l)
              
              # THE MATH SECTION
              # This section adds all the results above to a new variable
              
              RESULTS4=$(( RESULTS1 + RESULTS2 + $RESULTS3 ))
              
              # PING AND MATH TESTING SECTION
              # Uncomment the line below to test the results of the ping and the math sections
              #echo $RESULTS4
              # (When uncommenting the PING AND MATH TESTING line above, you may want to comment-out all the following lines of this script)
              
              # DECIDE TO RUN COMMAND SECTION
              # Based on the results of the pings and the math, this section decides to either
              #  1.) send a notification email, write a log, and run the command if all the pings fail,
              #  or
              #  2.) send a notification email, and write a log, if any of the pings reply.
              if [ $RESULTS4 -eq 0 ]; then
              
              # The line below will write a custom message, with the tag "IPSec", to the local system log
                      /usr/bin/logger -t IPSec "ELTSEN VPN tunnel is down. Restarting IPSec."
              
              # The line below will:
              #  1.) take down a specific IPSec tunnel connection with configuation named "con1000",
              #  2.) wait 10 seconds, and bring the connection back up (list you connections using the command "ipsec status"),
              #  3.) email the results of bringing the connection back up, to the email address in SYSTEM -> ADVANCED -> NOTIFICATIONS
                      /usr/local/sbin/ipsec down con1000; sleep 10; /usr/local/sbin/ipsec up con1000 | /usr/local/bin/mail.php -s"Eltsen tunnel is down. Restarting IPSec"
              else
              
              # The lines below will write a custom message to the local system log and send an email notification upon a successful ping reply from any of the hosts.
                      /usr/bin/logger -t IPSec "Eltsen tunnel is up"
                      /bin/echo "Eltsen tunnel is up" | /usr/local/bin/mail.php -s"Eltsen tunnel is up"
              #fi
              #```[2017-08-10_ping_test_and-restart_IPSec_tunnel.txt](/public/_imported_attachments_/1/2017-08-10_ping_test_and-restart_IPSec_tunnel.txt)
              
              
              1 Reply Last reply Reply Quote 0
              • T
                timboau 0
                last edited by

                thanks for the update and great looking script! :)

                I had disabled PFS on both sides and had the VPN running ok but it appeared to stop passing traffic when the P2 timeout expired after 3600 seconds.

                By adding the rekey @ 540 seconds before expiry I 'think' its now stable.

                I run approx 25 VPN tunnels from two sites to remote sites and Ive replaced a remote pfsense box with a USG device at one remote site.

                From one main site ive had 100% uptime 19 hours to the USG
                Strangely the other main has had drops during the same period - 5,56,45 minutes breaks

                • same IPSEC configuration
                  (all other IPSECs from that site were ok)

                Both main sites pfsense 2.4.3

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