Perfect, thank you If you need any logs or anything from me, let me know Right now i have OPT1 and OPT2 as inline and LAN and Legacy Mode and it seems fine. Its likely to affect a fairly limited number of people right now so no rush on my side for this and i'm happy to trial anything you need Regards, Jamie

@jake said in Snort Package - Potential New Feature Teaser: They are all Intel I210-AT NICs. Would the PPPoE still be an issue if I'm running Inline mode only on the LAN side? I also had it Inline Mode on my VLAN interfaces, could that be an issue? Thanks for all your help. I'm happy to do any testing if needed. No, so long as the interface is not using PPPoE, the Intel i210-AT chip should be using the igb or perhaps the em driver. First you need to verify that by looking under STATUS > INTERFACES in the pfSense menu and finding your LAN interface. The type of driver will be shown in parentheses in the header band for each interface. If your LAN is not showing one of the compatible netmap driver families I posted earlier, then inline mode likely won't work for you. If you have one of the listed NIC driver families, then try altering the settings mentioned in this post: https://forum.netgate.com/topic/138613/configuring-pfsense-netmap-for-suricata-inline-ips-mode-on-em-igb-interfaces.

Ok, thanks for the reply. I asked it because now it rebuilds 4 interfaces every time... (before it was eight)

@bmeeks @Gertjan Thanks for the feedback. I deleted the log files (with Suricata disabled) and then restarted Suricata. The PHP errors have disappeared.

I usually suggest deleting the package and re-installing it, especially for major updates. This update is minor and changes only one PHP file, so you can just do a re-install on the PACKAGE MANAGER tab. If a delete and then install is recommended, I will always put a warning in the package release notes. Suricata will retain your settings even when you delete package unless you specifically uncheck the Save Settings on De-Install checkbox on the GLOBAL SETTINGS tab. That setting is enabled by default, so you don't lose any settings when you remove the package. So for this update, go to the PACKAGE MANAGER tab and click the re-install icon.

@kiokoman said in Suricata php errors: yeah i saw it wasn't fatal, and when i went to check that line i was pretty sure it was only a minor glich, I just thought it was right to advise, anyway thanks for the info Yes, thank you very much for the bug report. It was an easy fix on my end, but this is the weekend and I'm not sure the pfSense guy that handles FreeBSD ports is working. It may be Monday before my fix gets merged and appears as an updated package on the Installed Packages tab of PACKAGE MANAGER.

Thanks, that did get it working. Not sure what the install issue was but glad it's good now!

@Grunt0307 said in Suricata Log Interpretation: Makes sense, let me ask you this then. I intend to have a DMZ network setup on another interface. If I configured Suricata to inspect my LAN and DMZ interfaces, that will increase the load on the system, correct? I'm assuming it would launch an instance of Suricata for each monitored interface resulting in duplicate data being loaded for each interface. That is correct. Each monitored Suricata interface will be a separate instance, and so resource utilization will increase when monitoring multiple interfaces. You can manage this by limiting the rules applied to each interface to only those needed to protect the assets behind that interface. Refer to my earlier example about mail servers, public-facing DNS servers and so forth. But in the end there is no free lunch. Using a tool like an IPS with rules takes CPU resources. Fortune 500 corporations do this by throwing a lot of really big iron at the problem (servers with lots of RAM and multiple Xeon server CPUs). My first reply about not putting the IPS on the WAN was based on the assumption you had only a WAN and LAN. That's the most common configuration for pfSense users. Some may have a number of VLANs running on say the LAN interface. In that case you can have Suricata run in promiscuous mode to see all the traffic on the interface to help with resource conservation. Promiscuous mode doesn't help with separate physical interfaces, though. I would think that with configuring the NIC's sysctrl settings like those I linked to several replies back, and choosing wisely which rules to enable, that you can achieve very close to linespeed on the SG-5100. Making sure flow control is disabled on the NIC is said to make a big difference.

Make sure you acutally have not enabled any blocking yet. Go to the INTERFACES SETTINGS tab for your WAN and verify the Block Offenders checkbox is unchecked. Save that change and then start or restart Suricata on that interface. See if it starts successfully. Look in the suricata.log file to see if any errors are printed. That file can be found on the LOGS VIEW tab. Select the WAN interface in the Interface drop-down and then choose the suricata.log entry in the Log drop-down. Post back the content of thesuricata.log and also look in the pfSense system log to see what errors may be logged there.

I would not have the GUI make that change everywhere. Only on interfaces with Suricata that are configured for inline IPS mode. I'm pretty sure netmap wants that off, but I will do more research to be sure. This whole business with netmap only comes into play when you choose Inline IPS Mode in Suricata. As for the load error message, that message actually means the netmap TX rings are filled with packets and there is no more room for the incoming packet. It might be due to the fact that hardware NICs have multiple sets of TX and RX rings for handling traffic, but the host OS stack end of the pipe has only a single software ring. So that means it would be possible for the NIC to process more traffic off the wire than the software ring of the host OS stack can handle. I need to research this some more as well. I have been trusting the netmap plumbing within FreeBSD and Suricata to the developers on those sides, and my work was just adding support to the GUI package. As a side note, the pfSense team is currently doing testing in-house with the new Snort Inline IPS Mode I introduced last week. They are helping me sort out the possible throughput and identify any bottlenecks. because I don't have the hardware on hand to do that.

Thank you again for explaining

@cTar -- Good deal. Thanks for the feedback confirmation!

Two great surprises in one day! Thanks again for your work. Bill

@bmeeks It was a DNS issue. After I configured DNS Resolver properly it began to work again.

@OpenWifi said in Snort not blocking P2P IP addresses: @bmeeks Thank you. The screenshots i am attatching are of the current block tab and my network topology respectively. [image: 1558856469990-img_20190526_103409_108.jpg] The highlighted Ips confirm that i enabled OpenAppID feature. [image: 1558856571128-img_20190526_101207_560.jpg] This is the Network topology. Kindly consider the reason as to why i didnot disable DHCP on the ISP router is because the router lacks bridging capabilities and so i decided to port forward some few ports i.e 53(DNS) and 1194(OpenVpn). What is the WAN IP address on your pfSense box? And what is the default route given to the clients hanging off that switch. For that setup to work, you would need your pfSense box to have a WAN address in the 192.168.1.0/24 network and then the LAN be the 192.168.7.0/24 network. Finally, the DHCP settings in the ISP router where you have the DHCP server enabled should handing out your pfSense box's LAN address as the default route to be used by the clients. Does the ISP route have wireless capability? If so, it should be disabled; otherwise it could provide a bypass of the pfSense firewall. I can tell you from the screenshot you posted that the pfSense box and Snort are working correctly. With those IP addresses listed on the BLOCK tab, they will and are being blocked for anything trying to go through your pfSense box. Now, if clients have another way to access the ISP router that bypasses pfSense, then obviously pfSense can't block them. And because pfSense with Snort runs the interfaces in promiscuous mode, Snort will see all traffic on the segment even if that traffic is not targeted to the MAC of your LAN interface. As a final test, try to ping those IP addresses of the Torrent servers listed on the BLOCKS tab. They should fail to respond to a ping request if they are blocked. If they respond to a ping, them I'm almost 100% certain your problem is going to be the clients have another path to the Internet that bypasses the pfSense box.