Restricting WebGui Access To One Interface

[Guest]

…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

[Guest]

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

[Guest]

…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?

[Guest]

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

[Guest]

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