This may be specifically a Windows problem, unless there's a way for a MikroTik SSTP VPN server to give a VPN client a hint about raising/lowering the metric of a route that the MikroTik SSTP VPN server provides to its VPN clients via it's own DHCP server's Options.
I have three MikroTik routers, one in each of three geographically different places. Each place has its own RFC 1918 address space - 192.168.255.0/24, 192.168.254.0/24, and 192.168.253.0/24. Each place is on its own, unrelated, fibre optic Internet service. (So, from any one of the three MikroTik LANs' point of view, the other two MikroTik LANs are "across the Internet", with no related local routes).
I have SSTP VPN servers on each of the MikroTik routers (RouterOS 7.22).
These SSTP VPNs are used in two ways:
- Two of the MikroTik routers (192.168.254.3, 192.168.253.3) each maintain a pegged-up VPN connection over the Internet to the third MikroTik router (192.168.255.5).
- Windows clients may make temporary connections to any of the three MikroTik routers.
The MikroTik SSTP VPN servers assign IP addresses via the MikroTiks' own DHCP servers.
The MikroTik DHCP servers have an Option Set which includes Option 0x18 (classless routes).
The Option on the router 192.168.255.5 includes routes, through itself, to the other two networks.
This works fine, except for one circumstance:
On a Windows client, on the local LAN with the MikroTik router 192.168.254.3, the normal route (provided by the MikroTik router 192.168.254.3 DHCP server) to get to 192.168.255.0/24 is via the 192.168.254.3 router.
But, when that Windows client makes a direct SSTP VPN connection over the Internet to the MikroTik 192.168.255.5 router, the Windows client ends up with two identical-metric routes to 192.168.255.0/24 - routing table excerpt:
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
192.168.255.0 255.255.255.0 192.168.254.3 192.168.254.25 26
192.168.255.0 255.255.255.0 192.168.255.125 192.168.255.99 26
The route via 192.168.254.3 is the Windows client's normal route, provided to it by its local MikroTik DHCP server.
The route via 192.168.255.125 is the route supplied via the remote MikroTik 192.168.255.5 SSTP VPN server's DHCP server (well, magically supplied by the MikroTik SSTP VPN, from an address pool listed in the Profile that applies to the SSTP VPN client connection; I don't actually see exactly how DHCP is involved, if it is at all. But I'll continue in the rest of this post to refer to the SSTP VPN clients getting a "DHCP" supplied address from the MikroTik SSTP VPN server, just to be consistently incorrect at least...).
The problem is that both routes end up with Metric 26. I thought that any time a Windows VPN client connection was made, that routes provided by the VPN server would take priority (end up with a lower metric) than any similar existing route, unless that would conflict with reaching the VPN server itself.
You may ask, "Why have a Windows box on MikroTik2's LAN make a direct VPN connection to MikroTik1's LAN, instead of riding over the pegged-up VPN link between these two MikroTik routers?" And you'd have a point .. except for a quirk of port and link speeds; the 192.168.255.5 MikroTik router has gigabit ports, and its Internet connection is 500Mb/s+ fibre; whereas all of the ports on the 192.168.254.3 MikroTik router are 100Mbit. The rest of the 192.168.254.0/24 LAN is gigabit ports. This is just an artefact of the age of the 192.168.254.3 MikroTik device. So, it's actually much faster for a Windows client on the 192.168.254.0/24 network to make a direct VPN connection, over its local 1Gb/s network, out its 500Mb/s+ Internet connection, to the 192.168.255.5 MikroTik router's VPN server, than to ride the pegged-up VPN link betweek the two MikroTik routers.
For routine purposes, the pegged-up link (which can move data at around 7MB/s) works fine. For moving quite large files, however, it's faster to temporarily make a direct VPN connection from the Windows client on the 192.168.254.0/24 network to the 192.168.255.5 MikroTik router's VPN server (bypassing the 100Mb/s interface limit on the 192.168.254.3 router).
(Obviously, buying a sub-€100 newer, gigabit interface MikroTik would solve this. And I'll do that. But this is still an interesting networking question).
So, how do I get the 192.168.255.5 MikroTik router('s SSTP VPN server, I suppose via its DHCP server) to advise the 192.168.254.0/24 LAN Windows client "Make sure that the new temporary VPN-provided route to 192.168.255.0/24 through me has a higher priority/ lower metric than any conflicting route that you may have otherwise already had"?
thanks,
[ edit 2026-05-22 14:51EU CET, add comment about my uncertainty about the relationship between the MikroTik SSTP VPN server and {not?}DHCP as the source of SSTP clients' IP addresses ]
. It "just works". Per an earlier response in this thread, I guess it's the DHCPINFORM that the Windows SSTP client sends after connecting, which the MikroTik forwards internally to its DHCP server? Or, actually, I now realize that the DHCP option set 121 is NOT being sent, and I think what I'm doing is using the explicit Routes option in the PPP secret configuration for the user as which the SSTP VPN is connected.
