[SOLVED] How to disable web interface on OVPN client interface

[graymattr]

Hi folks,

I've recently set up a client OVPN on my pfsense router.  It's working great, well, a little too great, as the web UI is reachable on the OVPN address.  I've followed the steps here:  https://doc.pfsense.org/index.php/Restrict_access_to_management_interface, but I cant seem to get the web UI to only be reachable from LAN addresses.  Attached is a picture of my current LAN firewall rules.  It seems to be correctly preventing me from reaching the pfsense UI from my WAN IP, but not from the OVPN Client IP…

I'm fairly sure I'm missing something obvious, but I think I've been staring at this for too long to see it.  :)  Any help is very much appreciated.

Cheers!

[KOM]

Shouldn't your block rule be on the OpenVPN interface as well as the LAN interface?

[graymattr]

Ahh yes, I totally forget to include that.  Apologies.  Here's the rule I have on the OpenVPN interface.

EDIT:  The OpenVPN interface is for the server, the one shown is the client.  Just realized that might be confusing.


[KOM]

I'm still unclear.  Your OpenVPN interface is to allow pfSense to connect to some external VPN service, and the SONICVPN interface lets your external clients connect to your pfSense?  Did you clear all states before running your tests?

[graymattr]

Sorry, no, it's the other way around.  Sonicvpn is the client (facing outward), OpenVPN is the server (for remoting in).

What do you mean by clear all stats?  I set the rules, reload them, and then test from an external network (via browser and nmap).  Is there another step I am missing?

Cheers

[KOM]

Sonicvpn is the client (facing outward), OpenVPN is the server (for remoting in).

And who is able to reach your WebGUI, your OpenVPN remote users?  If so, the rule should be on the OpenVPN interface, not the Sonic.

What do you mean by clear all stats?

Existing states don't get torn down with a firewall rule change.  Go to Diagnostics - States and clear/reset them (or filter for specific states and just clear those), then try your test again.

[graymattr]

The GUI is reachable on the client (Sonic) IP address (which is where the rule I posted is).  Thanks for the tip about states, I didn't realize that and I'll make sure I clear/reset those on firewall changes.  Maybe that's the issue…

EDIT:  Cleared all states, no change.  I'll keep fiddling my rules unless anyone has any other ideas.  The good news is that these rules are preventing GUI access on my WAN (non VPN'd) IP.  Halfway there.

[graymattr]

Would it make more sense/work if I set this up as a floating rule?  I was thinking I could allow on the LAN interfact from my 192.168.0.0/24 network as a top rule, and then reject any from LAN/WAN/SONICVPN.

Am I understanding floating rules that they are matched before interface rules, and in order?  Thanks so much!

[KOM]

Floating rules are typically used for traffic shaping.

[graymattr]

Ahh, ok.  I'll stick with the per interface variety.  I'm developing a bruise from all of the banging my head on this one.  :)

[graymattr]

I found it.  I had a rule on the OpenVPN interface (that was labeled "Rule via Wizard" or similar, so I didn't pay much attention to it) that was passing *.  I might have broken my OpenVPN Server config temporarily, but I've secured the web GUI from the VPN client VIP, which is want I was trying to do.  I can re-add server rules that are less permissive over time.

Thanks so much to KOM for the help.  Sorry for being a bonehead.  :)

Hope this helps someone else.