says my PFSense router is on the web; how can I stop it? tells me that port 443 is open. When I visit my public IP, it brings me to the PFsense page. Weirdly enough, the only port that I have knowingly opened is 25565, for a Minecraft server.

I have no idea how long it has been enabled for, but I’m not too concerned about being comprimised because I’ve always been on the latest release, and use a strong admin password.

Upon finding out, I setup a WAN rule as follows

However, is still showing that port 443 is open, but thankfully the PFSense WebGUI is no longer accessible.

I’m still concerned that port 443 is still opened for the PFSense router; how can I stop it? Thanks

1 Like

By default the WAN interface should block everything so if the only rule you have is for a portfoward then something is wrong. Can you post a screenshot of the wan interface rules page?

Also the source in that block rule should be ‘any’ not ‘wan net’. Wan net is the subnet of your wan address which is usually a /32 address, so wan net and wan address usually mean the same thing. This is probably why the rule works when you try it locally but is shown as open when checking externally.

they scan the entire internet… that takes lots of time…
It might be a week before they get back around to trying your IP again and then updating their site.

1 Like

If I set it to “any”, would I still be able to access the WebGUI from my LAN?

You’re right; is telling me they last updated my IP on the same day I made the rule change, except at a time earlier then my implemented rule change.

I think that upon me setting up the port-forwarding for the MC server, it also opened up the Webgui for PFSense, because I explicitely remember being curious and checking BEFORE opening the MC server, to see if there are any existing ports/services open, and it showed “No results found”

Have you considered using something like nmap from an external IP address, just to check?

Like with a laptop tethered to a phone or something ?


That’s a good idea. Never used nmap before, but I know it’s fairly simple. I’ll give it a try shortly. Thanks!

1 Like

So if you visit your public IP from home, it will go to your pfSense box, I can do the same thing and I will see my pfSense box, but if I was to visit my IP from an external devices outside my network, then I cannot reach the pfSense box.
This might have been the case with you. You can double check by using a mobile phone on data to actually confirm your pfSense box is not reachable from the outside.


I did do this; used my phone not connected to WiFi, but instead mobile data, as well as connected my desktop PC to a VPN; both allowed a connection to my PFsense box from the WAN.

Now I can’t seem to replicate the results? I tried running NMAP as well as online alternatives, with my “fix” enabled and disabled, and I can no longer access the WebGui from the WAN.

ANYWAY, I guess it’s fixed now, so thanks? ¯\(ツ)

Somewhat related to the MC server; I placed it inside a DMZ which has no access to any other LAN networks, and also has Surricata enabled on the DMZ.

Does this pose as a security risk?

(Switchport = LAN, is the MC server in the DMZ). Should I instead be VPN’ing into the DMZ, to access the MC server?

443 is typically https, or http on port 80. meaning if your connected to the web and its an https page your on.
your system will use 443 to authenticate the handshake by default.
where as if its an insecure http, it will be handed to port 80 by default.

and because you were connected to shodan via an https connection it would see your system as having 443 open until you disconnect from its site.

and guys/girls remember shodan has its used for security, but its also a REAL privacy violation.
every search you make with it is logged and matched to your token id, which is then stored…
i have no idea if they sell the data or just make it into another database they can mine.
but they do log everything so be careful how you use it and who you look up.

no… browsers use high values ports when they connect to a server

check your netstat to confirm

1 Like

Yes, the WAN rules don’t effect traffic coming in to the LAN interface. Any in this case means anything coming in on the WAN interface, ie. Internet traffic.

But this rule should be redundant as there is no allow rule to allow traffic to 443 on that interface everything should be blocked except for your port forward.

1 Like

i did check with netstat. and your right the browser does connect via a higher port.
after being redirected from port 443.
like i said port 443 is used for https authentication.
unless you change that port or its function.
if you feel up to it. load up wireshark and examine a connection. you will see your browser first connects to 443 of the server your going to browse and the server sends back and saying connect via this port. often up in the +9000 range. then when you send and receive data you do so though the higher port but every message is authenticated by port 443…
so basically port 6000 says can i send/receive. 443 says yes or no.

also if you have it look with tcpview or similar. you should see there’s a listener open by default on 443. for any webpage you visit. and a local high port outgoing to it. netstat just shows you your local outgoing port connection not the destination port.

if your connecting to a different service say a remote login to your own server. then the authentication port will be what ever you set it to, or it sets by default.

hope that helps. :slight_smile:

Two things:

First, do you have any floating firewall rules? Those might be allowing the traffic.
Second, the rule to block the web gui should be set to NOT LAN Net (select LAN Net for the source and then tick the match reverse box) to be safe, but can be set to any. Honestly, you shouldn’t even need it as the firewall is deny by default. Having it be WAN Net just means you’re only matching packets that source from just the connected network on the WAN port and not the Internet as a whole.

I found the same thing a few months ago while doing some security research on IP leaks and pfsense serves you from WAN too if you are on lan. Not a huge deal.
Try to https://wan_pfsense_ip:port from inside.
Here’s a pic of netstat -an -4

Firewalls have special sets of rules for controlling internal flow from themselves to interfaces.

So, why did shodan know your internal firewall answers from the wan side?
I can’t know for sure. websockets or webrtc? Browsers are a mess and sonar.js.
Routers can become confused. If you don’t need STP,CDP,SNMP,IGMP → block rules/disable. Routersploit those embedded toys to poke hole perhaps too.

Public Wan, no answers

I suppose you can get rid of anti-lockout + lan to all 443 rule. Plan ahead.

2 Likes free port scanning tool which I use to test my router configs