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.

^ who would of thunk that you would need a firewall rule to allow access… [image: zx4pom.jpg]

Changed ruleset to: pass a particular rule according to daytime schedule pass another rule according to daytime schedule etc and got rid of the: block according to nighttime schedule and it appears to work judging by the complaints I got when the daytime schedule ended. Thanks everyone.

@cmb: No need to have anything USB plugged in at all. PixArt seems like a mouse, maybe your mouse is flaky and is causing itself to disappear and reappear repeatedly. I unplugged the keyboard and mouse rebooted the pfsense machine message has went away thanks for the help i'll have to look into maybe getting a different keyboard or mouse depending on which one is causing it I'll plug them in one at a time and reboot the machine and see which one is giving me the issue. Thank you for replying to my post and giving me help.

No response at the console is probably because something/someone turned on scroll lock inside the VM (hit the up arrow to confirm, screen will scroll back if scroll lock's on).

@bruor: I use an ISP that has a seemingly half baked IPv6 implementation which is also impacted by a bug in pfSense. This problem is already under discussion in the IPv6 forum. @bruor: From time to time this will not work,  and that is because pfSense has multiple dhcp6c instances running which causes xid mismatch errors and requires me to shell in,  kill the processes, and restart the wan interface. Is there a client command that I can use in a script to get the wan interface to reconnect? As I just posted in that thread: /usr/local/sbin/ppp-ipv6 pppoe0 down ; pkill -xf '^.*dhcp6c.*pppoe0$' ; sleep 2 ; /usr/local/sbin/ppp-ipv6 pppoe0 up This attempts to bring down the IPv6 connectivity on pppoe0 cleanly, kills off any remaining dhcp6c instances for pppoe0, waits 2 seconds, then restarts IPv6 on pppoe0. Read the full thread for more information.