Yes I just see the port as not open from nmap on a remote server, and from canyouseeme.org or anywhere else. Like I said I've done a bunch of port forwarding, I was just looking for some king of proof before calling to bitch at the ISP, because I didn't think the port forward was wrong, and the fact that some work and other don't all point towards it being their equipment. I was just hoping to have some pingplotter on 8080 type of deal to be able to say "here is every hop this traffic takes and stops at your device, why?" is all.

A simple test is iperf. Remember not to do it to PFSense, but through PFSense.

Simple things first. Try disabling squid.

I ended up wiping the machine and doing a fresh install of 2.3.2 Along with the problems I had already mentioned, the update caused a lot of system instability and strangeness with the system.  I did not have time to troubleshoot and chase down all the issues I experienced, so a fresh install seemed like the best use of my time. After the install I restored to my backup config file I took before the update and now everything is pretty much back to normal (except for two traffic shaping rules I got alerts on which were not causing alerts in 2.2.6) On a side note, I was very happy with how well the restore backup config file worked.  I think next time there's an upgrade I will just wipe the system, install fresh and just restore the config file rather than going down the upgrade path.

Thanks Andrew, I'll have a play in the pfSense GUI later tonight. [2.3.2-RELEASE][admin@pfsense.localdomain]/root: usbconfig -d ugen0.4 dump_device_desc ugen0.4: <huawei mobile="" connect="" huawei="" incorporated="">at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) bLength = 0x0012   bDescriptorType = 0x0001   bcdUSB = 0x0200   bDeviceClass = 0x0000  <probed by="" interface="" class="">bDeviceSubClass = 0x0000   bDeviceProtocol = 0x0000   bMaxPacketSize0 = 0x0040   idVendor = 0x12d1   idProduct = 0x1408   bcdDevice = 0x0100   iManufacturer = 0x0003  <huawei incorporated="">iProduct = 0x0002  <huawei mobile="" connect="">iSerialNumber = 0x0001  <1234567890ABCDEF>   bNumConfigurations = 0x0001 [2.3.2-RELEASE][admin@pfsense.localdomain]/root: ls -l /dev/cuaU* crw-rw–--  1 uucp  dialer  0x74 Aug  9 17:24 /dev/cuaU0.0 crw-rw----  1 uucp  dialer  0x75 Aug  9 17:24 /dev/cuaU0.0.init crw-rw----  1 uucp  dialer  0x76 Aug  9 17:24 /dev/cuaU0.0.lock crw-rw----  1 uucp  dialer  0x7a Aug  9 17:24 /dev/cuaU0.1 crw-rw----  1 uucp  dialer  0x7b Aug  9 17:24 /dev/cuaU0.1.init crw-rw----  1 uucp  dialer  0x7c Aug  9 17:24 /dev/cuaU0.1.lock [2.3.2-RELEASE][admin@pfsense.localdomain]/root: cu -l /dev/cuaU0.0 Connected Manufacturer: huawei Model: E585 Revision: 1026.11.64.18.505sp01 IMEI: XXXXXXXXXXXXXX +GCAP: +CGSM,+DS,+ES OK</huawei></huawei></probed></huawei>

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