Regression #12215
closedOpenVPN does not resync when running on a gateway group
0%
Description
Hi all,
It seems that quite a bit of the codebase has changed in the relevant files since the fix I implemented in #9595. This change has caused a regression and as such the same issue that was originally defined in #9595 is now reoccuring. This is likely causing issues in quite a few deployments.
Best wishes,
James.
Related issues
Updated by Viktor Gurov over 3 years ago
- Status changed from New to Feedback
Unable to reproduce on 2.6.0.a.20210805.0500 -
OpenVPN with gwgroup successfully resync on gateway failure/restore
here is your code:
https://github.com/pfsense/pfsense/blob/master/src/etc/inc/openvpn.inc#L1720-L1742
Updated by Viktor Gurov almost 3 years ago
- Related to Bug #12613: DNS Resolver does not restart during link up/down events on a static IP address interface added
Updated by Viktor Gurov almost 3 years ago
- Related to Regression #11570: Gateway monitoring services is not always restarted on interface events, which may prevent a WAN from recovering back to an online state added
Updated by Oskar Stroka about 2 years ago
I'm also affected by this.
OpenVPN Client on DSL (PPPoE) and another OpenVPN Client on LTE (DHCP), both on Tier 1 in a Gateway Group.
LTE failed today for a few minutes, after it came back up OpenVPN reported to be connected, but there was no traffic passing this Interface (except for ICMP / dpinger).
Restarting the OpenVPN Service fixed that.
Updated by Jordan G over 1 year ago
seeing this with 23.05, OpenVPN using a gateway group as the interface won't failover unless dpinger is restarted, but it appears to fail-back when the connection is restored.
Updated by Jordan G over 1 year ago
23.05.1 has OpenVPN clients using the configured gateway group as the correct interface(s) and appears to failover and back upon latency/packet-loss threshold being surpassed