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

@johnpoz: "but i am unable to ping any computer/servers on the LAN side with 192.168.0.x addresses." Well yeah, why would you think you would be able to – since that 192.168.100 network is on the wan side of pfsense and would be hostile just like a public IP.. So unless you setup a port forward its blocked by default.  Also there is default rule to block all rfc1918 addresses even if you setup a port forward. If you want to use pfsense, You should really bring your wireless behind pfsense.  Get another wifi router and use it as AP, and disable wifi on your isp device.  Or get a real AP and again disable wifi on your isp device. I would also suggest changing your isp device to bridge or just modem mode so that pfsense gets your public IP right on your wan.. Thanks for the feedback, I did some reading and now I fully understand what is required. I will now act on your input/feedback and my reading. Thanks Again.

Yes.  Exposing the WebGUI to WAN is not the best choice when you have OpenVPN right there, built-in for free.  Use it.

Very true.. Some isp device might have filters put in place..  But seems odd that they would filter multicast traffic between switch ports.  But possible they might of done that between the wifi and the wired.. Not a fan of any of the devices where you put multiple technologies into one box..  Switch should be your switch, wifi should be AP(s) connected to your switch ;) and your router/firewall should be just that your firewall/router.  This way you don't run into any inconsistencies to how things work like a switch blocking multicast unless you specifically set it to do that, which any decent smart/managed switch would allow you to do. For example I have a low end smart netgear switch that allows you to enable igmp snooping, but can not limit or pick which ports that is enabled on etc.  Its either on or off for everything.  While my cisco switch gives me full control over stuff like that.

^What he said. You can also try Dansguardian, although it's mostly used for managing access to sites rather than direct proxying per se.

Also update my server address to the CN as per the certificate generated by ClearOS, still no luck…. :(

How are you checking the MAC address? Did you perhaps enable MAC spoofing in the interface options? Your ISP appears to only accept DHCP requests from verified MAC addresses, am I wrong?