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.

Out of box pfsense nats.  So for you to access something behind pfsense you would have to port forward the ports you want and where you want to send it on your lan 192.168.2/24 network. You would then access pfsense wan IP on that port, pfsense would forward that traffic to your VMs behind pfsense on their 192.168.2 IP Your other option which would be to turn off nat on pfsense.  Now your just firewalling/routing - so you would just create firewall rules to allow the traffic you want from your local network into your lan behind pfsense, and same thing for traffic from your lab into your lan. Hope you understand that in your setup your lab out of the box would have full access into your local network, unless you modified the lan rules on pfsense? If you disable nat on pfsense, keep in mind that your actual router/gateway for your local network that gives you access to the internet would have to allow for and nat your lab network (192.168.2/24)  You also run into a asymmetrical routing issue that way.  So prob better off to just keep natting and use port forwards into your lab.  But if you don't want your lab having access to your local your going to have to adjust the lan rules in pfsense. The best solution would be to just replace your actual router with pfsense so now both your networks are behind pfsense on different segments and you just firewall between them to limit access.  This can be done with pfsense on VM.  It is much easier if the vm host pfsense will be put on is dedicated vs your workstation.  But can be done both ways.

@johnpoz: huh?  if firefox is your browser of choice why would you not use that to admin pfsense?? Well as you asked…. I run daily with several dozen firefox tabs for my regular "work". I also have lots of other applications open. It was useful to have the pfsense dashboard and logs on a totally different browser so that I could quickly locate it on the taskbar. Actually I am still using it for this, but given the above am doing changes to config in firefox.

@johnpoz: Dude I brought that up much earlier in the thread.. ;) " If he can not ping, then either clients blocking it not answering.  He has a mask issue on this network between clients and pfsense.  Or he has some sort of connectivity issue be it at layer 1 or 2." Glad you got it sorted.. I admit I am kinda overwhelmed with other stuff here, wearing too many hats  ;) Thanks so much for helping out.

while your device might default to all trunk..  I am at a loss to why, this is bad choice on their part if you ask me.  There is no reason for those ports to be in trunk unless they are going to care more than 1 vlan. Understanding Access and Trunk Interfaces Ethernet interfaces can be configured either as access ports or a trunk ports, as follows: An access port can have only one VLAN configured on the interface; it can carry traffic for only one VLAN.     A trunk port can have two or more VLANs configured on the interface; it can carry traffic for several VLANs simultaneously. From cisco page http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5000/sw/configuration/guide/cli/CLIConfigurationGuide/AccessTrunk.html what I would do with your default setup is change all the ports to ACCESS.. Unless your going to have other switches connected to it, AP with vlans or to a router with vlans on a physical interface ports should be in access mode.  Trunk ports are for 1 going to take longer to come up.  There is zero point to leaving your ports in trunk unless they need to carry tagged traffic. Its possible the ports default to auto mode and try to determine what they should be, if they have issue figuring that out they might default to trunk mode.  I would have to dig deeper into why your ports are all trunk after a factory reset. https://supportforums.cisco.com/discussion/12476171/switch-port-modes Lets be clear your ports should ALL be access, Unless your going to link to another switch or AP or to a port on a router that will have multiple vlans on it. We could also debate the use of the default vlan 1.  In an enterprise/security setup this is normally a big no no.  You would set different vlan other than 1 to use for management and all ports would be moved to a holding vlan other than 1 until they need to be placed in the vlan they will be used for.  This is to keep mistakes from happening since switches all come up with default vlan 1, so if you do not turn off all your ports they would all be in the default vlan - so in this scenario it would be possible that someone might connect and be on a network you don't wan them in and be able to access resources your management of your infrastructure, etc.. In a HOME setup to me this just adds complexity for no reason.  I don't see a problem with just leaving your main lan and even management of your devices all in your default lan, which would be vlan 1.  But just be warned that from a pure security standpoint its bad practice to do that.  You might get suggestions to change your management vlan, and don't use vlan 1.  This way if you forget to configure a port or something worse case someone connects they are connected to nothing else, etc. Good security practice is also to disable all ports that are not in use..  Ie admin down them until such time they are need.  But we are talking a HOME network..  Which just adds more work when you want to plug something in ;)  Which is prob not something you want to do.  I would suggest you put all your ports into the vlan your going to use most often when you plug in a new device.  The will most likely be your lan and its ok to leave that as just default vlan 1.  Unless your worried about people coming into your home and plugging stuff in and being on your lan? ;)