PSA: If IPSec stops working after upgrading to 2.3.1, try 3DES

[mzhaase]

I just upgraded our VPN modem to 2.3.1 which caused all tunnels to go down. It seems packets were sent out, but none were coming in (status -> IPSec -> Show child SA entries). I tried to log all packets but nothing. Finally I found a similar issue in this forum someone had after upgrading to 2.2, were AES seemingly stopped working. So I downgraded P1 and P2 connections to 3DES and now it works again.

2.3.1-RELEASE-p1 (i386)
built on Wed May 25 14:53:12 CDT 2016
FreeBSD 10.3-RELEASE-p3
Platform pfSense
CPU Type VIA C7 Processor 1500MHz
Hardware crypto VIA Padlock

[cmb]

It'd strictly be with Padlock if that's the case. That's not something that's used much, and not tested by us at all. You'd be better off disabling Padlock and using AES, as you're bypassing Padlock by switching to 3DES and AES is faster and more secure without an accelerator.

[adelphi]

Same problem here: no IPSEC traffic after upgrade from 2.2.6 to latest 2.3.1 when using AES, but 3DES works.
My pfsense is connecting to various systems including Juniper, Cisco RV082 or Debians with openSWAN. Alle tunnels are having the same problem and were running on 2.2.6 without an issues.

• I already tried the recommended "Unity" Option without success.
• IP compression is off.
• I'm also using a VIA Eden Processor 1000MHz with Padlock but HW crypto is disabled in pfsense.

I also tried a clean install of 2.3 and loaded my existing config, but the problem still exist. The only workaround is to switch from AES to 3DES, as recommended in some other posts. But this can't be the final solution…

pfsense log:
Jun 24 10:09:58  charon  09[CFG] ignoring acquire, connection attempt pending 
Jun 24 10:09:58  charon  06[KNL] creating acquire job for policy local_IP.122/32|/0 === remote_IP.208/32|/0 with reqid {13} 
Jun 24 10:09:56  charon  06[CFG] ignoring acquire, connection attempt pending 
Jun 24 10:09:56  charon  10[KNL] creating acquire job for policy local_IP.122/32|/0 === remote_IP.208/32|/0 with reqid {13} 
Jun 24 10:09:55  charon  10[CFG] ignoring acquire, connection attempt pending 
Jun 24 10:09:55  charon  09[KNL] creating acquire job for policy local_IP.122/32|/0 === remote_IP.208/32|/0 with reqid {13} 
Jun 24 10:09:52  charon  09[CFG] ignoring acquire, connection attempt pending 
Jun 24 10:09:52  charon  10[KNL] creating acquire job for policy local_IP.122/32|/0 === remote_IP.208/32|/0 with reqid {13} 
Jun 24 10:09:52  charon  06[NET] <con5000|4498>sending packet: from local_IP.122[500] to 80.147.157.252[500] (92 bytes) 
Jun 24 10:09:52  charon  06[ENC] <con5000|4498>generating INFORMATIONAL_V1 request 3383855305 [ HASH N(DPD_ACK) ] 
Jun 24 10:09:52  charon  06[ENC] <con5000|4498>parsed INFORMATIONAL_V1 request 1611443253 [ HASH N(DPD) ] 
Jun 24 10:09:52  charon  06[NET] <con5000|4498>received packet: from 80.147.157.252[500] to local_IP.122[500] (84 bytes) 
Jun 24 10:09:52  charon  06[CFG] ignoring acquire, connection attempt pending 
Jun 24 10:09:52  charon  10[KNL] creating acquire job for policy local_IP.122/32|/0 === remote_IP.208/32|/0 with reqid {13} 
Jun 24 10:09:51  charon  06[ENC] <con6000|4904>parsed INFORMATIONAL_V1 request 1866387927 [ HASH N(DPD) ] 
Jun 24 10:09:51  charon  06[NET] <con6000|4904>received packet: from remote_IP.208[500] to local_IP.122[500] (92 bytes)

Cisco RV082 log:
Jun 24 10:09:34 2016 VPN Log (g2gips0) #110: [Tunnel Established] sent MR3, ISAKMP SA established
Jun 24 10:09:34 2016 VPN Log (g2gips0) #111: [Tunnel Established] ISAKMP SA established
Jun 24 10:09:34 2016 VPN Log (g2gips0) #112: [Tunnel Established] sent QI2, IPsec SA established {ESP=>0xc12a1c07 <0x04b2c27c}
Jun 24 10:09:34 2016 VPN Log (g2gips0) #113: [Tunnel Established] sent MR3, ISAKMP SA established</con6000|4904></con6000|4904></con5000|4498></con5000|4498></con5000|4498></con5000|4498>

[cmb]

Padlock isn't a configurable option, if it exists in the system, it's used. It's not like AES-NI and glxsb that can be enabled/disabled.

[adelphi]

@cmb:

Padlock isn't a configurable option, if it exists in the system, it's used. It's not like AES-NI and glxsb that can be enabled/disabled.

You said " You'd be better off disabling Padlock ". If it's not possible to disable it in pfsense, there's IMHO no other way do disable it. The Hardware has no BIOS option to disable it.

Does this mean we have to replace all our Lex Neo systems by other products or is there any chances this problem will be fixed in near future?

[MrMoo]

Same problem here, but I had to use OpenVPN until 2.3.2 before I could use 3DES.