@trumee, please report this on the Redmine bug reporting site at https://redmine.pfsense.org/. This is a warning message from the new PHP 7 interpreter. It is harmless for now, but if you report it on the Redmine site it will get logged and corrected. Thanks, Bill

@rogg said in snort blocking dns servers: its other trouble - snort blocking dns ip address which is whitelisted in snort configuration. When Snort blocks on a triggered alert, it can block either the Source IP, Destination IP or Both depending on a setting on the Interface Configuration tab. As @NogBadTheBad stated, check the Alerts tab to see which rule or rules are being triggered and blocking. You can filter on the tab by IP address to help in locating rules with your DNS server IP in either the SRC or DST columns.

Thank you Nog, that's done the trick.

Greetings. Thank you . i have enabled the LAN and it does start making sense. Thank you very much for all your advice. Still much to learn :)

Ah, thanks for that. We'll look into it here then. Steve

Yes, thank you for the best practice on what SID to use for custom rules, This was the information that was missing from the resources available online ( Although i did not look thoroughly so i might have just missed it ). In any case this is resolved. Thank you.

You really, really, really need to use a VPN for RDP. That is the most secure. You can easily configure OpenVPN on pfSense. That also eliminates the need for NAT port-forwarding.

The current Snort package on pfSense is based on the Snort 2.9.11 binary, so it is single-threaded.

I had every rule set checked just for testing purposes. But now i will check out if changing IPS policy will do a big improvement in my network. Thank you so much for your help, cheers!

@derpy456789 said in Potential Suricata Inline Netmap Solution: Hello NollipfSense, Just wondering what kind of system/specs are you running suricata inline on and also did you change any setting inside the interface setting of suricata like the Detection engine settings for max pending packets ? Ive been getting the same error netmap_grab_packets bad pkt Thanks Sorry for the late reply...I am running an HP Pavillion a6242n with Intel 82575 NIC 8GB RAM.

I suspect there's something wrong with inline mode as we've had cases where traffic doesn't flow but no alert is logged. See https://forum.netgate.com/topic/131572/moved-suricata-from-wan-to-lan-can-t-remote-desktop-in/10 https://forum.netgate.com/topic/109581/suricata-inline-whitelisting/8

I think I may have found the problem by uninstalling snort and trying suricata: After installing suricata, same problem happens. Then I tried an older version of the snort rules: snortrules-snapshot-29110.tar.gz works snortrules-snapshot-29111.tar.gz causes firewall to crash! So, something is definitely wrong with the pfSense code... a content update should not crash the firewall!

This is a wild guess but does your router have a file named /usr/local/etc/suricata?

@cukal Using Suricata wasn't all that scientific...we had to start somewhere, Suricata is multi-threaded and Snort isn't, and there were packages for both so we tried one. As I vaguely recall Suricata was developed by OISF as something of a next gen Snort, and it's compatible with Snort rules. Search "snort vs suricata" and you will find a bunch on it.

@vacquah said in Best way to block some gaming sites: Fortnite Your best bet would be to sniff to see exactly what is being used for this game, the fqdn that are being queried for, and or ports used, etc. More than likely this is hosted on some CDN somewhere.. My guess would be AWS. Then sure a simple host override on pfsense dns to send this fqdn to nowhere, ie loopback or 0.0.0.0 or even sure somewhere that presents a info page on 80/443 to not use company bandwidth, etc. Only problem with dns blocking - is you have to make sure your clients can not use some other sort of dns to resolve it. So you have to force all clients to use pfsense via dns redirection, and or only allow dns to pfsense and block all others. There is always away around.. You could tunnel out on 443 for example, you could use dnscrypt via some open port, etc. But a dns block and or simple blocks of the ports it uses if they are specific and not standard ports like http/https can stop the vast majority of typical users. Problem is once user figures out how to bypass your restrictions it spreads fast!!! Content filtering and or blocking is normally always an uphill battle that is hard to win.. If users want out, they normally can find a way. This day an age though users just going to play the game on their phones via their cell connection. But atleast then they are not using company resources and bandwidth ;) Good Luck!!!