search

adrienverge / openfortivpn

Client for PPP+TLS VPN tunnel services
GNU General Public License v3.0
2.75k stars 323 forks source link

Routes not correctly set #25

Closed paride closed 7 years ago

paride commented 9 years ago

Now that #18 is fixed openfortivpn basically works for me, but I found that the the routing table is not configured correctly, while it is when using the proprietary client.

The proprietary client adds some specific routes for some networks, while openfortivpn just adds a default route, breaking my Internet connection (I already have a working default route that should not be changed).

As a workaround it is possible to use --no-routes and then add the relevant routes manually. If you need more information on this issue just let me know. Thank you!

adrienverge commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Thanks for feedbacking @legovini.

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

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

recompile and try again?

paride commented 9 years ago

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 commented 9 years ago

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 commented 7 years ago

Is there update for this issue?

mrbaseman commented 7 years ago

this should be fixed now that #95 has been merged

DanMan commented 7 years ago

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 commented 7 years ago

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

mrbaseman commented 7 years ago

In the meantime 1.3.1 has been tagged which containsthe fixes

DanMan commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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).