Pfsense refusing to block 3 ports
-
I am attempting to reject traffic coming in on the WAN interface on ports 135, 139, and 445. I have several other ports rejected successfully, as well as port ranges which work fine. I have no microsoft devices connected on the LAN side. I make a rule to block these ports, they do not work. If I block a range of ports ( 135-445), then all the ports in the range except 135, 139, and 445 are rejected. I test this via an external nmap scan,a reset should show a closed port ( which it does for the various other rules). I have attempted to delete the rule, clear the state table (there is nothing on these ports that I can see), etc. but pfsense refuses to reject these microsoft ports.
In addition, when I remove all rules relating to these ports and rely on the default deny ( drop packets), the firewall logs indicate that the traffic on these ports is passing through with unfettered access, i.e. no blocked log messages.
Where can I start to debug this issue and get to the root, and does anyone have any idea why pfsense would refuse to block these 3 microsoft ports and allow a complete firewall bypass? I am on the most recent version
-
pfsense blocks all unsolicited traffic into the WAN port by default. You do not need to create block rules there to stop that traffic. If traffic is passing you need to explain changes you have made.
-
I wanted to change these ports from drop to reject, and the only changes that have been made are rules to make certain ports reject instead of block.
-
@chpalmer I just factory reset the box, and immediately after I did a scan and viewed the firewall logs, every port except 135, 139 and 445 are blocked but even after a factory reset those ports are still allowed
-
Ok. You are checking these ports from outside your network right? If you check from your LAN then the LAN rules apply.
If you are seeing answers from a service such as GRC.com then your modem or ISP is probably the culprit. pfSense by default blocks ALL inbound unsolicited traffic.
You need to describe how you are testing and what your internet connection consists of.. DSL or Cable or ??
Modem type? Do you actually have a publicly accessible IP address on the WAN of your pfSense box?
-
Yes I am getting an IP from the WAN. It is cable & docsis 3.0 modem. I'm not getting any answers from GRC.com. Yes the scan is coming from outside of the network on a completely separate public IP address.
-
@chpalmer After the factory reset, I downloaded the raw image and did a complete reinstall, and the same symptoms are occuring. I'm now wondering if my ISP is blocking those ports to protect those who plug their Windows XP SP1 boxes into their modem... Hence why I am not seeing it being filtered. Its an ISP provided modem. Is there anyway I can check and see if I'm receiving these packets at all to verify that there is some sort of ISP/modem filtering?
-
@pfsense_user07 said in Pfsense refusing to block 3 ports:
135, 139, and 445
Yes many if not most ISP's automatically block those ports.
Yes you can enable logging on your block rules that you had put in place. But if you are not already seeing them in your block logs then your ISP is definitely blocking them.
Sometimes I will build a block rule and enable logging just to see how much traffic is hitting a certain port over time. Its quick and dirty but it works.
These are all on my WAN as inbound and allowed on my primary box here. But block rules show the same info. You can see the amount of data that hit a particular rule.
-
Yes, almost certainly this is your ISP blocking or maybe null routing that traffic.
Run a packet capture on the pfSense WAN while you're testing. Does traffic arrive on those ports.
Steve
-
As stated those are almost always blocked by ISP or even at the cable modem (docsis)...
As stated sniff on your wan while your sending traffic to that port - does it get there?
Also sending rejects on wan (that is connected to public internet) is almost always going to be a BAD idea!!!
example - I just checked 445 to my public on can you see me, and nothing seen at my wan via packet capture.