set up routes correctly when ppp0 interface is already there

[mrbaseman]

as discussed in pull request #90 which implemented that a new ppp device is used when ppp0 is already there, I have noticed a problem when the vpn pushes a new default route over the new ppp1 interface.
In that particular case adding the gateway route fails in ipv4_set_default_routes with the following debug output:

DEBUG: ip route add to A.B.C.D/255.255.255.255 via 0.0.0.0 dev ppp0
WARN: Could not set route to tunnel gateway (Invalid argument).

Adding a host route over ppp0 before starting openvpn makes the tunnel work. The above warning still appears then, but the tunnel works. Comparing the routing entries I found that in this case the flags are sligtly different. Instead of
gtw_rt->rt_flags |= RTF_GATEWAY;
one would have to put:
gtw_rt->rt_flags |= RTF_HOST;
However, when I try to open a vpn connection to another gateway, which does not push a default route, the code is needed as it is. This is in the early stage, before the routes etc. are received, so I'm not sure how to handle this decision. Maybe we should add an option to the config file (something like is-gateway or host-route or additional-flags...) which is used here and allows us to control the setup of the routes. Any suggestions? I'm willing to implement and test this, but @adrienverge, I would like to have your opinion which path I should follow.

[Mabin-J]

I think that changing 321st line of ipv4.c is enough for fix issue of warning message because 'ipv4_set_default_routes' function is only called when it is set 'default gateway mode(?)'.

Apart from this issue, I think that adding a route for VPN server is needed when it is set not only 'default gateway mode' but also 'split routes mode(?).'

When I connect 'A.B.C.D' IP of VPN Server that contains 'A.B.C.0/24' route in 'split routing table,' Packets cannot be passed through VPN because 'A.B.C.0/24' route.

So, I have a plan that I'll insert logic that adding a default route for server's IP.

(Maybe my issue is like #25)

[mrbaseman]

@Mabin-J: Thanks for your input. You are right: 'ipv4_set_default_routes' function is only called when the config on the Fortigate contains
set split-tunneling disable
which you call 'default gateway mode'. And you are also right, we have received the configuration already from the Fortigate at this moment, it's just not yet fully processed. So, I agree that changing line 321 to
gtw_rt->rt_flags |= RTF_HOST;
should solve this issue.

I have to re-test. I thought that this would break the 'split routes mode', but you are right, in that case this line is not executed at all. Maybe I had messed up my routing table during my tests yesterday.

I believe we don't need the gateway flag here. Traffic is not routed to the public IP address of the Fortigate, but it is sent through the tunnel.

You have seen Pull request #88 which shall fix the split routes mode? Now that I have a deeper understanding I'll comment on that also.

@adrienverge: Now I'm convinced that we don't need an extra option in the config file.

[mrbaseman]

I forgot to mention two more thoughts:

I agree that there should be a host route to the Fortigate in 'split routes mode' just for the case that it pushes a route that contains its own public IP. If that's not the case, the host route doesn't hurt (except that it increases the size of the routing table by a single entry).

And I wanted to mention that I have already tried
gtw_rt->rt_flags |= ( RTF_GATEWAY | RTF_HOST);
which didn't work when my existing default gateway is ppp0 and the vpn tunnel on ppp1. Somehow it does not like the gateway flag in this case, perhaps because we have copied the whole routing entry from a route to a ppp device already, which due to its point to point nature might behave a bit different than routing entries over other network devices (I haven't examined the other fields of rentry in detail, just noticed that it still throws the invalid argument warning whenever the gateway flag is set).

[mrbaseman]

I think I have a working solution now in my ppp-routes branch - I have merged in the related pull requests as well and have successfuly tested with and without split routes over my lte modem (vpn on ppp1) and with split routes over wlan (vpn on ppp0). I hope that I can test default gateway mode over lan (vpn on ppp0) tomorrow.

[mrbaseman]

I have tested my ppp-routes branch again, this time with direct connection over lan and vpn on ppp0, both split routes and gateway mode. It works for all cases I could test and in #88 @Valantin has also reported that it fixes #25 for him. So, I'll open a pull request now and reference the current issue there.

[mrbaseman]

#95 has been merged. Thanks to @adrienverge