set up routes correctly when ppp0 interface is already there about openfortivpn

[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