I’m looking for some guidance on how I’d achieve this. I have a regular ISP on WAN1 but I have a ‘data cap’ of 1TB a month. My apartment complex offers ‘free wifi’ that I have on WAN2 interface. I was originally going to load balance, but decided it’s probably not a good idea because WAN2 has significantly less bandwidth available and high latency.
So my question is, what can I utilize on my Mikrotik router to say LAN Client A, B, and C go out on WAN1 and LAN Client X, Y and Z go out on WAN2?
Or is there a better idea behind this? Basically XYZ and streaming all dang day and giving me a huge headache with that data cap. I don’t want to connect them directly to the free-wifi as I the signal is rather poor without utilizing my wireless client on WAN2 which has a nice antenna, and I’d still like them to be on the network so they can access my local media shares and whatnot.
Thank you in advance! I just moved to Mikrotik stuff from OpenWRT / Tomato firmware devices, so I’m re-learning A LOT.
Search for “policy routing”. You use rules in mangle table to mark outbound connections from clients as they establish, and you translate connection marks to routing marks for packets which need to be routed out via one of your WAN interfaces. Beware not to mark connections/packets towards local destinations as that would require duplicating the local routes in all routing tables.
Identify the highest volume traffic and let it use the default routing table (so that you wouldn’t need to mark it), which will allow you to apply fasttracking on it.
Hi there,
Concur, no need to mangle and mark two sets of traffic.
Yes, you want to apply an IP Firewall Mangle Rule intended to identify those directed for WIFI connection
Then create an an additional route for that traffic in IP Route.
What I suggest is you create an address list in IP Firewall Address List to identify the bad boys.
I am not sure about default route. I think what sindy is saying is keep the default route for WAN1 and remove the default route for Wifi.
(this is done under the IP DHCP Client settings (uncheck the box)
For address list add the first IP you want to force out wifi and give the LIST a name, such as ONLYWAN2
Then add more IPs one by one and use the same Address LIst name.
/IP Mangle
Chain ; Pre-routing
source address list: ONLYWAN2
Action: mark routing
New Routing Mark: WIFI_USERS
IP Route
destination=0.0.0.0/0 gateway=gatewayIP(of ISP WIFI) routingmark=WIFI_USERS
Optional for a bit of a failover could be accomplished by removing the default route from WAN1 DHCP client checkbox and do the routes this way.
IP Route
destination=0.0.0.0/0 gateway=gatewayIP(of ISP1) ping gateway distance=1
destination=0.0.0.0/0 gateway=gatewayIP(of ISP WIFI) distance=2
destination=0.0.0.0/0 gateway=gatewayIP(of ISP WIFI) routingmark=WIFI_USERS
The purpose being that for any reason WAN1 is unreachable WAN1 users can still make use of WAN 2.
Not exactly. “default routing table” and “default route” are not the same thing. In the (correct!) example of /ip route configuration you’ve suggested, there is a default route in the non-default routing table named “WIFI_USERS”, and two default routes in the default routing table, which differ from each other in their distance parameter, so the one with lower distance value is preferred whenever the interface through which that route’s gateway is accessible is up.
What I’m saying is
categorize your clients into groups based on their required treatment,
use an independent routing table for each group, with its own set of primary and possibly backup default routes and maybe some exception routes for specific destinations
identify the client group with biggest volume of traffic exchange with internet and for that group, use the default routing table as its dedicated routing table, so that you could mark only traffic of the other client groups and let the traffic of this “most traffic” client group be processed with less resource consumption by means of fasttracking (which makes packets bypass marking)
be sure to exclude traffic routed between local destinations from the above handling because otherwise you’ll have to define routes for the local destinations in each routing table.
“be sure to exclude traffic routed between local destinations from the above handling because otherwise you’ll have to define routes for the local destinations in each routing table.”
How is this accomplished? Do you mean in the MANGLE rule?
I will help with two examples.
a. easy mode LANS segregated no cross talk to be possible.: LAN1 goes out WAN1 and LAN2 goes out WAN2
b. harder mode: same as a. except some users of LAN1 also go out WAN2. Plus all users in LAN1 need access to printer in LAn2.
Yes, I had in mind that the connection-marking mangle rules should not connection-mark connections between devices on various LAN segments, thus preventing them from being routing-marked in the next step and thus allowing them to use the default routing table which contains all the dynamically generated routes to LAN segments and thus also to be fasttracked.
The OP has stated he wants both ABC and XYZ clients to be able to access local resources (like datastores); unless he has everything (ABC and XYZ clients as well as the local resources) in a sinigle LAN subnet, it is necessary to think about routing between local subnets.
In your case a) where no traffic between LAN1 and LAN2 is expected, if we do not treat initial packets of connections between LAN1 to LAN2 specially, LAN1’s outgoing connections are not connection-marked, so clients in LAN1 can establish connections to servers in LAN2 because the responses of servers in LAN2 are not routing-marked. Therefore, to completely isolate LAN1 from LAN2 a firewall filter rule would be necessary. In the opposite direction, all the connections initiated by clients in LAN2 are connection marked, so unless there is a route to LAN1 subnet in the routing table matching the routing mark (which is always assigned to packets belonging to marked connections), the initial packets of these connections never reach LAN1 so there will never be a response from a server in LAN1.
In your case b), the default routing table may contain routes to particular destinations via WAN2 (and, beyond your case, the routing table dedicated for LAN2 clients may contain routes to particular destinations via WAN1 if needed). The access from LAN1 to LAN2 printer works without effort as it is similar to case a) (LAN1 clients can access LAN2 servers, and if you want to restrict that to only some servers in LAN2, you need to use firewall filter rules). Vice versa it would be less obvious, because you would have to add route to local subnet (specifying an interface instead of an IP address as a gateway) into the routing table dedicated for LAN2 clients (still talking about case when all outgoing connections from LAN2 clients are connection-marked).
To make it simpler to handle, and also to permit fasttracking of LAN to LAN connections, you would add a dst-address-list=!local-subnets match condition to the connection-marking rules in mangle table, and use firewall rules to permit only the necessary connections between clients and servers on various LAN segments. The members of address-list local-subnets would be the local subnets of course.
Sorry I asked LOL
Let me put it this way (more basic for slow me).
When attempting to identify LAN traffic intended for the internet, through mangle rules, how do you prevent catching LAN to LAN traffic in the mangle rule…
how do you state the mangle rule to ensure it only is intended for lan to wan traffic?
or is this done only with routing rules.
I don’t make routing tables, the router does, all I do is making routing rules!!!
the category (connection mark) of the connection to which the packet belongs
So dst-address-list=!lan-subnets is a match condition which prevents the marking rule from matching packets to LAN; the other conditions in-interface-list=LAN or src-address-list=lan-subnets are used to make the rule mark only packets from LAN.
Of course, /interface list name=LAN and /ip firewall address-list list=lan-subnets have to be populated properly, which is your job.
When you assign routing-marks directly, the above is enough.
or is this done only with routing rules.
I don’t make routing tables, the router does, all I do is making routing rules!!!
You do make the routing tables. By default there is only a single routing table, the default one, which is also called “main” (so no routing-mark at all and routing-mark “main” both choose this table). This one is pre-populated by the router itself and e.g. the DHCP protocol, but you can affect whether the DHCP adds a route or not and with what priority (distance), and you can add your own routes to it.
By assigning routing-marks you tell the router to use non-default routing tables which you have to compose completely.
.
A routing table is a list of routes which the router internally sorts by prefix length and distance, and dynamically activates and deactivates depending on monitored state of something, but it is you who decides about both the prefix and the distance (mutual priority of routes with identical prefix).
And to make it even more complex, a routing rule is not the same like a route, nor the same like a mangle rule assigning a routing mark, but something between the two. But don’t worry, a mangle rule assigning a routing mark can in most situations substitute a routing rule (not vice versa). Routing rules are useful e.g. when you do not use firewall at all.
Awesome, you should write the Bible on this!
However, concur I know the interface flow is coming in on,
and I should know the source address or source address list
BUT
I do not necessarily know the destination address (yes on the LAN to LAN side) but on the WAN side. Most of the time i simply know which gateway its going out of , but not dst IP.
You somehow seem to still have a small gap in the routing basics. After the originating device determines the destination address where to send a packet (by asking a DNS to translate a domain name to an address, or by using some internal translation table for that, or by fetching the numeric address from configuration, or by receiving it in some protocol message, …), the next step, which is the same for the originating device and any intermediate device (router) which forwards the packet closer to the final destination, is to find out the “next hop” - a directly neighbouring intermediate device one step closer to the destination, or the destination itself, and send the packet to it.
If we leave aside for the moment all the mangling, policy routing, alternative routing tables etc., each device looks for a route in its routing table whose dst-address matches best the destinaton IP address of the packet to be sent out (no matter whether it is a forwarded one or a locally originated one). Once the device finds such best-matching route, it looks what is configured as that route’s gateway. If it is an interface name, the device sends the packet (unchanged except decrementing the TTL value!) out via that interface, supposing there is only one recipient on the other end of the wire or tunnel connected to that interface. If the value of gateway is an IP address, the device does not replace the destination IP address of the packet with it either; it only resolves the IP address of the gateway to its MAC address and sends the packet to that MAC address, but the destination IP address written in the packet’s header remains unchanged and the IP address of the gateway is also not put anywhere else to the packet.
So every device along the network path gets the packet with the IP address of the final destination, and finds the best directly connected neighbour to forward it. The IP address of the gateway is not used for anything else than finding such neighbour’s MAC address, which may be an implicit one, i.e. “the other end”, in case of point-to-point interfaces.