I saw where the Netgate kernel developer updated the Suricata package in the pfSense 25.07 development branch to work with the new kernel PPPoE driver. But so far as I know that updated package has not been migrated to 2.8 CE. Here is the commit into the DEVEL branch: https://github.com/pfsense/FreeBSD-ports/commit/68a06b3a33c690042b61fb4ccfe96f3138e83b72.

@SteveITS It looks like it is detecting ipv6 better already is showing alerts [image: 1752342154032-screenshot-2025-07-12-at-10.39.56-resized.png] It sees some ipv6 going to my interface. Again snort also would spot stuff every once a a while. My son got a bad bug on his tablet and it had a Russian email server running I checked it on virus total and it was spot on as malware known abuses so I reported it

@1-21Gigawatts Should be similar to Suricata, at the bottom of the Suricata > (interface) settings page. By default it has/creates a name though, so that seems odd. If nothing else you can edit the list and make it blank.

@certifiable Thanks for gathering and sharing all this detail—super helpful. Yeah, I’m inclined to agree about the 8111. It probably is supported via the re(4) driver, and like you said, the “E” just denotes PCIe. Unless there were big changes to the Realtek driver between 2011 and 2015, it should still work with Netmap. Of course, without a definitive confirmation, there’s always some uncertainty, but it seems like a solid bet. On the Intel side, it’s interesting (and a bit frustrating) that inline Suricata doesn’t work even though the i211 is listed as supported in both the FreeBSD hardware notes and the Netmap man page. I did check the ifconfig output—my i211 shows up as igb0, not igp. From what I understand, igb is the correct driver family for the i210/i211 series. igp might be a typo or confusion with something else (maybe the older PRO/1000 series?). I’ve been using the i211 exclusively for testing because I’ve read in several threads (and you confirmed) that the i219LM can be more problematic, especially with netmap/pf_ring compatibility. If you haven’t already, I’d definitely try binding Suricata only to the i211 to rule out issues from the onboard i219. Also appreciate the fallback suggestion on the dual-port 1000e NIC—good to know there are reliable options if the built-ins keep acting up. And yeah, if it comes to that, maybe a direct appeal to Luigi Rizzo himself will be in order. Thanks again—like you said, this stuff can start feeling like work real fast, but having all these specifics in one place makes troubleshooting a lot easier. I’ll keep digging, and if I get it working, I’ll post back with the exact configuration.

Looks like Suricata's binary part will have the same issue as Snort. It is missing a match for the LINKTYPE_PPP_ETHER link type as well -- The relevant code is within src/decode.h starting at line 1122, static inline void DecodeLinkLayer(ThreadVars *tv, DecodeThreadVars *dtv, const int datalink, Packet *p, const uint8_t *data, const uint32_t len) { /* call the decoder */ switch (datalink) { case LINKTYPE_ETHERNET: DecodeEthernet(tv, dtv, p, data, len); break; case LINKTYPE_LINUX_SLL: DecodeSll(tv, dtv, p, data, len); break; case LINKTYPE_PPP: DecodePPP(tv, dtv, p, data, len); break; case LINKTYPE_RAW: case LINKTYPE_GRE_OVER_IP: DecodeRaw(tv, dtv, p, data, len); break; case LINKTYPE_NULL: DecodeNull(tv, dtv, p, data, len); break; case LINKTYPE_CISCO_HDLC: DecodeCHDLC(tv, dtv, p, data, len); break; default: SCLogError("datalink type " "%" PRId32 " not yet supported", datalink); break; } } An edit like the one below will probably work (again, as with Snort, if the raw PPP data is the same in the two link types) -- static inline void DecodeLinkLayer(ThreadVars *tv, DecodeThreadVars *dtv, const int datalink, Packet *p, const uint8_t *data, const uint32_t len) { /* call the decoder */ switch (datalink) { case LINKTYPE_ETHERNET: DecodeEthernet(tv, dtv, p, data, len); break; case LINKTYPE_LINUX_SLL: DecodeSll(tv, dtv, p, data, len); break; case LINKTYPE_PPP: case LINKTYPE_PPP_ETHER: DecodePPP(tv, dtv, p, data, len); break; case LINKTYPE_RAW: case LINKTYPE_GRE_OVER_IP: DecodeRaw(tv, dtv, p, data, len); break; case LINKTYPE_NULL: DecodeNull(tv, dtv, p, data, len); break; case LINKTYPE_CISCO_HDLC: DecodeCHDLC(tv, dtv, p, data, len); break; default: SCLogError("datalink type " "%" PRId32 " not yet supported", datalink); break; } }

@bmeeks your code is epic !!

I do not personally use either, although I did once, several years ago, toy with an ELK setup. It was installed on a separate VM in my case.

@bmeeks That would explain it. Thank you.

@Dr-Monarch said in Suricata IDP/IDS on PFsense blocking all traffic: What ideally i am aiming for is all traffic is dropped until particular rule is analyzed and cleared so it can be allowed. That's not how Suricata works -- unless I am still not understanding what you want to do. You whitelist hosts (by IP address) not SIDs (rules). There is no construct I am aware of that mimics a "whitelist" SID (Signature ID). You can certainly enable or disable particular rules (SIDs), but that will apply to all hosts. With Legacy Mode Blocking, all rules do block when triggered. The only exception is IP addresses in the Pass List which are not blocked. These are by default local LAN hosts, gateways, DNS servers, and the WAN interface's single public IP address. Inline IPS Mode requires that you manually change rule actions to DROP for all rules which you wish to block traffic when triggered. You can do this via SID MGMT or manually using the provided icons on the ALERTS or RULES tabs. There is no concept of a Pass List with Inline IPS Mode because that mode does not block an IP address. It instead drops the particular offending packet (the one that triggered the rule). If you want to exclude a particular IP address from enforcement action, you can use a Suppress List or change the rule's action to PASS and edit the target IP addresses in the SID as necessary. What you can do is selectively change the action of a given SID manually. You can set the action of a given SID to ALERT, DROP, REJECT, or PASS.

@jwnazz said in Netgate 1100: @bmeeks Snort started without issue with just the "Connectivity" IPS Policy selected. Thanks for the suggestion. Thank you for the feedback

@bmeeks Makes sense. Auto-updates are def working as expected now. To your point I adjusted my frequency to weekly, every Saturday at 4am. I think Maxmind pushes updates every Tuesday & Friday. [image: 1745245386774-cffaed5b-4c49-4cff-aca1-34032b216f29-image.png]

@rasputinthegreatest I realized I had packet captures enabled. I found this in Wireshark: 192.168.179.1 192.168.1.73 DNS 158 Standard query response 0x6ffc HTTPS chrome.cloudflare-dns.com HTTPS Doesn't tell me much though. Still makes no sense to me how this connection could happen and be captured. I saw this IP in the packet capture with an insane AV detection rate and IDS warnings on this website: https://otx.alienvault.com/indicator/ip/172.64.41.3

@tinfoilmatt Snort is running on the LAN interface.

I am very reluctant to add rules to the package containing a URL with "githubusercontent.com" as the repository because those can disappear as suddenly as they appeared. They are maintained by users generally, and those users could lose interest in future support.