That you think you switch is your problem is maybe why your having issues. If this is production use stable version of unifi controller and firmware.  And then lets troublehoot what wifi issues your having if any.

Aye, that's what I assume. As to why I'm stuck, as it doesn't "crash" every time (as if that whole thing wasn't crazy enough already)

Blocked from where to where? Link local is just that: Link local. Link local traffic on the local subnet does not use the firewall at all, nor can it be routed.

@johnpoz: sure that should work. As to trunk depends on how many interfaces you have in pfsense?  If your going to connect a port from switch that is in in each vlan on switch you don't even need to setup vlans on pfsense, only the interfaces.  your switch is doing all the vlan stuff. If you only have 1 interface in pfsense and are going to create the vlans on that physical interface, then yes you need a trunk to that interface from your switch and pfsense will figure out what packets are what based on the tags. i have 3 interfaces wan ( connected to my ONT/modem) lan (switch is connected to this one) opt1( nothing connected just an extra NIC card i had) Sorry im not fully grasping what your saying i plan on having 3 vlans on my switch unless i can connect my AP to my OPT1 and have that be its own VLAN type of thing then i will only have 2 vlans on my switch. what i picked up is if i connect a ethernet cable in each of my vlans to its own interface on pfsense then i dont need to configure VLANS on pfsense but if i plan to only use one cable from my Pfsense to my switch then i do need to trunk the VLANS?

Thanks. Just the info I needed.

The closest you'll see at the moment is how things are now: 2.3.3 is not that far off 2.3.2, but they pull from different package sources. If a package change is pushed to RELENG_2_3, it will be available on 2.3.3 and not 2.3.2, so that is good for development and testing.

We have a 2.3.2_1 release in the works for that. Though we've looked over the list of issues and the only one that appears to be relevant in any significant way is the OCSP issue, and that would only be a potential problem if you have HAproxy or FreeRADIUS configured in a way where they would answer OSCP queries on behalf of clients.

I found the fault on this one. if a domain is added to the bypass list that does not exist, it will stop working, probably a bug.

On Firewall > Rules, Faculty pass traffic to Laboratory. https://doc.pfsense.org/index.php/Firewall_Rule_Basics https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

ntopng has the data i want, but I can not see how to extract it with a command to include the data in the email report, ntopng  cli manpage just looks like configuration options, not extraction options. any ideas?

sorry man, it was about 2am, just before I went to bed.. thanks again for everything.. will let you know when I am ready for the stratum 1 setup.

I bought brand new J1900D2Y ITX server board. Also I have UPS connected via SNMP. I think it's possible to do some scripting on NUT side to select desired modes in PowerD, but I am not sure if this really necessary, may be there is some trick on pfSense/freebsd side?

"Unbound" is a play on "Bind", another DNS server. I guess I'm with you wondering if something is hammering the server when the portal is enabled. Try a packet dump.

I've got the same problem, resetting the modem did nothing so it seems the router actually is stuck, i clicked on the Save button on the PPOE settings page and i guess it initiated a new connection. I've had this problem about 3 times in the last 3 months, this is the first time i've bothered to look. Sep 24 07:44:41 pfSense ppp: [wan_link0] LCP: state change Closed –> Initial Log: http://pastebin.com/raw/LAzNqAUU includes before and after clicking save FreeBSD pfSense.local.lan 10.3-RELEASE-p5 FreeBSD 10.3-RELEASE-p5 #0 7307492(RELENG_2_3_2): Tue Jul 19 13:29:35 CDT 2016    root@ce23-amd64-builder:/builder/pfsense-232/tmp/obj/builder/pfsense-232/tmp/FreeBSD-src/sys/pfSense  amd64

Ok. Thanks for the answer. Yes, I have a very large lists IPv4 in pfBlockerNG ( > 300.000 items ), I will see how to optimizer the lists. Regards. –-- add --- Ok, if I uncheck: "CIDR Aggregation - Optimise CIDRs (not recommended for slow systems with large lists) " in menú Firewall > pfBlockerNG >  pfBlockerNG , all is fine :)

We are receiveing the same error after the 25th interface gets enabled. If we disable it, it's ok. If we enable it (no rules but bogus) the message comes up again.