PPTP disconnect brings IPsec VPNs down



  • On 2.0-RC1 (amd64) built on Tue Mar 22 21:02:19 EDT 2011

    When a PPTP user connects and then disconnects, all IPsec VPNs go down shortly afterwards.

    Disabling/enabling an IPsec VPN brings them all back up.

    We don't use PPTP much so it's the first time we've seen it.  We're planning on going back to the official RC1 in the mean time.  Known issue?

    It definitely looks lke this thread could be related:

    http://forum.pfsense.org/index.php/topic,34250.0.html



  • Well, don't know if it's related or not.

    I changed /usr/local/sbin/vpn-linkdown to read "/sbin/pfctl -b $4 -b $5" instead of "/sbin/pfctl -b $3 -b $4" and all IPsec connections still died.



  • Bit more info.

    We see the PPTP user get logged out.  About 30 seconds later, the IPsec VPN's DPD detection kicks in and it starts trying to renegotiate but fails:

    Mar 23 15:38:40 fw-vista racoon: [x.x.x.x] INFO: DPD: remote (ISAKMP-SA spi=xxx) seems to be dead.
    Mar 23 15:38:40 fw-vista racoon: INFO: purging ISAKMP-SA spi=xxx.
    Mar 23 15:38:40 fw-vista racoon: INFO: purged IPsec-SA spi=yyy.
    Mar 23 15:38:40 fw-vista racoon: INFO: purged IPsec-SA spi=zzz.
    Mar 23 15:38:40 fw-vista racoon: INFO: purged ISAKMP-SA spi=xxx.
    Mar 23 15:38:40 fw-vista racoon: INFO: ISAKMP-SA deleted y.y.y.y[500]-x.x.x.x[500] spi:xxx

    Mar 23 15:38:49 fw-vista racoon: INFO: IPsec-SA request for x.x.x.x queued due to no phase1 found.
    Mar 23 15:38:49 fw-vista racoon: INFO: initiate new phase 1 negotiation: y.y.y.y[500]<=>x.x.x.x[500]
    Mar 23 15:38:49 fw-vista racoon: INFO: begin Identity Protection mode.
    Mar 23 15:38:49 fw-vista racoon: ERROR: phase1 negotiation failed due to send error. www
    Mar 23 15:38:49 fw-vista racoon: ERROR: failed to begin ipsec sa negotication.



  • Hate to bump my own thread - but searching it doesn't seem like anyone else is seeing this… Anyone have any ideas at all?



  • I had a chance to test the original RC1 i386 build Sat Feb 26
    15:30:26 EST 2011 and it behaved the same way, so it's not an issue
    unique to the amd64 build…

    I'm a bit confused as to why I haven't received any response - I'm guessing I should enter a ticket?



  • Can you try removing the second -b from that command and see if that fixes it?
    So from /sbin/pfctl -b $4 -b $5 do it /sbin/pfctl -b $4



  • No luck.

    Changed the pfctl line from /sbin/pfctl -b $3 -b $4 to /sbin/pfctl -b $4 with no change in behavior.  I noticed that my SSH connection into the box died as well.  Had to open a new one.



  • I can confirm that this is a problem on our installation too.

    We are running PPTP for road warriors, IPSEC Site2Site, MultiWAN.

    The only way to re-establish the IPSEC is to restart Racoon.

    2.0-RC3 (i386) built on Sun Aug 7 01:58:01 EDT 2011



  • Can you all confirm that you are using an interface ip on the loacl PPTP address configuration?
    Can you also test to use another address there solves the issue?

    Normally the latest snapshot should behave in this regard.



  • I can confirm I am currently using the same IP for PPTP and IPSEC and it is the public WAN interface IP.

    I have now tried adding a virtual IP (a spare one in our block) and then setting that in the PPTP page.  When that was done, I couldn't connect to the VPN on the new IP.  Switch it all back and everything worked again.  So I can't tell if making the PPTP bind to a different IP solves the problem or not because I haven't got PPTP working.  I only get short maintenance windows so have to do quick tests.  Should I have done something else extra to get it to work?



  • Read on the new snapshots that that ip is not a binding ip.



  • I completely understand that I was incorrectly configuring it.  User error!  I have changed the ServerIP to something else (within my internal range) and the IPSEC tunnels stay up when a user disconnects.  I shall keep everything running now to see if it is resolved 100%


Locked