Palo Alto Out of Sync Packets

This something to keep in mind if you’re running a vWire configuration. A while back I implemented a vWire setup and we had some very old medical devices on the network that should of been decomm’ed years before. These devices were sending packets out of sync. If wasn’t all the devices which made it fun to troubleshoot. On top of that, it wouldn’t always do it but it did it often enough.

It wasn’t until we did a packet capture did we notice the devices not completing the TCP 3-way handshake SYN/SYN-ACK/ACK.

Running the command below helped verify the packets were out of sync:

kcordero@PA5250-A(active)> show counter global filter packet-filter yes

Global counters:
Elapsed time since last sampling: 16.575 seconds

name                                   value     rate severity  category  aspect    description
--------------------------------------------------------------------------------
...
tcp_out_of_sync                        12134        0 warn      tcp       pktproc   can't continue tcp reassembly because it is out of sync
...
--------------------------------------------------------------------------------
Total counters shown: 422
--------------------------------------------------------------------------------

On top of the command above, you can use the “delta” option to display difference from last read which helped see the hits were going up.

show counter global filter packet-filter yes delta yes

Like I mentioned above, this was a while ago and the configuration to allow this type of traffic had to be done via the CLI so it wasn’t like you could look the through the GUI and find the fix. Today it’s in the GUI.

CLI:

> configure
# set deviceconfig setting tcp asymmetric-path bypass
# commit

GUI:

pa-asym-bypass

If you want to verify via the CLI:

kcordero@PA5250-A(active)> show running tcp state

session with asymmetric path            : drop packet
Bypass if OO queue limit is reached     : no
Favor new seg data                      : no
Urgent data                             : clear
Drop if zero after clear urgent flag    : yes
Check Timestamp option                  : yes
Allow Challenge Ack                     : no
Remove MPTCP option                     : yes

Just keep this in mind this is something that could happen. If you do run across this issue you can bypass asymmetric checking while you get those devices upgraded/replaced/fixed and then turn it back on.