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_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 -- 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/87bnlnsxl6....@pobox.com