Pfsense open ports [SOLVED]
-
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
