Project

General

Profile

Actions

Bug #14646

closed

OpenVPN can select the wrong interface IP address when multiple addresses are present

Added by Jim Pingle 9 months ago. Updated 6 months ago.

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

100%

Estimated time:
Plus Target Version:
23.09
Release Notes:
Default
Affected Version:
Affected Architecture:

Description

If there are multiple IP addresses and VIPs on an interface, OpenVPN can unintentionally select the wrong address.

In the OpenVPN code when it attempts to find the interface address it first does this:

$interface = get_failover_interface($settings['interface']);

Then a bit below that:

$iface_ip=get_interface_ip($interface);

There are multiple problems with that arrangement:

  • It is redundant (get_interface_ip() checks the failover interface on its own)
  • The check for "any" can never succeed because if $settings['interface'] was 'any' then by the time it's checked the variable would be NULL as that would be returned by get_failover_interface()
  • get_failover_interface() returns the real OS interface (e.g. igb1, vtnet0) and get_interface_ip() works best when given the friendly config interface ('wan', 'lan', 'opt1') otherwise it falls through to a less reliable method of determining the interface address (find_interface_ip()) even if the IP address is hardcoded on the interface in config.xml

It would appear that this one change would be a minimal diff to eliminate the problematic behavior:

diff --git a/src/etc/inc/openvpn.inc b/src/etc/inc/openvpn.inc
index 0281a094cb..1e63e3dfbf 100644
--- a/src/etc/inc/openvpn.inc
+++ b/src/etc/inc/openvpn.inc
@@ -899,7 +899,7 @@ function openvpn_reconfigure($mode, $settings) {
     // OpenVPN defaults to SHA1, so use it when unset to maintain compatibility.
     $digest = !empty($settings['digest']) ? $settings['digest'] : "SHA1";

-    $interface = get_failover_interface($settings['interface']);
+    $interface = $settings['interface'];
     // The IP address in the settings can be an IPv4 or IPv6 address associated with the interface
     $ipaddr = $settings['ipaddr'];

That change works here in some local testing though I don't have a lab system which exhibits the problem behavior observed by customers in the field.

Actions #1

Updated by Jim Pingle 9 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100
Actions #2

Updated by Georgiy Tyutyunnik 9 months ago

wasn't able to reproduce the original issue as it's stated in the ticket.
However, found a somewhat linked issue:
If I run an openVPN server on an interface and disable the said interface, the socket remains hanging but in this way:
root openvpn 6696 7 tcp4 :1194 *:
so the openvpn server start listening on each interface, which enables me to connect to it using the different interface IP.
After applying the patch openvpn process stops if I disable the interface for it, and listening socket is not present.
tested on:
Version 23.05.1-RELEASE (amd64)
built on Wed Jun 28 03:57:27 UTC 2023
FreeBSD 14.0-CURRENT

Actions #3

Updated by Jordan G 9 months ago

Wasn't sure if this applied to clients and servers. After applying changeset via system_patches I rebooted upstream gateway and only one of my openVPN clients automatically failed over to my other WAN. Both tunnels were using the same gateway group; after resaving the affected tunnel and testing again, both tunnels reconnected as expected. This particular config could be to blame it's been re-used a few times, will test with different setup as well.

Actions #4

Updated by Jim Pingle 9 months ago

In my testing here, the behavior is correct when that is set to a failover group.

get_interface_ip(<group name>) returns the expected address for whichever address is active for the group at the time. If I disable the tier 1 gateway it returns whatever the next tier is.

Actions #5

Updated by Jordan G 8 months ago

retested with a different config after applying the related system_patch and failover appears to be working as expected for OpenVPN connections using a gateway group

Actions #6

Updated by Jim Pingle 8 months ago

  • Status changed from Feedback to Resolved
Actions #7

Updated by Jim Pingle 6 months ago

  • Target version changed from 2.8.0 to 2.7.1
Actions

Also available in: Atom PDF