How to close Port 23, 53 and 80 on WAN?
-
I put a block any any any rule on WAN, but it didn't help.
Port 22, 53, 80, 465, 853, 9929, 31337 are maybe open (Zenmap)
23 and 80 are open for sure (Public test)
-
Show your firewall rules on WAN and Floating if any. The listening sockets do not matter.
-
I dont know if its important, but the ports are only open when using OpenVPN.
The other rules are default except the block any rule on WAN. -
On WAN and Floating (if any). Not LAN.
Firewall rules are processed on the interface the connection is established INTO.
-
Floating and the others are empty.
Pfsense is behind a router, if that has anything to do with it.
-
There is zero reason for that rule you put on there.. Unless you don't want traffic hitting your wan logged.
out of the box all unsolicated traffic is blocked inbound to wan.
If your doing a port scan from outside then its what is in front of pfsense..
-
Nope. Nothing will pass into WAN with that rule set.
The third rule is unnecessary as the default deny rule will block that traffic.
-
If I use an online port scanner like this http://www.t1shopper.com/tools/port-scan/
While using OpenVPN it always shows me Port 23 and 80 are open.That's a big security hole, so how can I close these ports?
OpenVPN works fine, but I can not use it like that ...
-
Something in front of your pfSense firewall is likely responding on those. It's not the pfSense WAN or anything running on pfSense that is doing it.
If there is a "big security hole" look upstream.
If you are running port scanners while connected to OpenVPN, the controlling rules will be on the OpenVPN tab and/or and assigned interface tab, which is your WAN in that scenario. In that case "upstream" would be your OpenVPN provider. You certainly trust them to do the right thing, I assume.
-
I don't even think you could enable telnet (23) on pfsense if you wanted too - without installing some 3rd party package? your output shows its not even listening on 23.. So how could it be pfsense answering?
Its a well know fact that many an isp device answers to some of these ports..
You want a for sure test... Go to can you see me . org.. Do a test for 23.. Sniff on pfsense.. Do you see it hit? Do you see an answer?
Here..
Can you see me shows not open... But I see the traffic hit pfsense wan - but NO response.. So it is closed/dropped/not answered.. So no its not open. If something was answering from pfsense, or from behind pfsense you would see it with this test an answer.
-
Traffic does not (?) hit the pfSense, but that probably would not make sense ... what is the issue here?
Same with port 23. -
You have something in front of pfsense that is sending back syn,ack.. What is in front of pfsense? ISP modem/router/gateway?
What is that 81.x IP? Its not any IPs that you have talked to the forum from.. You routing traffic through a vpn - and testing to your VPN IP?
-
@johnpoz In front of pfSense is a Router.
Yes, 81.x is VPN IP, all tests were done on this IPI have tested the router in front of pfSense for open ports, no open Ports found.
The only thing I did on that router before pfSense was port forwarding for udp 1149 to pfSense, in case that matters. -
So your testing to some public IP from a vpn connection.. How would you think that is forwarded down the tunnel to you? Does your vpn support port forwarding? Did you set up those ports to be forwarded down the tunnel to pfsense?
There are not many vpn services that even support port forwarding, and even the ones that do require you to set them up, and more than likely for sure would not support ports like 80 and 23..
-
If you packet capture while you are testing and the SYN packets do not arrive on the pfSense interface, it is not the pfSense firewall that is responding there. Again, look upstream for your "big security hole."
-
My VPN provider supports it, but I have not changed any settings on my VPN account, it is turned off by default.
PfSense is also mostly on default settings, only OpenVPN has been set up ...
-
Again, pcap on your OpenVPN. If the SYNs don't arrive, something upstream is responding there.
-
Any chance, that's the cause?
I'm at a loss -
DUDE what part do you not get here... If your testing to your VPN public IP... Its not Pfsense answering, or anything behind pfsense... Its your VPN service!!! No your outbound nat has ZERO to do with it!!
-
I've done tests with all the filters turned off by the VPN provider, that's the result.
It looks to me that the ping has gone through the pfSense.
.
