<![CDATA[IPsec error connection after upgrading one site to 8.2.1]]>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

]]>https://forum.netgate.com/topic/200969/ipsec-error-connection-after-upgrading-one-site-to-8.2.1RSS for NodeSun, 16 Aug 2026 19:55:47 GMTFri, 17 Jul 2026 15:49:33 GMT60<![CDATA[Reply to IPsec error connection after upgrading one site to 8.2.1 on Sun, 02 Aug 2026 19:41:56 GMT]]>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.

]]>https://forum.netgate.com/post/1245966https://forum.netgate.com/post/1245966Sun, 02 Aug 2026 19:41:56 GMT<![CDATA[Reply to IPsec error connection after upgrading one site to 8.2.1 on Sun, 02 Aug 2026 14:31:24 GMT]]>@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.

]]>https://forum.netgate.com/post/1245956https://forum.netgate.com/post/1245956Sun, 02 Aug 2026 14:31:24 GMT<![CDATA[Reply to IPsec error connection after upgrading one site to 8.2.1 on Sat, 25 Jul 2026 13:17:53 GMT]]>@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.

]]>https://forum.netgate.com/post/1245645https://forum.netgate.com/post/1245645Sat, 25 Jul 2026 13:17:53 GMT