How to keep gateway on Gateway Group

[gnsinfo]

Greetings,
For the good communication, I am using AI power.TT

I am seeking advice on a routing issue in a Multi-WAN environment using a Gateway Group on OPNsense.

Topology & Environment:
- Setup: Dual WAN (SKT and SKB) configured in a Gateway Group (Load Balancing).
- Interface: SKT (WAN_GW, Priority 40) / SKB (OPNsenseSKB, Priority 50).
- Service: Caddy/Mail server running on OPNsense host (or behind NAT).
- Topology Link: [https://cloud.gnsinfo.mooo.com/s/QJagCtWLeQqVKRF]

The Issue:
1.  A packet arrives at the SKT WAN interface and is processed (NAT/Port Forward).
2.  The server/service generates a return packet (Reply).
3.  Instead of exiting through the same interface (SKT), OPNsense routes this return packet to the other gateway (SKB).
4.  The other gateway (SKB) drops the packet due to an invalid state or IP mismatch.

What I've observed:
- The system seems to favor the default gateway in the routing table even for inbound connection replies.
- The connection times out for external users attempting to access the service via SKT.

Question:
- How can I ensure that traffic entering via a specific WAN interface is always forced to exit through that same interface's gateway,
- especially when a Gateway Group is active for LAN traffic?
- I've looked into `Reply-to` settings but would like to know the best practice for this specific Multi-WAN scenario.

Thank you in advance for your help!

[OPNenthu]

- How can I ensure that traffic entering via a specific WAN interface is always forced to exit through that same interface's gateway,

This has been a hot question lately.  The 'reply-to' option is supposed to handle this, or so I think, but you are not the only one seeing that the default route is always chosen for reply traffic.

https://forum.opnsense.org/index.php?topic=50882.0
https://github.com/opnsense/core/issues/9702

OPNsense 26.1 has a new flow in the setup Wizard which asks whether or not to optimize the system for Multi-WAN (source-based policy routing).  I did a comparison of two config files with and without this setting and the difference was only two things.  In the Multi-WAN optimized setup, the global firewall options 'Disable force gateway' and 'Disable reply-to' were both disabled (unchecked).  They were the exact opposite in the setup for single gateway, which favors the default system route.

There appears to be some mysterious X factor affecting Multi-WAN that we haven't discovered yet.

(Or, it's above my skillset and no one is patient enough to point it out.)

[gnsinfo]

- How can I ensure that traffic entering via a specific WAN interface is always forced to exit through that same interface's gateway,

This has been a hot question lately.  The 'reply-to' option is supposed to handle this, or so I think, but you are not the only one seeing that the default route is always chosen for reply traffic.

https://forum.opnsense.org/index.php?topic=50882.0
https://github.com/opnsense/core/issues/9702

OPNsense 26.1 has a new flow in the setup Wizard which asks whether or not to optimize the system for Multi-WAN (source-based policy routing).  I did a comparison of two config files with and without this setting and the difference was only two things.  In the Multi-WAN optimized setup, the global firewall options 'Disable force gateway' and 'Disable reply-to' were both disabled (unchecked).  They were the exact opposite in the setup for single gateway, which favors the default system route.

There appears to be some mysterious X factor affecting Multi-WAN that we haven't discovered yet.

(Or, it's above my skillset and no one is patient enough to point it out.)

It works!!!
I can't find Disable reply-to, anyway, in the Reply-to option, I selected WAN interface.
After that, it is no longer blocked email traffic and etc.
Thanks for your effort. (",)(__)...

Have good times all in all.

[pfry]

[...]I can't find Disable reply-to[...]

Firewall: Settings: Advanced -> Miscellaneous.

[OPNenthu]

@gnsinfo if you have the time, a couple questions to help us with the other cases where this isn't working:

- If you disable the 'Disable reply-to' global option (double negatives are very confusing) and then revert the rule back to its original configuration, does it still work?

- Are you using Firewall->Rules or Firewall->Rules [new]?