It sounds like the transparent proxy is blocking port 443 which the game login might be using to authenticate. You either need to apply the proxy settings in the game itself or create an exception in the firewall rules for the game server IP address. Just my thoughts. Look at this post: https://forum.pfsense.org/index.php?topic=62256.msg405719#msg405719  and reply #243. This should also work for your situation.

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