Routes not correctly set about openfortivpn

[adrienverge]

Before setting the new default route, openfortivpn backs up the current default, and adds a route to the VPN gateway (using the current default). It seems like it's not working on your system: which GNU/Linux are you running? You could set openfortivpn in debug mode to get more info (and look for ip route add/del lines).

[paride]

Hi @adrienverge, I'm using Debian sid. This is my routing table before running the VPN client:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

The proprietary client brings to:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlan0
10.0.0.0        172.16.0.4      255.128.0.0     UG    0      0        0 ppp0
10.100.70.15    172.16.0.4      255.255.255.255 UGH   0      0        0 ppp0
10.128.0.0      172.16.0.4      255.128.0.0     UG    0      0        0 ppp0
93.XX.40.0      172.16.0.4      255.255.255.0   UG    0      0        0 ppp0
93.XX.40.1      192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

where 93.XX.40.1 is the VPN remote endpoint. With openfortivpn I get:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlan0
1.1.1.1         0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        172.16.0.4      255.128.0.0     UG    0      0        0 ppp0
10.10.0.4       172.16.0.4      255.255.255.255 UGH   0      0        0 ppp0
10.100.70.15    172.16.0.4      255.255.255.255 UGH   0      0        0 ppp0
10.128.0.0      172.16.0.4      255.128.0.0     UG    0      0        0 ppp0
93.XX.40.0      172.16.0.4      255.255.255.0   UG    0      0        0 ppp0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

the routing table is a bit different, but what I see is that the line

93.XX.40.1      192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0

is missing, and thus the VPN endpoint is not reachable. If I manually run route add 93.XX.40.1 gw 192.168.1.1 the problem is fixed.

The relevant debugging output of openfortivpn is:

INFO:   Setting new routes...
DEBUG:  ip route add to 10.0.0.0/255.128.0.0 via 172.16.0.4 dev ppp0
DEBUG:  ip route add to 93.XX.40.0/255.255.255.0 via 172.16.0.4 dev ppp0
DEBUG:  ip route add to 10.128.0.0/255.128.0.0 via 172.16.0.4 dev ppp0
DEBUG:  ip route add to 10.100.70.15/255.255.255.255 via 172.16.0.4 dev ppp0
DEBUG:  ip route add to 93.XX.40.0/255.255.255.0 via 172.16.0.4 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.10.0.4/255.255.255.255 via 172.16.0.4 dev ppp0
DEBUG:  ip route add to 10.0.0.0/255.128.0.0 via 172.16.0.4 dev ppp0
WARN:   Route to gateway exists already.
DEBUG:  ip route add to 10.128.0.0/255.128.0.0 via 172.16.0.4 dev ppp0
WARN:   Route to gateway exists already.
INFO:   Adding VPN nameservers...

so it's not trying to add the missing route. I hope this helps. Thank you!

[adrienverge]

Thanks for feedbacking @legovini.

What you describe shouldn't happen. This might be a side-effect of commit 7dca981. Could you:

git checkout 38a85d1     # go back before suspicious commit
git cherry-pick 8a4ca14  # apply Davíð's fix

recompile and try again?

[paride]

Done @adrienverge, now I'm getting this routing table:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp0
1.1.1.1         0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
93.XX.40.1      192.168.1.1     255.255.255.255 UGH   0      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlan0

The route for 93.XX.40.1 is there this time, but the rest is broken...
The debugging output is:

INFO:   Setting new routes...
DEBUG:  ip route show to 0.0.0.0/0.0.0.0
DEBUG:  Setting route to tunnel gateway...
DEBUG:  ip route add to 93.XX.40.1/255.255.255.255 via 192.168.1.1 dev wlan0
WARN:   Route to gateway exists already.
DEBUG:  Deleting the current default route...
DEBUG:  ip route del to 0.0.0.0/0.0.0.0 via 192.168.1.1 dev wlan0
DEBUG:  Setting new default route...
DEBUG:  ip route add to 0.0.0.0/0.0.0.0 dev ppp0
INFO:   Adding VPN nameservers...

[adrienverge]

Strange... I guess openfortivpn route and DNS handling is pretty poor. :-(

I think the best solution would be to plug into a real network daemon (systemd-networkd, NetworkManager, etc.) and stop trying to manage routes at openfortivpn's level. But I don't have any time for that.

For NetworkManager users I recommend using @lkundrak's NetworkManager-fortisslvpn plugin.

[Valantin]

Is there update for this issue?

[mrbaseman]

this should be fixed now that #95 has been merged

[DanMan]

This is not in the deployed 1.3 version is it? Because I still have the same problems there. It sets up routes that don't work and kills my default one, so I can't connect to the websites in the browser either.

[mrbaseman]

It was meged shortly after 1.3 was tagged. It's on the master branch.

[mrbaseman]

In the meantime 1.3.1 has been tagged which containsthe fixes

[DanMan]

For me on Fedora 26 it still only works, if I do the routing myself (--no-routes switch). The automatically created routes keep breaking my general Internet connection. The network icon even switches to "disconnected". That's with v1.5.0.

The NetworkManager-fortisslvpn plugin doesn't work right either. I have to set up the route(s) manually, too.

[mrbaseman]

Not being able to connect to the internet may be intended behavior. If your fortigate is configured with ssl vpn tunnel mode it simply replaces your default route by one that goes throuh the vpn connection. From there it is up to the admin of the fortigate to set up rules that allow internet access, or do deep inspection in order to scan for viruses, malicious email attachments, botnet activity, etc. Are you sure that split tunnel mode should be expected? If yes, how do the routes look like when openfortivpn configures them? And can you access anything on the other side of the vpn channel?

[CristianCardosoA]

This is still an issue ?
I'm using Fedora 26, NetworkManager-fortisslvpn.x86_64
Iḿ getting this issue after vpn is connected: platform-linux: do-add-ip4-route[7: 0.0.0.0/0 50]: failure 100 (Network is down)

[DimitriPapadopoulos]

@CristianCardosoA I recommend you open a new ticket. Multiple issues have been reported here, it's hard to tell if "this" is still an issue. Does the proprietary FortiClient work but not openfortivpn in your case? Please provide this information and complete error output in the new ticket.

And yes, the initial issue looks like it has been fixed.

[DanMan]

@mrbaseman I'm using that VPN tunnel only to connect to servers from one of our customers. I don't want it to change anything else about my network setup, only to allow access to those. If that's a special use-case, then so be it. I can post the created auto-routes later. I'm not at office atm. I think I can connect to the servers behind the VPN, but nothing else.

[DimitriPapadopoulos]

@DanMan I am under the impression that the FortiGate configuration describes the desired routes. The client configuration just follows the instructions of the FortiGate device. @mrbaseman understands the details of routing much better than me, but I would be worried if the client could override (easily and out-of-the-box) the routes requested by the FortiGate device.

[mrbaseman]

There are two operation modes of Fortinet's ssl vpn, "split tunnel mode enabled" vs. "disabled". If it is configured "enabled" on the Fortigate, then routes to each network for which access rules are configure are pushed to the client. Then, the "normal internet connection" keeps working.

If "split tunnel mode" is disabled, a new default route through the tunnel is pushed to the client, so that all traffic should go throught the tunnel when the connection is up. In this case, the administrator of the Fortigate can put further firewall rules to allow or deny traffic to the "normal internet" depending on the type of traffic, the user accounts, etc.
I think this is what you are seeing and it is intended behavior. To prevent data leakage "normal internet connection" is prohibited while you are connected to those servers.

One should add another remark: It is not a strong enforcement, because as administrator of the client machine, you can always decide not to set up the routes pushed by the Fortigate (you have already noticed this). You can manually set up additional routes to allow "normal internet traffic" through your regular network interface bypassing the tunnel, or you can configure host routes or routes to smaller network segments that have higher priority than the default route. You can permanently configure such routes beforehand and these routes stay there when you are connected to the vpn, and these routes still have higher priority than the modified default route. (I have seen these scenarios described somewhere in Fortinets VPN admin guide. At the moment I don't have the reference at hand, sorry).