Reinstall the box.

Some random lawyer sending your bills doesn't sound to me like something that stands any ground. In switzerland there are various places to get help with situations like this. I'm sure in germany there are similar agencies available (see http://www.beobachter.ch/justiz-behoerde/gesetze-recht/artikel/rechtsstreitigkeiten_rechtsberatung-zum-nulltarif/ )

Okay guys, I found out that the router has an option to use as an access point. It disables everything except for wireless. Thanks for the help. No double NAT or a different subnet

Under Firewall: Virtual IPs: https://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F#Proxy_ARP Steve

try disable the automatic update dashboard check In system-firmware-upgrade settings Dashboard check Disable the automatic dashboard auto-update check. If your connections are down your going to have issues with dns as mentioned, you could see if turning this off helps the dashboard display faster.

If that really is the MAC of the firewall, then look for a layer 2 loop. Something is causing the packets to come back into pfSense on that interface after it sends them out.

I don't have an Alix box to compare that behaviour to and I agree it's not what I'd expect to see on other equipment but if both boxes are doing it and one is working then it seems unlikely to be the cause of your problem. @opalit: less than 512M detected, disabling APC. That's normal on the Alix which has 256MB. Steve

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).