12.5.1 is GA

Thought I would post on the community that 12.5.1 is now available for download.
Proper Product and Support blog post will come out later this week.

George Grinnell
WatchGuard Representative


  • Install of WSM 12.5.1 on top of 12.5 does not ask what components one wants to be installed.
    Is this expected?

  • I just witnessed a MIRACLE!!!!

    A client's T10 upgraded from 12.5 U1 to 12.5.1 ON THE FIRST TRY without getting the dreaded low-memory error it usually gets.

    I am STUNNED.


    Gregg Hill

  • EGAD! I just upgraded my T35-W, and now the AuthPoint push for logging into the support site fails to show up on my phone when its on my wireless (UniFi access point). It worked fine before on 12.5 U1 firmware.

    UPDATE: It took about 10 minutes after the upgrade, and now the AuthPoint push works again with my phone on my wireless. You had me scared for a bit!


    Gregg Hill

  • Ever since installing 12.15.1 last night, I have multiple internal systems that show Deny in FSM traffic monitor with "msg=tcp invalid connection state" in the line. One is a UniFi wireless access point, one is a Windows 2019 server, one is my Moto G7 cell phone on Android 9, and one is a Roku on its own VLAN. I never saw these in my logs before, and I do not have TCP SYN Checking enabled.

    Restarting the UniFi AP or the Roku, or disabling/re-enabling wireless on my cell phone, results in the denies going away...for a while. After a few minutes, they start showing up again.

    Is anyone else seeing these "tcp invalid connection state" in your logs?


    Gregg Hill

  • edited September 2019

    Looks like a new "reason" message.
    I'm seeing them for what looks like mostly slow HTTPS replies - source port = 443, TCP
    All are Internal Policy denies from External to Firebox.

    Over the last number of releases I have seen lots of TCP source port = 443 denied in my logs. I have never found a reasonable explanation for them

  • Mine are internal devices: the UniFi AP on my LAN reporting back to my Cloud Key controller on its own VLAN on TCP 8080, or internal going to various external IPs on TCP 443 (several AWS IPs, plus others). I just noticed some incoming with the same message, with random high-numbered ports such as 35246, 10983, 36145, etc.

    Gregg Hill

  • The vast majority are the UniFi AP to the Cloud Key UniFi controller. Everything works fine on the wireless and in the UniFi controller; it's just the odd messages.

    Sometimes 8080 hits fine with an Allow, then there will be either one, two, three, four, or five times it shows Deny, followed by another Allow, rinse and repeat.

    Gregg Hill

  • Could be related to this "fix" in the V12.5.1 Release Notes:
    • The Firebox now generates meaningful log messages when it drops packets for a connection it is not aware of. [FBX-16424]

  • Hi, Bruce! It's not just that it a different message; it's a new problem with denying the packets that used to always go through. For example, I just looked, and there were seven lines in FSM traffic monitor from the IP of the UniFi AP. Two denies, one allow, one deny, one allow, two denies. Previously, these all would be Allow lines.

    I restarted the UniFi AP (I am testing with it only because this device is the easiest to test, although other devices have the same issue...Roku, etc.) and its first 8080 line was an Allow at 11:56:27, then Allows through 11:57:43, then the first Deny at 11:59:09, at which point it started the cycle of Allow/Deny again.

    Gregg Hill

  • without logging allowed packets or better yet doing a packet capture, one can't really say that this is a new problem or not.
    Perhaps the packets now shown with this new message were dropped in previous releases and there just was no log message to indicate it.

  • "Previously, these all would be Allow lines." I was already logging allowed traffic.

    The number of lines from this AP and the number for UniFi APs I have at client sites that phone home to my controller are nearly identical, expect that now the majority from this one AP are deny messages.

    I never saw the same ports get denied from the Roku, my server, or others I noted until this build.

    Gregg Hill

  • It is not clear from FBX-16424 if previously the log messages were not meaningful, or if XTM was not always displaying a log message when a packet got dropped, or both.

    The ones that I see are mostly for incoming packets, and mostly for what seems like replies to outgoing HTTPS sessions.
    There is 1 example:
    2019-09-12 16:11:54 Deny xxx.xxx.xxx.xxx 48734/tcp 443 48734 0-External Firebox Denied 40 53 (Unhandled-External-Packets-00)
    2019-09-12 16:11:54 Deny xxx.xxx.xxx.xxx 48734/tcp 443 48734 0-External Firebox tcp invalid connection state 40 53 (Internal Policy)
    2019-09-12 16:11:54 Deny xxx.xxx.xxx.xxx 48734/tcp 443 48734 0-External Firebox tcp invalid connection state 40 53 (Internal Policy)

  • Sorry, Bruce, I seriously need some sleep. Something you mentioned a few posts back FINALLY clicked in my head...the destination interface is "Firebox" on each of the Deny messages, whether an internal source IP or external source IP!

    Each of the internal "tcp invalid connection state" Deny messages is when a device on my network tries to reach an IP on a different VLAN or an external IP that they normally communicate with just fine, and suddenly they pop in a few of those Deny lines to the Firebox, and then go off to the same targeted IP that just got denied and get the expected Allow line.

    Here are two lines from my Roku:

    2019-09-12 13:46:33 Deny src_ip= dst_ip= pr=https/tcp src_port=38224 dst_port=443 src_intf=3-VLAN3-CellPhonesTabletsRoku dst_intf=Firebox msg=tcp invalid connection state pckt_len=52 ttl=64 policy=(Internal Policy) proxy_action= proc_id="firewall" rc="101" msg_id="3000-0148" tcp_info="offset 8 AR 4082266954 win 176" Traffic

    2019-09-12 13:46:33 Allow src_ip= dst_ip= pr=https/tcp src_port=38224 dst_port=443 src_intf=3-VLAN3-CellPhonesTabletsRoku dst_intf=0-External msg=Allowed pckt_len=83 ttl=63 policy=(UnrestrictedAccess.Out-00) proxy_action= proc_id="firewall" rc="100" msg_id="3000-0148" src_ip_nat="" tcp_info="offset 8 A 4082266923 win 176" geo_dst="USA" Traffic

    In each case, it tries to reach dst_ip=, BUT the interface it tries to reach is "Firebox" on the Deny, and it's "0-External" on the Allow lines.

    For the UniFi AP, its destination interface is normally "6-VLAN6-CloudKey" but it's "Firebox" on the Deny lines.

    Too much in my brain now. Need Starbucks!

    Gregg Hill

  • What I don't get is why the Firebox suddenly becomes the target interface, when the packets are clearly sent to a particular IP address either external or on a VLAN. Also, why would it get an Allow to a particular IP address either external or on a VLAN and then Deny some to Firebox, then go back to Allow, then Deny again, rinse and repeat, all day long?

    Gregg Hill

  • Firebox is an alias for any firewall interface.
    My guess that this is hard coded as Firebox for the generation of the deny message.
    The log messages do not show any of the TCP flags on the packet and without that info it is hard to tell if the deny is justified and if the packet is different from the allowed packet.

  • Looks like a job for something like WireShark..

    Adrian from Australia

  • Looks like a job for Superman!

    Gregg Hill

  • I am opening a case for it now.

    Gregg Hill

  • Case - 01282162 has been opened, verified, and escalated.

    Gregg Hill

Sign In to comment.