Hi Bryce! Thanks. I was actually not at my limit yet, and I think Jonas's reply was sufficient to get me going (which may expediate things in future bug reports). But now that you've picked it up, I'll happily hand it over.
[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. [Testing Done Locally] I see that your Questling has FTBFS ( https://bugs.launchpad.net/ubuntu/+source/openvpn/+bug/2120871 ) , so I cannot test your binary build from https://launchpad.net/~bryce/+archive/ubuntu/openvpn-fix- lp2108860/+packages . I did test my handle_intentional_route_push_float_ip.patch on top of 2.6.14-0ubuntu0.24.04.1 on Noble and it works there. [Edit] * Clarified that server1 doesn't need to be openvpn. * Clarified that the patch needs to be applied to server2. -- 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
