@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.

@johnpoz I hear ya, and I do have that working already. I was just very curious if there were any creative ways to catch someone casually sniffing with Wireshark in promiscuous mode. To your point, as soon as they start arp poisoning or scanning internal hosts I am going to catch them in seconds with my current setup and ruleset.

@bmeeks said in Open Appid Signatures - Updating?: The real story is that perimeter IDS/IPS is on the way out unless you devote time, effort, and energy into MITM proxying. Well i would argue its all about placement. I have firewalls (IPS/IDS built in) that police traffic DC <-> DC [East-West flows]. Yes if the majority of your traffic flows are to the Internet then an IPS is less effective as that is likely to be TLS encrypted but between datacenters you can detect unusual traffic. Its all about security in depth. I would rather have an IDS than not have one.

@rasputinthegreatest said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?: @bmeeks @bmeeks said in ET DNS Query for .to TLD from internal IP to gateway. False Positive?: Don't ever do this But for a VPN like Wireguard I still need to open one port. I did that in the past but it felt unsecure so I stopped using it. On my first trials with Tailscale I saw many error messages in the log. VPN connections are secured with a key and not a password. Long 256-byte cryptographic keys are considered very secure. They are much more secure than passwords. Having the VPN port open is not a big security risk because of the certifcated-based authentication. That's much different than say opening up port 3389 for Windows RDP or port forwarding non-authenticated generic connections.