adrienverge / openfortivpn

Client for PPP+TLS VPN tunnel services

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Question: routing table entry created even with --no-routes?

joshi-monster opened this issue · comments

Hi,

this is more of a question than an issue. I also want to apologize in advance if this is not the right place to ask. I don't have much experience with networking/routing, so I might just misunderstand a bunch of things here.

Originally, I ran into #1120. Currently NixOS ships with pppd 2.5.0, and openfortivpn 1.20.5. I added a patch locally to NetworkManager-fortisslvpn to make sure it passes the new --pppd-accept-remote option; this however was not enough to get it to work, I also had to remove the --no-routes option.

As far as I can tell, the plugin passes --no-routes and --no-dns, because NetworkManager wants to set up those itself. This seems to (almost) work, and for me, it produces a routing table that looks like this:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     50     0        0 ppp0
0.0.0.0         192.168.178.1   0.0.0.0         UG    255    0        0 enp33s0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.178.0   0.0.0.0         255.255.255.0   U     100    0        0 enp33s0
192.168.178.1   0.0.0.0         255.255.255.255 UH    50     0        0 enp33s0
XXX.XXX.XXX.XXX 0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
XXX.XXX.XXX.XXX 192.168.178.1   255.255.255.255 UGH   50     0        0 enp33s0
XXX.XXX.XXX.XXX 0.0.0.0         255.255.255.255 UH    50     0        0 ppp0

However, the first route added to the VPN server (XXX.XXX.XXX.XXX, 3rd line from the bottom) seems to cause problems; as I said, I'm not very experienced in network stuff, but from my understanding this does the following:

  • All traffic to XXX.XXX.XXX.XXX is sent to the device ppp0
  • ppp0 is a point-to-point device connected to XXX.XXX.XXX.XXX
  • so it will forward packets to XXX.XXX.XXX.XXX. To figure out where to send it, the kernel looks at the routing table
  • which tells it to send them to the device ppp0

Does this really create an infinite loop? After removing this entry manually everything starts to work.


I played around with openfortivpn from the command line, and figured out that this additional route is (likely) created by pppd itself? The bottom 2 ones are definitely created by NetworkManager, but this one even shows up when starting openfortivpn --no-routes from the command line! When it's allowed to create routes, it even tries to remove this erroneous one! This is the reason why when using openfortivpn instead of NetworkManager to set up the routing table (by not passing --no-routes), everything works.

Why does it only remove this route when --set-routes=1?

At this point I'm mostly lost. My main question here is probably which place to best fix this? pppd definitely has to have a reason why they add this route. NetworkManager might want to control the routing table fully. openfortivpn could apply their fix in all cases or call pppd in a different way (I don't know how). Maybe I failed to understand everything here and really it is just a me problem, so I should add a custom script that does the thing whenever I connect to the VPN?

Sorry this got so rambly.
joshi

I must admit didn't have the time to read everything. However:

  • If using NetworkManager, you'll have to raise issues: https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn
  • Indeed NetworkManager handles routing and DNS changes itself - I cannot recall how exactly at this point.
  • As for openfortivpn on its own:
    • It can modify routing or not (--no-routes)
    • It can modify DNS parameters on its own or not (--no-dns) and/or let pppd modify DNS parameters or not (--pppd-no-peerdns).