Some VPN (IPSec) not reconnect

rlai000

The same with snapshot 2.0-BETA5 (i386) built on Wed Feb 16 14:46:23 EST 2011

Here is a VPN connection log shown:
respond new phase 1 negotiation
ISAKMP-SA established
respond new phase 2 negotiation
IPsec-SA established
18 seconds later
DPD: remote (ISAKMP-SA spi=1cbd27f7ec9e0bc7:3c6cf2db85454670) seems to be dead
purging ISAKMP-SA
purged IPsec-SA
purged ISAKMP-SA
ISAKMP-SA deleted

And I'm getting this on other 2 VPN connections:
ERROR: can't start the quick mode, there is no ISAKMP-SA

I should manually click on the "connect VPN" button on pfSense to establish them.

All of them are SonicWall; NAS240, TZ100 and TZ170. Nothing changed on remote sites, only pfSense was updated.

-Raylund

jimp

If you fill in the keep-alive IP, it will cause the tunnel to be initiated from your side periodically, and keep the tunnel up.

There have been some changes in the version of ipsec-tools in use on pfSense over the past few weeks, but I haven't heard of anyone else having a similar issue.

What snapshot date were you on previously?

rlai000

I don't think the keep-alive IP works. I'm now having one of the problematic VPNs disconnected although I already set it to automatically ping host, the remote site SonicWall LAN IP.

I think my previous snapshot is Jan 26.

-Raylund

rlai000

More information. (I've updated to the latest again 2.0-BETA5 (i386) built on Fri Feb 18 06:31:46 EST 2011)

I'm still getting:
ERROR: can't start the quick mode, there is no ISAKMP-SA

Here are the logs from the remote site SonicWall NSA240:
Warning VPN IKE Received unencrypted packet in crypto active state
Info VPN IKE Received notify: INVALID_COOKIES

After I disabled the VPN on remote site's SonicWall, I got this on my pfSense (which I think it's normal):
ERROR: unknown Informational exchange received

I then re-enabled the VPN on remote site's SonicWall, I got this sequence of events on my pfSense:
INFO: respond new phase 1 negotiation
(a lot of transactions)
INFO: ISAKMP-SA established
INFO: respond new phase 2 negotiation
INFO: IPsec-SA established
INFO: IPsec-SA established
(35 seconds later)
INFO: DPD: remote (ISAKMP-SA spi=3fd652be49324ed5:360a5981b545c374) seems to be dead
INFO: purging ISAKMP-SA
INFO: purged IPsec-SA
INFO: purged IPsec-SA
INFO: purged ISAKMP-SA
INFO: ISAKMP-SA deleted

On the remote site's SonicWall logged (after the succesful connection):
Error VPN IKE Payload processing failed
(5 of the above and no more logs about the VPN)

I then initiate the VPN from my pfSense. Everything seems working.

-Raylund

rlai000

Still on the latest snaphot.

After I initiated the 2 problematic VPNs from my pfSense and they worked for some time, these 2 VPN connections are disconnected now.

The logs are filled with:
ERROR: can't start the quick mode, there is no ISAKMP-SA

I've already set automatically ping host. Although I seldom have activities between these links, they never disconnected before.

May be I should try to reverse back to previous snapshot to see.

-Raylund

rlai000

OK. I revered back to snapshot 2.0-BETA5 (i386) built on Wed Jan 26 09:44:03 EST 2011

The 2 problematic VPN links still not connect after the firmware downgrade. The logs still filled with:
ERROR: can't start the quick mode, there is no ISAKMP-SA

The remote site (SonicWall NSA240) still get this logs:
Warning VPN IKE Received unencrypted packet in crypto active state
Info VPN IKE Received notify: INVALID_COOKIES

So, I disabled the VPN link on SonicWall. As expected, my pfSense got:
ERROR: unknown Informational exchange received

Then I enabled the VPN link on SonicWall. The link established and is solid. No more "DPD: remote seems to be dead" nor "ISAKMP-SA deleted". No need to initiate the link from my pfSense in order to establish the link.

-Raylund

rlai000

Just updated to the latest snapshot 2.0-BETA5 (i386) built on Fri Feb 25 07:12:23 EST 2011

The same problem still there.

Now, I disabled DPD on the VPN configurations. I need to manually initiate the links from pfSense, the links established (the same as before that it works always if initiated from pfSense).

But I rebooted my pfSense, all the VPN links automatically reconnected. It's been running solid for 20 minutes now.

I think DPD is the culprit.

-Raylund

databeestje

Alternatively you can try the prefer old ipsec sa knob on the advanced tabs.

rlai000

I checked.

In the GUI System: Advanced: Miscellaneous, "Prefer older IPsec SAs" is checked.

In config.xml, there is entries:
<ipsec><preferoldsa>But in the racoon.conf, there is nothing on prefer older ipsec sa:

This file is automatically generated. Do not edit

path pre_shared_key "/var/etc/psk.txt";

path certificate "/var/etc";

listen
{
adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
isakmp 99.237.xxx.xxx [500];
isakmp_natt 99.237.xxx.xxx [4500];
}

I tried to un-check "Prefer older IPsec SAs" save and then re-checked "Prefer older IPsec SAs". Funny thing happened.

Although in the GUI, "Prefer older IPsec SAs" is checked now, but the <preferoldsa>is missed in the <ipsec>section on config.xml

There still nothing related to prefer older ipsec sa in racoon.conf

It seems the "Prefer older IPsec SAs" option is broken.

-Raylund</ipsec></preferoldsa></preferoldsa></ipsec>

jimp

The <preferoldsa>is what is used now, there used to be an older tag (<preferredoldsa>) but it was moved quite some time ago.

It works for me though, the first two lines are with the checkbox off, second two are with the checkbox on:

[2.0-RC1][root@pfsense.localdomain]/root(3): grep prefer /conf/config.xml 
[2.0-RC1][root@pfsense.localdomain]/root(4): sysctl net.key.preferred_oldsa
net.key.preferred_oldsa: 0
[2.0-RC1][root@pfsense.localdomain]/root(5): grep prefer /conf/config.xml
                <preferoldsa>
[2.0-RC1][root@pfsense.localdomain]/root(6): sysctl net.key.preferred_oldsa
net.key.preferred_oldsa: -30</preferoldsa>
```</preferredoldsa></preferoldsa>