Re: network newbie seeks help combining routesets for VPN tunnel
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_Roche@pobox.com>
[1]: https://lists.debian.org/debian-user/2015/01/msg00882.html
[2]: https://lists.debian.org/debian-user/2015/01/msg00886.html
Reply to: