[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: network newbie seeks help combining routesets for VPN tunnel

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_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
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
Reply to: