On 1/24/2015 1:00 PM, Tom Roche wrote:
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
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_ro...@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
Well, you don't need the 169 route unless you're actually doing
something with link-local addresses.
You may want to just reconfigure the OpenVPN to not be used as a default
route, but rather to just route traffic for any IPs needed for the
operation of the F5 VPN to go through the OpenVPN. There's no real need
for the OpenVPN link to ever be a default route since the F5 VPN
overrides that.
Basically, your final routing table, in plain English, should look like
this:
1. Traffic to 192.168.1.0/24 should go through eth0
2. Traffic to the OpenVPN server's external IP should go through eth0 to
192.168.1.1
3. Traffic to the F5 VPN server's external IP (I assume this is the
134.x.x.x one) should go through the OpenVPN ptp endpoint (10.8.0.5)
4. All other traffic should go through the F5 VPN's ptp endpoint
(10.144.x.x).
The F5 client seems to be adamant about having route #4 in place, so we
don't need to worry about that. As mentioned above, you should remove
the default routing to the OpenVPN server and just have 134.x.x.x route
through the 10.8.0.5, rather than 0/1 and 128/1. #2 is something you'll
probably need to manually add before (or after, not sure) starting the
F5 VPN. #1 shouldn't ever be touched by either VPN.
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/54c42517.2060...@mattventura.net