I’ve got two WAN connections: a Starlink and an FWA, both working between 150 and 300Mbps each one. There are two hEX routers in VRRP, acting with PCC. The link aggregation works very well as performances (i.e. 500Mbps), but when accessing a website, ping replies ok, while the page content could take several minutes to appear; once appeared, browsing between other pages same site is okay.
Tried to delete active connections, but no changes.
By preceding the PCC mangle cascade with an access rule, so bypassing it and using the Starlink only, the connection is very responsive as it should do.
I’ve found several posts describing this behaviour, but none of them helped me in solving that.
PCC with VRRP, I don’t see why not. But it’s probably good idea to share more info about what exactly you have (at least definition of interfaces and IP addresses; or just post whole config). You seem to have VRRPs on LAN and both WANs. But one weird thing I see, if srcnat is intended to be there and it’s not just some leftover, normally the outgoing interface would be the parent one, not VRRP. So something is not as I’d expect.
And your /ip firewall filter is half-useless mess, but it’s not breaking it.
Ok, my thought was to make the config as simple as possible to read. Here below the full config.
About the srcnat, already tried setting the parent interface, without success.
Addresses:
LAN 192.168.10.0/24
SAT1 192.168.1.1/24
FWA1 192.168.55.1/24
Hmm, not sure what you are doing, but whats wrong with 2 or three vlans for subnets, one bridge and then doing PCC as needed.
As well the deviation from default firewall rules ( aka the mess and utter garbage) makes the overall situation far more complex than it needs to be.
Can you state simply without any config or equipment speak what the requirements are.
a.. identify the users/groups of users includiing admin
b. identify what traffic they need.
Wan1 is which ISP type? Is its public IP? Is it static/fixed IP or dynamic?
Wan2 is which ISP type? Is its public IP? Is it static/fixed IP or dynamic?
Any servers involved which would be on the LAN side but independent of PCC.
Did you want to be able to config the router remotely and securely?
Well… indeed it’s intended to be very simple: LAN 192.168.10.0/24 should access internet via PCC, spanned on a Starlink router 192.168.1.1 and a FWA router 192.168.55.1. No port forwarding is needed, neither remote access: simply internet browsing from LAN.
The architecture should be redundant using VRRP.
What you mean redundant via VRRP. What is the part you are concerned about??
You have a mickrotik device with two WAN sources. Either both are up, one is up or both are down.
How is VRRP going to help you here??
A network diagram may clear up the mystery.
Ahh. reread the first post, have two HEXES doing VRRP.
Personally not worth the hassle, my hexes have not failed, so not needed IMHO,
But one can always have hex2 kept up to date on hex1 config quite easily.
If it ever fails, then 2 minute substitution.
Then outgoing interfaces will be parent ones, and even though masquerade should have the same effect, it’s better to use srcnat and set VRRP addresses manually:
Another possibly problematic is src-address-and-port PCC matcher. It uses both uplinks more equally, but different connections to same server will take different paths, and some servers may not like it. It could be avoided by using both-addresses, but traffic distribution can be worse.
As for firewall filter, it doesn’t do much. You’re blocking some ports from LAN, which may not work, because incoming interface is probably going to be vrrp1-LAN and not bridge1. Blocking traffic from .10 subnet to .50 seems like typo, because there’s no .50 elsewhere. Blocking DNS from WAN is generally good idea, but here it’s probably useless, if the router is behind NAT. And in case it isn’t useless (e.g. if there’s public address and NAT 1:1), then you’d want to block udp as well, not just tcp. And the rest after that does nothing, because it’s all accept rules, and anything not matched is accepted anyway. You can check this thread for some ideas.
Hi, VRRP is needed to provide hardware redundancy, and although there was an error (/32 mask), isn’t concerning the problem; the issue is concerning PCC.
Yes, correct. The weird matter is that the PCC cascade (isn’t the first one for me) won’t work at all, and by adding a simple accept rule before PCC, thus bypassing it, does work flawlessly, therefore I guess that the overall configuration should be nearly correct, except PCC. I suspect that the reply path from the WAN routers is somewhat messed up.
You’re right, my mistake; unfortunately, after correction, same issue. I’ve tried to rewrite the PCC rules several times from scratch, but same problems. Anyway, after your kind suggestions, I’ll redo it again.
If nothing else, now you have two unconditional srcnat rules. So the first one will be used for anything passing through router and nothing will ever get to second one.
But the main point was that if you thought it was working, it couldn’t. And it’s not just this. If you still have VRRP on LAN (on ether1-bbone instead of previous bridge1), and if devices use VRRP’s IP address (previously 192.168.10.20) as gateway, then in-interface=ether1-bbone can’t work, because in-interface for that traffic is vrrp1-LAN.
Well, I’ve corrected the interfaces as per your kind suggestions.
Now, the problem is how to have the proper output interface selected, related to PCC. A “plain” PCC config can’t select beyond the first output interface, while the output towards a WAN group via masq does some distribution between both, but not in respect to PCC.