Thank you DotDash!!

That is not a similar problem at all. Please start a new thread for that.

"failed horribly" how? We tested 2.3.3 on ALIX (I've been running it on my ALIX for months), and we tested upgrading from older versions in various stages (e.g. 2.2.x to 2.3.3, 2.3.2-p1 to 2.3.3). There isn't a way to get back to just 2.3.2-p1 at this stage, since it was an errata release. Fixing your setup to work with 2.3.3 would be simpler.

Exactly what Asus device are you referring to here? Everything I can see that might be an 'AC-1300' is already a router and not pfSense compatible. Steve

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