Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    IPsec error connection after upgrading one site to 8.2.1

    Scheduled Pinned Locked Moved Off-Topic & Non-Support Discussion
    4 Posts 2 Posters 465 Views 2 Watching
    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.
    • F Offline
      fme
      last edited by

      Hi
      We installed a new pfsense with 2.8.1 at a remote site and tried to establish an IPsec tunnel (P1) from another site which ran on 2.7.2
      We were not able to establish the connection, always got error message like the ones below.
      We have had a IPsec connection working between 2 sites running on 2.7.2
      After a while of trying out and checking we decided to upgrade one of the machines to 2.8.1
      Result: Now the formerly working IPsec connection can't be established showing the same errors.
      So my best guess is that there is a change of behaviour with 2.8.2. Unfortunately there is no easy way to rollback the machine and we have to get that going again. It doesn't seem to make much sense to upgrade the machine still running on 2.7.2
      since nothing works on 2.8.1
      If someone has an idea any help is very much appreciated!
      Thx

      Jul 17 17:33:59 charon 47965 10[NET] <82> received packet: from 83.xx.xxx.xx[61884] to 192.168.1.122[500] (720 bytes)
      Jul 17 17:33:59 charon 47965 10[ENC] <82> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
      Jul 17 17:33:59 charon 47965 10[CFG] <82> looking for an IKEv2 config for 192.168.1.122...83.xx.xxx.xx
      Jul 17 17:33:59 charon 47965 10[CFG] <82> candidate: 192.168.1.122...83.xx.xxx.xx, prio 3100
      Jul 17 17:33:59 charon 47965 10[CFG] <82> found matching ike config: 192.168.1.122...83.xx.xxx.xx with prio 3100
      Jul 17 17:33:59 charon 47965 10[IKE] <82> local endpoint changed from 0.0.0.0[500] to 192.168.1.122[500]
      Jul 17 17:33:59 charon 47965 10[IKE] <82> remote endpoint changed from 0.0.0.0 to 83.xx.xxx.xx[61884]
      Jul 17 17:33:59 charon 47965 10[IKE] <82> 83.xx.xxx.xx is initiating an IKE_SA
      Jul 17 17:33:59 charon 47965 10[IKE] <82> IKE_SA (unnamed)[82] state change: CREATED => CONNECTING
      Jul 17 17:33:59 charon 47965 10[CFG] <82> selecting proposal:
      Jul 17 17:33:59 charon 47965 10[CFG] <82> proposal matches
      Jul 17 17:33:59 charon 47965 10[CFG] <82> received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
      Jul 17 17:33:59 charon 47965 10[CFG] <82> configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
      Jul 17 17:33:59 charon 47965 10[CFG] <82> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_4096
      Jul 17 17:33:59 charon 47965 10[CFG] <82> received supported signature hash algorithms: sha256 sha384 sha512 identity
      Jul 17 17:33:59 charon 47965 10[IKE] <82> local host is behind NAT, sending keep alives
      Jul 17 17:33:59 charon 47965 10[IKE] <82> remote host is behind NAT
      Jul 17 17:33:59 charon 47965 10[CFG] <82> sending supported signature hash algorithms: sha256 sha384 sha512 identity
      Jul 17 17:33:59 charon 47965 10[ENC] <82> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
      Jul 17 17:33:59 charon 47965 10[NET] <82> sending packet: from 192.168.1.122[500] to 83.xx.xxx.xx[61884] (728 bytes)
      Jul 17 17:33:59 charon 47965 10[NET] <82> received packet: from 83.xx.xxx.xx[4500] to 192.168.1.122[4500] (272 bytes)
      Jul 17 17:33:59 charon 47965 10[ENC] <82> parsed IKE_AUTH request 1 [ IDi AUTH N(ESP_TFC_PAD_N) SA TSi TSr N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
      Jul 17 17:33:59 charon 47965 10[IKE] <82> local endpoint changed from 192.168.1.122[500] to 192.168.1.122[4500]
      Jul 17 17:33:59 charon 47965 10[IKE] <82> remote endpoint changed from 83.xx.xxx.xx[61884] to 83.xx.xxx.xx[4500]
      Jul 17 17:33:59 charon 47965 10[CFG] <82> looking for peer configs matching 192.168.1.122[%any]...83.xx.xxx.xx[192.168.200.103]
      Jul 17 17:33:59 charon 47965 10[CFG] <82> no matching peer config found
      Jul 17 17:33:59 charon 47965 10[IKE] <82> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
      Jul 17 17:33:59 charon 47965 10[ENC] <82> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
      Jul 17 17:33:59 charon 47965 10[NET] <82> sending packet: from 192.168.1.122[4500] to 83.xx.xxx.xx[4500] (80 bytes)
      Jul 17 17:33:59 charon 47965 10[IKE] <82> IKE_SA (unnamed)[82] state change: CONNECTING => DESTROYING

      stephenw10S 1 Reply Last reply Reply Quote 0
      • stephenw10S Offline
        stephenw10 Netgate Administrator @fme
        last edited by

        @fme said in IPsec error connection after upgrading one site to 8.2.1:

        Jul 17 17:33:59 charon 47965 10[CFG] <82> looking for peer configs matching 192.168.1.122[%any]...83.xx.xxx.xx[192.168.200.103]
        Jul 17 17:33:59 charon 47965 10[CFG] <82> no matching peer config found
        Jul 17 17:33:59 charon 47965 10[IKE] <82> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
        Jul 17 17:33:59 charon 47965 10[ENC] <82> generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

        That looks like an identifier mismatch. The remote side is sending it's local IP as the Identifier because it's behind NAT (presumably) and the local side doesn't have a P1 that matches.

        F 1 Reply Last reply Reply Quote 0
        • F Offline
          fme @stephenw10
          last edited by

          @stephenw10 Thanks for answering, I downgraded both FWs back to 2.7.2 (having a steep learning curve) changed "Peer identifier" entry in P1 to any and it works well. I tried that with 2.8.1 as well with no luck.
          It really looks like a "2.8.1 thing", I don't dare to upgrade for the time being.

          1 Reply Last reply Reply Quote 0
          • stephenw10S Offline
            stephenw10 Netgate Administrator
            last edited by

            You should just set the identifier to something specific but valid. So I'd use FQDN, it doesn't change with actual IP address used. It only needs to match at each end.

            1 Reply Last reply Reply Quote 1
            • First post
              Last post
            Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.
            Privacy Policy · Cookie Policy