Pfsense open ports [SOLVED]
-
As I posted in my other thread, I have reset everything to factory defaults and reconfigured it again. I noticed that when I originally installed everything I never saw the startup wizard, so I have a feeling its related to that. I also experienced unusually high CPU usage while nothing was going on and my other unusual problems are gone. I will scan it tomorrow with nmap and see if the problems are fixed.
-
You have/had port 443 open to the public/world by not specifying a source address. Also torrents only require TCP, they do not use UDP packets.
As for the upnp, you might want to do a port scan and then watch what ports open up. Or try disabling it, and then do a scan.
As for port 53, would anyone know if the "upnp port mapping (for windows)" would be letting windows services open up ports?
Maybe pfsense is opening port 80 on behalf of itself? Unless you have a web server back there trying to get out?
Also I assume your torrent port is 40122? Sort of the only one open that looks out of place.
Just saw your system.txt, in there I saw
Mar 2 19:19:30 miniupnpd[12590]: HTTP listening on port 2189
Mar 2 19:19:30 miniupnpd[12590]: HTTP listening on port 2189Is upnp intended to open ports even if it is a service on pfsense that wants them open?
 -
After the factory defaults, I am still getting the ports open. The previous port 443 was done by the OpenVPN wizard because I designated that as the port for it. Right now I have OpenVPN at the default port (1194) and upnp enabled, but only for the LAN. The only port forwarding and Rules I have done are for Torrents and what the automated wizards has done.
PORT STATE SERVICE
53/tcp open domain
80/tcp open http
443/tcp open https
1194/tcp open unknown
2189/tcp open unknown
40122/tcp open unknownWhy would the Upnp even be there if I selected it to only be there for the LAN section.. seems like PFSense services are before the Firewall
-
That is strange, and you're still able to access the web portal from work? If you tried now to log in does it give you that redirect error you were getting before?
-
Yep, same error and for some reason I can not get an IP from OpenVPN, but that might be a problem on my end. I will look into that tonight, but then again, I will probably go back to 1.2.3 if these ports keep showing up… I could probably try to manually block them using the firewall.
-
How is your network wired up?
Is that public IP directly on WAN, or do you have something else in front doing NAT?
Can you post the contents of /tmp/rules.debug - it might help show what the issue really is.
-
I never re-enabled ssh, but I will head home for lunch and set it up. By the way, I have never done anything related to port 53, so I know that should not be showing. At work, if I do:
host -T internalserver.local MyWAN-IP
I get my internal IP address for the internal server, so that is definitely not being blocked in any way (-T is for TCP connection)
-
here is that file
-
pass in quick on $WAN reply-to ( re0 x.x.x.x ) proto TCP from any to x.x.x.x keep state label "USER_RULE: OpenVPN Home wizard"There is no port on that rule for OpenVPN - so it's letting all TCP traffic in to your WAN IP.
Did you alter that rule?
-
Nope I did not, both times I just let the wizard create the rule (USER_RULE: OpenVPN Home wizard) and did not alter it. I will check on it when I get home
-
the screenshot I put of my rules page clearly has port 443 on it before hand. That would be the port you were talking about in the previous line? why would the port be listed there but not in the rules.debug?
-
ok, edit and save your OpenVPN rule, see if that fixes it. Make sure to re-select UDP as the protocol if it's supposed to be UDP and not TCP.
I fixed a bug with the wizard earlier today that was apparently causing this to happen, too.
The protocol (TCP or UDP) was getting into the rule as upper case, not lower case, and the port was being left off because it didn't match "tcp" or "udp".
Anyone on a new snap should be OK though. At least the next new one.
-
Just attached part of the config.xml If I change the 3rd one to match the other two and then restart my box, would that fix the problem? /cf/conf/config.xml
-
I am using TCP and I just upgraded to the newer snapshot a little while ago hoping it would fix the problem, but guess we nailed it down to that rule.
-
Just edit and save the rule - no need to alter config.xml
The problem is this:
<protocol>TCP</protocol>Needs to be:
<protocol>tcp</protocol> -
:( cant get into the web interface now. Guessing thats a good thing since its open to the world, lol
-
hmmm ok, so where can I edit and save the rule.. is the rule.debug file going to be persistent?
-
Edit the OpenVPN rule on Firewall > Rules on the WAN tab - edit that, save, and it should fix itself.
Or update once the next snapshot uploads, I committed a couple different protections against this.
-
Worked like a charm.. I got someone to run nmap on the IP and the firewall is back up. Thanks for your help! Did you guys find a bug in the Wizard?
-
Yeah, it was a problem in the wizard:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/6be90004d477bd74c5610ae341aae3ae9fcc9281
But I added some extra protection so that on future snapshots even people who have the 'bad' rules won't be harmed by it:
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/06b3df52262764723289a3ac65c3a7c05a8a8f4c
https://rcs.pfsense.org/projects/pfsense/repos/mainline/commits/7ec0e6e2f5206d750a6c00d598700836a57d056f
