I have setup an IKE2 VPN server on Mikrotik (v7.16.1).
It worked perfectly earlier: on Windows10, Windows11, Android.
Now, Windows11 started behaving strange: once it connects to this VPN, it shows “not connected” in tray (but there IS connection: to both remote sites behind VPN, and also to Internet (via remote gateway)):
This only happens, in case this checkbox is ticked:
If I untick this checkbox (i.e. NOT “Use default gateway on remote network”), then connection shows a secured sign in tray, I have Internet, but can NOT access anything behind VPN:
I would prefer to have a full-tunnel, just like in the above case. A “no connection” sign in tray doesn’t bother me too much, but there are quite a few apps which reads this status and refuses to start (Spotify, different messaging apps, etc).
First, the operating systems check reachability of internet by sending requests that can only be responded if internet is reachable, such as DNS requests to servers running on public addresses, but I’ve never managed to find any details. So the question is whether there are any restrictions in the Mikrotik firewall that would prevent some traffic that comes from the Windows 11 from reaching its destination.
Second, IKEv2 is the only VPN type on Mikrotik to support the Windows-specific way of pushing routes to the VPN client, where the Windows send a DHCPINFORM message asking for Option 249, which is a routing table in a specific format, and Mikrotik builds the response from the subnet list in the split-include parameter of a mode-config item. So rather than routing all the traffic of the PC via the tunnel, you can use it just for communication with the subnets at the remote site if you untick “use default gateway on remote network” and tick “disable class based route addition”. Of course, this is only useful if you use the VPN the traditional way, not as a means to bypass restrictions.
Wow, @sindy, hands down, you’re an all-time hero here.
split-include indeed works, letting me use all my resources behind the VPN, while also let my computer use other resources (Spotify for example) passing the VPN.
It’s extremely useful to have these insights on how things work behind the scenes.
1.) Defining some local IP ranges in split-include results my Android client not reaching anything else than those IP ranges. Is this intended/known? Shall I create different mode-configs, profiles, etc for Android and Windows in case this type of split-tunnel is needed?
2.) Windows update arrived half an hour ago, and now full-tunnel works.
For me it seems, Windows just doesn’t care about _split-include_s in case its VPN connection sets full-tunnel mode (use default gateway on remote network). Android on the other hand takes it into consideration when building up the connection, and in case there is anything defined in split-include, Android will only allow connections to those addresses during the connection.
Unfortunately, each IPsec implementation uses different mechanisms to deal with split-include. So indeed you may need to set different identities referring to different mode-config items for different types of clients. Whether you can tell that particular Android version/device to use the tunnel for matching traffic and direct uplink for the rest is uknown to me.
Indeed.
That may depend on version. For a long time, the embedded VPN client of Android did not support IKEv2 at all, so you had to install a Strongswan app, where you had to define the split-include destinations locally manually. Maybe you have to do something similar on the embedded client to prevent it from redirecting all the traffic to itself, no idea.
