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- [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
