Hello. So currently I have a coax modem in bridge mode that connects to my pfsense firewall. Their are rules on most vlans (untrusted) that blocks access to the firewalls login portal. The thing is if I use my public IP any internal device can access pfsense’s portal login. Is this because it’s hitting the coax router. Can I block this? Is this as simple as blocking my public IP internally on 443 or is their a more common practice method. Their are no nat rules to allow this and my pfsense does have a public IP so bridge mode is active. They only reason I found this out is because my wan made a DNS request to my internal DNS server which I found weird. The only port I have allowed in from my wan is wire guard.
What do you mean by:
Do mean that you allowed the pfSense UI login to appear on the WAN interface that has your public IP?
This is in general not a safe idea because then everyone on the Internet can access this login screen. What could possibly go wrong!
If your login is allowed for access on the WAN interface then all you internal networks that can access the Internet can also access the login page - because it IS on the public Internet now.
Then again you might have meant something entirely different which did not become clear to me.
Apologies. If I go to https://publicip it sends me to my pfsense login page. Yet if I try browsing to it on my phone off wifi or nmap from outside my network theirs no access. So with no nat or forwarding rules how are my internals allowed to travel to my pfsense’s public IP and have access to the portal.
To be honest, I never tried that before and now I found this:
(1) from networks that are supposed to access the pfsense login I can also access it through my public IP
(2) from networks that are NOT supposed to access the pfsense login I CANNOT access it through my public IP
My understanding is that the web server for the UI is running on localhost for the pfsense and as long as port 443 or 22 on the pfsense are reachable from some network, then you can access the UI.
I guess the public IP is just one of many IPs the pfsense has and it makes no difference which of the IP addresses of the pfsense are used. The difference is what the rules are on the interfaces and if those explicitly allow or implicitly deny access to port 443 / 22 on the pfsense.
Yes, I have understood that you are saying that you do not have observed behavior (2). I’d take a close look to all the rules you have on the interfaces that are not supposed to access to the UI.
Lets assume you have Interface A with IP address 10.10.10.10. if you can access 10.10.10.10 port 443 form 10.10.10.X then you can also use publicip instead. If there is no access from 10.10.10.X to 10.10.10.10 then also publicip should not work instead of 10.10.10.10.
In your case I’d check if that holds for all your interfaces.
so i just added a floating rule to apply on every internal vlan that blocks 443 to my public ip and its still getting through. i ran a traceroute and its its the first and only hop. i dont even see my vlans gateway as a hop. what am i missing. only natting rules is port 53 to force dns to pihole no matter where its destined too. @LTS_Tom pls help grand wizard.
so i guess the browser was holding onto the connection. when i used a new browser it blocked the connection with the floating rule to all interfaces. Yet this has to be some setting in advanced > nat + firewall that im missing. this only happened after the latest major release.
The firewall in pfsense looks at the source IP/network to make rule determination. My computer IP is 172.16.16.9 and my pfsense allows access from the 172.16.16.0/24 network to the admin page https://172.16.16.1:10443/. My rules block access on my camera network which is 192.168.60.0/24 but I can get to my pfsense admin page at https://192.168.60.1:10443/ when coming from 172.16.16.9 but this would not work coming from an IP in the 192.168.60.0/24 network. This is expected behavior because of rules based on source IP.
@LTS_Tom thanks tom but if wan is blocking all ports but wireguard (followed your video to the T) arnt the vlans coming into that interface and thus should be blocked? i understand i can access the portal from the gateways of each vlan but i am putting my public ip into any browser on any vlan and it is coming to the pfsense page. i didnt’t know if this is a nat error on my side in advanced prefs or this is default behavior. I have now put an implicit deny floating rule on all interfaces but i still find it weird.
If you are coming from a network that is blocked, such as from a public IP the default WAN rule to block should block that.
I would expect that the floating rules is unnecessary.
I have a rule that lets 443 out of the vlans to any which is why it’s prob allowed but prior to the I have block 443 to firewall. It works for the vlan gateway but not for the public. I get a lease from my provider so now I have a floating block 443 to an alias to my dynamic DNS public IP.
But agreed didn’t know I had to do this. Thought the block “this firewall” would cover it.
I am not using a pass to “*” (anywhere) rule on any interface. To let people browse the Internet I use a rule that allows to “! ALL_RFC1918” where ALL_RF1918 is an alias for all address ranges reserved for internal use and notice the exclamation mark which then negates this address space.
With such a rule if someone tries to access a port on the pfsense this will be blocked by the implicit default deny rule at the end of the rule list.
Hence I dont need to deny accesses to the pfsense explicitly.
You probably deny it for the Interface address only, but you would need a rule that blocks access to the interface address and also to the WAN interface address - and this on each interface.
Yeah sorry to be specific my any rule to the internet is an alias for my vlans as the source. So same same just more specific to what is created. I add to the alias as the vlans grow…
There’s something more fundamental going on that’s completely normal, and that’s that an IP host will typically accept traffic on an interface that’s addressed to any of that host’s interface IP addresses, even the addresses of other interfaces. So, if you’re on the LAN interface and attempt to connect to (e.g. ssh, web connection, etc.) or even just ping the pfSense public WAN interface address your connection request will arrive on the pfSense LAN interface, pfSense will recognize the destination of the request as one if its own IP addresses, and accept the connection. Any access rules that use the source address (i.e. LAN subnet) to allow such connections will still work, since the source address is still trusted. This is not an aberrant behavior on the part of pfSense.