Can't access GUI from WAN interface

[Ph0enix]

I'm doing some testing and I have an instance that is on my local network. The WAN interface is on my local interface and LAN has a different local network behind it. My PC is on the same local network as the WAN interface so it's convenient to access the GUI from that interface. At this point it's also about understanding what's missing for that to work.

Upon doing some research I've done the following:
- System -> Settings -> Administration -> Listen Interface == "All (Recommended)"
- On the same page I switched to `HTTP` just to make sure there are no HTTPS issues involved.
- Interfaces -> [WAN] -> "Block private networks" is unchecked
- Firewall -> Rules -> Wan. I added the rule to allow all the incoming traffic on the interface (IPV4+6, any source IP, any port, etc.), obviously not something to keep in production, just for testing. Same rule for outgoing traffic.

It appears that now the connection is not fully blocked but I get `The connection to the server was reset while the page was loading.` when I try access it via WAN interface. Works fine through LAN interface. If I disable the rule that allows all incoming traffic I get timeout so the firewall rule seems to allow the traffic to go through but there is something else that interferes with the connection.

If I execute `pfctl -d`then I can access the GUI via WAN.

What am I missing and what else needs to be configured to make it work?

I also tried to check some logs but I could not find any relevant connection attempts, maybe I need to increase the verbosity of the logs? In any case some pointers on how to investigate the issue would be appreciated as well.

[CJ]

How are you currently testing if you don't have something on the LAN side to access the UI?  Also, any reason other than double NAT to not put your PC on the LAN side?

Another option for testing is VMs.  OPNsense doesn't require much resources and you can spin up a tiny linux VM for a client to test with so that shouldn't bog you down much either.

[Ph0enix]

I'm testing in a VM. And I have another VM through which I can access the GUI via LAN network.

I could in theory arrange for my PC to get on the LAN network behind OPNsense but that's not the point of the current exercise. The point is to understand why setting up direct access to GUI does not work.

[franco]

Sounds like a case requiring to enable Firewall: Settings: Advanced: Disable force gateway.


Cheers,
Franco

[Mega32]

I'm testing in a VM. And I have another VM through which I can access the GUI via LAN network.

I could in theory arrange for my PC to get on the LAN network behind OPNsense but that's not the point of the current exercise. The point is to understand why setting up direct access to GUI does not work.

Do you use VirtualBox ?

I have the same issue ....
I have setup OPNsense in VBOX (Linux mint)  , and bridged OPN/VBOX WAN to my linux LAN IF.

If i try to connect (or ping) from my linux to the OPN WAN , pf is denying access (logs default deny - TCP A)
pfctl -d  solves it ... Until nexst fwall change (where pf s prob restarted or enabled)

My solution was to connect from another physical pc to the OPN WAN , then it worked ....

My guess in my case ...VBOX has an issue w. bridged packets in/out of same phys IF.

[Patrick M. Hausen]

In VirtualBox you cannot communicate from host to VM and vice versa on the NAT interface. You need a host-only network for that. Not quite sure about bridged but it might behave the same as NAT in that regard.

Anyway, to run OPNsense in VirtualBox I recommend using Vagrant:
https://github.com/punktDe/vagrant-opnsense

[Ph0enix]

Sounds like a case requiring to enable Firewall: Settings: Advanced: Disable force gateway.

Thank you for the suggestion but that did not help. I'm also not quite sure why it would help since the connection is within a single network so there is no routing involved.

[Ph0enix]

Do you use VirtualBox ?

No, it's in VM running on Proxmox.

[franco]

Sounds like a case requiring to enable Firewall: Settings: Advanced: Disable force gateway.

Thank you for the suggestion but that did not help. I'm also not quite sure why it would help since the connection is within a single network so there is no routing involved.

Because if you are directly connected from the WAN network segment the response of the firewall goes to the router. In some cases the router will not send it back to you. This is a common (testing) issue. In the real world it doesn't matter that often because between WAN and ISP there is nothing that needs to connect back to the firewall directly. And as long as the next hop is taken this is cured by routing. It still sounds like your issue given that pfctl -d makes it work indicating a firewall rule manipulation doing this.


Cheers,
Franco