Bug #9595
closedOpenVPN does not resync when running on a gateway group
100%
Description
When OpenVPN clients/servers are running on a gateway group interface, they should always bind to the most preferable interface within that group. In cases when cables are disconnected/reconnected or when IP changes occur, OpenVPN will often hug a lower priority interface and not resume operation on the most preferable online interface within a gateway group.
This is due to the following reason:
IP changes are monitored by the rc.newwanip
file which in turn executes the function openvpn_resync_all
in /etc/inc/openvpn.inc
An excerpt from this function is shown below:
if (is_array($config['openvpn']['openvpn-client'])) {
foreach ($config['openvpn']['openvpn-client'] as & $settings) {
if ($interface <> "" && $interface != $settings['interface']) {
continue;
}
openvpn_resync('client', $settings);
}
}
This excerpt sadly does not take account of the situation when OpenVPN instances are bound to gateway groups because the interface in question will never be equal to the OpenVPN interface, thus OpenVPN instances are never resynced when these situations occur.
The solution I propose will bring OpenVPN resyncs more in line with that currently implemented within rc.openvpn
to allow for instances operating on gateway group interfaces to behave correctly.
I will submit a PR for review shortly.
Best wishes,
James.
Files
Updated by James Webb over 5 years ago
Updated by Jim Pingle over 5 years ago
- Status changed from New to Pull Request Review
Updated by Renato Botelho over 5 years ago
- Status changed from Pull Request Review to Feedback
- Assignee changed from James Webb to Renato Botelho
PR has been merged. Thanks
Updated by Jim Pingle about 5 years ago
- Target version changed from 2.5.0 to 2.4.5
Updated by Jim Pingle almost 5 years ago
- Status changed from Feedback to Resolved
Client changes WAN bindings at the expected times as gateways fail/recover on 2.4.5.
Updated by James Webb over 3 years ago
There has been a regression introduced in the latest changes of the pfSense codebase that have caused this bug to reappear. In particular, when higher priority gateways within gateway groups come back online after a failure, OpenVPN fails to restart onto the more preferable and now available gateway. Instead, OpenVPN remains bound to the lower priority gateway and requires a manual restart to the relevant OpenVPN service to correct.
This bug needs to be re-opened and the regression removed as it's likely causing issues in quite a few environments.
James.