Besides those with Mikrotik below their name, none of us are getting paid for for being on this forum so you might just have to wait before you get response. Especially given your more specific requirements and ideas, this cannot be addressed with a typical 5 minute reply.
Secondly, use the code tags when posting exports: works wonders for readability.
Thirdly, while most of us will help you when you run with difficulties, it’s up to you to your configuration working. We will not do it for you.
The configuration you’ve posted should generally work, but has a few problems going with to it.
First and foremost, your configuration assumes complete UDP and TCP separation between the NICs already has taken place. It is the host (i.e. your game PC) that is responsible which NIC it uses to source the traffic from, not the router that tells the PC what is allowed on what link. Unless the game allows you to specifically configure which NIC to use, I think you’ll going to find that it’s quite hard to reliably configure a multihomed host where traffic is split across NICs and the applications used lack control.
If the game does allow you to bind to a specific NIC, the rules you have a sufficient (i.e.: all traffic on LAN1 goes to WAN1). If the game doesn’t allow you to explicitly bind the application to a specific NIC, you’ll have to opt for a ‘neutral’ link, i.e. all traffic is pushed over the link regardless and the hAP separates the traffic.
If the NIC drivers on the PC allow for this, you could try and bond the two interfaces together, e.g. using 802.3ad. This would give you 200Mbit (in case of your hAP) full duplex bandwidth to the hAP. Drawback of that bonding in RouterOS is that it is software-based, so you’re adding a layer of indirection here and tax the CPU besides routing duties. If I were you, I’d benchmark to see what different bonding options do with pingtimes and packetloss compared to just a single ethernet link. Given the eventual bandwidth available on the WAN connections though, I doubt TCP traffic on the PC-hAP-link will be the bottleneck and result in UDP packet loss, even on a single 100Mbit link.
To make the actual policy based routing happen, I don’t know the specifics of your game (or even what game it is), but I wouldn’t just blindly select on ALL UDP or ALL TCP, but specifically mark the traffic you need for your application. You could for instance mangle outgoing traffic from your game PC destined for UDP port 27000-27005 to go out WAN1 by using:
/ip firewall mangle
add chain=prerouting src-address=192.168.1.33 protocol=udp dst-port=27000-27005 action=mark-routing new-routing-mark=to_WAN1
/ip route
add dst-address=0.0.0.0/0 gateway=192.168.1.1 routing-mark=to_WAN1 check-gateway=ping
Also, don’t forget to set the correct dst-nat rules for portforwarding for incoming connections.
/ip firewall nat
add action=dst-nat chain=dstnat in-interface=WAN2 dst-port=27000-27005 protocol=udp to-addresses=192.168.1.33
/ip firewall filter
add action=accept chain=forward connection-nat-state=dstnat
Second problem I see is that it it only marks LAN-bound traffic directed to the hAP (i.e. input and output chains), not through the hAP. In other word: this works for services runing on the hAP, but not for traffic that is being NATted to a host in the LAN. The key to understand the rules necessary is to understand the packetflow in RouterOS. Study http://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6. Say you would be able to completely separate UDP on WAN1 and TCP traffic on WAN2, any TCP traffic still destined and inadvertently NATted for WAN1, would be answered on WAN2 leaving receiving end very confused by your responses.
To prevent this, you must also mark (inbound) connections on the forward chain and mark the (outbound) traffic in those connections for routing on the prerouting chains to make sure traffic leaves on the same WAN connection as it entered.
The following example uses the new in-interface-list attribute to achieve this (which sticks to the methods used in your configuration), but you could also do this src-address(-list) based.
/interface list
add name=LAN_INTERFACES
/interface list member
add interface=LAN1 list=lan-interfaces
add interface=LAN2 list=lan-interfaces
/ip firewall mangle
add chain=forward connection-mark=no-mark in-interface=WAN2 action=mark-connection new-connection-mark=WAN2_fwd
add chain=prerouting connection-mark=WAN2->LAN in-interface-list=LAN_INTERFACES action=mark-routing new-routing-mark=to_WAN2
Third issues is that for the (unmarked) default routes, WAN1 is set as distance=1 and WAN2 as distance=2. This means WAN1 will serve as the active default route and be preferred over WAN2 for all unmarked traffic. If you’re really anxious not to have any other traffic, I’d suggest to turn this around. This means that unless WAN2 goes down OR the traffic is marked to go over WAN1, all traffic will go over WAN2. If you’re manually configuring the routes, you can change the distance in your routing table. If using PPPoE or DHCP client to automatically create default routes you can add/change them at the respective client settings.
Besides these points, personally I’d opt for a topology where the hAP sits in the middle for all routing, including that of the LAN routing. Consider the following logical traffic flow based on your diagram:
Outbound
+-----------------+
Eth2+3 | Gaming | Eth1 +--------+
Game PC +----------> ++------------> +---------->+ WAN1 |
| | | +--------+
| | Other |
Eth4 | +------------> | Eth4 +--------+
WiFi hosts +----------> +-------------> +---------->+ WAN2 |
| | +--------+
+-----------------+
Inbound
+-----------------+
+--------+ Eth1 | Gaming | Eth2+3
| WAN1 +-----------> +------------> +----------> Game PC
+--------+ | +-----------> |
| | Other |
+--------+ Eth4 | | | Eth4
| WAN2 +-----------> ++-----------> +----------> WiFi hosts
+--------+ | |
+-----------------+
This does mean, both traffic to and from WiFi hosts as well as traffic to and from the gateway for WAN2 are on the same (in my example eth4) interface. For clarity and to prevent routing issues, I’d separate broadcast domains on the LAN side of the hAP from the WAN side of the hAP in the following steps:
- give WAN2 gateway a fixed IP in a different subnet, e.g. 192.168.2.1/30.
- disable DHCP server on on the WAN2 gateway
- set IP in the ‘gateway subnet’ (192.168.2.2/30 following the IP from above) for ether4 on the hAP
- also set IP for 192.168.1.2/24 for ether4 on the hAP
- configure your hAP as DHCP server for 192.168.1.0/24 subnet with 192.168.1.2/24 as gateway (if that is the IP of your hAP)
This way you can easily distinguish between traffic coming in from LAN and traffic coming in from the WAN2 connection. This would prevent any routing problems because of ‘upstream gateways’ being in the same broadcast domain.
Two notes:
- I would probably also use a different subnet between the hAP and the WAN1 gateway, e.g. 192.168.2.5/30 and 192.168.2.6/30).
- I would recommend NOT to use the 192.168.1.0/24 for you LAN, but use something less common (e.g. 192.168.37.0/24, 192.168.213.0/24, etc.)
Another step to further simplify your routing configuration is to prevent a double NAT scenario i.e. both the hAP and WAN2-gateway are NATting and firewalling traffic. You’re already doing this with WAN1 by putting it into bridge mode, but this generally isn’t possible without disabling e.g. the wireless capabilities. However a default-server or DMZ option that’s available on most consumer devices would already be step in the right direction here.
Now finally if you have this topology, you can also start thinking about how to maintain a level of exclusivity on WAN1 when you’re gaming, but not let the bandwidth go to waste by allowing the rest of the LAN to use the WAN1 connection when it’s available. You could do so by adding a more dynamic load balancing rules, e.g. PCC (simple and useful if connection speeds are quite similar) or a bandwidth based (as explained by Tomas in his slides). You can keep things very simple here by just disabling these load balancing rules when you start gaming en re-enable them when you’re done, add a schedule to the rules (e.g. only weekdays during business hours) or more advanced QoS through and queues priorities that make sure UDP traffic gets priority when routing. For the latter, you could just adapt a QoS example used for VoIP as it will generally have the same requirements you have for your gaming packets.
