[Bug 2108860] Re: floating IP due to "route VPN_IP net_gateway" causes 60 second "Disallow float" in openvpn 2.6

Wed Sep 10 13:47:10 UTC 2025

Hello Walter, or anyone else affected,

Accepted openvpn into plucky-proposed. The package will build now and be
available at
https://launchpad.net/ubuntu/+source/openvpn/2.6.14-0ubuntu0.25.04.2 in
a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested, what testing has been
performed on the package and change the tag from verification-needed-
plucky to verification-done-plucky. If it does not fix the bug for you,
please add a comment stating that, and change the tag to verification-
failed-plucky. In either case, without details of your testing we will
not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: openvpn (Ubuntu Plucky)
       Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-plucky

** Changed in: openvpn (Ubuntu Noble)
       Status: In Progress => Fix Committed

** Tags added: verification-needed-noble

-- 
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:
  Fix Released
Status in openvpn source package in Noble:
  Fix Committed
Status in openvpn source package in Oracular:
  Won't Fix
Status in openvpn source package in Plucky:
  Fix Committed
Status in openvpn source package in Questing:
  Fix Released

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