Disable reply-to on WAN Rule to access GUI from WAN

[ricksense]

Hi everyone,

I installed OPNsense as a VM on two different PCs. In order to access their own WEB GUIs from WAN (just for convenience, they run on LAB environments which I use for learning purpose), I set pass rules to allow that, of course.
I can access the OPNsense's WEB GUI from the browser of the host where the VM runs,
BUT if I want access it from another PC (the other one when another OPNsense VM runs) , it isn't allowed unless I check "Disable reply-to on WAN Rule"



Could anyone please explain to me what this option is for and how does it work exactly?

Thanks

[Monviech (Cedrik)]

"reply-to" is a defining feature of "pf".

When activated, it will force packets to the default gateway of the interface. This means, it can circumvent issues like asymmetric routing natively.

It also means, that clients in the same network as the interface with the gateway will not receive responses since they are all sent to the default gateway.

You do not have to globally disable it, creating a firewall rule that matches the exact traffic of the WebGUI, and enabling advanced options in that rule, and setting "reply-to" to "disable" should solve it selectively. Of course, that rule has to match first on the WAN firewall rules.

E.g:

Source Network: WAN net
Source Ports: Any
Destination Network: WAN address
Destination Ports: HTTPS
- Advanced Options -
Reply-To: Disable

[dseven]

If that option is not selected, inbound rules on WAN interfaces will be created with a "reply-to" option pointing to that interface's gateway. IIUC, this is intended to make multi-WAN scenarios work, where inbound connections to a specific WAN interface's IP address might break if the outbound responses got routed to a different (more preferred at the time) gateway. Unfortunately this breaks connections to the WAN interface from hosts which are not behind the gateway. BTW, you can specify reply-to on a per-rule basis (under "Advanced Features").

Edit: D'oh - I'm too slow!

[ricksense]

"reply-to" is a defining feature of "pf".

When activated, it will force packets to the default gateway of the interface. This means, it can circumvent issues like asymmetric routing natively.

It also means, that clients in the same network as the interface with the gateway will not receive responses since they are all sent to the default gateway.

You do not have to globally disable it, creating a firewall rule that matches the exact traffic of the WebGUI, and enabling advanced options in that rule, and setting "reply-to" to "disable" should solve it selectively. Of course, that rule has to match first on the WAN firewall rules.

E.g:

Source Network: WAN net
Source Ports: Any
Destination Network: WAN address
Destination Ports: HTTPS
- Advanced Options -
Reply-To: Disable

Okay, I think I get it, and I'll give "the selective rule" a try.

By the way, does this also mean that I need to uncheck this option if I want to set up a dual WAN failover (which is what I actually want to do)?

Thank you very much

[dseven]

If you're planning on Multi-WAN, you should not disable reply-to globally - rather do it on the specific rules where it's causing an issue - like your WebUI access rule....

[ricksense]

If you're planning on Multi-WAN, you should not disable reply-to globally - rather do it on the specific rules where it's causing an issue - like your WebUI access rule....

Okay. Thanks