Tom Roche Sat, 24 Jan 2015 16:00:37 -0500 [1] (envvar names translated to `bash`ian) >> [The "original routeset" on the client/laptop:]
>> 1: default via 192.168.1.1 dev eth0 proto static >> 2: 169.254.0.0/16 dev eth0 scope link metric 1000 >> 3: 192.168.1.0/24 dev eth0 proto kernel scope link src ${LOCAL_ETH0_IPN} >> [OpenVPN routeset, overwrites the original routeset:] >> 1: 0.0.0.0/1 via ${OPEN_VPN_ENDPT_IPN} dev tun0 >> # inherited from "original" route#=1? >> 2: default via 192.168.1.1 dev eth0 proto static >> 3: 10.8.0.1 via ${OPEN_VPN_ENDPT_IPN} dev tun0 >> 4: ${OPEN_VPN_ENDPT_IPN} dev tun0 proto kernel scope link src 10.8.0.6 >> 5: 128.0.0.0/1 via ${OPEN_VPN_ENDPT_IPN} dev tun0 >> # inherited from "original" route#=2? >> 6: 169.254.0.0/16 dev eth0 scope link metric 1000 >> 7: ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 >> # inherited from "original" route#=3? >> 8: 192.168.1.0/24 dev eth0 proto kernel scope link src ${LOCAL_ETH0_IPN} >> [F5VPN routeset, overwrites the OpenVPN routeset:] >> 1: 0.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 >> # inherited from "original" route#=1? >> 2: default via 192.168.1.1 dev eth0 proto static >> 3: 10.144.0.1 dev ppp0 proto kernel scope link src ${F5_VPN_ENDPT_IPN} >> 4: 128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 >> 5: ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0 proto none >> metric 1 Matt Ventura Sat, 24 Jan 2015 19:26:48 -0800 [2] (slightly reformatted) > [The new routeset] should look like: new routeset option 1: > [192.168.1.0/24 dev eth0 proto kernel scope link src ${LOCAL_ETH0_IPN}] > ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 > ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0 ... > 0.0.0.0/0 via ${F5_VPN_ENDPT_IPN} dev ppp0 ... > Come to think of it, the set of routes that the F5 VPN puts in place should > work, needing only the addition of > ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 > What I wrote above is the cleanest possible set of routes that would > still work, but just adding that one route should fix the existing > one. I think you would want to add it just before starting the > OpenVPN, otherwise do it right after. Well, the OpenVPN client sets that route itself: the problem is, the F5VPN client overwrites it (see above). So I'd need to add it after starting the F5VPN client, producing something like new routeset option 2: F5VPN routes with 1 added route: 1: 0.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 2: default via 192.168.1.1 dev eth0 proto static 3: 10.144.0.1 dev ppp0 proto kernel scope link src ${F5_VPN_ENDPT_IPN} 4: 128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 5: ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 6: ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0 proto none metric 1 Is that the correct order? > After starting the F5 VPN, you might need to [also] re-add the > 192.168.1.0/24 dev eth0 ... src ${LOCAL_ETH0_IPN} so that would be option 3: F5VPN routes with 2 added routes: 1: 192.168.1.0/24 dev eth0 proto kernel scope link src ${LOCAL_ETH0_IPN} 2: 0.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 3: default via 192.168.1.1 dev eth0 proto static 4: 10.144.0.1 dev ppp0 proto kernel scope link src ${F5_VPN_ENDPT_IPN} 5: 128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 6: ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 7: ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0 proto none metric 1 Is that the correct order? thanks again, Tom Roche <tom_ro...@pobox.com> [1]: https://lists.debian.org/debian-user/2015/01/msg00882.html [2]: https://lists.debian.org/debian-user/2015/01/msg00892.html -- 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/871tmjroj7....@pobox.com