[Bug 2108860] Re: floating IP due to "route VPN_IP net_gateway" causes 60 second "Disallow float" in openvpn 2.6
Walter
2108860 at bugs.launchpad.net
Mon Sep 1 11:47:44 UTC 2025
Updated [Where problems could occur].
** Description changed:
[ Impact ]
OpenVPN 2.6 blocks new VPN connection setup via existing VPN for 60
seconds due to detected source ip address change.
- First VPN (2.2.2.2) acts as default gateway (so device has source IP 2.2.2.2)
- Second VPN (3.3.3.3) gets set up (sees source 2.2.2.2 (VPN-in-VPN))
- client gets pushed route to IP 3.3.3.3 with net_gateway (client does not route traffic to 3.3.3.3 via 2.2.2.2 anymore)
- Second VPN detects this as floating ip (source changes from 2.2.2.2 to 1.1.1.1)
With openvpn 2.5, this works flawlessly.
With openvpn 2.6, this is handled as a second connection from another source ip.
Error message: "Disallow float to an address taken by another client 1.1.1.1:sourcePort".
After 60 seconds and "client-instance restarting" the second connection is allowed.
During these 60 seconds, all traffic to/through targetVPN is disallowed.
[ Test Plan ]
* Configure openvpn on server1. How to do that is beyond the scope of
this test plan. See https://openvpn.net/community-docs/how-to.html
although I don't think that's quickest. Maybe google some and/or ask
your local LLM for some tips:
mode server
#tls-server
local <externalip>
proto udp
port 1194
server <mynetwork> 255.255.255.0
topology subnet
dev-type tun
* The server1 config needs to push its route as default route:
https://openvpn.net/community-docs/routing-all-client-traffic--including-web-traffic--through-the-vpn.html :
push "redirect-gateway def1"
NOTE: You can actually use a pre-existing VPN as server1, doesn't have
to be openvpn. It just needs to set the default route.
* Configure server2 config. This can be basically a copy of server1 (use
a different mynetwork). Instead of pushing its route as default route,
it pushes its own external IP (3.3.3.3) as net_gateway. This forces the
traffic to server2 to go there directly, instead of via server1. Also
set log level to 3:
verb 3
push "route 3.3.3.3 255.255.255.255 net_gateway"
* Connect the client to server1. Check with https://ifconfig.co/ or
similar that server1 IP is your source IP. Connect the client to
server2. The logs on server2 will show this:
myuser/<server1ip>:39892 SENT CONTROL [myuser]: 'PUSH_REPLY,route 3.3.3.3 255.255.255.255 net_gateway,route-gateway <mynetwork2>,topology subnet,ping 15,ping-restart 55,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Disallow float to an address taken by another client <clientip>:39892
Disallow float to an address taken by another client <clientip>:39892
...
* At this point, all traffic between client and server2 is dropped
(confirm by not being able to ping the server2 mynetwork2.1 IP). After
60 seconds, a restart mechanism kicks in, and things start to work.
* When the fix is applied to server2 (!), the logs on server2 will show
this:
myuser/<server1ip>:35886 SENT CONTROL [myuser]: 'PUSH_REPLY,route 3.3.3.3 255.255.255.255 net_gateway,route-gateway <mynetwork2>,topology subnet,ping 15,ping-restart 55,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
myuser/<server1ip>:35886 Data Channel: cipher 'AES-256-GCM', peer-id: 0
...
myuser/<clientip>:35886 PUSH: Received control message: 'PUSH_REQUEST'
* Observe how both server1ip and clientip appear next to myuser/. The
traffic works immediately. Confirm by being able to ping the server2
pushed mynetwork2.1 IP.
[ Where problems could occur ]
- * Think about what the upload changes in the software. Imagine the
- change is wrong or breaks something else: how would this show up?
+ * The patch expands checks before considering packets as legal for
+ new connections. Packets now marked as "invalid" will be checked
+ against existing connections instead, where they might be valid
+ (like in the floating IP case).
- * It is assumed that any SRU candidate patch is well-tested before
- upload and has a low overall risk of regression, but it's important
- to make the effort to think about what ''could'' happen in the event
- of a regression.
-
- * This must never be "None" or "Low", or entirely an argument as to why
- your upload is low risk.
-
- * This both shows the SRU team that the risks have been considered,
- and provides guidance to testers in regression-testing the SRU.
+ * So, a regression would be if connections that could previously
+ be set up, cannot anymore. Or, if traffic that is supposed to be
+ for a new connection now matches an existing connection.
+ Neither is expected.
[ Original Report ]
OpenVPN unjustly blocks a source IP switch immediately after connection
setup.
We're using a (different) VPN (main) with a default gateway;
we connect to the target VPN (3.3.3.3) with source IP 2.2.2.2;
once connected to targetVPN, targetVPN pushes its own IP 3.3.3.3 with net_gateway so we don't get VPN-in-VPN;
this is detected as a floating IP by openvpn.
With openvpn 2.5, this works flawlessly.
But with openvpn 2.6, it's counted as a second connection, and we get
"Disallow float to an address taken by another client
1.1.1.1:sourcePort". This lasts for 60 seconds until "client-instance
restarting", after which the second connection is finally allowed.
During these 60 seconds, all traffic to/through targetVPN is disallowed.
----
Upstream bug report: https://github.com/openvpn/openvpn/issues/704
Upstream patch: https://www.mail-archive.com/openvpn-
devel at lists.sourceforge.net/msg31495.html
Patch against 2.6.12 (for Noble) attached.
----
Walter Doekes
OSSO B.V.
--
You received this bug notification because you are a member of Ubuntu
Sponsors, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/2108860
Title:
floating IP due to "route VPN_IP net_gateway" causes 60 second
"Disallow float" in openvpn 2.6
Status in OpenVPN:
New
Status in openvpn package in Ubuntu:
In Progress
Status in openvpn source package in Noble:
Triaged
Status in openvpn source package in Oracular:
Won't Fix
Status in openvpn source package in Plucky:
Triaged
Status in openvpn source package in Questing:
In Progress
Bug description:
[ Impact ]
OpenVPN 2.6 blocks new VPN connection setup via existing VPN for 60
seconds due to detected source ip address change.
- First VPN (2.2.2.2) acts as default gateway (so device has source IP 2.2.2.2)
- Second VPN (3.3.3.3) gets set up (sees source 2.2.2.2 (VPN-in-VPN))
- client gets pushed route to IP 3.3.3.3 with net_gateway (client does not route traffic to 3.3.3.3 via 2.2.2.2 anymore)
- Second VPN detects this as floating ip (source changes from 2.2.2.2 to 1.1.1.1)
With openvpn 2.5, this works flawlessly.
With openvpn 2.6, this is handled as a second connection from another source ip.
Error message: "Disallow float to an address taken by another client 1.1.1.1:sourcePort".
After 60 seconds and "client-instance restarting" the second connection is allowed.
During these 60 seconds, all traffic to/through targetVPN is disallowed.
[ Test Plan ]
* Configure openvpn on server1. How to do that is beyond the scope of
this test plan. See https://openvpn.net/community-docs/how-to.html
although I don't think that's quickest. Maybe google some and/or ask
your local LLM for some tips:
mode server
#tls-server
local <externalip>
proto udp
port 1194
server <mynetwork> 255.255.255.0
topology subnet
dev-type tun
* The server1 config needs to push its route as default route:
https://openvpn.net/community-docs/routing-all-client-traffic--including-web-traffic--through-the-vpn.html :
push "redirect-gateway def1"
NOTE: You can actually use a pre-existing VPN as server1, doesn't
have to be openvpn. It just needs to set the default route.
* Configure server2 config. This can be basically a copy of server1
(use a different mynetwork). Instead of pushing its route as default
route, it pushes its own external IP (3.3.3.3) as net_gateway. This
forces the traffic to server2 to go there directly, instead of via
server1. Also set log level to 3:
verb 3
push "route 3.3.3.3 255.255.255.255 net_gateway"
* Connect the client to server1. Check with https://ifconfig.co/ or
similar that server1 IP is your source IP. Connect the client to
server2. The logs on server2 will show this:
myuser/<server1ip>:39892 SENT CONTROL [myuser]: 'PUSH_REPLY,route 3.3.3.3 255.255.255.255 net_gateway,route-gateway <mynetwork2>,topology subnet,ping 15,ping-restart 55,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
Disallow float to an address taken by another client <clientip>:39892
Disallow float to an address taken by another client <clientip>:39892
...
* At this point, all traffic between client and server2 is dropped
(confirm by not being able to ping the server2 mynetwork2.1 IP). After
60 seconds, a restart mechanism kicks in, and things start to work.
* When the fix is applied to server2 (!), the logs on server2 will
show this:
myuser/<server1ip>:35886 SENT CONTROL [myuser]: 'PUSH_REPLY,route 3.3.3.3 255.255.255.255 net_gateway,route-gateway <mynetwork2>,topology subnet,ping 15,ping-restart 55,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' (status=1)
myuser/<server1ip>:35886 Data Channel: cipher 'AES-256-GCM', peer-id: 0
...
myuser/<clientip>:35886 PUSH: Received control message: 'PUSH_REQUEST'
* Observe how both server1ip and clientip appear next to myuser/. The
traffic works immediately. Confirm by being able to ping the server2
pushed mynetwork2.1 IP.
[ Where problems could occur ]
* The patch expands checks before considering packets as legal for
new connections. Packets now marked as "invalid" will be checked
against existing connections instead, where they might be valid
(like in the floating IP case).
* So, a regression would be if connections that could previously
be set up, cannot anymore. Or, if traffic that is supposed to be
for a new connection now matches an existing connection.
Neither is expected.
[ Original Report ]
OpenVPN unjustly blocks a source IP switch immediately after
connection setup.
We're using a (different) VPN (main) with a default gateway;
we connect to the target VPN (3.3.3.3) with source IP 2.2.2.2;
once connected to targetVPN, targetVPN pushes its own IP 3.3.3.3 with net_gateway so we don't get VPN-in-VPN;
this is detected as a floating IP by openvpn.
With openvpn 2.5, this works flawlessly.
But with openvpn 2.6, it's counted as a second connection, and we get
"Disallow float to an address taken by another client
1.1.1.1:sourcePort". This lasts for 60 seconds until "client-instance
restarting", after which the second connection is finally allowed.
During these 60 seconds, all traffic to/through targetVPN is
disallowed.
----
Upstream bug report: https://github.com/openvpn/openvpn/issues/704
Upstream patch: https://www.mail-archive.com/openvpn-
devel at lists.sourceforge.net/msg31495.html
Patch against 2.6.12 (for Noble) attached.
----
Walter Doekes
OSSO B.V.
To manage notifications about this bug go to:
https://bugs.launchpad.net/openvpn/+bug/2108860/+subscriptions
More information about the Ubuntu-sponsors
mailing list