As an update: I by now have my replacement Dell, so I could test my pfSense1 to the memory test. It has been running memtest86 for 24 hours with no problem whatsoever.

I also discovered in the bios the motherboard will automatically scale back the frequency; the bios said 'RAM 1600, actual 1333'.

A wise man who knows many, many things whispered in my ear I should try the PSU (thank you, wise man  ;D), so this is what I will do next. And else I will remove pfblocker, since that appeared to keep on crashing on line 262 constantly.

Thank you for your help  ;D

Thanks, Phil!

As it turns out, the only thing that was wrong was NAT (I already had the PIAGW assigned to LAN2).

I really appreciate the explanation for the NAT situation.  I had read somewhere about setting NAT to manual but I didn't understand why.  When the rules automatically appeared upon selecting Manual, I assumed that the rules were present in Automatic and if they were present in Automatic, why change to Manual?  Since I'm not a NAT expert by any stretch of the imagination, it made sense to go back to Automatic rather than rely on a Manual set of rules.

I've now assigned LAN1 to WANGW an it seems that the two LAN ports are working as I had hoped.  There a bunch more functionality I want to learn so I'll probably be posting more dumb questions; but that was a major hurdle.

Thank again!

You can operate pfSense as a transparent firewall but if you do that it will not route or NAT.

I guess the obvious answer to your original question is; it's much cheaper.  ;)

Steve

@jimp:

2. You have a cron job that generates an error or output

Cron will email any output, not just error. Adding /sbin/sendmail to arpwatch pckage caused many emails sent from newsyslog job, which is left for some reason in pfSense 2.1 even if newsyslog is not included. But besides that, there are other packages, which may generate email - Snort is one example.

The best workaround is to inlclude empty MAILTO in crontab file, however I do not think it was the best idea to include /sbin/sendmail in arpwatch without a way to turn emails off in the first place.

For future readers - in pfSense 2.2 onwards you will be able to have a "hybrid" outbound NAT. That will leave Automatic Outbound NAT to generate the default outbound NAT rules and then you can add 1 or more manual outbound NAT rules to that.
That means you can have some extra manual outbound NAT rules for special stuff (like for private subnets that are "hidden" behind another internal router), but then if you add another directly-connected LAN interface+subnet to pfSense you do not have to remember to add outbound NAT rules for it. It will "just happen" because automatic outbound NAT rule generation is still in effect.

Celeron D 2.8 GHZ  is better

Never mind, I disabled "TFTP Proxy" from System -> Advanced -> Firewall / NAT, Then did a UDP port forward from 69 to 127.0.0.1 on port 69. I then set the TFTP server to listen on the LAN, uploaded my PXE files, and used TFTP GET and transferred the file perfectly.

You might try logstash.  I haven't used it personally, but I'm told folks like it and that it isn't as heavy as a full Splunk installation.

Splunk supports acting as a syslog server itself, and accepting syslog style traffic on port 514 (or whatever port you want).  I'm using Splunk Storm[1] as a destination for my pfSense logs.  Unfortunately, at the moment I'm having to do it in a very round-about way.  It seems as if the Splunk Storm instance isn't actually listening for UDP traffic, but TCP traffic works fine.  I ended up installing a Splunk forwarder on a different host in my network, making that listen for log traffic from pfSense (UDP), and sending it from there onto Splunk Storm (over TCP).

The basic version of Splunk Storm is free, but there are quite a few limits (how many accounts you can have log into the same instance, how long the data is kept, etc).  One of the really nice things is you don't have to administer the Splunk server yourself.

[1] https://www.splunkstorm.com

After having the switch out of the mix for a week or so, as expected, it made no difference.  OTN physically/directly attached to the pfSense and channels still went missing.  I was hoping maybe somehow the switch was caching something in its internal routing or ARP table, but that doesn't seem to be the case.

That's odd. Channels stay available even when channels are switched? I would assume that if you switch to a different channel then the new channel is subscribed to and the old channel is unsubscribed (via IGMP). So either the unsubscribing does not happen or there is something else that your ISPs box does.

Yep, it seems as if the channels vanish after a while - not right away.  I don't know exactly when they stop working, but initially they all seem to work fine switching through them.

I put the ISPs router back in (so pfSense out), and have a packet sniffer set up like a mouse trap with peanut butter trying to grab anything to/from what appears to be a management port, 4567.  I'm hoping there is a clue, or a way to access that ISP device's internal configuration to see if I'm missing something in my multicast setup.

Can you just open the firewall completely temporarily? This could rule out that the firewall is causing the problems.

Thanks for the suggestion.  I've put that on my list of things to try.  I need to look at it again, but IIRC there are rules showing up in the pfSense logs that do not seem to be accessible in the UI that I've been able to find.

Each new configuration takes some amount of time (have been giving it a few days or so) for the channels to stop working, which is making this difficult to sort out.

I'm not sure if this is related but when I was looking at some packet traces a couple of weeks ago with the ISP's box in place, I think I noticed something that may be different about two of the channels I'm having trouble with - each of these trouble channels has the same source IP as at least one adjacent channel.  I haven't gone through all channels recording their IP addresses, I just happened to notice when changing channels on these particular ones, the source IP wasn't changing (but the channel/programming changes just fine).  On other channels that always work, they don't (from what I could see) have the same IP.

The two problem channels do not share a source IP address (one is channel 13 and the other channel 119) with each other, they just seem to share one with an adjacent channel (ie (don't remember exact specifics) channel 13 and 14, channel 118 and 119).

I think that using CARP + Virtual IP will help me :-)

My_CARP_and_VIPs.png
My_CARP_and_VIPs.png_thumb

@james_h:

You can just create one rule under LAN firewall rules, allow any to WAN to get you up and running.

Could you show me how I create a single rule?

Its like subnet = lan any to wan any!?

Check the system logs on the secondary, odds are it's being pushed a setting that it can't properly apply (usually trying to add a VIP to a missing interface or similar)

@xenHR:

What would my cables have anything to do with it.

Because with rules like above, there is absolutely ZERO chance you'd get webGUI access blocked by firewall on LAN. Except that you claim that instead can access it on "WAN". Cannot see anything productive coming out of this. Wipe the mess and reinstall the box from scratch, making sure you set up both WAN and LAN properly at install time.

@xenHR:

The LAN is operating fine except I can't get out or to web gui.

Sure. If you plug the cables to a dumb switch, no firewall is involved in traffic flow between boxes on that switch.

Snort has blocked things a time or two for users.

You can test DNS from Diagnostics > DNS Lookup or using "host" from the shell. You can check general connectivity by trying to ping a host on the Internet by name.

Usually if your DNS and routing are OK, and packages still do not load, it turns out to be either something like snort blocking or maybe broken IPv6 routing that makes pfSense believe you have IPv6 connectivity when you do not. See https://doc.pfsense.org/index.php/Controlling_IPv6_or_IPv4_Preference for a fix for that.

Possible but not recommended. It's best that everyone have a unique certificate, otherwise you may as well not use certificates at all and use auth only.

@BBcan17:

Is there a reason why the "COMM" command is not included in the pfSense /USR/BIN folder?

Is there any way to download that file from a secure source?

Reasoning is the same as any other "missing" item, we remove things that aren't needed and/or to save space. We don't have a need for that utility and nobody has required it before, so it's not included.

You can copy the utility from any other FreeBSD installation that is of the same version as pfSense you're using.