Put it in /etc/rc.conf.local

Hehe!  :P I'll try to make it it a bit better than. 8)

Two possibilities: 1. The disk is actually full. On NanoBSD, perhaps, on a full install, possible but less likely 2. The disk is dead/dying and the OS is unable to contact the disk. Check the console, it should have a much more informative error if it's a dying disk (lots of ATA/DMA/CAM type errors)

CCTV systems have notoriously weak security. Ask yourself: Would you really want someone (not you) to be able to view your cameras over the Internet? Leaving such a system exposed is a ticking time bomb. Adding a VPN is pretty easy (especially OpenVPN), and eliminates the possibility that a vulnerability in your CCTV device will expose your cameras (and perhaps your entire LAN) to an attacker. Save yourself the potential headache and don't port forward that traffic. VPN all the way, every time.

All the certs would be stored in cert section of the all xml you downloaded, all the ca's you have would be in their own ca sections. You are correct there is no backup and restore listed for only these sections, so you would have to edit the xml by hand to put your backup in if you don't want to use the ALL, etc.  You could put in a feature request to all all the different individual sections of the xml to be individually restored or backed up.

Thats not a problem with UPS control, more a repo issue and its hardly representative of NUT historically. Im sure it will be fixed shortly.

Hi .. what are you using as a shebang path in your script? (the #!/ line at the top).  If you've got that wrong then your script won't execute. AFAIK unless you have modified your system your choices are #!/bin/sh or #!/bin/tcsh  - If you are using something from linux bash will NOT work on an unmodified system. Have a look at this post: https://forum.pfsense.org/index.php?topic=116494.0  - I had the same problem, although it was with python and not shell, but it's pretty much the same thing.  Modify your script to runs minicron and see if the error shows up in the log.  If it doesn't you can be pretty sure your shebang path is wrong. Good luck.

So make a bridge. One member interface will be lan1_vlan201, one will be lan2, and the other lan3. I've done it. It works. Bridge traffic will be tagged with ID 201 on lan1 and untagged on lan2 and lan3. I, too, would use a switch since you want a switch and pfSense is not a switch. https://doc.pfsense.org/index.php/Interface_Bridges

Thanks w0w… very useful, that gave me what I needed to figure it out. The issue was that python was not executing. The so called "portable" shebang that worked at the command line #!/usr/bin/env python2.7 - DOES NOT WORK from cron. I created the following file as /home/custom/bin/tcron #!/usr/bin/env python2.7 import os os.system('/usr/local/bin/minicron') When run from the command line, it put the minicron error into the log every time it is run, but did nothing when run from cron. I changed #!/usr/bin/env python2.7 to #!/usr/local/bin/python2.7, and now it works. I don't know if this is intentional that #!/usr/bin/env python2.7 doesn't work from cron, but for now I'm not going to worry about it. I hope by documenting this it might save somebody else the same trouble, and if it's a bug that should be reported, someone who knows how to do that will do so.

@Harvy66: HTTPS proxies are bad ideas. There have been attacks over the years that take advantage of the proxy blindly signing content. You mean "transparent HTTPS proxy with SSL-Bump" isn't it?  ??? Because HTTPS proxy with explicit proxy without MITM (SSL-Bump) doesn't exhibit behaviour you (rightly) describe  ;)

im trying to do exactly this. If you just use the unifi captive portal, you need a dedicated computer to run the captive portal on, which is why i want to use pfsense. I can customize the pfsense CP more, and i dont need to sit a second computer on the lan to run it.

Check: https://forum.pfsense.org/index.php?topic=110043.0

iPhone tethering discussion: https://forum.pfsense.org/index.php?topic=114559.0

Following the suggestion on this thread : https://forum.pfsense.org/index.php?topic=101587.msg617211#msg617211 I set WAN to flowcontrol, master and LAN to master.  This eliminated the watchdog timeout, and reduced the frequency of the discard frame from every 3-4 hours to roughly 11 - 12 hours. I will try disabling driver options and see what happens

Yeah kind of need to see when it disconnects and its going to show it trying to reconnect, etc. You could even bump up the logging level, verbosity in the vpn client settings as precursor.. You may want to increase the number of lines you can view in the log, and or even send your logging to syslog so you don't loose anything, etc. You can always view the actual logs vs what is presented in the gui.. But just blindly rebooting is not good idea..

@justsomeguy6575: Did you get this resolved with new network cards? I'm having this exact issue using D-Link DGE-530T cards. I believe it only started after a recent update to 2.3.2 as I hadn't experienced this before. I haven't had a chance to revert back to an older version to test yet but probably will this weekend. Unfortunately not… I received the Intel 3 days ago, I did a fresh install of the stable build with no luck. After that, I tried to install the 32bit stable version and the PC did not boot :p :p I finally fresh installed the 64bit daily snapshot which appears to have a little bit better performance. I tried to play with the QoS and I realized that if I find the way to find tune it, I will solve the problem. I'm looking for a guide for a simple QoS but I can't find something complete and for beginners...