Restricting WebGui Access To One Interface

simply seth

I have:
Lan: 172 address
Opt1: 192.168.6 address

I can access the WebGui from both networks, how can I restrict it to LAN only?
Thanks.

Derelict

Put block rules on OPT1 above your pass rules.

Not being able to post attachments sucks.

I maintain two Firewall aliases: admin_ports (tcp 22,80,443,8443) and local_nets (CIDRs for all my local networks).

For public networks (like customer-accessible wi-fi) I then block all traffic to local_nets and, for good measure, to admin_ports on the guest interface.

You have to pass certain things like DNS first, which is why I wish I could post a screenshot. I also usually pass ICMP echo requests so they can ping the gateway, etc.

I've heard that pfSense 2.2 is going to maintain something like local_nets automatically. Welcome feature.

stephenw10

@Derelict:

I've heard that pfSense 2.2 is going to maintain something like local_nets automatically. Welcome feature.

+1 on that. :)

The webgui listens on all interfaces so you should also be aware that users on OPT1 will be able to access it using the WAN address if you haven't also blocked that (or just not allowed it in the first place).

Steve

The webGUI is listening on the WAN interface? HOW CRAZY IS THAT? Where should I have allowed that?

Derelict

There are no default WAN rules so all connections are blocked.

You have to specifically create a WAN rule allowing access to the webGUI port.

stephenw10

Exactly, this isn't an external security risk.
If you have created a rule that doesn't allow access to locally connected subnets then clients will not be able to access the webgui on the LAN or OPT1 (OPT2 etc) addresses because those are local addresses. However, as described above, you will have a rule that allows traffic with a destination of an external public address for general internet access. This will allow access to the WAN address and because the traffic is coming from an internal interface the rules on WAN don't apply so the webgui will respond.

Really you only need take this into account if you're wanting to hide pfsense completely as you might if you're running a public wifi hotspot for example.

Steve

…even on a "normal" OPT1 net I don't want anybody to be able to access the webGUI, including via the WAN IP. Now I have to fiddle some firewall rules for that, hmm...

stephenw10

Well you could argue that you have allowed access to it because by default no traffic is allowed. ;)
I pointed this out here because I was caught out by it. It would be nice if you could include the system alias 'wan_address' in your own custom aliases. I use a custom 'local subnets' to isolate interfaces I consider high risk and that would make it much easier.
You could use a floating rule and a custom port perhaps. There are many ways to prevent this as long as you are aware of it, which I wasn't.

Steve

I have a dyndns for the WAN address, which I use for site-to-site VPN allow-rule on WAN, which I could use for a block rule for OPT1, no?

Derelict

Reject from source OPT1 Net dest WAN address … Sure. (I'm partial to reject for this instead of block. Plays nicer with clients.)

stephenw10

Hmm, very good point I never thought of that. ::) Since you can include other urls in an alias I don't see why that wouldn't work.
But yes for a simple block rule you can just use 'wan address'.

Steve

Derelict

DDNS hostnames for security rules would make me nervous.

stephenw10

Ah, very true. If ddns fails for whatever reason the webgui would be exposed.

Steve

…something like this:

??

btw: as we are here together, some drinks arround, is anybody willing to share the secret how to force the internet traffic of a single clinet (say 10.0.0.30 out of 10.0.0.0/24) through an openVPN tunnel and the WAN of the other end of the tunnel? Any ideas :-)

Derelict

Looks good to me.

(Regarding the VPN, if you're gold watch the latest hangout with jimp about openvpn. I haven't set it up in test mode yet but there's all kinds of cool stuff in there. Your question was specifically addressed, IIRC.

Talking about it more should probably be its own thread.)

keyser

Whooa, this really caught me out too. I didn't realize this could be an issue.
I just tested, and my OPT1 does have access to the web gui using the WAN address.

I'm also using the local_networks alias and a NOT rule to grant internet access to OPT1 users.

One thing i don't understand however. Since the Webgui is listening on WAN, howcome i'm fx. Allowed to let my HAproxy listen on the WAN interface as well? Should't that create a port conflict (80 and 443)? I'm not doing that, i just seem to remember testing that and it worked.

Also, is there any way this could be used against me if i have NAT translation rules listening on WAN 80 and 443 to redirect to OPT1 servers?

Just for the sake of completeness: I don't need to block something on ipv6 to stop opt1 from accessing the webGUI? I don't use it, i turned it off in pfSense, but….

Is it possible to "spoof" my WAN IP to an IP of the local net of a remote pfSense and access the webGUI via the WAN interface?

Derelict

@keyser:

Whooa, this really caught me out too. I didn't realize this could be an issue.

Yeah. My guest network rules don't cover this either.

stephenw10

@chemlud:

Is it possible to "spoof" my WAN IP to an IP of the local net of a remote pfSense and access the webGUI via the WAN interface?

Hmm. Not quite sure what you mean by this. :-\ Can you clarify it?

Steve

Thankx for asking! Forget about it, just a strange idea after not enough coffee this morning… We're all safe, I guess :-D