Can't access admin on WAN2 unless it's the gateway
-
We have a multi-WAN setup with two ISPs configured in a failover group. WAN1 is our primary and WAN2 is the backup. Fail-over works great! However, the issue is that, despite having the appropriate rules on each interface, I cannot access the admin interface from WAN2 while it isn't the primary gateway. I have a single floating rule for both interfaces which works to allow access when said interface is the primary gateway.
When Comcast is the primary gateway I can access the admin ports via Comcast's IPs. When Lumen is the primary gateways I can access it via Lumen's IP address. But I can't access Comcast IPs when Lumen is the primary gateway and vice versa. It's essential that I have access over both links for remote maintenance.
For troubleshooting I created individual rules under each interface with the same outcome. I even explicitly specified the gateway to use for each rule. No dice. In all instances I tcpdumped the interface and see my external packets arrive but no response is sent from the firewall.
I had a similar issue with here where it appears that asymmetric routing was the culprit.
-
@Troutpocket said in Can't access admin on WAN2 unless it's the gateway:
I created individual rules under each interface with the same outcome. I even explicitly specified the gateway to use for each rule.
Did you disable the floating rule beforehand? And I wouldn't set a gateway there.
-
@Bob-Dig Yes, the floating rule was deleted. Setting the gateway was just an act of desperation.
-
Classic asymmetric routing problem.
Try ticking “Disable reply-to” on the WAN2 rule — usually does the trick -
@Mikedyx Unfortunately that did not resolve the issue. I see the packets arrive with tcpdump, but there's no reply from the firewall. This coax connection is being replaced in a week or two. I'll see if the new fiber works as expected.
-
@Troutpocket Might be worth checking if there are any rules or NAT settings on WAN2 that block access when it’s not the active gateway. Also, could be a policy routing issue — maybe the replies aren’t going out the same way they came in?
Enabling logging or packet captures on the firewall might give some clues.
