Project

General

Profile

Actions

Bug #12771

closed

Automatic filter reload with OpenVPN client gateway uplink happens too soon or not at all

Added by Jon8RFC . about 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Viktor Gurov
Category:
OpenVPN
Target version:
Start date:
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
2.5.2
Affected Architecture:

Description

Not sure if this is strictly an OpenVPN client gateway issue or a gateway up/down issue in other scenarios as well, rather than making a singular fix for OpenVPN gateways.

Filter Reload seems to be set to happen when an OpenVPN client is enabled, but happens too soon in the process based on my observation, documented in the thread below.
And, it does not happen at all when an OpenVPN gateway uplink is restored in the background (as best I can infer from the thread below) when the OpenVPN client has already been enabled.

Here's the problem and a workaround to automatically reload the filter via /usr/local/sbin/ovpn-linkup , though there may be a more appropriate operative manner to accomplish this:
https://forum.netgate.com/topic/149636/problem-with-automatic-filter-reload-when-openvpn-is-in-a-gateway-group


Related issues

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 stateClosed

Actions
Actions #1

Updated by Viktor Gurov about 2 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
Actions #2

Updated by Viktor Gurov about 2 years ago

  • Assignee set to Viktor Gurov
  • Affected Version set to 2.5.2

after merging https://gitlab.netgate.com/pfSense/pfSense/-/merge_requests/516
`/usr/bin/touch /tmp/${1}_upstart4 (upstart6)` must be added at the end of /usr/local/sbin/ovpn-linkup

Actions #3

Updated by Viktor Gurov about 2 years ago

  • Target version set to CE-Next
  • Plus Target Version set to 22.05
Actions #4

Updated by Jim Pingle about 2 years ago

  • Status changed from New to Pull Request Review
  • Target version changed from CE-Next to 2.7.0
Actions #5

Updated by Viktor Gurov about 2 years ago

  • Status changed from Pull Request Review to Feedback
  • % Done changed from 0 to 100
Actions #6

Updated by Jon8RFC . about 2 years ago

I can't say "fixed" for this issue since I have new problems in 2.6.0, so I can't give it a solid test. I also don't want to risk that the change may cause problems for others, like it seems fixes for others have caused problems for me.

I had problems going from 2.4 to 2.5 with my OpenVPN client, and now from 2.5 to 2.6 with both client and server.
Things connect without a problem, but either won't use policy-based routing correctly or seem to have no connectivity at all.
I don't know enough to easily troubleshoot where the issue exists, just need to read what others' solutions are when things go awry.

If I'm the only person who really needs that fix, maybe it's not worth the risk of causing new problems for someone else in the next version.
Thank you for taking the time to look at it.

Actions #7

Updated by Viktor Gurov about 2 years ago

to test this fix you need to install the system patches pkg:
https://docs.netgate.com/pfsense/en/latest/development/system-patches.html

apply patch id ec73bb89489d830ec21c4e04ffa3ec401791b55d
and patch id 324bff6498bbd8e04d735195348d8b78b3e9a4a8

Actions #8

Updated by Jon8RFC . about 2 years ago

Thanks! Seems like it's all working properly with the patches applied.

Actions #9

Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF