I have an OPNsense box connected to another firewall on its WAN port (Daisy chained). I want to access from another system that is connected to that higher up firewall.
When I run this command in the Opnsense console:
echo "pass in quick on ix1 proto tcp from 192.168.10.101 to (ix1) port 443 keep state" | pfctl -f -
I can access the webui.
I then add the rule for the WAN interface to allow in the traffic that matches that rule, click save, then apply, then I get nothing but a small hang and white web page. PLUS, I then have to redo the console command to even access the webui again.
How can I acheive what im trying to do?
Don't block RFC1918 in Interfaces - WAN
I actually saw that and disabled it when I was trying to fix things. (Block private networks). I confirmed it was disabled again and I still have the same issue.
Here's what finally fixed my WEBui access from the WAN
Firewall / Settings / Advanced - Disable anti-lockout = Checked
I already had - Disable administration anti-lockout rule = Checked
That didnt work neither
Can anyone pls help? Surely I am not the first to want to do something like this.
Disable the anti-lockout rule and also disable force gateway (in Firewall > Settings > Advanced). That *should* do it.
It didn't. :(
Quote from: Patrick M. Hausen on September 24, 2024, 10:50:37 AM
Disable the anti-lockout rule and also disable force gateway (in Firewall > Settings > Advanced). That *should* do it.
Do you have any other ideas?
Use tcpdump to observe what is happening.
I also disable "Firewall: Settings: Advanced - Reply To" for my daisy chained OPNsenses since when you communicate with them on the WAN port they send the packet back to their default gateway instead.
In my experience that one needs a restart of the router.
Quote from: Monviech on September 26, 2024, 08:09:59 AM
I also disable "Firewall: Settings: Advanced - Reply To" for my daisy chained OPNsenses since when you communicate with them on the WAN port they send the packet back to their default gateway instead.
In my experience that one needs a restart of the router.
In my case, wouldnt the default gateway be the router which my system is using? So it would be right?
I did try that, and rebooted, and I still need to do my console command to get access.
Quote from: bravosecure on September 26, 2024, 03:01:02 PM
In my case, wouldnt the default gateway be the router which my system is using? So it would be right?
Right when trying to access across the Internet. Wrong if there is an entire WAN network and you are trying to access the UI from a PC connected to that same network as OPNsense and the default gateway.
In that case sending the reply packets to the gateway instead of using ARP on the local network is exactly what makes the UI access fail.
I wonder why that "magic" exists at all. OPNsense should follow its routing table and that's that. Unless explicit policy routing is configured.
P.S. use tcpdump on WAN and observe what happens.
Quote from: Patrick M. Hausen on September 26, 2024, 03:04:25 PM
Quote from: bravosecure on September 26, 2024, 03:01:02 PM
In my case, wouldnt the default gateway be the router which my system is using? So it would be right?
Right when trying to access across the Internet. Wrong if there is an entire WAN network and you are trying to access the UI from a PC connected to that same network as OPNsense and the default gateway.
In that case sending the reply packets to the gateway instead of using ARP on the local network is exactly what makes the UI access fail.
I wonder why that "magic" exists at all. OPNsense should follow its routing table and that's that. Unless explicit policy routing is configured.
P.S. use tcpdump on WAN and observe what happens.
Given this, what should I set here (in the rule)
Also, why would this behaviour not be happening when I use the console command? It seems to be only linked to the GUI. I may need to screenshot my entire rule... maybe there is something I am doing wrong.
Here is the full rule in PDF format. The source "Lan Address" was the last thing I tried. Before I had it set to the actual IP address of 192.168.10.101.
Nobody has anymore ideas?
The source needs to be "any".
Quote from: Patrick M. Hausen on September 28, 2024, 01:23:28 AM
The source needs to be "any".
Tried that and it's still timing out. Still need to do the console command to connect.
Scratch that. It worked. Thank you!