The idea is to prevent anything blocking while doing the update.

Note: The problem does not always occur with ICMP rules. It is only if the rule has no other "clue" as to whether it is for IPv4 or IPv6. Rules that have a gateway, or are on an interface (like WAN) that has an IPv4 gateway will load OK. If you have a rule that gives you this trouble, then be careful when you edit it. If it had particular icmp-types selected, those will not get selected automatically in the edit screen. You will need to make sure to re-select those before pressing Save.

So why 3 times - good luck or something ;)  Maybe you have OCD? ;) And what exactly is the AP, and is that just a dumb switch?  Does your client not get an IP?  You sure that is just an AP and not some wifi router doing nat??  Or running its own dhcp server? Maybe your laptop is connecting to the wifi across the street?  Love to help but without something to go on - my guess is you didn't turn on the wifi on your laptop ;)

@chpalmer: What kind of connection to the web do you use? I use multiple connections with gateway groups. In update to this problem, it does indeed appear to the traffic shaping.  When the traffic shaping is on, problems, when it is not, good. I might try to rebuild my traffic shaping rules after the update and see if that helps.  For now, I'm going to leave it off until I can investigate further.

Has nothing to do with Suricata if you can ping/access it via SSH. Is nginx running? Does it listen on port you are trying to access? Perhaps try with a different browser.

@doktornotor: We have sites where ping to 8.8.8.8 is rate limited. We have sites where it's blocked by Google. I wouldn't use that for monitoring. Not reliable/useful. While what you say is valid point, I have been using google DNS for several months with no issues. I preformed an upgrade and have had issues. Google blocked / rate limited me on the same day I upgraded? I just swapped my gateway monitors, my Comcast was using 8.8.8.8 now its 8.8.4.4 and swapped my other internet from 8.8.4.4 to 8.8.8.8. I still get packet-loss that is miss reported.

@jimp: The create/restore full backup scripts were removed a long time ago. They were no longer useful, and could leave the system in a messy inconsistent state. Thanks Jim, Since I got my SG-4860 (with factory load and fresh package load/configure) it seems every package update has come with some level of grief.  I was just looking for another safety net on this core program update.  Duly noted. Rick

That message usually means it's trying to contact something on that interface that isn't actually on that interface. For example if the interface subnet is y.y.y.0/24, but it's trying to find x.x.x.x on that interface using ARP. You need to look at the interface configuration, interface status ("ifconfig -a" output is preferable) and compare it to what you see in the routing table (Diag > Routes, or "netstat -rWn") and see if it has a proper link route. You might see that in some cases if an address was on an interface and then disappeared. Resetting states for that address might also help.

Getting 10/10 generally means everything is fine. That site does a bunch of tests for IPv6. Getting 10/10 is supposed to mean it all worked. Maybe just ipv6.google.com doesn't work? Maybe post your radvd.conf file. You can get it from the console, SSH, or Diagnostics -> Command Prompt by running: cat /var/etc/radvd.conf One other thing I thought of: every time I reboot I have to go to WAN and resave the interface to get IPv6 actually working. Happens with 6rd and DHCP6-PD. Go to Interfaces -> WAN. Click save, click Apply. See if that helps. As for the MTU stuff, I don't think it's related to your issue anymore but you can run these commands on the console (SSH) to get & set the MTU of wan_stf to 1480 (I do this for performance reasons). I would recommend not messing with the MTU until after your issue is resolved. ifconfig wan_stf mtu 1480 netstat -r -n find each destination with an entry in the Netif column that belongs to wan_stf route -6 change <destination> -mtu 1480 route -6 get <destination></destination></destination> Again, not sure why 2.3.3 would make a difference for you. Everything is pretty much the same for me (including IPv6 not working until I resave the WAN interface).

Early as it starts, the console will give you a prompt to press 1 or 2 to select/switch the boot slice (I think it says F1 or F2, but you actually press the normal ASCII 1 or 2 number key)

Must be the butterflies encountering no loss of separation today. :P

Of course this is possible with pfSense, but you may need to invest time (and money) to make it work properly. In my experience, most WIFI adapters won't work (properly) in pfSense. I guess this is because of the FreeBSD base. FreeBSD doesn't seem to support WIFI adapters as good as for example Linux. The solution I'm using is to use WIFI routers in "Client Mode", and use the LANs of these routers as WANs in pfSense (this means "Double NAT", which isn't a real problem IMO). My setup is working like this: one ADSL line (main WAN), and two TP-Link Archer C7 v2 with DD-WRT in Client Mode as Load Balance/Failover WANs. All of these are connected to a switch with seperate VLANs for LAN and each WAN. In pfSense several Gateway Groups are setup to utilize the different WANs, and traffic is forwarded to these Gateway Groups with firewall rules. The system is working very well, but it's a rather complicated (and expensive) setup because of the many different devices involved. On the plus side, it's easy to change the WIFI networks the routers connect to, or swap the routers for other models (3G/4G routers for instance).

Also, when the user edits an old rule that has no 'ipprotocol' tag in the XML, the ICMP types listed in the XML are not automagically selected on the rule edit GUI. So the user can easily press Save without noticing and lose the previously-selected values. Issue: https://redmine.pfsense.org/issues/7300 PR: https://github.com/pfsense/pfsense/pull/3573

I would just set the Comcast gateway to bridge mode and disable its internal firewall (or setup a rule to pass all if it can't be disabled). That way you just have pfSense manage everything.

My username is accepted at the Portal. Everything is in lowercase So that is NOT the problem.