Add two new routes to your routing table
dst=x.x.x.x/n (the network / netmask of your ISP 2 WAN) with gateway=ether2 (or whatever interface it’s on) routing-mark=ISP2
dst=0.0.0.0/0 gateway=x.x.x.x (default GW for ISP2) routing-mark=ISP2 in-interface=!ether2
Then add a few mangle rules:
/ip firewall mangle
add chain=prerouting connection-mark=no-mark in-interface=ether2 action=mark-connection new-connection-mark=isp2
add chain=prerouting connection-mark=isp2 action=mark-routing new-routing-mark=ISP2
Done.
EDIT: If you’re having trouble determining the x.x.x.x/n for rule 1 above, just look in your IP addresses and use the value from “Network”
Why did you make that two commands? Why did you not simply have the action of the first one be the: action=mark-routing new-routing-mark=ISP2
Or was it so you could specify the connection-mark=no-mark? If so, why do you need that filter at all? Couldn’t it have been just:
add chain=prerouting in-interface=ether2 action=mark-routing new-routing-mark=ISP2
Or did I miss something making it that simple?
Note that I’m VERY new with Mangle rules, and my first attempt is not quite working right, so I’m trying to learn…
The issue is that the reply packets from the LAN must be directed to ISP2.
mark-routing only affects individual packets.
So if you use just one rule (in ether2, mark routing) then the problem is going to be that the replies from the server will never be matched (they’re not arriving on ether2 - they should be leaving via ether2) and so this marking rule would miss the very packets it should match, and is matching packets that it doesn’t need to be marking.
Rule 1 marks packet flows based on their having first been created at ingress via ether2. (that’s what connection-mark does - marks the entire flow)
Now connection tracking will know which reply packets belong to that flow.
Rule 2 marks all packets of this flow with the routing mark that will force them out ether2.
– While writing this reply, I saw a flaw in my earlier suggested logic.
rule 2 should be this:
add chain=prerouting connection-mark=isp2 in-interfae=!ether2 action=mark-routing new-routing-mark=ISP2
(just add the boldfaced condition to what I suggested earlier)
The problem was that without this extra condition, the rules would route-mark packets both outbound AND inbound. Applying the routing mark to the inbound packets changes the rules a bit - and in this simple implementation, the easiest fix is to simply make the rule fail to match packets coming in on ether2. (that’s what the boldfaced additional condition match does)
The problem is this: if incoming traffic is ALSO placed into the ISP2 routing table, then the LAN needs to be added to the ISP2 routing table as well, or else the incoming packets will not have enough routing information to reach their ultimate internal destination. In fact, they’ll be ping-ponged back up to the ISP in the configuration I gave earlier). Adding the in-interface=!ether2 will fix the ping pong problem.
Other fixes:
Add the LAN’s connected route to the ISP2 routing table
or
Create a route rule which states dst-address=(internal IP range) lookup in table main.
I would prefer the second of these, as it scales more easily to more complex configurations.
I made the change and it works, thanks. But, I have a new problem. The connection to ISP1 is like it should be. However the connection to ISP2 is VERY slow. For example It takes minutes to initialize a rdp session. Also connection to other servers times out because it takes to long
I also did this but not solved the slow connection problem.
Cool. I have a commercial license with instrument airplane, airplane single engine land ratings and about 675 total hours. At lest half my flight time is in the Cessna 172. Unfortunately have not flown as PIC in a couple decades due to lack of money - buying a house, having kids, wife not working = no money! I enjoy any opportunity to fly with other people. Most of my passenger flying the last decade has been in one of several MD520N helicopters that belong to the police department for the city I work for. I can fly with them almost any time I want - sometimes even getting paid to do it.
I think I know why incoming connections on wan2 are so bad. When i disable fasttrack problem is solved. But I want to keep fasttrack on because i see big cpu usage difference between fasttrack disabled and enabled. Is there a solution?
