1.,2. - correct, 3 - wrong, I've written that as the WAN interface is an ethernet one (point-to-multipoint), its name cannot be used as a gateway and instead an IP address of a particular device in that subnet must be used, as the dhcp-client
does, /ip route print
shows the result to you (export
shows the configuration set manually, print
shows the actual running configuration including dynamically created items). So to all routes other than the default one in the default ("main") routing table which should send packets via WAN, you have to copy, using a script, the gateway IP address from the default route in the default table each time it can eventually be changed, i.e. at each DHCP renewal. RouterOS provides a convenience measure for this which is the script
parameter of /ip dhcp-client
But as you've simplified the rules in point 4 as compared to the generic case described in the other post, I deduce that you don't need to prepare the complete infrastructure for policy routing of all.kinds of traffic.
Therefore, you can simplify things a lot by making use of the fact that PPTP-VPN is a point-to-point interface so its name can be used as a gateway.
So instead of using the default routing table (consisting of routes with no routing-mark
) for the traffic of LAN devices, and only using marked routing tables for responses to requests coming in via WAN and for the PPTP transport packets, you can do the reverse and let all traffic outgoing from the 'Tik itself be routed using the default routing table (so you don't need to update the gateway IP address in other routes each time it might eventually change) and let the traffic from LAN use the PPTP-VPN whenever that interface is active.
So you would do the following:
- remove the route with routing-mark=eth and all the /ip firewall mangle rules
- set add-default-route to no on the pptp-client interface (and keep defaut-route-distance=1 in the dhcp-client)
- add a route dst-address=0.0.0.0/0 gateway=PPTP-VPN routing-mark=vpn
- instead of /ip firewall mangle rules, add the following:
/ip route rule
add src-address=192.168.88.0/24 dst-address=192.168.88.0/24 action=lookup table=main
add src-address=192.168.88.0/24 action=lookup table=vpn
That way, all packets sent by devices in the LAN subnet and all your VPN clients, which also get addresses from 192.168.88.0/24, will be routed via the PPTP-VPN, except those for other devices in the same subnet (i.e. between LAN devices and your VPN clients). All the remaining packets, which actually means only packets sent by Mikrotik itself, will use the default routing table.
When the PPTP-VPN will eventually be down, the route with routing-mark=vpn
will be down too, and the routing will thus fall back to the default routing table "main".
Regarding the "example for the WinBox service", the only point in real multi-WAN arrangements is that the device can receive requests on several
WAN interfaces and it has to send the response the same way back, so the only thing you need is to "remember", for each connection initiated from outside, the WAN interface through which the connection was initiated. So no specific arrangement is required for Winbox or another service in particular; it is a job of /ip firewall nat
rules to eventually forward some requests to servers on LAN and of /ip firewall filter
rules to let through only requests to some services and/or from some remote clients. So you would only mark connections based on in-interface=WAN
, nothing else. But if you use the approach above, you don't need this at all.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.