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 >> [my proposed new routeset:] >> # 1st route in Hartge's Trinity == OpenVPN route#=1 (compare with F5VPN >> route#=1) >> 1: 0.0.0.0/1 via OPEN_VPN_ENDPT_IPN dev tun0 >> # inherited from "original" route#=1 == OpenVPN route#=2 == F5VPN >> route#=2 >> 2: default via 192.168.1.1 dev eth0 proto static >> # OpenVPN route#=3 >> 3: 10.8.0.1 via OPEN_VPN_ENDPT_IPN dev tun0 >> # OpenVPN route#=4 , but what is the difference between 'src' and 'via'? >> 4: OPEN_VPN_ENDPT_IPN dev tun0 proto kernel scope link src 10.8.0.6 >> # F5VPN route#=3 >> 5: 10.144.0.1 dev ppp0 proto kernel scope link src F5_VPN_ENDPT_IPN >> # 2nd route in Hartge's Trinity == OpenVPN route#=5 (compare with F5VPN >> route#=4) >> 6: 128.0.0.0/1 via OPEN_VPN_ENDPT_IPN dev tun0 >> # inherited from "original" route#=2 == OpenVPN route#=6 (absent in >> F5VPN routeset) >> 7: 169.254.0.0/16 dev eth0 scope link metric 1000 >> # OpenVPN route#=7 >> 8: OPEN_VPN_PUBLIC_IPN via 192.168.1.1 dev eth0 >> # almost F5VPN route#=5 ... but which dev should this take? eth0, ppp0, >> tun0? >> 9: F5_VPN_PUBLIC_IPN via OPEN_VPN_ENDPT_IPN dev ???? proto none metric 1 >> # inherited from "original" route#=3 == OpenVPN route#=8 (absent in >> F5VPN routeset) >> 10: default via 192.168.1.1 dev eth0 proto static Matt Ventura Sat, 24 Jan 2015 15:04:55 -0800 [2] (slightly rearranged) > Basically, your final routing table, in plain English, always tricky, that plain English :-) > should look like this: Please correct me where I get it wrong: > 1. Traffic to 192.168.1.0/24 should go through eth0 192.168.1.0/24 dev eth0 proto kernel scope link src ${LOCAL_ETH0_IPN} which is original route#=3 == OpenVPN route#=8 > #1 shouldn't ever be touched by either VPN. OpenVPN respects it, but F5VPN removes it! > 2. Traffic to the OpenVPN server's external IP should go through eth0 to > 192.168.1.1 ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0 which is OpenVPN route#=7 > #2 is something you'll probably need to manually add before (or after, not > sure) starting the F5 VPN. I should be able to script that (more below). > 3. Traffic to the F5 VPN server's external IP (I assume this is the 134.x.x.x > one) (correct, though F5_VPN_PUBLIC_IPN changes per-connection, hence the parameterization) > should go through the OpenVPN ptp endpoint (10.8.0.5) on dev=tun0? I.e. ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0 proto none metric 1 If so, that's F5VPN route#=5 > 4. All other traffic should go through the F5 VPN's ptp endpoint (10.144.x.x). Does '128.0.0.0/1' == 'all other traffic'? If so, 128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 is F5VPN route#=4 > The F5 client seems to be adamant about having route #4 in place, so we don't > need to worry about that. OK. > As mentioned above, you should remove the default routing to the OpenVPN > server i.e., proposed route#={1, 3, 4}, which are also OpenVPN route#={1, 3, 4} > and just have [F5_VPN_PUBLIC_IPN] route through the 10.8.0.5, rather than 0/1 > and 128/1. i.e., F5VPN route#=5. But then (IIUC) we're routing 128.0.0.0/1 but not 0.0.0.0/1. If so, does 0.0.0.0/1 not need routed? (And why did I not take the networking elective when I got my BSCS ?-( Meanwhile, assuming I understand correctly, it sounds like, after I start the F5VPN client on my client/laptop, I need to produce the routes given above with something like the following bash scriptlet: ### IP-related envvars ## (hopefully) constant IP addresses # public IP# (as visible to, e.g., whatismyip.com) of linode/jumpbox running OpenVPN server OPEN_VPN_PUBLIC_IPN='whatever I register' # the default pseudo-address configured by OpenVPN: I suspect this is canonical # (ICBW, if so will need to scrape) OPEN_VPN_ENDPT_IPN='10.8.0.5' ## variable IP addresses # I can scrape the IP# of the client/laptop dev=eth0 with bash like # FOO1="$(sudo ip addr show dev eth0 | fgrep -e 'inet ')" # FOO2="${FOO1##*inet }" # LOCAL_ETH0_IPN="${FOO2%%/*}" LOCAL_ETH0_IPN='192.168.1.142' # I'll need to scrape the public IP# of the F5VPN server from the routeset self-set by the F5VPN client # (since I know this gets set per-connection) F5_VPN_PUBLIC_IPN='whatever they set it to' # 134.x.x.x # I'll need to scrape the pseudo-addr of the IP# of the F5VPN server from the routeset self-set by the F5VPN client F5_VPN_ENDPT_IPN='whatever they set it to' # was 10.144.1.8 ### the actual routeset 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 proto none metric 1 128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0 proto none metric 1 I'll get started on that; meanwhile, please lemme know if I'm missing or misunderstanding anything. But please understand that your assistance is very much appreciated! 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/msg00886.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/874mrfsgzr....@pobox.com