Routes not correctly set #25
Comments
|
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 |
|
Hi @adrienverge, I'm using Debian sid. This is my routing table before running the VPN client: The proprietary client brings to: where 93.XX.40.1 is the VPN remote endpoint. With openfortivpn I get: the routing table is a bit different, but what I see is that the line is missing, and thus the VPN endpoint is not reachable. If I manually run The relevant debugging output of openfortivpn is: so it's not trying to add the missing route. I hope this helps. Thank you! |
|
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 fixrecompile and try again? |
|
Done @adrienverge, now I'm getting this routing table: The route for 93.XX.40.1 is there this time, but the rest is broken... |
|
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. |
|
Is there update for this issue? |
This issue has been discussed in adrienverge#94 (set up routes correctly when ppp0 interface is already there) as a follow-up for adrienverge#90 which implemented that a new ppp device is used when ppp0 is already there. - in ipv4_set_split_routes: add a host route to the gateway (basically copy&paste code from ipv4_set_default_routes) - in ipv4_set_split_routes: merge in the two fixes for issue adrienverge#25 from adrienverge#88: 1) add the gateway flag to the routes received from the remote side. Without the gateway flag the destination is directly connected (over the vpn tunnel), which is not always the case. There might be more hops behind the remote gateway to reach the network to which this route points. 2) correct the test if the route has already a gateway set or not: -1 casted to an unsigned int would result in UINT_MAX which is 255.255.255.255 in IP notation. Routes without a gateway however carry the gateway IP 0.0.0.0 which is 0 written as uint. - in ipv4_set_default_routes: change the route flag to host instead of gateway for the route to the Fortigate. This is important when the existing default route is over a ppp device, because in that case the gateway flag can not be set on linux. Moreover, the gateway flag is not needed here at all, because the vpn traffic is not routed via this ip as a gateway in the sense of a routing instance. The traffic is sent through the vpn channel and the encrypted packages are sent to the remote IP which can be seen as a single host that unpacks the encrypted traffic afterwards. - in ipv4_restore_routes: remove the host route to the gateway which is now added in gateway mode, and properly free resources
|
this should be fixed now that #95 has been merged |
|
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. |
|
It was meged shortly after 1.3 was tagged. It's on the master branch. |
|
In the meantime 1.3.1 has been tagged which containsthe fixes |
|
For me on Fedora 26 it still only works, if I do the routing myself ( The NetworkManager-fortisslvpn plugin doesn't work right either. I have to set up the route(s) manually, too. |
|
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? |
|
This is still an issue ? |
|
@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. |
|
@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. |
|
@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. |
|
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. 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). |
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!
The text was updated successfully, but these errors were encountered: