Hey, I've set up an L2TP/IPSEC vpn to allow remote access of local network resources.
Everything works fine, except VPN clients are trying to route using the remote gateway's internet connection.
Creating a Filter to drop packets that are !local-networks stops the traffic, but then the client is unaware and things just time out for them.

I've tried searching this, but most people seem to be trying to ensure the opposite, or do some combination of each with policy based routing, to which I am unfamiliar.

I'll appreciate any pointers, thanks.

Hi,
I think I remember the answer to this from my sysadmin days. The option you are looking for is to be set on your Windows client's side.
This can be done manually, look for the option "Use default gateway on remote network" found in [Connection Properties - Networking - IPv4 - Advanced] on NT6x systems. It is indeed enabled by default when a VPN Connection object is created.
If you are in the context of a large organization, this may help you : https://social.technet.microsoft.com/Fo ... oup-policy.
I hope it helps.

This gateway is not pushed to the client, it is assumed by the client.
There should be a config setting in the client setup to set default gateway to the newly created VPN or not.
Indeed you will find that once you disable that setting, you are faced with the difficulty to route one or more
subnets via the VPN, as you found on those other topics.

Thanks for the responses.

I see the option within windows to 'Use default gateway on remote network'.
Now I need to figure out how to push additional routes to Windows clients and I'll be set.

Now I need to figure out how to win million dollars and I'll be set. But some things in life are suprisingly complicated.

Windows can use VPN as default route, it works great, but you don't want that. Or there's option for "class-based route", which means that if Windows get 10.x.y.z from VPN, they will add route to 10.0.0.0/8 via VPN. In some cases, it might be usable. But if you use 192.168.x.y, you'll only get route to 192.168.x.0/24, which is probably not enough. Nothing is lost, Windows can get routes from L2TP VPN using DHCP. But that in turn is not supported by RouterOS.

Next step is usually a lot of googling, disbelief, dissapointment, head banging, ... and no real happy end. With Windows 10 clients, you can configure additional subnets on client side using powershell (at least I think it also works with L2TP), but it's manual work repeated for every client. Or you can switch to OpenVPN (but it's only tcp in RouterOS), where you can set routes in config file (full OpenVPN can push them, but not RouterOS), so that clients at least don't have to do it themselves.

Next step is usually a lot of googling, disbelief, dissapointment, head banging, ... and no real happy end.

Yes, it is surprisingly difficult. Everyone seems to have their own proprietary solution and nothing is really standardized.
For main/subsidiary VPN I normally use BGP which works OK, but it is not possible with Windows.

Even if something is standardized, implementers either pick only some parts of it, or there are shotcomings and everyone tries to fix them in own way. You'd think that perfectly interoperable VPN is something that everyone needs, but sometimes it doesn't look like it.

The "funny" thing is that in the end, something basically non-standard like OpenVPN (there's no RFC or anything, as far as I know) works best, because everyone uses the same version. Well, until someone like MikroTik decides to make own implementation and adds only half of features. And I don't mean just the most famous missing UDP/LZO, but also the management parts like pushing routes, certificate-only authentication, etc.