Thanks Mr. Derelict - that was shutting the gate after the herd of cattle had bolted  :) The Squd thingy seems to be working fine … I've deliberately taken a step backwards and I'm using a single AP now.  I'll close this thread now and I'm going to ask some more questions in the wireless forum.

I doubt anything is being blocked, but you haven't provided much information to go off. It could be bad traffic shaping, possibly IPv6, or you just have a slow connection compared to what they're used to. It could very well be a configuration issue (dependency management is a fun game to play) on their local machine, for instance: https://github.com/bower/bower/issues/2014 I've had issues with git being slow before, and it turned out to be an ipv6 issue and I had to use the -4 flag until it was resolved (although I've slept since then and don't remember how it was resolved). happy troubleshooting!

Very informative!  Thank you!

Sending your config via e-mail is highly insecure and a questionable practice. There are much better ways to accomplish regular backups: https://doc.pfsense.org/index.php/AutoConfigBackup or https://doc.pfsense.org/index.php/Remote_Config_Backup But that's a topic for new different thread.

Thanks. I'll disable pfsync until you have a fix out. Seems to be the lesser of two evils and only connection-oriented sessions (RDP, ssh and such) will have to be manually reconnected on a failover which is tolerable. Thank you for the quick assistance! Lars

@johnpoz: So when you mean they can no longer resolve stuff or can not access public IPs and resolve just fine?  My guess would be your using multiple dns servers one that can resolve public, and other than can not - like your AD server maybe? The machines can not access public IPs, but resolve just fine… I still can ping any URL, while no page are showing, giving timeout error. Just the pfSense is the DNS Server. @johnpoz: On these clients try and resolve www.google.com via either ping?  Or nslookup or dig or whatever your fav dns query tool is.  Does that not work?  What dns is pointing to - nslookup or dig will tell you that. If they do resolve try pinging something on the outside say 8.8.8.8 does that not work? I can ping and resolve google.com and 8.8.8.8 or anything outside…. Nslookup return the pfSense IP.

This issue stopped for a while and it just started again today. Sep 15 15:39:27 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:39:27 xinetd 9901 readjusting service 6969-udp Sep 15 15:39:27 xinetd 9901 Swapping defaults Sep 15 15:39:27 xinetd 9901 Starting reconfiguration Sep 15 15:39:26 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:39:26 xinetd 9901 readjusting service 6969-udp Sep 15 15:39:26 xinetd 9901 Swapping defaults Sep 15 15:39:26 xinetd 9901 Starting reconfiguration Sep 15 15:39:26 check_reload_status Reloading filter Sep 15 15:39:26 php-fpm 63247 /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.1) (interface: LAN[lan]) (real interface: sk0). Sep 15 15:39:26 php-fpm 63247 /rc.newwanip: rc.newwanip: Info: starting on sk0. Sep 15 15:39:25 check_reload_status Reloading filter Sep 15 15:39:25 check_reload_status rc.newwanip starting sk0 Sep 15 15:39:25 php-fpm 63247 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:39:24 kernel sk0: link state changed to UP Sep 15 15:39:24 check_reload_status Linkup starting sk0 Sep 15 15:38:03 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:38:03 xinetd 9901 readjusting service 6969-udp Sep 15 15:38:03 xinetd 9901 Swapping defaults Sep 15 15:38:03 xinetd 9901 Starting reconfiguration Sep 15 15:38:02 check_reload_status Reloading filter Sep 15 15:38:02 php-fpm 63247 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:38:01 kernel sk0: link state changed to DOWN Sep 15 15:38:01 check_reload_status Linkup starting sk0 Sep 15 15:31:42 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:31:42 xinetd 9901 readjusting service 6969-udp Sep 15 15:31:42 xinetd 9901 Swapping defaults Sep 15 15:31:42 xinetd 9901 Starting reconfiguration Sep 15 15:31:41 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:31:41 xinetd 9901 readjusting service 6969-udp Sep 15 15:31:41 xinetd 9901 Swapping defaults Sep 15 15:31:41 xinetd 9901 Starting reconfiguration Sep 15 15:31:41 check_reload_status Reloading filter Sep 15 15:31:41 php-fpm 39526 /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.1) (interface: LAN[lan]) (real interface: sk0). Sep 15 15:31:41 php-fpm 39526 /rc.newwanip: rc.newwanip: Info: starting on sk0. Sep 15 15:31:40 check_reload_status Reloading filter Sep 15 15:31:40 check_reload_status rc.newwanip starting sk0 Sep 15 15:31:40 php-fpm 56830 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:31:38 kernel sk0: link state changed to UP Sep 15 15:31:38 check_reload_status Linkup starting sk0 Sep 15 15:28:30 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:28:30 xinetd 9901 readjusting service 6969-udp Sep 15 15:28:30 xinetd 9901 Swapping defaults Sep 15 15:28:30 xinetd 9901 Starting reconfiguration Sep 15 15:28:29 check_reload_status Reloading filter Sep 15 15:28:29 php-fpm 56830 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:28:28 kernel sk0: link state changed to DOWN Sep 15 15:28:28 check_reload_status Linkup starting sk0 Sep 15 15:18:29 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:18:29 xinetd 9901 readjusting service 6969-udp Sep 15 15:18:29 xinetd 9901 Swapping defaults Sep 15 15:18:29 xinetd 9901 Starting reconfiguration Sep 15 15:18:28 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:18:28 xinetd 9901 readjusting service 6969-udp Sep 15 15:18:28 xinetd 9901 Swapping defaults Sep 15 15:18:28 xinetd 9901 Starting reconfiguration Sep 15 15:18:28 check_reload_status Reloading filter Sep 15 15:18:28 php-fpm 91971 /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.1) (interface: LAN[lan]) (real interface: sk0). Sep 15 15:18:28 php-fpm 91971 /rc.newwanip: rc.newwanip: Info: starting on sk0. Sep 15 15:18:27 check_reload_status Reloading filter Sep 15 15:18:27 check_reload_status rc.newwanip starting sk0 Sep 15 15:18:27 php-fpm 34083 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:18:25 kernel sk0: link state changed to UP Sep 15 15:18:25 check_reload_status Linkup starting sk0 Sep 15 15:15:48 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:15:48 xinetd 9901 readjusting service 6969-udp Sep 15 15:15:48 xinetd 9901 Swapping defaults Sep 15 15:15:48 xinetd 9901 Starting reconfiguration Sep 15 15:15:47 check_reload_status Reloading filter Sep 15 15:15:46 php-fpm 34083 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:15:45 kernel sk0: link state changed to DOWN Sep 15 15:15:45 check_reload_status Linkup starting sk0 Sep 15 15:12:25 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:12:25 xinetd 9901 readjusting service 6969-udp Sep 15 15:12:25 xinetd 9901 Swapping defaults Sep 15 15:12:25 xinetd 9901 Starting reconfiguration Sep 15 15:12:24 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:12:24 xinetd 9901 readjusting service 6969-udp Sep 15 15:12:24 xinetd 9901 Swapping defaults Sep 15 15:12:24 xinetd 9901 Starting reconfiguration Sep 15 15:12:24 check_reload_status Reloading filter Sep 15 15:12:24 php-fpm 69749 /rc.newwanip: rc.newwanip: on (IP address: 192.168.1.1) (interface: LAN[lan]) (real interface: sk0). Sep 15 15:12:24 php-fpm 69749 /rc.newwanip: rc.newwanip: Info: starting on sk0. Sep 15 15:12:23 check_reload_status Reloading filter Sep 15 15:12:23 check_reload_status rc.newwanip starting sk0 Sep 15 15:12:23 php-fpm 69749 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:12:22 kernel sk0: link state changed to UP Sep 15 15:12:22 check_reload_status Linkup starting sk0 Sep 15 15:10:06 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 15:10:06 xinetd 9901 readjusting service 6969-udp Sep 15 15:10:06 xinetd 9901 Swapping defaults Sep 15 15:10:06 xinetd 9901 Starting reconfiguration Sep 15 15:10:05 check_reload_status Reloading filter Sep 15 15:10:05 php-fpm 69749 /rc.linkup: Hotplug event detected for LAN(lan) static IP (192.168.1.1 ) Sep 15 15:10:04 kernel sk0: link state changed to DOWN Sep 15 15:10:04 check_reload_status Linkup starting sk0 Sep 15 14:51:47 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 14:51:47 xinetd 9901 readjusting service 6969-udp Sep 15 14:51:47 xinetd 9901 Swapping defaults Sep 15 14:51:47 xinetd 9901 Starting reconfiguration Sep 15 14:51:46 xinetd 9901 Reconfigured: new=0 old=1 dropped=0 (services) Sep 15 14:51:46 xinetd 9901 readjusting service 6969-udp Sep 15 14:51:46 xinetd 9901 Swapping defaults Sep 15 14:51:46 xinetd 9901 Starting reconfiguration ```. I wonder if something on the network is causing this. Anyone else experiencing this?

Well yeah stun is going to try and transverse your nat ;)  Which I take is something you don't want it to do ;)  There is a way to disable webtrc in chrome browser, you could try doing that and see if that reduces your hits.. Guess your other option is just not log it..  You could still allow for dns and or quic, etc.  but all other unknown UDP just drop it in the bin without logging.

did you validate that your actually getting back the icmp unreachable message on your wan? So your lan rules are any any?  So your probing IPs you control on the public internet and you know they send back icmp redirects when hit on nonlistening/closed port? As I showed many firewalls will not do that.. Since then every single noise packet they get would generate a icmp answer..  That would be bad! ;)  You need to validate that your packet is getting to the server from the client, and then validate it is actually sending back an icmp redirect and pfsense is seeing it on its wan.  If it does then yes it should send that back into your client that created the traffic.  As you can see from my above traceroute test.

I should have asked what model the Netgear was from the start.  I assumed it was an R7000 or something similar, since those tend to be the most popular.  Or at least a relatively recent model. I doubt that Netgear Router you own has AP mode. What is the model number of the TWC equipment you have?  Can you confirm that it is a Modem/Router combo, or could it just be a Modem?

If I had to guess part of his problem could be related to running multiple layer 3 networks over the same layer 2.  There is a thread about that, and then there is also a thread about using the forwarder or the resolver what is the difference and using forwarder for cp, etc.  There there is a thread that mentions trying to go to https sites first before auth to the cp. Im with jimp though you need to post up the actual details of your CP issue.  You have multiple things going on it seems, trying to use squid and the cp from one thread is another possible issue. If you post up the full details, what packages your using how you have your network setup and your captive portal setup and what is not working with it.. Sure there are plenty of people here to work through your issues with you.

curl is in the base system, so is fetch. For most thing you'd need or want wget for on a firewall, fetch is fine, and curl will work if fetch will not. There's really no need for wget.

No, it is not possible for pfSense to act as a PPP server and route networks in that fashion.

Resetting the password is usually fairly simple, the other errors you show indicate your system has a far more serious problem. Likely you can't login because of a problem with the filesystem. Even after running fsck a few times (keep running it until it returns no errors!) it's still possible there are missing files or files with corrupted or missing contents. Reinstall and restore the config from a backup. It's also possible your disk has a problem, but reinstall first. If problems continue, replace the disk and try again. If you don't have a backup, choose "Rescue config.xml" in the installer, if it fails, reboot and try "Rescue config.xml" again (and again). If it doesn't work after 3-4 tries then you'll have to start with a blank config.

I'm not sure what your problem is.  You don't seem to have excess fragmentation.  You could try swapping out the NIC and see if it goes away but I have no other suggestions.

not one replay!!

As it is now my switch (TP-8port) is just on it's default setting: VLAN 1. The TP is connected to the LAN (NIC 2) interface on pfSense box. NIC 1 is WAN NIC 3 is Unifi AP connected with VLAN 100 (Private WLAN), VLAN 200 (Shared WLAN), VLAN 300 (Guest VLAN). Would I be able to set the switch up to do IGMP across VLANS like my current setup as in VLAN100,200,300 talk together when doing IGMP on the switch? Thanks mate! Well, as a first step I would configure all VLANs in the switch too. Just add 100,200,300 as VLANs in the switch. Designate two ports (say port 7 and port8) to have all three VLANs tagged. Designate first one port (say port 6) to be in VLAN 100 untagged, and set PVID also 100. In the switch's IP settings, where you set the IP address of the switch, set management VLAN to 100. Now unplug your UniFi from pfSense, and plug it in port 7 of the switch. Also connect port 8 of the switch to where UniFi was on pfSense. Unplug the switch from NIC3 of pfSense, you won't need that anymore (and you won't need the bridge in pfSense either). You can now access the switch through UniFi through VLAN100 directly, not around through the bridge! You can now safely set the rest of the ports in the switch to any vlans, say VLAN 100 untagged (and PVID 100 too!). From this on, proceed with Multicast configuration as described in the FAQ section I linked above.

well patience wasnt a virtue here, reloaded and back to normal for now. Just need to figure out exactly what i did to gum and since i am not taking backups yet since i am still learning this has been a good experience reconfiguring everything :-). Glass half full for sure….....