Re: Problem with vpn connection

[Thomas Haller <thaller redhat com>]

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 <thaller 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 <thaller 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

Attachment: signature.asc
Description: This is a digitally signed message part