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

Re: network newbie seeks help combining routesets for VPN tunnel



On 1/25/2015 5:13 AM, 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
Matt Ventura Sat, 24 Jan 2015 19:26:48 -0800 [2] (slightly reformatted)
[The new routeset] should look like:
new routeset option 1:

[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 ...
0.0.0.0/0 via ${F5_VPN_ENDPT_IPN} dev ppp0 ...
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.
Well, the OpenVPN client sets that route itself: the problem is, the F5VPN client overwrites it (see above). So I'd need to add it after starting the F5VPN client, producing something like

new routeset option 2: F5VPN routes with 1 added route:

1:  0.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0  proto none  metric 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:  ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0
6:  ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0  proto none  metric 1

Is that the correct order?

After starting the F5 VPN, you might need to [also] re-add the
192.168.1.0/24 dev eth0 ... src ${LOCAL_ETH0_IPN}
so that would be option 3: F5VPN routes with 2 added routes:

1:  192.168.1.0/24 dev eth0  proto kernel  scope link  src ${LOCAL_ETH0_IPN}
2:  0.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0  proto none  metric 1
3:  default via 192.168.1.1 dev eth0  proto static
4:  10.144.0.1 dev ppp0  proto kernel  scope link  src ${F5_VPN_ENDPT_IPN}
5:  128.0.0.0/1 via ${F5_VPN_ENDPT_IPN} dev ppp0  proto none  metric 1
6:  ${OPEN_VPN_PUBLIC_IPN} via 192.168.1.1 dev eth0
7:  ${F5_VPN_PUBLIC_IPN} via ${OPEN_VPN_ENDPT_IPN} dev tun0  proto none  metric 1

Is that the correct order?

thanks again, 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/msg00892.html

Yes. Although the OpenVPN client shouldn't be adding those unless it was configured to do so (or the server pushed instructions to do so), or you're using some frontend like network-manager in which case you'd want to configure that frontend to not do that.

Matt Ventura


Reply to: