openfortivpn
openfortivpn copied to clipboard
Question: routing table entry created even with --no-routes?
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 deviceppp0
-
ppp0
is a point-to-point device connected toXXX.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 letpppd
modify DNS parameters or not (--pppd-no-peerdns
).
- It can modify routing or not (