Is it possible that alias is not doing what you want or it is not completely bypassed? I was able to get my client to bypass the proxy completely in a less sophisticated way (mine is not transparent though). I couldn't use the bypass destination field as you did. I'm not sure know how to completely bypass a transparent proxy without disabling it. You confirmed that same page is loading up fine if you access it from anywhere other than your pfSense network? Via a different browser? Or after clearing browser cache, history, etc.

Also, I assume you already tried manually clearing all blocked hosts from Snort and then accessing it again?

@bmeeks:

@NollipfSense:

@bmeeks:

No, the POP3 preprocessor most definitely does not communicate with any mail server.  It is simply looking at the commands flowing back and forth between email clients on your network and whatever mail servers they are connecting to (assuming that traffic passes through Snort).  The line you underlined from the Snort manual is simply saying you need to tell the POP3 preprocessor what ports to be looking at within the incoming/outgoing datastream.  It does not imply that Snort is talking to the mail server, though.  Telling the POP3 decoder what port is in use lets it filter the traffic and only inspect data coming or going from the active POP3 port.

You define the POP3 ports on the VARIABLES tab for the interface in Snort.  There are settings on that page for servers and ports.  Leaving boxes blank will use the default values which are shown in the help text under each box.

Bill

Thank you Bill for the detail explanation. Well, one cannot just add the port…one has to create an alias; so, I created two firewall aliases, inmail and outmail and added firewall...see pic. Then, I added the aliases to Snort's variables tab > SMTP >outmail and POP3 >inmail. But, I cannot send or receive mails...should I have added anything in the server section? I got this Snort alert and have since changed the source port. Had to hide destination IP for privacy on Snort alert pic. Outmail port is 465 and inmail port is 995.

Port 995 is typically for POP3S (encrypted POP3), so Snort is going to have trouble seeing everything correctly on that port.  That rule is a "false positive" in your case because it is looking at an SSL encrypted datastream, so the byte patterns are not going to match the "standards" that Snort would see on a port 110 plain-text POP3 connection.  That's why the rule is triggering.

So short answer is just disable that rule as it is going to fire on you a bunch and means nothing on an encrypted session.

Bill

Thank you Bill…disabling the rule worked and can now send, received emails from my SOHO...in time for Monday morning!

Your hardware is capable of running Suricata or Snort for a home network application.

Whether you need it or not is really up to you.  One of the things to consider is what type of risk is your network exposed to via the VPN.  What I mean by that is if you simply access mainline streaming services like Roku and AppleTV and avoid other more "wild and wooly" sites, then you don't need an IDS/IPS package.  If you have guests with laptops, or other household members that might visit more risky sites (such as torrent hosting sites, some gamer sites, etc.), then an IDS/IPS like Suricata or Snort can help protect users from themselves by blocking some known exploits.

Just be aware that it is NOT as simple as just installing the Suricata or Snort package and turning on blocking.  Doing it that way will most certainly result in lots of spurious blocks from false positives.  You have to understand the rules and enable only the ones that are appropriate for your network usage.  There are examples of good setups in the threads of this IDS/IPS sub-forum.  Just search through using the search tool on the forum.

Bill

@mpdsville1:

I examined the igb(4) page and see the chipset is supported but that it doesn't specifically state Dual/Quad.  Am i correct in that you are referring to the lack of Dual/Quad specifically listed ?

Yes, it very well can be that the Dual/Quad variety is not supported.  I'm not a NIC driver expert, but I assume there is still some degree of difference between the driver for a single port NIC versus one for a multiport NIC even if the underlying physical chipset is the same.  For one thing, the multiport NIC driver would have to know which "port" on the card to send and receive a given datastream from.

Suricata supports several Inline IPS operating modes on various operating system platforms.  The two available on FreeBSD are Netmap and IPFW Divert Sockets.  In the distant past I tried using the IPFW Divert Sockets mode with Suricata on pfSense but it would not work due to some customizations done within the IPFW module at the time to support some of the old limited Layer 7 inspection capability pfSense offered.  IPFW is also used, I believe, as part of Captive Portal.  IPFW is the alternate firewall engine available in the FreeBSD used for pfSense.  The other firewall engine, and the one pfSense uses, is the pf (packet filter) engine.  IPFW Divert Sockets mode is NIC driver agnostic and thus would work with any NIC, but that mode is quite slow as it does not allow direct connections between the NIC, Suricata and the kernel network stack.  So Inline IPS mode would be much slower with IPFW Divert Sockets than it is with Netmap.

Bill

The problem appears to be within Barnyard2.  Notice that is where the error is generated according to the log message.  Barnyard2 on FreeBSD (and thus on pfSense as well) is very old and not well supported.  It will be removed from the Suricata package in the near future, and I'm considering doing the same for Snort because Barnyard2 is so unreliable.

Your particular error message comes from Barnyard2 not being able to adequately handle IPv6 events.  Here is a thread link to an open bug report on Github for this issue.  Notice the date is 2015 and still no action, so that's what I mean by Barnyard2 being poorly supported.

https://github.com/firnsy/barnyard2/issues/144

Bill

It actually has nothing to do with Suricata and more to do with FreeBSD kernel and the NIC driver. I just recently experience the same issue and have submitted a bug report to FreeBSD…see here. https://forum.pfsense.org/index.php?topic=144538.0

After researching, it seems that the dual Intel NIC is not natively supported per here: https://www.unix.com/man-page/freebsd/4/netmap/

@knownPlayer:

With the default rule I mean my drop any rule from my first post. Sorry if I wasn't being clear.

drop ip any any <> any any (msg:"default deny"; )

Since I am experimenting with implementing a whitelist in Suricata, I allowed all traffic on all interfaces in my pfSense. This way I can focus on Suricata first.
My test setup seems to be working now, though I don't know exactly why.  Might have been a system restart…

Thank you for your help Bill.

Oh … OK.  When I type replies the start of the thread is buried down on the bottom of the screen and I frequently forget what has been said before... :).  I thought maybe you were talking about the firewall's default deny rule since I had forgotten about the earlier discussion.

Bill

Okay Bill…found it...FreeBSD Bugzilla – Bug 226289 Submitted...Bug 226289 has been successfully created.

Bill/bmeeks, that's perfect and good information - exactly along the lines of what I was thinking also. I am in a small medical installation, not home, so I do want some of this "noise" to show up, even if just for my own satisfaction of preemptive acknowledgement of blocking.

To that end, I'll run the same rules as you suggest; I'm noticing the ET-CIARMY is already reasonably noisy.

It would be super-cool if you could possibly find the time to update the first post of the sticky for New Users in this category, as there is a lot of information that is now outdated/superceded - new users have a rough time identifying the basics. In fact, the current pfSense tutorial/guide for Snort was the best I've found, but not many references to it within this forum. Coupling a link to that page, plus a brief overview of WAN/LAN suggestions, would be ideal - rather than reading a day's worth of scattered posts from 2013 onwards.

Thanks.

I go check.

Suricata and Snort both depend on the values of the HOME_NET and EXTERNAL_NET variables being set correctly.  Many of the rules from both the VRT and Emerging Threats uses HOME_NET and EXTERNAL_NET as source and destination values for IP addresses.

If the IP addresses in HOME_NET and EXTERNAL_NET are not correct, many rules will fail to trigger and fire alerts because all of the "conditions" for triggering are not met.  So first question would be have you modified any of the defaults for HOME_NET or EXTERNAL_NET?  If you are trying to monitor a VPN, it could be the IP addresses of the VPN tunnel are not getting properly placed in HOME_NET.  In that case, you would need to create a Pass List and use it as a customized HOME_NET.

Bill

@afagund:

Should I message the developers mail list? For me its clear we have a bug on this package.

You can, but if you mention "_package on pfSens_e" or "pfSense" anywhere in your report they will just send you right back here as they will assume somehow pfSense is to blame.  The Snort package on pfSense uses the same Snort binary as is used on any other Linux/FreeBSD machine.  So just tell them you think you have a memory leak issue with Snort using the HTTP_INSPECT preprocessor with gzip encoding enabled and don't mention the platform you are running on unless they ask.  If they ask, just say "FreeBSD 11" and don't mention pfSense.

I'm not trying to be coy and hide information, but just pointing out that the default response will likely be to send you right back to the pfSense forums if you mention pfSense in your bug report.  Your issue is not with the pfSense package per se, it is potentially with the Snort binary, and that binary is the same as any other FreeBSD user would be using without pfSense in the mix.

Bill

Oh good grief, I didn't realize there was already custom rules section.  Nothing like reinventing the wheel.  :-[  Thanks Bill

@bmeeks:

A better and more secure way to handle this type of issue is to identify which rule SID (Signature ID) is causing the block and either disable that rule entirely or suppress that alert for the impacted IP (your cloud provider's address or address space).  To identify the rule causing the block, look on the ALERTS tab for the interface and filter for the blocked IP.  See which rule SID (or it may be more than one) is causing the block.  You can suppress the alert by adding the rule SID to a suppress list that filters on source or destination IP, or you can click the "X" icon under the GID:SID column to disable that rule completely.

Bill

Thanks for the direction Bill.  I did exactly as you said and found the rule causing the error.  I've since suppressed it and am no longer running into issues.

Hi DaReaLDeviL,

Bill Meeks has a good explanation of what Inline Mode is and its benefits over Legacy Mode here:
  https://forum.pfsense.org/index.php?topic=108010.0

The biggest issue with inline mode is hardware compatibility and stability.  When running as a physical machine FreeBSD's netmap only supports a limited number of NIC chipsets.  Supported list of adapters: https://www.unix.com/man-page/freebsd/4/netmap/

But as for running it in a virtualized environment I'm not sure if pfSense's netmap supports vmware adapters.  Maybe someone has already tested and can chime in on this.  If it is supported I would think it would require you to configure SR-IOV (which your NIC does support) on your VMware Host.  If you're not in a production environment I'd say snapshot and see if it works.  Hope that helps.

Hey

Sorry for the (very) late reply, stopped checking the thread. I have not resolved the issue, it still works in this counter intuitive manner. As of right now I am just letting it work with the rules suppressed and disabled. We have been working on moving to Suricata inline as a replacement, but haven't moved it from the testing stage yet. I've actually been away from the office for some time now and have to catch up on suricata dev. They were having issues with the inline mode and vlan tags. Hopefully that has been resolved.

What kind of hardware are you running?  What is the type and speed of the CPU and how much RAM?

Suricata needs CPU, and the higher the packet load the more CPU it needs to keep up.  Granted with no rules enabled it should not need nearly as much, though.  Might be an issue with your NIC drivers and the Netmap module in FreeBSD.  As as been said in this forum about a thousand times, inline IPS mode uses the experimental Netmap kernel interface.  Some NICs don't work with Netmap at all, and others work in a buggy fashion.  Your NICs might be one of the latter.

Put Suricata in Legacy Blocking Mode and see what the throughput is then.  This will isolate the problem down and hopefully show Netmap compatibility as the culprit.

Bill

In Snort a Pass List entry should not prevent receiving an alert.  It just prevents that alert from going on to generate a block.  So you should still see alerts on the ALERTS tab.  The pass list is checked by the custom blocking plugin after it receives the alert but before it sends the IP address to the snort2c table.  If the alert's IP address is in the pass list, then the IP is not sent to the snort2c table but it should still show up on the ALERTS tab as an alert.

Bill

Dale thanks for the suggestions.  After some time of testing I found:

1.  The primary problem was Snort's Preproc http was blocking most of the IP's for the speedtest, even after turning virtually all rules off.  If I would clear the blocks it would start to work again (instead of rebooting which also clears the blocks) before blocking all the IP's again.  I could not find a way to fix this except to turn off the Preproc http (which numerous posts claim will break much of Snort), or to install suppress rules to suppress the rules that were too aggressive (I didn't test the suppress method, find that too be a little cumbersome for basic functionality).

2.  The secondary problem with the upload speed being low was using the bce network driver (built in Broadcom NICs).  Apparently this driver or hardware has issues with BSD.  I switched to another NIC that used the bxe driver and the upload speed problem went away.  I'm going to try some better Intel NICs later to try and take advantage of the "Netmap" functionality.

I'm testing Suricata now, finding it less cumbersome so far.

Okay, I read through the entire thread…one doesn't need to implement all those scripts as one can use the custom DNSBL Feed rules into PFBlockng...really grateful to BBcan177.

I also changed firewall flowing rule to block with the quick set checked, interface: WAN, direction: any, family address: IPv4+IPv6,  protocol: TCP, source: any, destination: any, destination port range: other, then from the WebGUI to the WebGUI.

I also added a second firewall flowing rule to block with the quick set checked, interface: WAN, direction: in, family address: IPv4+IPv6, protocol: TCP, source: any, destination: any, destination port range: other, then from outgoing privilege ports to outgoing privilege ports.

Extremely grateful to jflsakfja as well thank you and wish you all the best.