Hello folks
coming from pfSense and after few hours of happiness to see more advanced development here I struggle to set up symetric routing correctly with current version of OPNsense.
Here is ticket on github - https://github.com/opnsense/core/issues/9806 (https://github.com/opnsense/core/issues/9806)
In short:
I have multiwan setup at home. I am hosting few services on WAN1 and few on WAN2. Everything looks like normal but yesterday I have tested downloading from my cloud from remote location which is hosted on WAN2 and I have wondered why is downloading so slow when I have stronger upload on WAN2 than WAN1. I have found out that handshake to my cloud is made correctly via WAN2 BUT download stream will start on WAN1.
What I have tested to fix this:
1. Forced rules reply-to WAN2
2. Disable forced gateway in settings
3. Check Bind states to interface
4. Gateway policy routing
Nothing worked.
Everytime OPNsense honors default gateway no matter what you set in rules.
I am curious why this worked out of box on pfSense right after setting up rules and port forward and here it does not work (even after hardsetting rules and state behavior).
Can somebody help me to test this out and maybe make some logs for devs ? This needs to be fixed if its broken here. I really wish to stay here because of more options but this keeping me back.
Thanks in forward.
I have the same issue on v26.1.5
wan1 = DHCP
wan2 = PPTP over wan1
gateway on wan2 is default
ping wan2 from remote
The packet arrived on wan2
Respond to remote goes through wan1
I have not updated to every version, but when I updated to v26.1.4 I noticed this issue appeared.
I can tell you it works fine on 26.1.5 so you must have something misconfigured.
You havent really given us enough information.
Have you checked "Disable Reply-To on WAN rules" on Firewall/Settings/Advanced?
Have you set the "Reply-To" on the actual firewall rule? (advanced mode)
The OPNSense docs state:
For legacy compatibility WAN interfaces set to type DHCP or interfaces with a Gateway Rules selection send reply packets to the corresponding gateway directly, also when the sender is on the same interface. This will break connectivity in some rare scenarios and can be disabled via Firewall->Settings->Advanced->Disable reply-to.
With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.
In my case, I have "Disable reply-to on WAN interface" selected, and my firewall rules have the reply-to explicitly set.
My secondary WAN is DHCP, and my primary is PPPoE, so this felt safest.
That works fine.
EDIT: I should add, I have migrated to the NEW rules....
Quote from: ProximusAl on April 02, 2026, 10:53:38 AMI can tell you it works fine on 26.1.5 so you must have something misconfigured.
You havent really given us enough information.
Have you checked "Disable Reply-To on WAN rules" on Firewall/Settings/Advanced?
Have you set the "Reply-To" on the actual firewall rule? (advanced mode)
Wait what ??? Disable reply-to and using manual reply-to for each rule ? This is completely nonsense isnt it ?
Reply-to is set as default on all rules(written in docs).
Also I have already tried to setting theese options as you suggested but none of it worked correctly. It behave still the same (wrong)
Quote from: ProximusAl on April 02, 2026, 11:00:51 AMThe OPNSense docs state:
For legacy compatibility WAN interfaces set to type DHCP or interfaces with a Gateway Rules selection send reply packets to the corresponding gateway directly, also when the sender is on the same interface. This will break connectivity in some rare scenarios and can be disabled via Firewall->Settings->Advanced->Disable reply-to.
With Multi-WAN you generally want to ensure traffic leaves the same interface it arrives on, hence reply-to is added automatically by default. When using bridging, you must disable this behavior if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface.
In my case, I have "Disable reply-to on WAN interface" selected, and my firewall rules have the reply-to explicitly set.
My secondary WAN is DHCP, and my primary is PPPoE, so this felt safest.
That works fine.
EDIT: I should add, I have migrated to the NEW rules....
In this scenario it does not work - https://github.com/opnsense/core/issues/9806#issuecomment-4194715800
EDIT: Also to mention I am using old rules, but nonethless it should work on both because this is core function. Funny is that on pFSense it works correctly and this is project is fork of it...
Why dont you sanitise your config.xml of passwords/secrets etc, and upload it to chatgpt and describe your issue.
I'm not an advocate of AI, but it has actually resolved an issue for me in the past with asymmetric routing, and inevitably, it was caused by me....and identified by AI.
Have you tried sticky connections with a long timeout?