Cool. I updated the [Impact] so it better reflects how I'd describe the situation.
** 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) + - 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 + 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 : + https://openvpn.net/community-docs/routing-all-client-traffic--including-web-traffic--through-the-vpn.html : - push "redirect-gateway def1" + push "redirect-gateway def1" - NOTE: You can actually use a pre-existing VPN as server1, doesn't have + 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 + 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 1.2.3.4 255.255.255.255 net_gateway" + 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 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 - ... + 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 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' + 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? + * 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. + * 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 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. + * 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
