Open Ports on New Installation
-
Not sure what your scanning - but clearly it would be impossible for ALL Ports to be open. Which ports showed open? For something to be open something has to be listening, so its just plain impossible for them "all" to be open.
Yes out of the box there are no port forwards, there are no wan firewall rules so nothing would be open. Why don't you post up this can you did. So for example here is my scan.
GRC Port Authority Report created on UTC: 2016-07-19 at 15:21:21 Results from scan of ports: 0-1055 1 Ports Open 0 Ports Closed 1055 Ports Stealth --------------------- 1056 Ports Tested NO PORTS were found to be CLOSED. The port found to be OPEN was: 443 Other than what is listed above, all ports are STEALTH. TruStealth: FAILED - NOT all tested ports were STEALTH, - NO unsolicited packets were received, - A PING REPLY (ICMP Echo) WAS RECEIVED.As you can see from the attached rules and the scan results above and graphic only port open is 443, which I have open on purpose because I run openvpn on this port to get around locations that might block udp 1194, etc.
-
Many thanks johnpoz for your feedback. On a previous install of pfSense I did progress to creating a couple of port forwards, eg. including 3389, and these both worked as expected. After observing what seemed to be open ports I decided to do a complete reinstall of pfSense and test for open ports before creating any Port Forwards or Rules and that is where I am now. Default SheildsUp probing reports the following:
---------------------------------------------------------------------- GRC Port Authority Report created on UTC: 2016-07-19 at 23:07:05 Results from scan of ports: 0, 21-23, 25, 79, 80, 110, 113, 119, 135, 139, 143, 389, 443, 445, 1002, 1024-1030, 1720, 5000 26 Ports Open 0 Ports Closed 0 Ports Stealth --------------------- 26 Ports Tested ALL PORTS tested were found to be: OPEN. TruStealth: FAILED - NOT all tested ports were STEALTH, - NO unsolicited packets were received, - NO Ping reply (ICMP Echo) was received. ----------------------------------------------------------------------I seem to have jumped on the wrong train at the beginning of this journey. I am sorry for my pre-newbie experience here.
-
With your prompting johnpoz I have just discovered the ShieldsUp graphic report for all ports that might shed light on my problem. (apart from me, which I think is the main problem)
Does the mix of ports open and stealth suggest how I should progress my issue?
Re-running the ShieldUp utility produces similar but not identical results.
-
Does your pfSense have a public IP address on its WAN? If it's behind another NAT router the open ports are caused by this other router. Compare the reported WAN address in the Webgui against what the GRC page reports as its idea of your IP address.
-
Thank you kpa for your feedback. My WAN address is definitely a public IP address. It is assigned by my satellite ISP. It is reflected in both the pfSense Webgui and the GRC record of IP.
-
That scan is certainly not of a pfSense install in the default configuration. It would return nothing (all "stealth") on all ports. It is scanning or receiving results from something upstream of you.
Diagnostics > Packet capture on interface WAN. Set the number of packets to 0. Start it, run a Shields up scan, and stop it.
You will probably not see any of those attempts hit your WAN. You certainly won't see the TCP SYNACKs that GRC is seeing leaving your WAN.
-
Yeah ^^^
Could also connect only a PC directly to satellite modem and scan again, probably the same result. -
That clearly is not pfsense with those ports open, its something in front of pfsense or something you have forwarded too. Pfsense sure not going to be listening on 445, ftp and telnet… 135 and 139 etc..
Not sure what your scanning there Bruce but it sure and the hell is not pfsense ;)
Derelict suggestion right on the money - I would highly suggest you sniff and then scan.. you would see something like this if packets are actually making it to pfsense.
-
Thanks guys for putting me straight. I will come up to speed with interpreting packet capture soon. In the mean time I have just swapped back to an old Billion router and run a ShieldsUp and of course got the same open port pattern as before. There must be something going on in the satellite delivery of internet that I am yet to understand. My WAN IP is definitely a Class C Public address. I will follow this up with the provider. Thanks again for your helpful words.
-
To be honest the ports you showing open are quite common ports than an ISP would block.. 1002 for example is old MS netmeeting locator service port. Port 1720 is also a netmeeting used port. 5000 UPnP, etc. I could see many a isp blocking those.. And the typical server ports, 21-23 and 80,443 and 25,110,143 all email related inbound. etc. etc..
-
That is just a quick scan GRC does of common ports. The other scan with the bands of blocks is more telling of some automated system.
I am guessing that a satellite provider does not want internet noise actually using transponder time so they are just eating inbound connections before they go up to the satellite and making them go away. Though I would probably RST them instead of SYNACK them. They might have their reasons.
I would also search your provider's help for inbound connections and port forwards and see what they have to say.
-
^ yeah that makes complete sense Derelict why send the traffic up to the sat, back down to the subscriber to just to be denied. But what is the point of giving the user a public IP if they are not going to allow unsolicated inbound traffic to them. Why not just put them behind a nat, and let them have some sort of interface/portal to setup the forwards they need? What system in place do they use to check if port is open before allowing the traffic to the actual user?
I have no experience with sat connections. Off to do some reading ;)
But I for sure could understand them not wanting to send noise eating up valuable sat time/bandwidth, etc.
-
My provider responded with the following explanation:
The effect is due to the Transparent Performance Enhancing Proxy (TPEP). If the Transport Protocol (TP) component of TPEP were to be turned off for your service, the effect would disappear. However, the performance of your service would also take a dive.
