You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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
The text was updated successfully, but these errors were encountered:
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: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:XXX.XXX.XXX.XXX
is sent to the deviceppp0
ppp0
is a point-to-point device connected toXXX.XXX.XXX.XXX
XXX.XXX.XXX.XXX
. To figure out where to send it, the kernel looks at the routing tableppp0
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
The text was updated successfully, but these errors were encountered: