IPSEC connection dropping



  • I have 2 Pfsense 1.2.2 boxes connected via an IPSEC VPN tunnel.  Both sides have static IPs.  A few times a day, seemingly at random, the tunnel will go down.  It will stay down for anywhere from 1 minute to 2 hours, then come back up on its own.  Both boxes are also connected to an OpenBSD box.  The connections between the PFSense boxes and it seem much more stable.  Any ideas?



  • Adding some more information.  I have multiple tunnels.

    Site #1
    192.168.10.0/24
    192.168.11.0/24

    Site #2
    10.1.1.0/24
    10.1.2.0/24

    Each of these blocks has a tunnel between them.  When the tunnels go down, sometimes restarting racoon fixes it, other times you just have to wait.  Today I discovered that if I went in and disabled tunnels one by one that eventually the ones left would come up, and then I could go back and reenable the others.


  • Rebel Alliance Developer Netgate

    By multiple tunnels, do you mean parallel tunnels (two tunnels to the same far side router with different subnet info)?

    You might check your lifetime values for phase 1 and phase 2 on each side and adjust them slightly. Some have seen odd drops happen when the phase1 and phase2 lifetimes expire both at the same time.



  • Yes, parallel tunnels.  Is there a better way to connect the multiple subnets to each other?  I'll try modifying the lifetime values and see if that has any effect.


  • Rebel Alliance Developer Netgate

    @bmcnabb:

    Yes, parallel tunnels.  Is there a better way to connect the multiple subnets to each other?

    Since your subnets are adjacent, supernetting would work:

    192.168.10.0/23
    That will cover 192.168.10.0/24 and 192.168.11.0/24

    For the other side, since they are not on a /23 boundary, a /22 would do it:
    10.1.0.0/22
    Covers: 10.1.0.0 through 10.1.3.0

    Otherwise, not really, until 2.0 comes and we can have as many subnets per tunnel as we like.



  • I've changed to a single tunnel with different p1 and p2 lifetimes.  Hopefully that will stabilize them.



  • Well, it stayed up for one lifetime(86400s) and then went down again.  Here's some logs with IPs masked.  Its confusing to me because the OpenBSD -> Pfsense connection is stable, but the Pfsense -> Pfsense one is not.  It wouldn't be an issue either except it takes so long for the tunnel to reestablish.

    Aug 28 10:17:56 racoon: [VPN to office network]: ERROR: XXX.XX.13.230 give up to get IPsec-SA due to time up to wait.
    Aug 28 10:17:26 racoon: [VPN to office network]: INFO: initiate new phase 2 negotiation: XX.XXX.170.206[0]<=>XXX.XX.13.230[0]
    Aug 28 10:17:11 racoon: [VPN to office network]: ERROR: XXX.XX.13.230 give up to get IPsec-SA due to time up to wait.
    Aug 28 10:16:41 racoon: [VPN to office network]: INFO: initiate new phase 2 negotiation: XX.XXX.170.206[0]<=>XXX.XX.13.230[0]
    Aug 28 10:16:37 racoon: [VPN to office network]: ERROR: XXX.XX.13.230 give up to get IPsec-SA due to time up to wait.
    Aug 28 10:16:07 racoon: [VPN to office network]: INFO: initiate new phase 2 negotiation: XX.XXX.170.206[0]<=>XXX.XX.13.230[0]
    Aug 28 10:16:07 racoon: [VPN to office network]: ERROR: XXX.XX.13.230 give up to get IPsec-SA due to time up to wait.
    Aug 28 10:15:37 racoon: [VPN to office network]: INFO: initiate new phase 2 negotiation: XX.XXX.170.206[0]<=>XXX.XX.13.230[0]
    Aug 28 10:15:37 racoon: [VPN to office network]: INFO: phase2 sa deleted XX.XXX.170.206-XXX.XX.13.230
    Aug 28 10:15:36 racoon: [VPN to office network]: INFO: phase2 sa expired XX.XXX.170.206-XXX.XX.13.230



  • Some more information.  I set the lifetimes of phase 1 to 10 days and the lifetimes of the phase 2 to 1 day.  After 1 day the vpn tunnel went down and did not come back up until I 1) Disabled both ends of the tunnel 2) setkey -FP on both ends of the tunnel 3) restarted both racoons 4) Reenabled the tunnels.  I've tried many different ways to get the tunnels back up when they get in this state, but this seems to be the only reliable way I can do it.


  • Rebel Alliance Developer Netgate

    A little late, I know, but you may want to try a new 1.2.3-RC3 snapshot. The NAT-T feature caused a lot of IPsec regressions just like the one you are seeing, and has been removed. If you try a snapshot from the past couple days it should behave a lot better.



  • I'm running 1.2.2 which I thought didn't have NAT-T.  Trying to avoid running 1.2.3 until its stable and not a RC since this is a production environment.  I still have the problem, but I've bandaged it by setting the lifetimes to 10 days so that the tunnel only drops once every 10 days instead of multiple times a day like before.


  • Rebel Alliance Developer Netgate

    Ah, nevermind then. It may still be worth a try.

    1.2.3 is just about ready to go, there are just one or two issues holding it up. It may even be in the next week.



  • Its just confusing to me that the tunnels from Pfsense <–> OpenBSD are stable, but the tunnels from Pfsense <--> Pfsense aren't.  I would have thought it would be the opposite.


  • Rebel Alliance Developer Netgate

    Hard to say why that may be the case.

    Do you know what version of ipsec-tools is running on the OpenBSD box?



  • I'm not sure.  Its an older box that I didn't set up and I'm not very familiar with OpenBSD.  Any suggestions how to check the version?


  • Rebel Alliance Developer Netgate

    It usually prints it in the log, wherever racoon is set to log to. It may just be in the main system log.



  • Hmm…looking at a ps I don't think its even running racoon.  Looks like its just running isakmpd.


  • Rebel Alliance Developer Netgate

    Well then I really have no idea on that one. Unfortunately, ipsec-tools does have more than its fair share of bugs.

    They are nearing the release of a new version, but it won't be out in time for 1.2.3. Hopefully it will work out for 2.0, though.


Log in to reply