network newbie seeks help combining routesets for VPN tunnel
summary: How to combine/synthesize OpenVPN and F5VPN routesets, so that
the F5VPN can tunnel through the OpenVPN? 3 more specific questions @ end.
details:
my intent [1]
>>> <-my control | agency control->
>>> |
>>> (DHCP from ISP) (static) | (per-connection)
>>> CLI.ENT.IP.NUM SER.VER.IP.NUM | F5.VPN.IP.NUM firewall
>>> +-----------+ +-----------+ | +---------------+ || +---------+
>>> | laptop + | | linode + | | | remote-access | || | cluster |
>>> | OpenVPN | <--> | OpenVPN | <-|-> | website + | <-||-> | node(s) |
>>> | client + | | server + | | | F5VPN server | || | |
>>> | F5 client | | other | | | | || | |
>>> | | | security | | | | || | |
>>> +-----------+ +-----------+ | +---------------+ || +---------+
Matt Ventura Fri, 23 Jan 2015 12:47:21 -0800 [2]
>> 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.
Sven Hartge Fri, 23 Jan 2015 21:53:35 +0100 [3] (tweaked)
> That would complete the VPN Trinity:
> * one route 0.0.0.0/1
> * one route 128.0.0.0/1
> * one host route to the other VPN endpoint (making it reachable regardless of other routes)
I'm looking at the following client routesets (as reported by `ip route show` and am not seeing how to combine them. This is the "original routeset" put on my client/laptop (by ... some combination of Debian and my ISP?) (line numbers added):
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 192.168.1.142
This is the routeset put on my client/laptop by the OpenVPN client
1: 0.0.0.0/1 via 10.8.0.5 dev tun0
# inherited from "original" route#=1?
2: default via 192.168.1.1 dev eth0 proto static
3: 10.8.0.1 via 10.8.0.5 dev tun0
4: 10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
5: 128.0.0.0/1 via 10.8.0.5 dev tun0
# inherited from "original" route#=2?
6: 169.254.0.0/16 dev eth0 scope link metric 1000
7: SER.VER.IP.NUM 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 192.168.1.142
where SER.VER.IP.NUM==relatively static IP# of the {linode, OpenVPN server}, which the F5VPN server needs to see.
This is the routeset put on my client/laptop by the F5NAP[4] (aka F5VPN client), overwriting the OpenVPN client routeset:
1: 0.0.0.0/1 via 10.144.1.8 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 10.144.1.8
4: 128.0.0.0/1 via 10.144.1.8 dev ppp0 proto none metric 1
5: F5.VPN.IP.NUM via 10.8.0.5 dev tun0 proto none metric 1
So the question is, how to synthesize (in the dialectic sense[5]) the two routesets into one that will make both VPNs happy and achieve my goals[1]? Note that
0. In "the productive past"[6], after my client/laptop connected to the F5VPN[7], *all* IP traffic from the client/laptop routed through the F5VPN. This was annoying (due to, e.g., inability to SMTP (disallowed service), general sluggishness, belief that all my traffic was being logged by the agency), but *did* allow me to SSH into the agency's clusters, which is my primary need.
1. For now, I'm just trying to have *all* IP traffic from my client/laptop routed through the OpenVPN server (so that it "shows" the OpenVPN server's IP#, which is registered/whitelisted with the F5VPN) to the F5VPN server. That *should* allow me to resume SSHing into the clusters.
2. Ultimately, I'd like to redesign such that I could separately route (only) SSH traffic through the VPNs, with other traffic going through my ISP's modem "normally."
I suspect something like the following routeset is needed, but see questions (embedded and following), and note `ip route` syntax (I suspect I can translate from `route` syntax if needed, but I like the way I can plug `ip route show` results directly into `ip route add` and `ip route del`):
# 1st route in Hartge's Trinity == OpenVPN route#=1 (compare with F5VPN route#=1)
1: 0.0.0.0/1 via 10.8.0.5 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 10.8.0.5 dev tun0
# OpenVPN route#=4 , but what is the difference between 'src' and 'via'?
4: 10.8.0.5 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 10.144.1.8
# 2nd route in Hartge's Trinity == OpenVPN route#=5 (compare with F5VPN route#=4)
6: 128.0.0.0/1 via 10.8.0.5 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: SER.VER.IP.NUM via 192.168.1.1 dev eth0
# almost F5VPN route#=5 ... but which dev should this take? eth0, ppp0, tun0?
9: F5.VPN.IP.NUM via 10.8.0.5 dev ???? proto none metric 1
# inherited from "original" route#=3 == OpenVPN route#=8 (absent in F5VPN routeset)
10: 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.142
Question 1: what is the difference between 'src' and 'via' in `ip route` syntax? I see
`info ip-route`
>>>> via ADDRESS
>>>> the address of the nexthop router. [The] sense of this field depends on the route type.
>>>> For normal unicast routes it is either the true next hop router or,
>>>> if it is a direct route installed in BSD compatibility mode, it can be a local address of the interface.
>>>> For NAT routes it is the first address of the block of translated IP destinations.
>>>> src ADDRESS
>>>> the source address to prefer when sending to the destinations covered by the route prefix.
but am not sure how to apply this knowledge to route statements.
Question 2: which dev[ice] should traffic to F5.VPN.IP.NUM go on? Such traffic has gotta go via the OpenVPN server == SER.VER.IP.NUM (which is usually serviced by `dev tun0`) but ultimately wants to go to F5.VPN.IP.NUM (which is usually serviced by `dev ppp0`).
Question 3: What am I missing? Conversely, what do I have that is superfluous?
Your assistance is appreciated! Tom Roche <Tom_Roche@pobox.com>
[1]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/Home#rst-header-intended-solution
[2]: https://lists.debian.org/debian-user/2015/01/msg00830.html
[3]: https://lists.debian.org/debian-user/2015/01/msg00831.html
[4]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/Home#rst-header-f5nap
[5]: https://en.wikipedia.org/wiki/Thesis,_antithesis,_synthesis
[6]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/Home#rst-header-productive-past
[7]: https://bitbucket.org/tlroche/linode_jumpbox_config/wiki/Home#rst-header-f5vpn-only-connection
Reply to: