Bug #9595


OpenVPN does not resync when running on a gateway group

Added by James Webb over 4 years ago. Updated about 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
3.00 h
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


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/

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']) {
        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,


ovpngwgroup.patch (2.01 KB) ovpngwgroup.patch patch file James Webb, 06/19/2019 08:38 AM
Actions #2

Updated by Jim Pingle about 4 years ago

  • Status changed from New to Pull Request Review
Actions #4

Updated by Renato Botelho about 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee changed from James Webb to Renato Botelho

PR has been merged. Thanks

Actions #5

Updated by Jim Pingle almost 4 years ago

  • Target version changed from 2.5.0 to 2.4.5
Actions #6

Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to Resolved

Client changes WAN bindings at the expected times as gateways fail/recover on 2.4.5.

Actions #7

Updated by James Webb about 2 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.



Also available in: Atom PDF