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

[karan293474]

I have a problem that may or may not be related to this reply-to feature but I would like some help. I have a client for which I have put policy based routing in rule set to forward traffic out a different interface/gateway to test new ISP. Now I see packet enter from LAN interface and go out second WAN interface using my PBF and also see return packets on second WAN interface but thereafter I see no packets.
I did packet capture and noticed on my LAN interface outbound traffic is captured but incoming traffic is not captured whereas I see both incoming and outgoing packets on second WAN interface. So basically I see no return packets from internet on my LAN interface and internet access is broken for this test host.Any idea what may be wrong