Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
On Fri, Mar 31, 2017 at 12:14:29AM +0200, Thomas Schäfer wrote: > By the way. > It works. (with 2.4.1) Glad to hear that! Thanks for reporting back. Cheers, -- Antonio Quartulli signature.asc Description: Digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
By the way. It works. (with 2.4.1) Thomas -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Hi, following up on the thread starter... On Wed, Jan 18, 2017 at 04:43:22PM +0100, Thomas Schäfer wrote: > This works perfectly as long the client has still an IPv4-connection. > > But in case of an IPv6-only-client (not system-wide disabled, just not > getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't > set the IPv4-default route, since it can not find the old one. This has been fixed (thanks, Antonio), and the fix will be in the upcoming 2.4.1 release - no fixed date has been set but "in the next few weeks" or so. Thanks for reporting this application silliness :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Hi, On Thu, Jan 19, 2017 at 02:42:18PM +0100, Thomas Schäfer wrote: > > In case "def1" is not enough, please try "redirect-gateway def1 local", > > which is a hack (but a documented one). "local" signals "do not install > > a host route pointing to the default gateway, because the VPN server is > > in the same locally connected network" (think "university wifi"). So that > > should make things succeed. > This did not work. Same error as before. This is a bit annoying. It does not need the default gateway when it's not going to use it. *Flag as bug*. > > If that is still not working, use brute force, and replace > > "redirect-gateway" > > with > > > > route 0.0.0.0/1 > > route 128.0.0.0/1 > > This leads to: > > Thu Jan 19 14:10:43 2017 RESOLVE: Cannot resolve host address: > 128.0.0.0/1: (Name or service not known) Uh. Sorry. Forgot that this is still netmask-land. > But > > route 0.0.0.0 128.0.0.0 > route 128.0.0.0 128.0.0.0 > > works. This is how the syntax should be. Thanks for testing, happy to finally reach a working solution :-) - and I'll put "rework that v4 stuff" on my limitless TODO list... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Am 18.01.2017 um 20:35 schrieb Gert Doering: > Servus, > > On Wed, Jan 18, 2017 at 04:43:22PM +0100, Thomas Schäfer wrote: >> Client: >> client >> dev tun >> proto udp6 >> remote raspberrypi..myfritz.net 1194 udp6 > [..] >> redirect-gateway >> verb 3 >> >> This works perfectly as long the client has still an IPv4-connection. >> >> But in case of an IPv6-only-client (not system-wide disabled, just not >> getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't >> set the IPv4-default route, since it can not find the old one. > > I can see the problem. > > The most elegant solution might be to use "redirect-gateway def1". The > "def1" flag instructs the code to not add a 0.0.0.0/0 route (replacing > and later restoring the existing default route) but to add 0.0.0.0/1 and > 128.0.0.0/1 routes - which cover "the default" as well, but do not > need to interfere with the existing /0 route. This did not work. Same error as before. > > In case "def1" is not enough, please try "redirect-gateway def1 local", > which is a hack (but a documented one). "local" signals "do not install > a host route pointing to the default gateway, because the VPN server is > in the same locally connected network" (think "university wifi"). So that > should make things succeed. This did not work. Same error as before. > > > If that is still not working, use brute force, and replace "redirect-gateway" > with > > route 0.0.0.0/1 > route 128.0.0.0/1 This leads to: Thu Jan 19 14:10:43 2017 RESOLVE: Cannot resolve host address: 128.0.0.0/1: (Name or service not known) Thu Jan 19 14:10:43 2017 OpenVPN ROUTE: failed to parse/resolve route for host/network: 128.0.0.0/1 Thu Jan 19 14:10:43 2017 RESOLVE: Cannot resolve host address: 0.0.0.0/1: (Name or service not known) Thu Jan 19 14:10:43 2017 OpenVPN ROUTE: failed to parse/resolve route for host/network: 0.0.0.0/1 > > in the client config - that is the same thing as "def1 local" should give > you, but explicitely only the "two half-default routes". But route 0.0.0.0 128.0.0.0 route 128.0.0.0 128.0.0.0 works. Thomas -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Servus, On Wed, Jan 18, 2017 at 04:43:22PM +0100, Thomas Schäfer wrote: > Client: > client > dev tun > proto udp6 > remote raspberrypi..myfritz.net 1194 udp6 [..] > redirect-gateway > verb 3 > > This works perfectly as long the client has still an IPv4-connection. > > But in case of an IPv6-only-client (not system-wide disabled, just not > getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't > set the IPv4-default route, since it can not find the old one. I can see the problem. The most elegant solution might be to use "redirect-gateway def1". The "def1" flag instructs the code to not add a 0.0.0.0/0 route (replacing and later restoring the existing default route) but to add 0.0.0.0/1 and 128.0.0.0/1 routes - which cover "the default" as well, but do not need to interfere with the existing /0 route. It might *still* fail, as the code might still want to check and install a v4 /32 host route for the VPN gateway, pointing to the existing default gateway. Which is arguably something that should not be done if we're not talking v4 in the first place, but I'm not sure that part of the code was ever adapted (I'd love to see a log with "def1" :-) ) - the v6 part is smart enough to only try looking at v6 routing tables if we're connecting over v6. In case "def1" is not enough, please try "redirect-gateway def1 local", which is a hack (but a documented one). "local" signals "do not install a host route pointing to the default gateway, because the VPN server is in the same locally connected network" (think "university wifi"). So that should make things succeed. If that is still not working, use brute force, and replace "redirect-gateway" with route 0.0.0.0/1 route 128.0.0.0/1 in the client config - that is the same thing as "def1 local" should give you, but explicitely only the "two half-default routes". (Whatever the outcome of your tests, I think our code should be smarter - the v4 code is 10+ years old, and has grown over time, and parts of it have been contributed by non-networking folks...) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de signature.asc Description: PGP signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] NOTE: unable to redirect default gateway -- Cannot read current default gateway from system
Hi, In case of being totally wrong here, please redirect me to the right place (bug-systems, forum,...). Some words about the configuration: Server: shares a private IPv4-Network and ula-IPv6-Network IPv4-Adresses also NATed to the public. proto udp6 dev tun ca ca.crt cert server.crt key server.key dh dh2048.pem server 192.168.178.128 255.255.255.128 server-ipv6 fd00::1:1/112 push "route 192.168.178.0 255.255.255.0" push "route-ipv6 fd00::/64" keepalive 10 120 verb 3 Client: client dev tun proto udp6 remote raspberrypi..myfritz.net 1194 udp6 ca ca.crt cert client.crt key client.key remote-cert-tls server redirect-gateway verb 3 This works perfectly as long the client has still an IPv4-connection. But in case of an IPv6-only-client (not system-wide disabled, just not getting IPv4-addresses by the ISP, e.g. eduroam-IPv6) the client doesn't set the IPv4-default route, since it can not find the old one. Regards, Thomas openvpn --config client.ovpn Wed Jan 18 16:11:34 2017 OpenVPN 2.4.0 x86_64-suse-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 27 2016 Wed Jan 18 16:11:34 2017 library versions: OpenSSL 1.0.2j-fips 26 Sep 2016, LZO 2.08 Wed Jan 18 16:11:34 2017 TCP/UDP: Preserving recently used remote address: [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:34 2017 Socket Buffers: R=[212992->212992] S=[212992->212992] Wed Jan 18 16:11:34 2017 setsockopt(IPV6_V6ONLY=0) Wed Jan 18 16:11:34 2017 UDPv6 link local (bound): [AF_INET6][undef]:1194 Wed Jan 18 16:11:34 2017 UDPv6 link remote: [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:34 2017 TLS: Initial packet from [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194, sid=f70817fa 1f034096 Wed Jan 18 16:11:34 2017 VERIFY OK: depth=1, C=KG, ST=NA, L=BISHKEK, O=OpenVPN-TEST, emailAddress=me@myhost.mydomain Wed Jan 18 16:11:34 2017 Validating certificate key usage Wed Jan 18 16:11:34 2017 ++ Certificate has key usage 00a0, expects 00a0 Wed Jan 18 16:11:34 2017 VERIFY KU OK Wed Jan 18 16:11:34 2017 Validating certificate extended key usage Wed Jan 18 16:11:34 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication Wed Jan 18 16:11:34 2017 VERIFY EKU OK Wed Jan 18 16:11:34 2017 VERIFY OK: depth=0, C=KG, ST=NA, O=OpenVPN-TEST, CN=Test-Server, emailAddress=me@myhost.mydomain Wed Jan 18 16:11:34 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Wed Jan 18 16:11:34 2017 [Test-Server] Peer Connection Initiated with [AF_INET6]2003:63:2417:f900:ba27:ebff:feb6:f293:1194 Wed Jan 18 16:11:36 2017 SENT CONTROL [Test-Server]: 'PUSH_REQUEST' (status=1) Wed Jan 18 16:11:36 2017 PUSH: Received control message: 'PUSH_REPLY,route 192.168.178.0 255.255.255.0,route-ipv6 fd00::/64,tun-ipv6,route 192.168.178.129,topology net30,ping 10,ping-restart 120,ifconfig-ipv6 fd00::1:1001/112 fd00::1:2,ifconfig 192.168.178.134 192.168.178.133,peer-id 0,cipher AES-256-GCM' Wed Jan 18 16:11:36 2017 Note: option tun-ipv6 is ignored because modern operating systems do not need special IPv6 tun handling anymore. Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: timers and/or timeouts modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: --ifconfig/up options modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: route options modified Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: peer-id set Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: adjusting link_mtu to 1624 Wed Jan 18 16:11:36 2017 OPTIONS IMPORT: data channel crypto options modified Wed Jan 18 16:11:36 2017 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Jan 18 16:11:36 2017 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key Wed Jan 18 16:11:36 2017 ROUTE: default_gateway=UNDEF Wed Jan 18 16:11:36 2017 GDG6: remote_host_ipv6=2003:63:2417:f900:ba27:ebff:feb6:f293 Wed Jan 18 16:11:36 2017 ROUTE6_GATEWAY fe80::da67:d9ff:fe6e:a242 IFACE=wlan0 Wed Jan 18 16:11:36 2017 TUN/TAP device tun0 opened Wed Jan 18 16:11:36 2017 TUN/TAP TX queue length set to 100 Wed Jan 18 16:11:36 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=1 Wed Jan 18 16:11:36 2017 /bin/ip link set dev tun0 up mtu 1500 Wed Jan 18 16:11:36 2017 /bin/ip addr add dev tun0 local 192.168.178.134 peer 192.168.178.133 Wed Jan 18 16:11:36 2017 /bin/ip -6 addr add fd00::1:1001/112 dev tun0 Wed Jan 18 16:11:36 2017 NOTE: unable to redirect default gateway -- Cannot read current default gateway from system Wed Jan 18 16:11:36 2017 /bin/ip route add 192.168.178.0/24 via 192.168.178.133 Wed Jan 18 16:11:36 2017 /bin/ip route add 192.168.178.129/32 via 192.168.178.133 Wed Jan 18 16:11:36 2017 add_route_ipv6(fd00::/64 -> fd00::1:2 metric -1) dev tun0 Wed Jan 18 16:11:36 2017 /bin/ip -6 route add fd00::/64 dev tun0 Wed Jan 18 16:11:36 2017 Initialization Sequence Completed -- Check out the vibrant tech
