tcp invalid connection state

Fred2KFred2K
in Firebox - Other

My M270 is throwing back the error **tcp invalid connection state **for a printer which is trying to send outbound emails. I have a rule to allow TCP traffic on port 587 which works for about 20 other printers... but with this one I'm seeing this error.

Have googled it but there's not much info on it.

Comments

  • Bruce_BriggsBruce_Briggs

    There was a discussion about this log message here:
    https://community.watchguard.com/watchguard-community/discussion/457/12-5-1-is-ga

    Please post a sample log message showing this.

  • Fred2KFred2K

    Hi Bruce. Yeah, I spotted that thread, but there didn't seem to be any conclusion. I am running 12.5.1 though, so perhaps it's related to the firmware. Her's a sample form WG Dimension:

    FWDeny, tcp invalid connection state, pri=4, disp=Deny, policy=Internal-Policy, protocol=submission/tcp, src_ip=192.168.134.140, src_port=39575, dst_ip=40.100.174.226, dst_port=587, src_intf=1-Trusted, dst_intf=Firebox, rc=101, pckt_len=646, ttl=60, pr_info=offset 5 AF 2603074243 win 54784, 3000-0148

  • greggmh123greggmh123

    You have the same issue I noted. The target is dst_intf=Firebox and the messages are bogus. I get that randomly from internal devices that are working perfectly fine and random external messages. It started with 12.5.1 and apparently those message have always existed, but were not shown in traffic monitor.

    Gregg Hill

  • greggmh123greggmh123

    Fred2K,

    Do you have logging enabled for the outbound 587 rule? If not, enable it, and I bet you'll see allowed traffic from the printer that is throwing the deny messages that hit the dst_intf=Firebox target. If the printer works to send on 587, ignore the messages. I have an open case on it with a request to allow disabling logging of those bogus messages. My perfectly-working UniFi wireless access points seem to throw these logs a lot...there are four or five for each successful outbound packet to my UniFi controller, whether it's my LAN or a clients' remote AP phoning home (their Fireboxes show the same thing).

    I ignore all of those message as they are utterly meaningless.

    Gregg Hill

  • Bruce_BriggsBruce_Briggs

    An invalid packet is packet that does not belong to any already established connection, and is not a connection establishing packet.

    Some things which can cause this is when the session times out in the firewall or when the session is ended abruptly by the session initiator, such as when a user hits refresh on their web browser.
    Neither of these things seem likely in your case.

    To find out more about this, you really need a packet capture to see the full packet flow from/to the printer.
    You can do this from the firewall using TCP DUMP - from the Web UI of Firebox System Manager.
    Example:
    Advanced Options Arguments = -i eth0 host 10.10.1.1

    Consider opening a support incident on this for more help.

    Also, in V12.5.2, there is this fix, which may help. No further info on the issue which is fixed by it.

    FBX-16918 This release resolves an issue with very specific connections with packet filter policies.

  • Fred2KFred2K

    Thank you both for the suggestions. I enabled logging on my port 587 policy and ran another test - it's being allowed:

    2020-01-28 10:55:37 FWAllow, Allowed, pri=4, disp=Allow, policy=SMTP-TLS-Email-out-00, protocol=submission/tcp, src_ip=192.168.134.140, src_port=37274, dst_ip=52.97.146.2, dst_port=587, src_ip_nat=81.144.129.90, src_intf=1-Trusted, dst_intf=0-External, rc=100, pckt_len=48, ttl=59, pr_info=offset 7 S 3288430083 win 2105, 3000-0148

    There was no invalid connection state message to go with it, so sounds like it was a red herring and not linked to my issue.

  • greggmh123greggmh123

    Bruce,

    Regarding the FBX-16918 fix, it does not resolve the issue with these messages.

    According to support, the "tcp invalid connection state" messages have always existed internally to the Firebox, but were not exposed in FSM traffic monitor. The need to be hidden again as they are completely useless and misleading, and there is a request in for this feature.

    Gregg Hill

  • kbergroskbergros

    Hi...

    I have the same issue migrated to a M300 from a xtm330 and now i see this logging for our Nagios monitoring we have over a Bovpn tunnel we are running on version 12.5.3. Should it be fixed in that version? Everything works with the Nagios monitoring as it should.

  • Bruce_BriggsBruce_Briggs

    No
    Those log messages are still here

Sign In to comment.