Hi, This actually works :)
Thanks Jeka On Wed, Aug 17, 2016 at 10:42 PM Thomas Haller <thal...@redhat.com> wrote: > On Wed, 2016-08-17 at 19:27 +0000, Jetchko Jekov wrote: > > Hi Tomas, > > > > Unfortunately this doesn't work either. Maybe because 1st VPN server > > pushes 10.0.0.0/8 route and some route optimizations NM is doing, the > > specific route to 2nd VPN server is not added to the routing table. > > I even tried with ignoring pushed routes and adding static routes to > > 10.0.0.0/8 and 10.x.x.x/32 (route to 2nd VPN server), still this > > second route is ignored by NM > > Just for the record: 1st VPN connection is managed by openconnect > > plugin. > > oh, you are right, that is a bug (thanks!) :( > fixed now: > > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ac5dc1a9510c086c54c365b1160a51cc25402010 > > > > In the meantime, how about you don't use 0.0.0.0 as gateway but the > actual (internal) address of the VPN? (see the patch, which only > suppresses the route if it's gateway is 0.0.0.0). > > I think, the gateway doesn't really matter on a tun-device. You may set > it to any 10.x.y.z and it should still work. > > > Thomas > > > > > Br, > > Jeka > > > > > > > > On Tue, Aug 16, 2016 at 11:48 PM Thomas Haller <thal...@redhat.com> > > wrote: > > > On Mon, 2016-08-15 at 21:51 +0000, Jetchko Jekov wrote: > > > > Hi, > > > > > > > > Thanks for clarification. > > > > Although I am little puzzled with NMs view of "best-device". > > > That's > > > > definitely not the default gateway in many cases. > > > > Yes the case I described is not so widely (vpn over vpn) spread > > > but > > > > in my lab I am using VPNs with similar routing all the time. > > > > Fortunately till now I havent tried to use NM for managing these > > > VPN > > > > connections. And now I know why I shouldn't even try it. > > > > > > > > As for your suggestion: > > > > How can I specify a route in format: > > > > 10.87.2.207 dev vpn0 proto static scope link src > > > 10.144.204.217 > > > > ? > > > > > > > > > Hi, > > > > > > in this case, your route is a "device-route", that is a route with > > > a > > > gateway equal to 0.0.0.0 (or on-link, or whatever you call that). > > > > > > You can create such manual routes in NM, so that should work. > > > Choose > > > 0.0.0.0 as gateway. > > > > > > (what you cannot create in NM are manual routes that use as gateway > > > the > > > gateway provided from DHCP/SLAAC/VPN, like openvpn supports with > > > special names "vpn_gateway/net_gateway/remote_host"). > > > > > > You can also not directly specify "proto", "scope" or "src" for the > > > route, but that shouldn't matter for your case. > > > > > > > > > Thomas > > > > > > > To me it seems NM expects next-hop IP address in manual routes > > > > specification. > > > > And in my case I cant know this in advance (this is corporate VPN > > > and > > > > I can land on any of dozens entry points). > > > > > > > > Jeka > > > > > > > > On Mon, Aug 15, 2016 at 7:46 PM Thomas Haller <thal...@redhat.com > > > > > > > > wrote: > > > > > On Sun, 2016-08-14 at 17:44 +0000, Jetchko Jekov wrote: > > > > > > Hi guys, > > > > > > > > > > > > I have following problem: > > > > > > I am trying to setup openvpn connection to VPN server > > > accessible > > > > > not > > > > > > via default gateway. > > > > > > Wnen NM configures vpn connection it sets the route to VPN > > > > > server's > > > > > > IP address wrongly via default gateway. > > > > > > Here is an example: > > > > > > - before activating VPN connection my routing table looks > > > like > > > > > this: > > > > > > > > > > > > default via 192.168.13.1 dev br0 proto static metric 425 > > > > > > 10.0.0.0/8 dev vpn0 proto kernel scope link src > > > 10.144.204.250 > > > > > > metric 50 > > > > > > 10.39.49.28 dev vpn0 proto static scope link src > > > > > 10.144.204.250 > > > > > > metric 425 > > > > > > 172.21.0.0/24 dev virbr0 proto kernel scope link src > > > > > 172.21.0.1 > > > > > > linkdown > > > > > > 192.168.13.0/24 dev br0 proto kernel scope link src > > > > > 192.168.13.11 > > > > > > metric 425 > > > > > > 194.251.119.216 via 192.168.13.1 dev br0 proto static > > > metric > > > > > 425 > > > > > > > > > > > > (yes, the vpn I am trying to connect to is accessible via > > > another > > > > > vpn > > > > > > (split-vpn) connection established in advance, but I guess > > > this > > > > > > doesn't matter) > > > > > > > > > > > > Now, when I activate openvpn connection to server with > > > address > > > > > > 192.167.3.254 accessible via http proxy at 10.39.49.28, > > > > > > and after successful connection my routing table look like > > > this: > > > > > > > > > > > > default via 192.168.13.1 dev br0 proto static metric 425 > > > > > > 10.0.0.0/8 dev vpn0 proto kernel scope link src > > > 10.144.204.250 > > > > > > metric 50 > > > > > > 10.39.49.28 via 192.168.13.1 dev br0 proto static metric > > > 425 > > > > > > 172.21.0.0/24 dev virbr0 proto kernel scope link src > > > > > 172.21.0.1 > > > > > > linkdown > > > > > > 192.167.0.0/16 via 192.167.15.1 dev tun0 proto static > > > metric 50 > > > > > > > > > > > 192.167.15.0/24 dev tun0 proto kernel scope link src > > > > > 192.167.15.66 > > > > > > metric 50 > > > > > > 192.168.13.0/24 dev br0 proto kernel scope link src > > > > > 192.168.13.11 > > > > > > metric 425 > > > > > > 194.251.119.216 via 192.168.13.1 dev br0 proto static > > > metric > > > > > 425 > > > > > > > > > > > > The problem is 3rd line. I have no idea why NM sets route > > > this > > > > > wrong > > > > > > way. > > > > > > If correct this route manually to > > > > > > 10.39.49.28 dev vpn0 proto static scope link src > > > > > 10.144.204.250 > > > > > > metric 425 > > > > > > everything works as expected > > > > > > > > > > > > The question is: Have I missconfigured something on my end or > > > NM > > > > > (or > > > > > > openvpn plugin) is broken in this regard. > > > > > > > > > > > > > > > > hi, > > > > > > > > > > > > > > > NM always associates a VPN connection with the "best-device", > > > that > > > > > is > > > > > the device which currently has the default-route. And then it > > > adds > > > > > a > > > > > direct route to the external gateway via that device. That is a > > > > > current > > > > > short-coming of NM, as it breaks down in your case. > > > > > > > > > > (there is no concrete plan how to fix that yet). > > > > > > > > > > How about you add a manual route to 10.39.49.28 to vpn0 with a > > > > > metric > > > > > lower then 425? > > > > > > > > > > > > > > > Thomas
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
