IPSec site-to-site between PFSense and USG rekey issue
I have successfuly connected PF Sense 2.4.4 to Unifi Security Gateway PRO (184.108.40.20624212).
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:
Key Exchange version: IKEv2
Internet protocol: IPv4
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):
Key length: 256 bits
DH Group: 14 (2048 bit)
Dead Peer Detection: checked
Max failures: 5
In Phase 2 is:
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):
Encryption Algorithms: AES 256 bits
Hash Algorithms: SHA1
PFS key group: 14 (2048 bit)
Automaticall ping host: 10.20.11.1
Key Exchange Version: IKEv2
DH Group: 14
Enable perfect forward secrecy unchecked
Dynamic routing unchecked
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.
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:
timboau 0 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?
@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)
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
- same IPSEC configuration