Netgate SG-1000 microFirewall

Recent Posts

Pages: 1 [2] 3 4 5 6 ... 10
Firewalling / Re: Invert match doesn't work
« Last post by Derelict on Today at 03:04:11 pm »
That rule will not block access to the internet even if the WAN is RFC1918-addressed. It would block access to the things on WAN net like the ISP gateway in that case.
IPv6 / Re: TLS handshake fails for some sites over IPv6?
« Last post by jkmuk on Today at 03:03:47 pm »
Did you manage to find a solution to the above problem?
IDS/IPS / Re: suricata log browser memory error
« Last post by bmeeks on Today at 03:00:40 pm »
Using pfSense 2.4.2p1 and Suricata 4.03, I also get this error.  So I edited the /etc/inc/ to allow 1024M for amd64 and rebooted.  But after I still get:

PHP ERROR: Type: 1, File: /usr/local/www/suricata/suricata_logs_browser.php, Line: 58, Message: Allowed memory size of 536870912 bytes exhausted (tried to allocate 625753393 bytes)

This is the section from my
// Set memory limit to 512M on amd64.
if ($ARCH == "amd64") {
   ini_set("memory_limit", "1024M");
} else {
   ini_set("memory_limit", "128M");

Server has 48 Gig of memory so should be no problem right?
Is this memory setting moved somewhere else now for Suricata?

If you let your logs get very large, the viewing in the GUI is just not going to work.  The PHP process that the GUI runs within has limits on the amount of memory a given PPH session can consume.  This is set during boot-up time by pfSense.

If you have a busy network and large log files, I strongly recommend copying them off to another host running an application designed to parse IDS/IPS logs.  There have been some suggestions by users here on the forum. I don't currently have a recommendation as my home network does not generate large logs and the normal rotation logic within the package keeps my logs files of manageable size.

IDS/IPS / Re: Snort configuration
« Last post by bmeeks on Today at 02:56:27 pm »
To be honest, OpenAppID has very limited usefulness in a home network setup.  It is really for enforcing/policing computer acceptable use policies in corporate neworks.  For example, monitoring and alerting if employees are using Facebook, BitTorrent or such things during working hours.  Usually that is of no concern on a home network.  I don't use OpenAppID on my home network.

With only the ET-Open rules, your options as a beginner are limited.  Those rules don't offer any pre-defined protection policies to choose from like the Snort Subscriber Rules do.  My recommendation is to do this --

1.  Sign up for the Snort Subscriber rules at  You can choose the free version or pay $29.99 US per year for the subscriber version.  The difference in the two is the free version rules are 30 days old.  That means each time a new rule for a new threat is added to the subscriber package, it will not show up in the free package until 30 days after it first debuted in the subscriber package.

2.  Enable the Snort Subscriber Rules download on the GLOBAL tab and enter the Oinkcode you received from step #1 above.  Save the changes.

3.  Go to the UPDATES tab and click Update to trigger the download of the Snort rules.  Wait for it to finish and the modal dialog to close.  Leaving the page prematurely will kill the download.  It might take a couple of minutes on a slow connection.

4.  Go to the CATEGORIES tab and click the checkbox to enable IPS Policy, then choose "Connectivity" in the drop-down selector.  Click Save, then go to the INTERFACES tab.

5.  Click to edit the interface you run Snort on (I strongly suggest you run it on the LAN only).  Uncheck the "Block Offenders" box for now and save the change.  You need to gain some experience with the kinds of alerts it is going to generate on your network before enabling blocking.  If you turn on blocking before you have a good handle on what types of alerts you will receive, then you are going to be frustrated quickly by the blocking.

6.  Back on the INTERFACES tab, either start Snort (or restart it if it was already running).

Watch the ALERTS tab for a few days and notice the kinds of alerts you get on your network.  Each alert you see would have been a block, and that connection and traffic would have been shutdown.  Examine the alerts and use Google and some of the old thread resources in this forum to figure out which alerts are false positives.  For those that are false positive, either disable those rules by clicking the red X in the GID:SID column, or click one of the plus icons in the SRC or DST address columns to suppress that alert by IP.

Once you gain confidence in your knowledge of the process and have your rules tuned by weeding out false positives, then you are ready to go turn "Block Offenders" back on.

You can do a search on the IDS/IPS forum here for "Suppress List" or "Suppression List" and that should pop up a long thread about various suppress list rules other users have found useful.

Changing Suricata config to live reload the rules stopped carp from failing over.  It does seem like Suricata was causing the issue.  I thought I didn't enable live reloading because of issues a few years ago but that was quite a few versions ago so maybe that isn't an issue anymore.  There is a note that if live reloading causes problems that you should disable live reloading.  Hopefully things keep going smoothly.

Thanks for the help.

Thanks for the follow-up.  Using Live Reload should be OK.  It is relatively mature now in Suricata.

I still have no good explanation for why Suricata restarting woud cycle the network connection.  As I said earlier, the only thing it is doing with Legacy Mode blocking is starting up libpcap to get packet copies of traffic traversing the interface.  Maybe that causes something to hiccup in FreeBSD someplace and CARP sees the hiccup because maybe it disrupts traffic very briefly.  Strange issue.


Success! Looks like enabling "Live Swap" fixed the issue for me too. Only got past 1 "expected CARP failover event" thus far, but appears to be good.

Thanks for the suggestion. All I did to fix it on my side is filled in the checkbox "Enable "Live Swap" reload of rules after downloading an update" on my pfsense routers and so far so good. Typically the routers appeared to fail back and forth a lot as the general system logs showed >5000 logs of CARP failover. Gladly CARP works very well, so actual impact was approx 2-5 lost pings, slight freeze on RDP sessions, but SSH sessions would continue to work as expected.

Because I only just set this rule I have only gotten past one potential failure (update every 12 hours starting at 00:30. 00:30 did have failure, but at 11:40 I enabled the "Live Swap reload" in Suricata, and 12:30 typical CARP failover did NOT happen). In other words, I typically have two failures, one at 00:30 midnight, and a second at 12:30 noon. After changing this setting I have not had any failures.

Crossing my fingers this was the solution :)

PS. if helpful, my versions are:
pfSense: 2.4.2-RELEASE
Suricata: 4.0.3_1
DHCP and DNS / Re: Inability to get DHCP ? No Carrier -- SOLVED.
« Last post by JKnott on Today at 02:44:09 pm »
They forced my connection to 100FD, over 1000FD.  Apparently they had a contractor come out and dig/install the fiber, and they stole some of the pairs for TV/phone rather than running separate lines.

It's obvious someone doesn't know what they're doing.  Ethernet auto-negotiation takes place at 10 Mb, over 2 pairs.  It will then switch to the best common speed, which the NICs think is 1 Gb.  However, GB requires all 4 pairs and so will fail.  By locking the modem at 100 Mb, it now only needs 2 pairs.
Hopefully I will cover a lot of basis here with this post because we have seen a lot of these faults.

If you are getting any of the following errors updating pfSense please try these steps.

Upgrading from console option 13
Error updating repositories
Child process pid=xxxx terminated abnormally: Segmentation fault
pkg: Repository pfSense-core load error: access repo file(/var/db/pkg/repo-pfSense-core.sqlite) failed: No such file or directory
Warning: require_once(Net/IPv6.php): failed to open stream:

Console or SSH into you device
Try running these commands exactly as typed here.

Code: [Select]
pkg-static update –f

pkg-static upgrade –f

pkg update -f

pkg upgrade -f

pfSense-upgrade -4

If any of these fail, check your DNS
Code: [Select]
set type=srv

If you do not receive a valid response then your DNS servers may have been wiped or the GW removed from the DNS settings. You need to temporarily fix this with these commands.

Code: [Select]
echo "nameserver x.x.x.x" > /etc/resolv.conf
route add default y.y.y.y

where x.x.x.x is a valid public dns and y.y.y.y is your public wan gw ip address.
Deutsch / Re: High Availability Sync zerlegt die erste Firewall
« Last post by Grimson on Today at 02:38:07 pm »
Sind da Limiter mit im Spiel, in dem Fall:
Español / Re: Direccionar Paguina a 1 wan
« Last post by el23456 on Today at 02:35:36 pm »
Cache/Proxy / Re: Unofficial E2guardian package for pfSense
« Last post by marcelloc on Today at 02:24:47 pm »
@Marcelloc, I'm having problems with Regex for enforcing Youtube Restricted. Do you use this on your network? Anyone else here using it? It seemed to be working fine on 4.1, but on v5, that's stopped working. I've yet to pin down if its a change Youtube made on their end or if its E2G for sure.

The below is what I'm using for YouTube:
Code: [Select]
# Enforce restricted mode in YouTube

I did the test right now and it worked fine. I've setup this under acl -> site lists -> SSL Regex

the resulting file is unde /usr/local/etc/e2guardian/lists/sslsiteregexplist.g_your_group

Tested without transparent mode with ssl filter and ssl interception as well.
Pages: 1 [2] 3 4 5 6 ... 10