Bind webGUI only to certain interfaces

[dam034]

Thanks for your replies.

Connecting with the data connection of my smartphone, I realized the webGUI isn't available on WAN interface, but is available from LAN interface visiting WAN IP.

About SSL, in LAN I don't need the HTTPS, but I can change the port of webGUI so the LAN users have less possibility to reach the webGUI. But I already know it's useless.

Now the question is reversed: if I will need the webGUI from the internet, can I enable it?

Thanks

[johnpoz]

@dam034 said in Bind webGUI only to certain interfaces:

if I will need the webGUI from the internet, can I enable it?

Yes you can - but its a REALLY BAD IDEA!!! If you need to admin pfsense from internet side it would be better to vpn in, then admin it through the vpn connection.

The gui will be available via the lan network with the antilock rules in place, no matter what port you change the gui too. You would need to turn off the antilock out rule, and then only allow the IPs you want to access the gui be it on the actual lan IP or another IP or even the wan IP from the lan side.

As to blocking users, its pretty trivial rule to block IPs you don't want to access the gui. But on the lan you have to disable the antilock out, then just create rule that blocks access to the gui port on firewall (built in alias) This will block ALL ips firewall, lan, wan, opt, etc..

[dam034]

Yes, I know it's a bad idea, and now I'm not thinking to do it.

I just want to know how to do it.
I have understood that there is an antilock rule which commands the webGUI.
Can you show me in what page I can manage it?

Thanks

[Derelict]

The anti-lock rule is on LAN, not WAN.

If you absolutely MUST access the webgui from over the WAN, I would strongly suggest source limiting the firewall rule to a subset of administrative networks/hosts (You can use a firewall Alias for this). Then you just pass TCP to WAN address on the webgui port you set in System > Advanced.

Nothing magical here.

[johnpoz]

The antilockout rule is ONLY On the lan interface, or on wan when there is ONLY the wan interface.

You can disable it here
System / Advanced / Admin Access

There is checkbox to disable antilock out

[dam034]

So now the webGUI isn't accessible from WAN, but if I create a NAT rule, it can be.

The NAT rule can accept connection from a subnet like 79.12.24.0/24 so only 254 IPs can access webGUI from WAN.

Am I right?

Thanks

[johnpoz]

You don't need a nat rule, just a rule to allow it on the wan to the wan address and the port the gui is on.

[dam034]

Thanks for the replies.

Now I want to ask the same informations about the SSH connection.

Should have I to open another topic or can I continue here?

Thanks

[johnpoz]

What is your question? That port will be allowed on lan as well for antilockout.

[dam034]

Just a moment.

I create a teporarily rule to enable the webGUI on WAN interface:

But visiting from my smartphone in data connection, I can't access it.

Am I wrong?

Thanks

[johnpoz]

Does pfsense have a public IP on its wan, or its it behind a NAT? Its quite possible your ISP blocks port 80 inbound.. Many do on home connections, etc.

I don't see any hits on that rule - so traffic prob never even go to pfsense. that 0/0 tells me nothing has hit that rule

[dam034]

The pfsense machine WAN IP is private, and I'm now trying from another pc in the same LAN as pfsense's WAN interface.

Is there any mistake?

Thanks

[Gertjan]

@dam034 said in Bind webGUI only to certain interfaces:

The pfsense machine WAN IP is private, and I'm now trying from another pc in the same LAN as pfsense's WAN interface.
Is there any mistake?

No mistake at all.
Look at your firewall rules.
The first rule is put in place 'automatically' when you check this option on the WAN interface.
Here it is :

So, when this box is checked - yours is checked - local IP's like (192.168./16 10/8 etc) are blocked.
The counter in front of your first rule indicates it is blocking "something".
These must be your attempts to use your phone to connect to the GUI.

When you use your phone, you use some real WAN IP (an address IPv4 that is addressable on the Internet).
The connection comes in on your first router, probably the one your ISP gave to you, or some other upstream device.
This device NAT's to the pfSense WAN IP - and this IP is a "RFC 1918" class IP.
pfSense, according to your instructions, blocks these IP's.

Btw : before you ask : the second rule will not bother you, although it's a nice exercise to know who's triggering that rule ^^