[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 6:59 PM, Tom Roche wrote:

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
As Sven Hartge said early in the conversation, the 0.0.0.0/1 and 128.0.0.0/1 essentially form a default route, but it gets higher priority over a normal default route (0.0.0.0/0) because it's slightly more specific. You need to reconfigure your OpenVPN client to not use those two routes (or configure the server to not push them, if it's configured to do so). Or just delete them before starting the F5 VPN.
The route through the F5 VPN should be 0.0.0.0/0 since you won't have any other default route that needs to be overridden. 

So it should look like:
192.168.1.0/24 dev eth0 ... 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 ...
0.0.0.0/0 via ${F5_VPN_ENDPT_IPN} dev ppp0 ...
Actually, ignore that. Come to think of it, the set of routes that the F5 VPN puts in place should work, needing only the addition of "${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0". What I wrote above is the cleanest possible set of routes that would still work, but just adding that one route should fix the existing one. I think you would want to add it just before starting the OpenVPN, otherwise do it right after. After starting the F5 VPN, you might need to re-add the "192.168.1.0/24 dev eth0 ... src ${LOCAL_ETH0_IPN}" route too. 

Matt Ventura
Reply to: