Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - mer

Pages: [1] 2 3 4 5 ... 22
Installation and Upgrades / Re: Guidance regarding switching to ZFS
« on: February 05, 2018, 12:15:24 pm »
So getting into the weeds, yes, ARC is nominally kernel memory, accounted for in the Wired statistics in top, but by design it will expand to a threshold of system memory.  Wired and nonswappable does not mean unrecoverable. 
There are boottime tunables to change this behavior (vfs.zfs.arc_max, vfs.zfs.arc_min)

So if you have 32GB of RAM in a system and your use case warrants it, ARC certainly will use I think up to all but 1 or 2 GB reserved for the kernel.  But if other processes demand RAM, ARC will flush and use less.  Plenty of documentation on this, but the best I've seen is the Michael W Lucas books on ZFS.

Installation and Upgrades / Re: Guidance regarding switching to ZFS
« on: February 05, 2018, 07:31:06 am »
It may depend on what version of FreeBSD you're basing on.  The TrueOS project (ixSystems guys, PC-BSD followon) are basing on 12-CURRENT and a ZFS install and they have been doing binary upgrades into a new BE since day 1.  11-Release should support them just fine.

The process is basically create snapshot and clone of the currently running environment and the upgrade is done into that clone.  Then you readjust flags and reboot into that upgraded BE.  If anything fails, the fallback is either:
reboot, stop in bootloader, select previous BE and continue booting
if the system is up enough, use the beadm command to activate the previous BE and reboot.

There are some rules you need to follow when creating any datasets (use of the canmount property to make sure things wind up where they need to be), but it should be doable.  This is the part that gets a lot of people, things needed for booting have to fall under whatever root dataset you create.  Just remember to limit the number of BE's so you don't run out of disk space.

Installation and Upgrades / Re: Guidance regarding switching to ZFS
« on: February 05, 2018, 06:48:44 am »
A feature of ZFS that doesn't get mentioned often enough is the use of boot environments (BEs, beadm is the tool used to administer them).  Best way to upgrade a system I've ever seen.  If it fails in some manner, easy to fall back to a known good one.  I'd bet one could even automate a fall back if something in the new environment fails.  It's very easy to create mirrors with ZFS so you can get a lot of redundancy easily.  Yes, you can create mirrors for UFS using geom, but not too many folks do that.  Of course your system needs the ability to have multiple devices.

Amount of RAM is very dependent on use case as others point out.  If you look at what a pfSense or any firewall is doing, they boot, read configuration, start up processes.  After that the bulk of what happens is writing to logs and "in memory stuff" (travsering state tables and such).  There are standard FreeBSD packages that let you look a the zfs usage stats, so you could keep an eye on things.

ZFS by default will use system RAM so there may be some competition on that resource, but ZFS lets you tune and set limits.  ZFS also groups transactions (mostly reads) that get batched out to the device, so you may have periodic spikes in CPU usage because of this.

Just my opinions.

General Questions / Re: I want to pay a PFsense Expert to help me
« on: January 30, 2018, 05:01:09 am »
Doesn't pfSense/Netgate offer paid support?  I know there is Gold Subscription when you buy their hardware preinstalled, but I can't imagine them turning down a paid consulting gig like this.

General Questions / Re: Admin password changed itself. Twice. Yes it did.
« on: January 24, 2018, 07:37:54 am »
I'll add in another WTF.  @johnpoz, I don't spend much/any time on reddit, so did not realize the exposure.  Thanks

General Questions / Re: Admin password changed itself. Twice. Yes it did.
« on: January 24, 2018, 06:01:58 am »
@jwt, you may want to pull out some of this discussion (the what can/should we do) into a separate topic for wider community input.

My couple of cents:
Licensing:  most/all of pfSense is it BSD or BSD-ish License?  If so, that gives you one set of options.  Other licenses (GPL, et al) mean other things.

Defend the trademark as vigorously as possible, don't just give up on it.
Make it clear on the front page of the website that the only official systems preinstalled are from NetGate.  Anything else is "buyer beware".

"free" pfSense:  this is a similar situation to ixSystems and FreeNAS, no?  There is value to providing a user downloadable version for use on their own hardware.  What you need to do is differentiate it enough from the officially installed on Netgate hardware so folks will try the free version and then buy the preinstalled.  I know, hard to do.  You can't cripple the free version, you  need to make the preinstalled version have useful bells and whistles.  The free version also lets people that have the ability and desire generate patches for you.

Activation keys:  I understand the reason and logic, but have never liked them.  Too much like a "you paid money for this but we're going to control your ability to run it".  Is it a "one and done" so I can reinstall on different hardware as much as I want?  Is it tied to a specific version of pfSense on a specific hardware platform meaning I can't move it to different hardware if something dies?  Do different features require different activation keys?  Are the keys going to expire (yearly subscription)?

I don't know what's right for the project, I've always been fine with paying a resonable price for something I need and for my home use the SG2440 was more than I needed but it was a reasonable price.

General Questions / Re: UPS PfSense Shutdown
« on: January 05, 2018, 07:43:45 am »
Second what dennypage is saying.

If you already have NUT on the pfSense system, you don't need/want apcupsd on it, just make it shutdown the pfSense system.  That way pfSense is the master.
The Windows machines then run NUT as a client, over a network connection to the pfSense system.   That way the one master instance controls the other machines and should be able to shut them all down.

It's a fairly common configuration;  moreso as machines evolved so they draw less power so a single UPS handles more than one.

General Questions / Re: UPS PfSense Shutdown
« on: January 03, 2018, 11:50:28 am »
You should be able to use apcupsd or NUT package on the pfSense box and have it gracefully shutdown.
If you want the single UPS to gracefully shutdown all the machines, you'll need to pick something that runs everywhere and has the ability to talk across the network. 
NUT ( has this feature, I believe there is a pfSense package for it, it looks like it may run on Windows.

I'd set up pfSense to be the master of the UPS and the other machines as slaves to that.  When it's time to shutdown, master tells the slaves to shutdown then shuts itself down.

Just my opinion and you may need to play around with whatever solution (timing between slaves shutting down and the master shutting down)

Firewalling / Re: How are rules executed ?
« on: July 05, 2017, 09:39:43 am »
For floating rules, last wins. I guess you could think "bottom to top". But it's still top to bottom. The difference is important if you do any "quick" rules.

I thought that all user defined rules added the quick keyword internally?  pf inherently is  "evaluate from the top, last match wins unless there is a quick keyword"

Setup a cron job to do packet capture, start at 0358, end at 0402 then do offline analysis?  That would give you the traffic, no?

By default, pfSense blocks everything coming into the WAN port UNLESS it's a response to outbound traffic.  All outbound traffic by is allowed by default.

You need to think a bit more about your network configuration.  Draw pictures, arrows with the directions of the traffic, which port it comes in on and what you want to do with it.    Rules are very specific in and out is from POV of "being pfSense".
Packet captures of traffic can make it easy for you to understand the characteristics of the packet you want to allow or block.

That said, generically pfSense rules are applied on an interface basis (except floating rules), user rules evaluated before default rules unless you muck with the order, rules are evaluated from top down, first match wins (because they make good use of the quick keyword), you want a couple of user rules top would be a pass in on LAN interfaces with characteristics matching windows upgrade packets followed by a block everything in on LAN interfaces.

Now keep in mind doing this is guaranteed to break things like DNS, HTTP/HTTPS, and other generally useful packets.  That is why you really need to understand what you are asking.

General Questions / Re: Missing Link
« on: May 15, 2017, 06:30:14 am »
That's a traditional symlink on FreeBSD systems to the source tree.

Firewalling / Re: Blocking IPV6 Traffic / Teredo
« on: July 16, 2016, 10:26:19 am »
Sorry, John, I was trying to give a little positive reinforcement to the OP.  It also sounds like it's on his home network and he's trying to learn what's on it and understand security implications.  Nothing wrong with that, is there?  If I stepped out of line, sorry.

Firewalling / Re: Blocking IPV6 Traffic / Teredo
« on: July 15, 2016, 04:25:54 pm »
Fantastic  ;D  That's one of the subtle things lots of folks miss.  Don't forget about ordering:  user defined rules "first match wins".  If you put a block all rule first, your pass rules don't get triggered.

Floating rules are applied a bit differently, so make sure you research them before using (they have in and out and are typically applied before interface specific rules)

Firewalling / Re: Blocking IPV6 Traffic / Teredo
« on: July 15, 2016, 05:27:17 am »

Rules are applied inbound on an interface, not outbound.  So your rule you put on your WAN is saying "block any traffic inbound on my WAN interface that is sourced from any IPV4 address, with any IPV4 protocol, that is destined to".

Is inside your network (LAN side of pfSense) or outside (WAN side of pfSense)?  How about  LAN side or WAN side?
What would happen if you put that same rule on your LAN interface?

Pages: [1] 2 3 4 5 ... 22