fix detecting new connection bug when ppp connections are existed. #90
Conversation
Mabin-J
force-pushed
the
fix-multi-connect
branch
2 times, most recently
from
a1d5b3b
to
37a2db4
Compare
|
I have created a testing branch and at a first glance this doesn't break things in my setup. I'm also interested in running openfortivpn over an LTE modem connection which itself uses ppp0 already. However, I haven't tested that, yet. |
|
I fix 'ppp_interface_is_up' with my code base for get interface's address type. int ppp_interface_is_up(struct tunnel *tunnel)
{
struct ifaddrs *ifap, *ifa;
log_debug("Got Address: %s\n", inet_ntoa(tunnel->ipv4.ip_addr));
if (getifaddrs(&ifap)) {
log_error("getifaddrs: %s\n", strerror(errno));
return 0;
}
for (ifa = ifap; ifa != NULL; ifa = ifa->ifa_next) {
log_debug("Interface Name: %s\n", ifa->ifa_name);
if (&(ifa->ifa_addr->sa_family) != NULL){
log_debug("Interface's Address Type: %d\n", ifa->ifa_addr->sa_family);
} else {
log_debug("Interface's Address Type: NULL\n");
}
if (strstr(ifa->ifa_name, "ppp") != NULL
&& ifa->ifa_flags & IFF_UP) {
if (&(ifa->ifa_addr->sa_family) != NULL
&& ifa->ifa_addr->sa_family == AF_INET) {
struct in_addr if_ip_addr =
((struct sockaddr_in *) ifa->ifa_addr)->sin_addr;
log_debug("Interface Addr: %s\n", inet_ntoa(if_ip_addr));
if (tunnel->ipv4.ip_addr.s_addr == if_ip_addr.s_addr) {
strncpy(tunnel->ppp_iface, ifa->ifa_name,
ROUTE_IFACE_LEN - 1);
freeifaddrs(ifap);
return 1;
}
}
}
}
freeifaddrs(ifap);
return 0;
}and I connected one fortivpn and try to connect one more fortivpn. If use original code, 'ppp_interface_is_up' select 'ppp0' because check only interface name with 'ppp' this point. I think that order of interface list of 'getifaddrs' function's return value can be different each machine. so I think that checking address is more correct than interface name. |
|
@mrbaseman |
|
On the weekend I found the time to test this with my lte modem. Without your patch openfortivpn uses ppp0 for both, the modem traffic uplink and the vpn channel, which of course does not work. INFO: Connected to gateway. it might be due to the fact that my Fortigate pushes a default route throgh the vpn channel (to ensure that the vpn also encrypts my surf traffic when I'm on an insecure network) - or I might have missed the latest commit (I'm not sure anymore, when I have pulled the source that I have used for testing). I'll re-test and give you an update. |
|
ah, I just noticed that I have probably merged PR #88 into the code I was using for testing and I might have hit a problem with that code or some interference between the two pull requests. I definitely have to re-test. |
|
Hi, this looks good! I'd be happy to merge once it is reported to work. |
|
I don't have split routes configured on my fortigate, That means all traffic goes through the vpn connection. When I manually add a host route over ppp0 for my fortigate before starting openfortivpn this works for me. The traffic of the vpn channel goes over ppp0 and everything else is routed over the new ppp1. When split routes is configured this patch should work out of the box but I haven't tested that yet. It would be nice if the host route could be added automatically when starting openfortivpn. |
|
I have just verified that when no default route is pushed by the fortigate this patch works fine. Adding a host route over ppp0 in the other case could be added in a separate commit. |
When ppp connections are existed before connect with openfortivpn, openfortivpn use only 'ppp0'. So, after connect vpn with openfortivpn that situation, routing table get tangled. There is also same situation when connecting one more vpn with only openfortivpn. So, I changed checking new connection logic.
|
Thanks a lot @Mabin-J and @mrbaseman for testing! |
adrienverge
force-pushed
the
fix-multi-connect
branch
from
b02432c
to
83c8072
Compare
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
When ppp connections are existed before connect with openfortivpn, openfortivpn use only 'ppp0'.
So, after connect vpn with openfortivpn that situation, routing table get tangled.
There is also same situation when connecting one more vpn with only openfortivpn.
So, I changed checking new connection logic.