Hi Skart, Can you explain how you fixed it. It can be helpful for the other members on the board.  …Actually im pretty interested at your version of the solution ;-) -m4rcu5

Hi rwhawkes, What i use to block the crap out is the rate limiter on the rules. Why on earth would someone make 100 conns/s if he is just browsing on port 80? That usually blocks the big offenders. If you have something like slowloris going on then snort might be of help. Snort also does a nice job blocking any known malicious networks. Hope this helps a bit in blocking your attacks. -m4rcu5

Not at this time, not easily anyhow. If it's in a rule or alias, you could hand edit the config (using viconfig) and then run /etc/rc.filter_configure If it's in a table that is dynamic, like snort or the ssh lockout, you can clear it on the command line with pfctl like so: pfctl -t sshlockout -T flush That would clear all entries in the sshlockout table

all you can do is enable or disable it.  search for: debug.pfftpproxy Roy…

Hardware update clients are notorious for being problematic - it all depends on how much effort the manufacturer put into making them work correctly and how they find out the WAN IP. One solution I've found to work reliably is to replace the firmware with the likes of DD-WRT, which has a well behaved update client built into it. Obviously that only works if your router is supported by DD-WRT.

@driek: Could you tell me what your firewall rule looks like? My logs contain a lot of these and I think I need to let them pass for my IPTV to work, but I can't figure it out.. If you're seeing them in your logs, then they're not being passed, so if your IPTV is working, it doesn't need them. They're usually just "chatter" you get being on a cable modem. It's a fairly straightforward rule to block them, without logging. Cheers.

My microcell works perfectly under 2.0 and has worked perfectly under 1.2.3. I did not have to forward any ports at all.

Syslog is the only way to do it out of the box. I'm not sure if anyone has a package out there that does what you're after. You could write your own daemon that attached to the pflog device and reads the data (or pipe it through tcpdump, check out how the current log is taken with tcpdump.) and then work that into your database however you like.

http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

Thanks for the response.  That makes perfect sense now.

It could be in the order of the rules. The top rule gets processes first, so if you have a block rule above your pass rule, that could be the problem.

For some reason I couldn't get 1:1 NAT to work properly. Kept messing up some other things… However, the second suggestion worked flawlessly. Thanks a lot guys, problem solved!

There is a package for proxying IM connections, or you could use the likes of Squid (with Squidguard) and only allow the destinations you want.

Don't forget that your firewall (pfSense box) is the weak link here - there's nothing stopping somebody simply DDoSing it if you just protect your DNS server.