Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved IPsec
    6 Posts 4 Posters 2.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • M
      mzhaase
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • A
          adelphi
          last edited by

          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>

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • A
              adelphi
              last edited by

              @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?

              1 Reply Last reply Reply Quote 0
              • M
                MrMoo
                last edited by

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

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.