-
Same here.
We have multiple IPSec, both tunnel and VTI in a kind of hub & spoke layout.
Since "'central" pfSense have been migrated to 25.05 and well as some spoke pfSense, when IPSec starts, P1 & P2 connect and it works but after some time, while both P1 & P2 are still connected, no traffic goes trough IPSec links, I believe because gateways are seen as "off-line".I suspected dping issue but restarting dpinger doesn't help.
The only way to bring tunnel "on" (well, they are seen as "on" in IPSec status) is to stop then start again IPSec daemon.
Something wrong with reauthentication ?
I don't really know how to investigate further, not finding anything obviously wrong in logs. -
Hmm, so the tunnels show as up but no traffic passes including the dpinger traffic? You don't see the tunnel packet counters increasing? Restarting dpinger doesn't change anything?
-
Indeed behavior is exactly this one!
But I need to investigate further whenever some other changes applied. -
It looks like deactivating "make before break" on each side does the trick.
I will confirm hopefully in a couple of days. -
Mmm, I would run a pcap on the interface and see what, if anything, is being sent across the tunnel when it fails.
-
I definitely will do this next week and post here the results. Thank you
-
Hi,
similiar problem here.
there are several sites, some with Pfsense+ 25.07.1 and some with PfsenseCE 2.8.1.
Tunnels are running classical site2site and route based VTI.
MSS on lan is set to 1300 Byte.After upgrade to latest PFsense 25.07.1 and 2.8.1 managing VeeamBackup stopped working.
scp of bigger files (bigger than 32kByte) has a timeout for about 58 seconds, before it starts at full speed.We took a paketcapture on destination linux-server and saw the initials packets.
Afterwards some retries and out of sync Ack packets, afterwards it starts and packetflow is ongoing.Interesingly this does not happen on all connections, only some, but unfortunatly we haven't found the common thing between them.
br
Thomas -
Hmm, but in your case it does eventually pass the traffic? That seems different to the other two reports above.
-
Hi
Same here, had to revert to 2.7.2
-
Any more detail?
We've not seen anything like this in testing. If it's real and is going to get solved we need to be able to replicate it.
-
@stephenw10 said in Upgrade from 2.7.2 to 2.8.0 ipsec:
We've not seen anything like this in testing. If it's real and is going to get solved we need to be able to replicate it.
I've heavily reshapped our IPSec network so that we can highlight what's happening here in order to, I fully agree, been able to replicate it.
We are still facing this issue from time to time but I can't fully say this is due to pfSense bug or wrong configuration.As our network is made of mesh IPSec + BGP, this is not that simple to spot the issue.
-
This is still happening, and I accidentially deleted my 2.7.2 setup, so now I'm fucked, after upgrade, to 2.8.1 VTI tunnels stop working about 20 seconds after reboot. This is really, really annoying, as it stops me from being able to do my work. Luckily IPV6 is not affected, but IPV4 connectivity dies on 2.8.1
I am guessing it's a problem with VTI, as the two IPV6 tunnels do not use VTI.
-
It's one way, from the remote site, running a fortigate, connectivity is working fine. Behind the pfsense, nothing is flowing, no firewall blocks either. It's bloody strange, as when I ping a certain ipv4 it works, and continues to work, yet trying to ping another host on the same network, even ping won't work anymore, rpd or ssh does not work at all, and the ONLY change is the upgrade from 2.7.2 to 2.8.1 same config, on both sides. I think it is due to VTI being broken, as my IPV6 tunnels don't use VTI, but the ipv4 do use routed tunnels. Broken on 2.8.1 for sure.
probably a routing issue, it's not going to the VTI interface :
ipv6 not using VTI:
Tracing route to vsadc-dc01.soapeople.com [2001:920:4011:6::60]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfsense.jvangent.nl [2a10:3781:23d4::1]
2 10 ms 10 ms 10 ms 2001:920:4011:f::1
3 11 ms 11 ms 10 ms 2001:920:4011:fff::1
4 12 ms 11 ms 11 ms 2001:920:4011:6::60same host, using ipv4, VTI;
Tracing route to vsadc-dc01.soapeople.com [10.10.10.60]
over a maximum of 30 hops:1 * * * Request timed out.
2 * * * Request timed out.
3 *this stuff is broken.
edit: when I disable the VTI interface, then enable it, it works for a few seconds tracert and rpd work, and then it stops working again. Easily reproducable on my end.
tracert on ipv4 and VTI just after re-enabling the VTI interface :
C:\Users\admjgent>tracert -4 vsadc-dc01
Tracing route to vsadc-dc01.soapeople.com [10.10.10.60]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms pfsense.jvangent.nl [192.168.0.1]
2 10 ms 10 ms 10 ms 198.18.60.3
3 12 ms 11 ms 11 ms 10.10.19.206
4 11 ms 10 ms 10 ms 10.10.10.6020 seconds later or so, it's done, and won't work anymore.
I guess for now is trying to re-install 2.6 which I still have a proper ISO for (why the hell is the normal ISO gone ??, ridiculous decision, not enterprise ready) and try to restore the config, or change to non routed tunnel and having multiple SA's running. Please fix this, it is a clear regression, both on 2.8 and 2.8.1
-
This post is deleted! -
Was able to download a 2.7.2 iso, and fix everything, merely by reinstalling the system and using my existing config.
- please just offer normal installation iso on your main website
- fix this clear regression on 2.8/2.8.1 VTI tunnel routing is broken on this version, see my previous post.
Reverted back (again) to 2.7.2.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.