Firewall blocking not working
-
I have set my router to sleep after an idle of 3 mins and wake on pattern match,
the above allow a transparent on and off for convenience as well power saving.However, as you may know, there are many annoying crawler on the web.
For ftp, I forward the request from WAN side to my server in LAN by NAT.
On observing, I spot an IP frequently disturb my server, that way I tried to block it by setting up a rule.
However, it never worked, the IP can still sexually harass my server as he likes.
Any idea? Or my setting is wrong? :-\Update : On more search, I find that the order of the firewall rules may matter.
Previously the blocking rule was at the end of the Firewall Rule Listing.
Just now I move all allowing rule to the end of the rule list, see if this would help. -
I find that the order of the firewall rules may matter
Not may… Does! I generally put the bad ones on top of the entire list... They dont get to do nuttin!
-
Can you post a screenshot of your WAN rules please.
-
@Cry:
Can you post a screenshot of your WAN rules please.
Thanks for the help:
Just changed by moving those allowing rules to the end as mentioned in the update.
-
Sorry for an addition question that just fell into my concern:
What exactly is causing the request from 192.168.11.100?
My DHCP server has only an allowed range : Available range 192.168.1.1 - 192.168.1.254,
there shouldn't be a 192.168.11.100 on LAN, and unlikely it is on WAN.It is blocked yet kidnapped my Firewall Blocking Logs and I can hardly take the logs as an effective reference for problem solving.
Would you share your ideas on it?
Thanks for the attention. -
You have a device with that IP (192.168.11.100) on your LAN. Check your ARP logs to see what the MAC is, that coupled with the OUI tables, may tell you what the device is. As a hint, a quick Google search tells me that port 1900/UDP is for SSDP.
-
@Cry:
You have a device with that IP (192.168.11.100) on your LAN. Check your ARP logs to see what the MAC is, that coupled with the OUI tables, may tell you what the device is. As a hint, a quick Google search tells me that port 1900/UDP is for SSDP.
Thanks for the idea, I will study it later, now I just untick the box "Log packets blocked by the default rule" and it seems the problem no longer appears….may take this as a temp. solution for me to first focus on tackling the crawlers.
-
I have a customer that used a Linksys router as an access point. It overran the logs with those same requests until we put a firewall rule in place. But since it would still pass traffic having the wrong subnet on it my bet is yours is also an AP or other router used as an AP…
-
I have a customer that used a Linksys router as an access point. It overran the logs with those same requests until we put a firewall rule in place. But since it would still pass traffic having the wrong subnet on it my bet is yours is also an AP or other router used as an AP…
Thanks for reminding and it's exactly caused by the Buffalo router acting as a wireless switch.
Unplugging it solved the problem, will see how to make it work without this issue. -
For the original issue, thanks for your help and information on forum,
solved awesomely by re-ordering the rule list, putting the blocking rules at the top.I would suggest pf put all new block rules on top of any allowing rules by default so that ignorance like me will no longer appear :D
