The pfSense Store

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 ... 21
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?

Firewalling / Re: Redirect to internal services
« on: July 13, 2016, 11:44:03 am »
So traffic from LAN hitting pfSense you want to redirect it to something else on the LAN or OPT1/etc?  Should be able to, just make sure you don't block the "final" one that may need to come out.

Take DNS, if a LAN client is going to the pfSense for DNS resolution, sure you could redirect that to LAN DNS servers, just make sure that those DNS servers have a way to get out or it won't work.  You also need to be aware that a client may put in a different DNS server, say Google that won't get redirected.   DNS can be setup on pfSense in a couple different modes, one where it does the resolution, another you could have it forward to others.  You still need to be aware of what a client could do.

There are also proxies that you can run to do things like this;  others with more specific knowledge as to setting up and configuring them will likely jump in.

Installation and Upgrades / Re: My Installation Experience
« on: July 13, 2016, 08:37:41 am »
After you updated, you rebooted, a warm restart, not power cycle, yes?  If so, have you tried setting WAN back to autoneg (not forced to anything) and power cycling?  There could be an issue with incomplete reinitialization of an interface at the driver level that causes issues on a warm restart but on a power cycle everything comes up clean.  Reason for asking is that it was fine yesterday, you updated, warm reboot and it had problems.

Installation and Upgrades / Re: My Installation Experience
« on: July 11, 2016, 06:18:33 am »
The only relationship that autonegotiation has to an interface getting an IP address is that a link must be physically up for DHCP requests to go out and for responses to come back. 

Edmund, was your pfSense WAN connected directly to your cable modem or was there a switch in between?  Are you sure your cable modem was also set to autoneg?

Auto neg has 2 parts:  speed and duplex.  If one end is forced the other not, speed will often be correct, but duplex is wrong.  Duplex wrong is one end thinks "full" the other thinks "half"  and you wind up with a lot of errors on the interface.

Installation and Upgrades / Re: My Installation Experience
« on: July 10, 2016, 02:01:02 am »
Ethernet autoneg is a function of the hardware, no?  The most the software does is reinit the phy, perhaps put in a configuration, but the hardware is where it actually happens (unless I'm misrembering my BroadComm specs).  Heck a lot of times "forcing" a configuration the software doesn't disable autoneg, it simply limits the configurations.  Speed and duplex are both functions of autoneg, not just speed (and that's part of the problem if one end is autoneg the other forced.  Duplex often fails to negotiate so what should be a 100/Full winds up at 100/Half on on end).

And yes, different hardware can have problems talking with other hardware.  Lots of times it comes down to how the mfg interpreted a spec.

Firewalling / Re: Strange Firewall problem
« on: July 06, 2016, 12:44:58 pm »
10.40 and 100.19, are they sitting on 2 different ports (lan, opt) of your pfSense device?  Do you have rules on both of those interfaces that will allow traffic between them?

At some point, someone will probably ask you to post screenshots of the firewall rules for all the interfaces and any floating rules.  It makes it easier to help you.

General Questions / Re: Blocking Specific Outbound IP Address?
« on: July 06, 2016, 12:39:37 pm »
A subtle distinction about rules in pfSense that may differ from other products:  they are applied in the inbound direction on an interface.  Inbound means you are sitting in the middle of the box, between the LAN and WAN.  Traffic from your clients is inbound on LAN;  traffic from the rest of the world is inbound on WAN.  That's why you add the rule to the LAN interface.

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