VPN issues after switch to FTTP

[#1]

I recently switched from FTTC (SOGEA) to FTTP. I've retained my static IP (thanks PN). Immediately following the change, I started seeing bad packet ID errors logged by openvpn UDP client (out of sequence packets). I rarely if ever saw this prior to my migration to FTTP. I can trigger 1000s of these log entries if I initiate a download, 100s if I watch a youtube video. They are not continuous, but come in bursts of 100+ at a time. I have reduced MTU for the openvpn client, desktop OS and the local router interface the desktop connects to. (VPN client runs on the router.) This seems to have little or no effect on the frequency of the error.

"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368650 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368651 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368648 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368652 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368645 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368646 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368047 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368050 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"
"2026-04-06T15:59:41.000Z","fw","openvpn_client1","error","AEAD Decrypt error: bad packet ID (may be a replay): [ #368045 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings"

I'm aware of the --mute-replay-warnings option but wondered if any one else experiences this here?

Moderator's note by Mike (Mav): Post released from Spam Filter.

[#2 · Accepted solution]

This seems to be caused by traffic shaping my end.

[#3]

@keeka 

Always helpful to give details of the router and firmware is being used, looking at the event log I would have wondered if QoS or SQM was implemented.

[#4]

I would have given more details. However I haven't fixed it as such yet and all I know ATM is, if I turn off my traffic shaping, the errors stop. I had thought I'd enabled it after the surge in errors appeared (when I got FTTP). But there's no avoiding the fact that errors stop if I disable my shaper config.

I am using OPNsense 26.1 and the pipes/queues/rules are intended to reduce upstream buffer bloat and prioritise VoIP: one upstream and one downstream pipe (~90% bandwidth & FQ Codel scheduler), dedicated queue pair for VoIP and another pair for everything else. I was surprised that a scheduler might produce out of sequence UDP packets between a single remote IP/port and local port. The router is virtualised, so there are other potential causes for this but it is related to shaping in way or another.

[#5]

@keeka 

Did you come to a conclusion?

Does a bufferbloat check result give you poor results with your current router, being virtual adds another variable to your situation

For what it worth I see no need for need for any QoS or SQM with my Full Fibre 900 / 100.

[#6]

@keeka 

The router is virtualised, so there are other potential causes for this but it is related to shaping in way or another.

Now that's interesting...

I have a 900/115 FTTP connection and I run Openwrt on an MT7621 based router. With h/w acceleration it can handle the 900Mb but that precludes any QoS usage. I have a Intel i5 based mini-PC running Proxmox VE used for various things so I thought I'd try a virtualised instance of Openwrt to see if being able to run with QoS (since the I5 had plenty of CPU power) had any advantages. 

Everything seemed to be working and bufferbloat tests gave 'A' results whereas using the MT7621 gave 'C'. However I have a SIP phone connected to the office PBX and it was noticed that the PBX was showing it offline whereas the phone thought it was online?.

Now SIP is UDP so maybe I was experiencing something similar to you in the virtualised scenario. Switching back to the real hardware and the problem goes away...   

[#7]

@Dan_the_Van I don't need it either. The bufferbloat mitigation seemed like a good starting point to experiment  I was interested in prioritising some traffic over others.

@MisterW
Something seems to cause the UDP packets to arrive out of sequence, or to such an extent that they're outside the default OpenVPN replay window.
I have a 145/30 connection, 2 core guest, multiqueue off on all the guest's network interfaces. Shaper config is as per OPNsense docs with separate higher weight queues for VoIP. VoIP didn't seem impacted at all, though I did not look any deeper. Bear in mind the issue only rears its head when link is near or at saturation (like start of stream replay or a download).
I could may be try bare metal but it's not big enough problem for me ATM to abandon virtualised router.