reply-to: default does not seem to work as expected.

[Isabella Borgward]

I have two WANs. Each WAN has a gateway configured.
I want to be able to manage the firewall remotely to either public IP address.
I have spent quite a bit of time fiddling with this.
Ping works fine to both WANs. I could only get HTTPS working to one at a time.
I have found that the key to fixing this was explicitly setting a reply-to on the management access rule.
The rule consists of a source alias [a list of remote management public IPs], destination of "This Firewall" and a service of Any.
If I leave "reply to:" as "default", it doesn't work. The help for this option says:

Determines how packets route back in the opposite direction (replies), when set to default, packets on WAN type interfaces reply to their connected gateway on the interface (unless globally disabled). A specific gateway may be chosen as well here. This setting is only relevant in the context of a state, for stateless rules there is no defined opposite direction.

This makes sense - ICMP is stateless and works regardless of this setting. But HTTPS does not work unless I explicitly set reply-to to the interface's default gateway here. This contradicts what the documentation says.
There is a hint about "unless globally disabled", but what is that setting called and where is it?
Even specifying the gateway explicitly with the Gateway setting does not make this work.

[viragomann]

Did you even add both WANs to System: Settings: Administration: Listen Interfaces?

[Isabella Borgward]

No, it's set to default which is "all".

[viragomann]

Where did you define the management access rule?
To enable the default reply-to, the rule allowing the incoming traffic must be defined on the respective interface. It must not be on an interface group or a floating rule.
This means, you need separate rule for your WANs on the respective interface. Is this given?

[Isabella Borgward]

Yes, I started with a floating rule but it did not work, so I created individual rules.
However I just realised I left the floating rule in place, so I will remove this and re-test, in case it somehow takes precedence and breaks it.

[viragomann]

in case it somehow takes precedence and breaks it.

Yes, it does.

Floating rules and interface group rules take precedence over interface rules.
Therefore you have to ensure, that none of these matches the incoming traffic.

In a multi WAN environment you should avoid creating floating pass rules applied to the WANs and also not create a WAN interface group.

[Isabella Borgward]

Well that's annoying because a multi-WAN is the only use I've ever had for a floating rule  ::)  ;D

[Isabella Borgward]

Deleted the floating rule. Rebooted. No different, management access does not work unless an explicit reply-to gateway is specified.

What is the "unless globally disabled" hinting at?

[Isabella Borgward]

I guess it's this, but it's already not-disabled.

[viragomann]

Do you confirm, that the rule you've added to the interface matched the access?
To ensure, state a proper description to the rule and and enable logging.

[Isabella Borgward]

Logs of it not working [reply-to: default]. The source IPs are all in the "Management" alias.

[Isabella Borgward]

OK, I was going to show the logs of it working but it looks no different, so there's no point. Drill in to it, it's the same RID. Definitely the correct rule on the correct interface.