[Solved] Port 53, 80, 443 always open on all interfaces
-
Hello,
I'm quite satisfied with pfSense, however I cannot get rid of an annoying issue about open ports from WAN.
I have 3 WAN facing interfaces: WAN, VPN1, VPN2
Webconfigurator is set to listen only on 443, detailed settings:
In System - Advanced
- Protocol: HTTPS
TCP Port: 443
WebGUI Rediret: disabled
Tried with disabled WebConfigurator antilockout rule as well
I have some user defined firewall rule, however nothing which would open these ports from the WAN and VPN channels. To make sure I have created a rule and put on the top of WAN to explicitly deny them (IPV4, TCP/UDP, from * source, from * port to WAN Address on 53-443, Gateway: *). If I scan the interface IP from outside, I see these 3 ports are always open.
Is this a bug or what did I wrong here? As I understood, pfSense never does such thing by default)
Thanks a lot for your help.
**[Solved]
Tried to summarize what was going on during troubleshooting this issue:
-
The portscanner app used on iPhone was not reliable as indicates port 80 and 443 open on WANIP, however online portscanner tools show them filtered. Resolution is to use online portscanners.
-
53, 80, 443 ports are reported as open (by online portscanners) on the remote IP of the pfSense OpenVPN client, however this comes from the box of the ISP or VPN provider. Evidence: the result is the same with disconnected VPN client on pfSense, even with powered off pfSense box.
-
The request in a browser to http://VPN_IP shows an nginx error page with 403 Forbidden. I thought it's pfSense, however it comes from the box of ISP or VPN provider. Evidence: the result is the same with disconnected OpenVPN client on pfSense, even with powered off pfSense box.
-
The request in a browser to https://WANIP lands on the pfSense Login page. I thought port 443 is open on the WANIP, however the test wasn't accurate as the client probably connected back to the access point then the request routed internal.
Thanks a lot for everyone who helped me with this case!**
- Protocol: HTTPS
-
How exactly do you test these ports, any devices in front of pfSense (ISP router for example). Do a packet capture on the WAN interface and see if the traffic actually arives, or if your ISP is doing something with it.
-
How exactly do you test these ports, any devices in front of pfSense (ISP router for example). Do a packet capture on the WAN interface and see if the traffic actually arives, or if your ISP is doing something with it.
Ran a port scanner from my phone (4G gsm network, iPhone, 'Net Analyzer' tool). Targeted the WAN IP, and the VPN public IPs (what you also see as Remote Host IP in Status - OpenVPN).
Also accessed http/80 for example from an external browser and landed on the pfSense box with an error ("403 Forbidden", nginx). So I'm sure these ports are really open from outside.
-
Make sure WLAN is disabled on your phone when you test. If the ports are open then you must have created rules that allow incoming connections. Post screenshots of your WAN and floating rules.
-
Make sure WLAN is disabled on your phone when you test.
Yes, sure. I take care of that, otherwise I would scan from the LAN.
If the ports are open then you must have created rules that allow incoming connections. Post screenshots of your WAN and floating rules.
My feeling is, it's opened by a service or services and I don't see it on the GUI. (DNS Forwarder and WebConfigurator for example). Btw, I checked DNS forwarder to use only the LAN interface.
Thanks a lot for your effort reviewing my problem.
-
Post screenshots of your WAN and floating rules.
Added screenshots about Outbound NAT and Port Frowards as well.
1:1 and NPt are empty.
-
I got caught with this once before where there was a pre existing state entry in the state table for my test before i changed the firewall rules. Can you check your state table and delete any states to those ports and test again?
-
Can you check your state table and delete any states to those ports and test again?
Tried a state reset, but did not help. Anyway, thanks for the hint.
Did a fresh portscan on WAN, VPN_US and VPN_HU public IPs, seems the WAN and VPN_HU IPs did not have 53 open anymore.
Current status:
WAN, Open ports: 80, 443
VPN_US, Open ports: 53, 80, 443
VPN_HU, Open ports: 80, 443Opening the public IPs from external browser:
WAN, http/80: timeout
WAN, https/443: pfSense login page
VPN_US, http/80: 403 Forbidden, error page from nginx, see screenshot
VPN_US, https/443: browser error: ERR_CONNECTION_CLOSED
VPN_HU, http/80: 403 Forbidden, error page from nginx, see screenshot
VPN_HU, https/443: browser error: ERR_CONNECTION_CLOSED
-
By default, nothing is open on WAN unless you open it up yourself. You don't need to add specific block rules since all traffic is blocked unless there is an explicit allow rule. If a scan of your IP always shows open ports for 80,443 then I would tend to believe that it's hitting your ISP's equipment somehow. Easy enough to do a packet capture on WAN while scanning it and look at the traffic in Wireshark. Running nmap to fingerprint it might also be helpful if it exposes what kind of device is responding.
-
If you are getting a response into WAN from the outside on 443 then you have a rule passing the same. Period.
You're not getting any weird "Can't load rules" errors or anything are you?
Here's what I would do:
Figure out whatever address you are hitting pfSense from, packet capture on WAN filtered on that address and test again. While you're testing also look at the states filtered on that address. See what it's really doing.
-
You can check the full pf ruleset: https://doc.pfsense.org/index.php/How_can_I_see_the_full_PF_ruleset
Did you enable UPnP & NAT-PMP?
-
@KOM:
By Running nmap to fingerprint it might also be helpful if it exposes what kind of device is responding.
Understand, but it's not a question what's responding as I see the pfSense login screen if I open https://WANIP from a foreign browser.
Capture might be helpful to see what's the situation on the VPN_US IP, as this is the only one which respond to port 53.
-
Did you enable UPnP & NAT-PMP?
No, never touched that. Just checked it under Status - UPnP & NAT-PMP, it's disabled.
-
If you are getting a response into WAN from the outside on 443 then you have a rule passing the same. Period.
You're not getting any weird "Can't load rules" errors or anything are you?I did a week ago, but it's disappeared by setting this value to 400 000:
System -> Advanced -> Firewall & NAT -> Maximum Table EntriesRead on the forum somewhere, that's the solution. I have no error since then.
-
Figure out whatever address you are hitting pfSense from, packet capture on WAN filtered on that address and test again. While you're testing also look at the states filtered on that address. See what it's really doing.
- Switched to the GSM network again from my phone and checked my public IP
- Started a packet capture on WAN with filling the IP above to Host Address.
- Ran a portscan from the phone on 443 only
Result:
16:55:59.218056 IP PHONEPUBLICIP.54409 > WANIP.443: tcp 0
16:56:00.219797 IP PHONEPUBLICIP.54409 > WANIP.443: tcp 0
16:56:02.226128 IP PHONEPUBLICIP.54409 > WANIP.443: tcp 0 -
I see the pfSense login screen if I open https://WANIP from a foreign browser.
While on LAN or WAN? If you are on LAN and access your public address in a browser, pfSense will give you the GUI even though it isn't accessible from WAN.
-
@KOM:
While on LAN or WAN?
While I'm on WAN on a very different network. So Webconfigurator is exposed to WAN attacks at the moment which really concerns me. I will put WebConfigurator to another port to decrease the risk as 80 and 443 are open from WAN.
-
That packet capture shows nothing but SYNs.
Again, if you can get to the WebGUI you have a rule passing the traffic.
Look at the states. See what's really happening.
-
If he was getting to his gui from his wan, then his packet capture would show answer, ie syn,ack - like derelict says it only shows syn…
-
I'm wondering if he's got the bogonsv6 issue and his ruleset has failed to load?
