Hey, thanks! I tried to understand your issue and filled the stable update template in the top post, please check if it's correct now :) Once the merge to our development release is accepted, we can continue porting that patch to our stable releases.
** 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 acts as default gateway (so device has source IP 2.2.2.2) + - Second VPN gets set up (from source 2.2.2.2) + - client gets IP 1.1.1.1 + - client gets pushed route to IP 3.3.3.3 with net_gateway (so we reuse the existing gateway from first VPN) + - openvpn 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 (1.2.3.4) 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 1.2.3.4 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 1.2.3.4 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 1.2.3.4 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? + + * 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. + + [ 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- [email protected]/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 Bugs, which is subscribed to Ubuntu. 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 To manage notifications about this bug go to: https://bugs.launchpad.net/openvpn/+bug/2108860/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
