Concerned port scan of pfSense public WAN IP shows all ports open (most likely noob error)
-
Hi all - I finally managed to put my Virgin Media cable modem into modem mode - so Ive only got one WiFi (plugged into my switch operating instead of 2) and that means Pfsense has the direct public WAN IP.
This was a goal and I was very happy to achieve it.
I thought Id run a port scan just to check everything is locked down.
To my shock every port is shown as open using an nmap -sT scan (I didtn wait for the stealth scan). A couple of port scanning apps on android indicated a lot of open ports initially and thats what made me try nmap as thats what I know best.
When I actually try to connect to the ports they dont connect, but then there is no services behind them.
Im very concerned as I love my setup but normally I would expect to see only the ports I have allowed through.
The firewall is showing it has blocked all requests, but the ports are showing as open!
I am confused as to whether this is normal but Ive not seen this before and it striked me as not normal!
My firewall rules are pretty much default for WAN, although there is an OpenVPN port 1194 which was the only one I was expecting to see as open.
Any help appreciated!
-
Firewall rules (WAN):
Rules (Drag to Change Order)
States Protocol Source Port Destination Port Gateway Queue Schedule Description Actions
0 /2 KiB
* Reserved
Not assigned by IANA * * * * * Block bogon networks
0 /0 B
IPv4 UDP * * WAN address 1194 (OpenVPN) * none OpenVPN OpenVPN wizard -
Port scan (from 4G device scanning public IP of pfSense WAN interface):
Host is up (0.039s latency).
PORT STATE SERVICE
1/tcp open tcpmux
3/tcp open compressnet
4/tcp open unknown
6/tcp open unknown
7/tcp open echo
9/tcp open discard... for every port! :-S
-
Tell us more about your Setup, show Firewall Rules and Logs as Screenshots.
I just checked with a very basic 2.4.4-p3 setup and it behaves exactly as expected.
nmap -sT xxx.xxx.xxx.141 Starting Nmap 7.60 ( https://nmap.org ) at 2019-06-02 10:35 Nmap scan report for xxx.xxx.xxx.141 Host is up (0.0050s latency). All 1000 scanned ports on xxx.xxx.xxx.141 are filtered Nmap done: 1 IP address (1 host up) scanned in 49.80 seconds
Make sure the Virgin modem isn't the devices answering to this request.
-Rico
-
Hi thanks for reply.
Many of the log entries are seemingly denying external IP#s from accessing 23, 8080 etc
Perhaps it is just my Virgin Media router that is blocking the requests?
I cannot think how to test this easily.
-
Lets say the port X was actually open... If you don't have it something listening, it could not show open.. There is nothing sending back a syn,ack to the syn... So whatever you testing methodology is wrong.. Is your phone on IPv6 - many carriers only give their mobile devices IPv6 and send that traffic through a gateway to get to IPv4.. Maybe they run you through a proxy?
If you want to do an external scan - then go to one of the services that do it for free.. Shields Up is a pop one.. And will give you the so called stealth info <rolleyes>..
Or validate your external source is not running through some sort of "ISP" shenanigans.
-
Why is the automatic block RFC 1918 rule missing?
Do you actually have two routers or is the Virgin one in modem mode?
-
Use this can test https://www.grc.com/x/ne.dll?rh1dkyd2
-
@johnpoz This is the result of the third party scan, which as you have mentioned might be a better method than a phone ISP. No open ports at least, which is reassuring! Thanks to all who helpd with your time.
Still wandering why they are showing as stealthed and not closed however.
-
@NogBadTheBad I purposefully removed that as one client used AWS Route 53 entries to point back to local addresses and this prevented it.
Just the Virgin one so....
Virgin Superhub (Modem mode) --> RJ45 VLAN 0.80 switch untagged through to trunk port on --> ESXi --> ESXi trunk port through to pfSense VM on vmx.080
The VLan part is seemingly working fine.
-
Stealth means there was no answer, closed means that something was returned.. either a RST or icmp redirect, etc.
Normally a firewall would just drop and not return anything.. ie "stealth" which is misleading at best. Just because your scan doesn't return anything doesn't actually mean you can not be found, etc..
Those are 135, 137-139 that are returning "closed" Could be your isp telling you sorry No Go on those ports.. Many an isp will on purpose block those.
Ah and the other is 445, yeah that is smb over tcp.. Also normally blocked by many a isp.
-
@johnpoz Thanks mate. That makes sense, guessing the root cause was me testing over a 4G/cellular data connection and therefore getting unreliable results.
Still have the results here:
ost is up (0.039s latency).
PORT STATE SERVICE
1/tcp open tcpmux
3/tcp open compressnet
4/tcp open unknown
6/tcp open unknown
7/tcp open echo
9/tcp open discard
13/tcp open daytime
17/tcp open qotd
19/tcp open chargen
20/tcp open ftp-data
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
24/tcp open priv-mail
<snipped by mod - just make post so long and useless info>
Won't let me move into code - says spam ;)Youd think they would set every port to closed if they were trying to stop hackers unless they have something akin to a honeypot.
-
Not sure what shenanigans they could be up too.. Could be something to do with a ipv6 to ipv4 gateway, they could be running you through some sort of tcp proxy, etc.
But tell you for sure testing such stuff over cell can be misleading info..
Could be a form of optimization.. where their handing you back a syn,ack before any sort of connection is actually made, etc. etc..
