@mudmanc4: Thanks for the reply, and I should clarify to insure were on the same page: So would this require adding a route in the VPN client, to allow only the LAN subnet ? Reading what you wrote, I dare say yes, just pushing the route for the local LAN should be sufficient.

Sigh, found it. find / -name syslogd /usr/sbin/syslogd

Most likely BIOS (or "Legacy" boot mode on newer computers)… I don't believe pfSense (or maybe even FreeBSD in general) uses UEFI yet.

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

Alienvault has now release a pfsense plugin. Check out https://github.com/decay/alienvault-pfsense

It would be best to run your du command when your drive is showing full or nearly full usage. You can then drill down through the directory showing the most use until you get to the directory where the space is being used up. Otherwise it's anyone's guess where your space is being eaten up. Squid might be the culprit, though if your Postfix settings aren't correct your firewall might be queuing large amounts of undelivered mail - possibly system warnings(?).

Multiple things at 192.168.1.1 causing something in the middle (switch) to get confused by different MAC addresses?  Reason for asking is 192.168.1.1 is a pretty common default IP for lots of home network stuff.

@heper: on the general tab there used to be a field "bypass proxy for these source ip's' (or something similar) use that Thanks! That worked! Happy New year!

Thanks!! That solved it!

@tlf30: I would have never found the issue had I not followed your advice and reset it! But, my problem is one that I really don't like. The LCDproc-dev package is the one that causes the issue. If I disable it from the GUI, all interfaces start working again. If I enable it, it is like a time bomb waiting to go off and kill all of my traffic. Does anyone know a solution? Thanks, Trevor Is it possible you have LCDproc-dev as well as LCDproc (hanging out prior to the update)? They will likely interfere with one another.

At this point it's the second reinstall in a few months.  I'm ready to blame the hardware, starting with the disk because fsck just doesn't work.  It's a solid state disk. It's an Atom fanless box that was pre-configured I got on Amazon.  I'll replace the drive with a standard hardware sata.

Dude LAN never talks to pfsense to talk to LAN..  No its not the same thing..  Client on 192.168.0.0/24 doesn't talk to pfsense to go to 192.168.0.0/24 ?? Smarter way to create an alias for a list of networks?

If you're doing any manual ifconfig, you're doing something wrong. Maybe you're trying to manually configure IPs on things, which will get stomped on, and bypasses input validation that prevents invalid configs. Overlapping/conflicting subnets on multiple interfaces might be another reason you'd have issues along those lines. You're losing a link route for the IP where 'route get' shows the IP going via the default gateway.

Ok thanks bummer it doesn't go by the RFC. Doing syslog-ng is an ass

You might get help over at miniupnp site..  Your listening IP is going to be the networks on that interface..  But you have downstream networks, so that source does not fall to what your listening network is.. You might want to change your listening_ip to say 192.168.0.0/16 and see if that gets rid of the error and allows ports to be opened..

Which is more secure depends on several factors. FQDN aliases rely on DNS working securely. If you trust the DNS server(s) (as you really have to when using AD) and ideally are using DNSSEC, it is a good solution. I don't know whether pfSense resolves FQDN aliases using DNSSEC, though it is good practice to configure DNSSEC whenever possible. Make sure you test DNSSEC carefully, as it can be tricky to configure correctly. IP aliases are immune to DNS related issues, but can be a maintenance headache as they need to be updated manually following a DNS change. Enforcing restrictions on local users is best done using 802.1x on your switches and having your RADIUS server allocate the user to the appropriate VLAN based on user privileges. Assuming the connection between the switch and your RADIUS server(s) is appropriately secured (a dedicated AAA subnet is recommended), this prevents users working round restrictions by spoofing their local MAC address and/or allocating a static IP address. A user that cannot provide valid 802.1x credentials will be placed in the guest VLAN if you have one configured, or will have no network access at all. For wireless, you can use a similar approach based on WPA2-Enterprise. A suitably configured business grade AP will bridge the user's connection to whichever VLAN was allocated by the RADIUS server. If you wish to have fine grained control over access from the outside than 'whole network' rules, there is really little alternative to rules that use some form of alias, though it is worth remembering that you can create VLANs fairly freely if you have suitable switches.