Can't access WebGUI from OPT1 with pf enabled

Started by elyl, September 08, 2023, 10:41:34 PM

Previous topic - Next topic
Print
Go Down Pages1
User actions
September 08, 2023, 10:41:34 PM
I have OPNsense set up as a VM in Proxmox.

I have the WAN and LAN interfaces passed through to OPNsense, and I have OPT1 set up as the vmbr0 bridge from Proxmox, so that I can hopefully manage the router directly if it ever fails on LAN (and set it up without having to have everything live).

I can't seem to access the web gui from this OPT1 interface, unless I SSH in and pfctl -d to disable the firewall, then it lets me log in.

I have tried various combinations of firewall rules on OPT1 to allow all traffic, but I still can't access the GUI without disabling pf from the shell.  Logs say access to port 443 from my systems connected via OPT1 are failing on "Default deny / state violation rule".  WebGUI listen interfaces are set to All.

I feel like I'm missing something obvious, but even with an all * rule on OPT1, it's still blocked.  Any suggestions?
October 14, 2024, 08:43:21 PM #1
I had the exact same problem. Even an "allow everything" rule did not help. The only thing which made the gui accessible on OPT1 was changing its port from 443 to something else (4443 for me, still https)

(I know the question is old, but since I only found questions like this and never answers I reply anyway)
October 14, 2024, 08:51:18 PM #2
Quote from: Arigion on October 14, 2024, 08:43:21 PM
I had the exact same problem. Even an "allow everything" rule did not help. The only thing which made the gui accessible on OPT1 was changing its port from 443 to something else (4443 for me, still https)

(I know the question is old, but since I only found questions like this and never answers I reply anyway)

If you need hacks like that for extremely basic functionality to work it's time to look after the fundamental setup. Virtualization is definitely not helpful in such a situation.
kind regards
chemlud
____
"The price of reliability is the pursuit of the utmost simplicity."
C.A.R. Hoare

felix eichhorns premium katzenfutter mit der extraportion energie

A router is not a switch - A router is not a switch - A router is not a switch - A rou....
October 15, 2024, 03:36:25 AM #3
I have not yet verified this (still new) but I'm under the impression that the firewall does not deal with established connections seamlessly (e.g. reset state table, or insertion of a filtering bridge in live network). And by that, I mean that it doesn't seem to catch up.
That might apply to idle connections as well. Their state gets dropped at some point.
In both cases, in absence of state, further communication is blocked until a connection is reestablished from scratch.
Is my understanding correct?

Is it possible that all that's needed is a refresh or new session from a different browser?
Print
Go Up Pages1
User actions