Thanks for the prompt reply Bill :) I mentioned the enc0 interface as you can do a packet capture and see unencrypted traffic from the VPN client via tcpdump. [2.4.3-RELEASE][admin@pfsense.xxxxxxxxxx.net]/root: tcpdump -i enc0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes 08:38:49.508431 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.62644 > pfsense.xxxxxxxxxx.net.domain: 62+ A? www.apple.com. (31) 08:38:49.508533 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.55246 > pfsense.xxxxxxxxxx.net.domain: 48200+ A? apple.com. (27) 08:38:49.508604 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61700 > pfsense.xxxxxxxxxx.net.domain: 60069+ A? gateway.icloud.com. (36) 08:38:49.508671 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.59659 > pfsense.xxxxxxxxxx.net.domain: 32698+ A? www.icloud.com. (32) 08:38:49.508730 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.55246: 48200 3/8/12 A 17.172.224.47, A 17.178.96.59, A 17.142.160.59 (460) 08:38:49.509125 (authentic,confidential): SPI 0x0db585ec: IP pfsense.xxxxxxxxxx.net.domain > 172.16.9.3.61700: 60069 9/4/0 CNAME gateway.fe.apple-dns.net., A 17.248.144.180, A 17.248.144.89, A 17.248.144.49, A 17.248.144.86, A 17.248.144.152, A 17.248.144.85, A 17.248.144.91, A 17.248.144.92 (336) 08:38:49.516628 (authentic,confidential): SPI 0xcb4900c7: IP 172.16.9.3.61275 > pfsense.xxxxxxxxxx.net.domain: 40342+ A? metrics.icloud.com. (36) 172.16.9.3  = my iPhone https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4&manpath=FreeBSD+7.1-RELEASE I just wonder if snort was to enumerate enc0 as a valid interface I'd be able to alert / block IP addresses handed out to my IKEv2 clients.

I may have stumbled across a root cause. I enabled the Snort VRT rules, and as soon as I did CPU usage shot up through the roof and stayed there.  Disabling VRT and restarting Snort corrected it. I can't remember if the VRT rules are available in Suricata.  If they aren't, that may explain why I wasn't seeing the problem with Barnyard when using that instead of Snort. What's different about VRT? Is there something with that ruleset that could cause this? I'll keep an eye on things and let you guys know how things progress. And as always, thanks bmeeks for your contributions  :D

Good info Onyxfire!

@NRgia: Nice tutorial so to speak, maybe you could do a sticky post, in order for others to find it more easily in the future? Where to read more about rules tips & tricks ? "How to create Snort rules documentation", on their site is ok? There is some useful documentation on the Snort.org site.  However, to be honest, I've never found a great all-in-one location for this kind of information.  Bits and pieces are scattered all over.  As with lots of software, especially open-source and other "free" software, the developers spend more time on coding and adding features than creating documentation.  I am guilty of that as well with the Snort and Suricata packages. Bill

@mdes: First question, is Suricata in pfSense (inline mode) able to drop (or instruct PF to do it) a connection instead of blocking an IP? Second question, is Suricata in pfSense (inline mode) able to block destination (WAN) IP:port while it listens on LAN interface? Go read this post to answer question #1:  https://forum.pfsense.org/index.php?topic=135331.0. The answer to question #2 is "no, it can't do that".  Why would you want to do that anyway? Bill

@JohnSCarter: Hello all, Recently I've had some time on my hands and I've been thinking about pfSense and have some questions and was hoping that someone could elaborate as I'm not quite getting my head around them. Question 1: Is there any way to mass-drop rule actions in Suricata / snort just because I don't have time to 100% be active on my network to see the alert telling me that malware has infected my system and also because manually changing the "alert" rules to "drop" (even with a AHK script) takes more time than I have in a day. Question 2: With IDS/IPS systems (for someone who doesn't have time to sit and monitor their constantly active network 24/7) why aren't most rules set to automatically drop, for example if there was a rule for a packet that's a known malicious packet that compromises a system and that packet triggered a rule but the action was "alert" wouldn't that be pointless? like a fire alarm with a 6 hour delay, wouldn't the damage already be done? Question 3: Obviously putting all the firewalls, IPS/IDS and additional content filtering systems in place is good however none of it means anything if pfSense itself is compromised, I was just wondering (from somewhat of a "lamens" perspective) what is done to keep pfSense secure, how difficult it would be to compromise and if there's any way to check / know if your pfSense is compromised (perhaps a tool or checklist of sorts?) Thanks for your time, John. Question #1 Answer: You don't have to change each rule action to DROP in order to get a block if you simply do these two things: (1)  Use Legacy Mode blocking (on the INTERFACE SETTINGS tab) and then; (2)  Uncheck the option for "Block on drops only". If you do those two things, then every single rule that raises an alert will result in a block.  Just be prepared for some frustration, though, since with all the sloppiness in web programming these days you can expect some rules to trigger that are enforcing various standards.  When those standards are not ahered to, the rules trigger.  You can mitigate this somewhat by being more selective in the rules you enable. Question #2 Answer: Because most security admins want to be notified of issues, evaluate the alert to weed out false positives, and only then enable blocking.  This is to prevent the "frustration problem" alluded to in answer #1 above.  Put yourself in the shoes of a network security admin in a Fortune 500 corporation who just turns on an IPS with all the rules enabled and all the rules set to drop traffic.  Just imagine how many times his phone would ring from users whose computers stopped working because of all the blocked traffic.  Would it not be better to run with everything in alert, analyze the received alerts, weed out and either disable or suppress false positive rules, and only then enable blocking? Question #3 Answer: Firewalls are incredibly hard to compromise unless they are horribly administered.  All the stuff you see on TV shows where the "good guy" hacks into the firewall to save the day is just BS.  Doesn't happen.  But if your firewall is compromised, then all bets are off.  If you are really paranoid, you could put Suricata inline between your firewall and your first LAN switch and run it on a separate physical box.  You would also need a NIC that fully supports Netmap and Inline IPS mode. Bill

The best place to run an IDS/IPS such as Snort or Suricata for home networks is on the LAN interface.  That way host IP addresses in alerts will be shown with their native addresses.  When you run the IDS on the WAN, all alerts will have the WAN IP as the "local host" address since the IDS sees traffic outbound on the WAN only after NAT rules have been applied. There are number of posts in this sub-forum by me and others that talk about this.  So move your configuration over to the LAN interface and your problem will be solved.  Internal hosts will show up in the alerts with their own IP address. Bill

@teamits: Never mind, I found the release notes at https://forum.pfsense.org/index.php?topic=145489.0 and even better https://forum.pfsense.org/index.php?topic=145257.msg790339 that discuss pass lists. You can use custom PASS rules to create a pass list, but just be careful as I warned in the posts you linked.  It is probably better to watch and either disable the bothersome rules, or use suppress lists and either of the "filter by IP" options that are available when you click the plus sign (+) beside the IP address columns on the ALERTS tab.  Doing it that way allows a rule-by-rule tuning and even limiting that to certain hosts (IP addresses).  Using a pass list is more like using a large hammer when what you really need is a jeweler's screwdriver.  With a PASS rule that filters only on an address, you are potentially exposing the whitelisted host to a lot of malicious stuff. Bill

Thank you for this. In this article (https://forum.pfsense.org/index.php?topic=50141.0), the problem is explained. I increased the value of System/Advanced/Firewall & NAT/Firewall Maximum Table Entries to 400000.The default value was 200000. The description for this field is: Maximum number of table entries for systems such as aliases, sshlockout, snort, etc, combined. Since it mentions snort, I assume using suricata also impacts the number of table entries. It is however a system setting, so Bill's remark is correct. The error didn't appear anymore after the value was increased.

@alchemyx: Hi, How to change max_client_bytes in SSH preprocessor? If I put that in Advanced Configuration Pass-Through preprocessor ssh:         max_client_bytes 19600 Then SNORT won't start up. Probably because I have duplicated preprocessor ssh: with the one provided by pfsense. I tried disabling SSH altogether and putting it again but snort also refuses to come back up. pfsense version is 2.4.2-RELEASE-p1 and SNORT is 2.9.9.0 Thanks! Michał At the moment that is not a configurable parameter within the GUI.  And using the Advanced Passthrough feature doesn't work with preprocessors because of how the internal GUI code works for now. I will add this parameter to the next Snort GUI update.  I'm working on some other Snort updates and hope to get an updated package posted in a couple of weeks or so. Bill

Thanks, Bill.  Probably just pushing down ads.

Thanks. Worked great.

No worries, thanks

@zombietek: Hi, I have upgraded to 2.4.2-RELEASE-p1 and it is nice to have the addition of "Click to force a different action for this rule" option under Alerts on Suricata. Only comment I have so far, I hope they would add in the future that when a GID:SID is set to a specific action on an interface like WAN, there is an option at least that prompts or check boxes whether or not you want to apply it as well to other interfaces on your pfSense box. My question is, where could I check in pfSense the GID:SID that I have been setting to DROP through the option above? I used to manually copying GID:SID and pasting it to a dropsid configuration file under SID Mgmt and I don't see anything new that I have been setting lately to DROP. Thanks. When you "force" different rule actions on the ALERTS or RULES tabs, those changes are saved in a special section of the firewall configuration file, config.xml.  They are not written to any of the SID MGMT configurations.  Go check out this sticky post at the top of the forum:  https://forum.pfsense.org/index.php?topic=145467.0.  User overrides are the last actions processed as the rules are built for an interface.  If you want to see what rules you have user overrides for, go to the RULES tab and view using one of the new categories listed in the drop-down there.  There are categories for each class of applicable user overrides. The software version you quoted as upgrading to is for pfSense itself.  That is not the version of Suricata.  Suricata's version is currently 4.0.4. Bill

@Actionhenk: Hi, On my pfsense box (hyperv vm) I have installed suricata on the lan interface. Suricata is dropping traffic like it should however I also have a guest network which im running on a vlan. When I assign the guest vlan to my lan interface suricata stops blocking/working. Im guessing it is because pfsense now has 2 interfaces assigned as 1 and suricata cant seperate them correctly, or only sniffs 1 of the 2 interfaces. I read about someone who also noticed suricata stopped working properly and he set the mtu of the suricata/lan interface from 1500 to 1502 and this solved it for him. I dont know what im doing with mtu sizes so I would like to know how this could negatively impact traffic flow? Will this cause congestion? Dropped packets ? Anyone else who noticed ? How did you resolve it ? Thanks! Make sure you have the latest version of the Suricata package.  If you are using Legacy Mode blocking, then you can increase the new snaplen parameter on the INTERFACE SETTINGS tab for the Suricata interface.  It defaults to 1518, but sometimes VLAN tagging operations need a larger snap length from the pcap library in order to process VLANs. Unfortunately, if you are using Inline IPS Mode, then a limitation within the Suricata binary makes using a non-default snaplen value impossible and you are stuck with the 1516 value.  This is sometimes not large enough for VLANs.  Additionally, Inline IPS Mode uses the netmap API and there may be some capatibility issues with netmap and VLANs in FreeBSD.  I know the traffic shaper does not support netmap at the moment. Bill

@NRgia: Although freshports is still pointing to 4.0.3 version, you made this possible. Thank you for keeping the Suricata package updated With a little help from Renato on the pfSense team, too.  Thanks! Bill

@Raffi.: Thanks Bill. Do the same installation instructions apply to the 4.0.4 update released today? I guess a better question would be, do those instructions only apply to 4.0.3_2 or is it generally advisable to do a complete uninstall/reinstall? I can do so anyway for good measures since it doesn't take much time, but I'm just curious about best practices and understanding why. Raffi No, the update released today was for the binary only.  The pfSense team went ahead and pulled in the 4.0.4 binary update. I'm working a small update for the GUI, but it's not ready yet.  Will be adding the capability to use custom URLs for rule archive downloads and the ability to use a rejectsid.conf configuration when using Inline IPS mode. That being said, it's not a bad idea to generally follow the "remove and then re-install" process.  By having "save settings" checked, you don't lose any configuration info.  I do make it point, though, of pointing out in the release notes when "remove and re-install" is necessary.  So if you don't see it specifically called out in the release notes, then you can consider it optional. Bill

@Noisette: Thank you for your reply. I thought there was a ready-made list. Apparently all 119 and 120 are false positives. If you search for the threads I referenced and then browse through them, you fill find a number of posts similar to @NogBadTheBad's post containing code you can copy and paste into your own list.  There is no place to just go download a ready-made file.  That's because suppressing alerts and tuning an IDS/IPS is network-specific.  Some users need rules that others do not depending on the types of "normal" traffic on their network. I keep repeating this mantra for the benefit of new IDS/IPS users – "using an IDS/IPS such as Snort or Suricata is not like installing an anti-virus client.  You can't just install, enable all the rules and live happily ever after.  If you do that, you will in fact live in constant frustration dealing with nuisance blocks.  Spend some time reading the posts on this forum and browsing the "school of Google" to learn about tuning an IDS/IPS. Bill

Thank you for your reply. My problem has been solved by updating snort rules. The scan appears in the LAN interface.