Re: SIOCDELRT, or: proper syntax to delete default route for an interface?
On 01/23/2015 04:05 AM, Sven Hartge wrote: Matt Ventura mattvent...@mattventura.net wrote: me@client:~$ date ; sudo route -n Thu Jan 22 11:48:48 EST 2015 Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 0.0.0.0 192.168.1.1 0.0.0.0 UG0 00 eth0 10.144.0.1 0.0.0.0 255.255.255.255 UH0 00 ppp0 128.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 134.67.15.3010.8.0.5255.255.255.255 UGH 1 00 tun0 Try it with 0.0.0.0 instead of default. I didn't notice that the netmask was 128.0.0.0 rather than 0.0.0.0. Not sure why it would do that or if that has some kind of special meaning. VPN clients normally use two routes as default route: 0.0.0.0/128.0.0.0(or 0.0.0.0/1) 128.0.0.0/128.0.0.0 (or 128.0.0.0/1) This way, the VPN client does not need to replace the existing default route. Because those two new route are more specific than 0/0, all packages are routed into the tunnel and not to the old default gateway. If the VPN client crashes (or the tunnel interfaces is removed) those two routes are automatically removed too and the old default route is active again. If the client replaced the old default route then you would be left with a system without any default route, because the new one would have been deleted together with the tunnel interface. Grüße, Sven. Well, that confirms my original suspicion. The F5 VPN is throwing its default route over the original one, and that's causing traffic to the OpenVPN server to try to route over the F5 VPN. Obviously this doesn't work because the traffic to the F5 VPN needs to go through the OpenVPN link, so it becomes circular. What you need to do is add a route, something like: route add external IP of OpenVPN server gw 192.168.1.1 dev eth0 so that the traffic to the OpenVPN server can be routed properly. Matt Ventura -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54c2b359.7000...@mattventura.net
Re: SIOCDELRT, or: proper syntax to delete default route for an interface?
Matt Ventura mattvent...@mattventura.net wrote: On 01/23/2015 04:05 AM, Sven Hartge wrote: Matt Ventura mattvent...@mattventura.net wrote: Well, that confirms my original suspicion. The F5 VPN is throwing its default route over the original one, and that's causing traffic to the OpenVPN server to try to route over the F5 VPN. Obviously this doesn't work because the traffic to the F5 VPN needs to go through the OpenVPN link, so it becomes circular. What you need to do is add a route, something like: route add external IP of OpenVPN server gw 192.168.1.1 dev eth0 so that the traffic to the OpenVPN server can be routed properly. This then would complete the Trinity of VPN: one route 0/1, one route 128/1 and one host route to the other VPN endpoint so that it can be reached regardless of other routes. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/abb116082...@mids.svenhartge.de
Re: SIOCDELRT, or: proper syntax to delete default route for an interface?
Matt Ventura mattvent...@mattventura.net wrote: me@client:~$ date ; sudo route -n Thu Jan 22 11:48:48 EST 2015 Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 0.0.0.0 192.168.1.1 0.0.0.0 UG0 00 eth0 10.144.0.1 0.0.0.0 255.255.255.255 UH0 00 ppp0 128.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 134.67.15.3010.8.0.5255.255.255.255 UGH 1 00 tun0 Try it with 0.0.0.0 instead of default. I didn't notice that the netmask was 128.0.0.0 rather than 0.0.0.0. Not sure why it would do that or if that has some kind of special meaning. VPN clients normally use two routes as default route: 0.0.0.0/128.0.0.0(or 0.0.0.0/1) 128.0.0.0/128.0.0.0 (or 128.0.0.0/1) This way, the VPN client does not need to replace the existing default route. Because those two new route are more specific than 0/0, all packages are routed into the tunnel and not to the old default gateway. If the VPN client crashes (or the tunnel interfaces is removed) those two routes are automatically removed too and the old default route is active again. If the client replaced the old default route then you would be left with a system without any default route, because the new one would have been deleted together with the tunnel interface. Grüße, Sven. -- Sigmentation fault. Core dumped. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7bb023u82...@mids.svenhartge.de
Re: SIOCDELRT, or: proper syntax to delete default route for an interface?
On 1/22/2015 3:55 PM, Tom Roche wrote: summary: me@client:~$ sudo route del default ppp0 SIOCDELRT: No such process me@client:~$ sudo route del default dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default gw 10.144.15.234 dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default netmask 128.0.0.0 gw 10.144.15.234 dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default gw 0.0.0.0 dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default netmask 255.255.255.255 gw 0.0.0.0 dev ppp0 SIOCDELRT: No such process details: I'm trying to debug a VPN-related misconfiguration on a laptop (call it the client) which is running me@client:~$ cat /etc/debian_version jessie/sid me@client:~$ uname -rv 3.11-2-amd64 #1 SMP Debian 3.11.8-1 (2013-11-13) me@client:~$ gcc --version | head -n 1 gcc (Debian 4.8.2-1) 4.8.2 me@client:~$ sudo route --version [sudo] password for tlroche: net-tools 1.60 route 1.98 (2001-04-15) +NEW_ADDRT +RTF_IRTT +RTF_REJECT +I18N AF: (inet) +UNIX +INET +INET6 +IPX +AX25 +NETROM +X25 +ATALK +ECONET +ROSE HW: +ETHER +ARC +SLIP +PPP +TUNNEL -TR +AX25 +NETROM +X25 +FR +ROSE +ASH +SIT +FDDI +HIPPI +HDLC/LAPB +EUI64 On this client, I have started an OpenVPN client (after previously starting an OpenVPN server in the cloud), logged into a remote-access website, and used that site's web UI to connect to an F5 SSL VPN (which I want to tunnel through the OpenVPN). (More details on the design goal here[1] and the problem configuration here[2].) This produces me@client:~$ date ; sudo ifconfig Thu Jan 22 11:48:43 EST 2015 eth0 Link encap:Ethernet HWaddromitted/ inet addr:192.168.1.142 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr:omitted/ UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10224715 errors:0 dropped:0 overruns:0 frame:0 TX packets:6011530 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:12886933501 (12.0 GiB) TX bytes:677423768 (646.0 MiB) Interrupt:20 Memory:f260-f262 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:497 errors:0 dropped:0 overruns:0 frame:0 TX packets:497 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:51273 (50.0 KiB) TX bytes:51273 (50.0 KiB) # Note I get slightly different IP#s for interface=ppp0 each time I run this scenario. ppp0 Link encap:Point-to-Point Protocol inet addr:10.144.15.234 P-t-P:10.144.0.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:56 (56.0 B) TX bytes:2418 (2.3 KiB) tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.6 P-t-P:10.8.0.5 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:304 (304.0 B) TX bytes:304 (304.0 B) me@client:~$ date ; sudo route -n Thu Jan 22 11:48:48 EST 2015 Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 0.0.0.0 192.168.1.1 0.0.0.0 UG0 00 eth0 10.144.0.1 0.0.0.0 255.255.255.255 UH0 00 ppp0 128.0.0.0 10.144.15.100 128.0.0.0 UG1 00 ppp0 134.67.15.3010.8.0.5255.255.255.255 UGH 1 00 tun0 Once at that point, I'm directed[3] (IIUC) to delete the default route being set by the F5VPN, for debugging. Furthermore, I need to do this quickly, because (and this is the problem with the current misconfiguration) the misconfiguration causes the OpenVPN tunnel to fail quickly, which breaks the situation I want to debug. Hence it is quite infuriating that I cannot seem to find the correct `route` syntax to do this: me@client:~$ sudo route del default ppp0 SIOCDELRT: No such process me@client:~$ sudo route del default dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default gw 10.144.15.234 dev ppp0 SIOCDELRT: No such process me@client:~$ sudo route del -net default netmask 128.0.0.0 gw 10.144.15.234 dev ppp0 SIOCDELRT: No such process
