TCP Windows scale option

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP Windows scale option

L1 Bithead

Hi, could someone explain if PanOS is able to consider  the filed "TCP Window Scale Option (WSopt)" ( http://www.ietf.org/rfc/rfc1323.txt?number=1323). when tcp asymmetric-path is disabled (drop)?

I mean that in my experience the firewall drop the packet as "oow - out of window" even if it not should be dropped if we consider "calculated windows size = windows size * windows size scaling factor”.

Example:

below TX capture from PA:

  1. Time                       Source                Destination           Protocol Length Info

    158 2015-03-25 11:36:04.413633 10.2.5.6 172.30.1.63           TCP      70 860→514 [ACK] Seq=577538268 Ack=1190880267 Win=87296 Len=0 TSval=2774776809 TSecr=922042109

Frame 158: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)

Ethernet II, Src: Netscreen_ff:40:d0 (00:10:db:ff:40:d0), Dst: PaloAlto_00:01:31 (00:1b:17:00:01:31)

  1. 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 311

Internet Protocol Version 4, Src: 10.2.5.6 (10.2.5.6), Dst: 172.30.1.63 (172.30.1.63)

Transmission Control Protocol, Src Port: 860 (860), Dst Port: 514 (514), Seq: 577538268, Ack: 1190880267, Len: 0

    Source Port: 860 (860)

    Destination Port: 514 (514)

    [Stream index: 2]

    [TCP Segment Len: 0]

    Sequence number: 577538268

    Acknowledgment number: 1190880267

    Header Length: 32 bytes

    .... 0000 0001 0000 = Flags: 0x010 (ACK)

    Window size value: 682

    [Calculated window size: 87296]

    [Window size scaling factor: 128]

    Checksum: 0x84c1 [validation disabled]

    Urgent pointer: 0

    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps

    [SEQ/ACK analysis]

    [Timestamps]

  1. Time                       Source                Destination           Protocol Length Info

    159 2015-03-25 11:36:04.414000 172.30.1.63           10.2.5.6              RSH      1518 [TCP Previous segment not captured] Server username:xymon Server -> Client Data

Frame 159: 1518 bytes on wire (12144 bits), 1518 bytes captured (12144 bits)

Ethernet II, Src: Cisco_5f:8c:43 (7c:69:f6:5f:8c:43), Dst: PaloAlto_00:01:31 (00:1b:17:00:01:31)

  1. 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 13

Internet Protocol Version 4, Src: 172.30.1.63 (172.30.1.63), Dst: 10.2.5.6 (10.2.5.6)

Transmission Control Protocol, Src Port: 514 (514), Dst Port: 860 (860), Seq: 1190881715, Ack: 577538268, Len: 1448

    Source Port: 514 (514)

    Destination Port: 860 (860)

    [Stream index: 2]

    [TCP Segment Len: 1448]

    Sequence number: 1190881715

    [Next sequence number: 1190883163]

    Acknowledgment number: 577538268

    Header Length: 32 bytes

    .... 0000 0001 0000 = Flags: 0x010 (ACK)

    Window size value: 8760

    [Calculated window size: 8760]

    [Window size scaling factor: 1]

    Checksum: 0xe51d [validation disabled]

    Urgent pointer: 0

    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps

    [SEQ/ACK analysis]

    [Timestamps]

Remote Shell

Drop from packet capture on PA:

  1. Time                       Source                Destination           Protocol Length Info

      159 2015-03-25 11:36:04.414096 172.30.1.63 10.2.5.6              RSH      1518 Server -> Client Data

Frame 1: 1518 bytes on wire (12144 bits), 1518 bytes captured (12144 bits)

Ethernet II, Src: Cisco_5f:8c:43 (7c:69:f6:5f:8c:43), Dst: PaloAlto_00:01:31 (00:1b:17:00:01:31)

  1. 802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 13

Internet Protocol Version 4, Src: 172.30.1.63 (172.30.1.63), Dst: 10.2.5.6 (10.2.5.6)

Transmission Control Protocol, Src Port: 514 (514), Dst Port: 860 (860), Seq: 1190881715, Ack: 577538268, Len: 1448

    Source Port: 514 (514)

    Destination Port: 860 (860)

    [Stream index: 0]

    [TCP Segment Len: 1448]

    Sequence number: 1190881715

    [Next sequence number: 1190883163]

    Acknowledgment number: 577538268

    Header Length: 32 bytes

    .... 0000 0001 0000 = Flags: 0x010 (ACK)

    Window size value: 8760

    [Calculated window size: 8760]

    [Window size scaling factor: -1 (unknown)]

    Checksum: 0xe51d [validation disabled]

    Urgent pointer: 0

    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps

    [SEQ/ACK analysis]

    [Timestamps]

Remote Shell

thank you regards

3 REPLIES 3

Not applicable

Hi,

PA firewall does consider the window scale option. It is capable of adjusting its sliding window accordingly. Only if the packets arrive out of this window range, it would drop packets considering it as 'out of order'.

You can refer the below links that has more information on it:

How to Set the Palo Alto Networks Firewall to Allow non-Syn First Packet

Palo Alto Networks TCP Settings and Counters

If it still drops, then we would have to investigate on it further.

Regards,

Ramya

Hi, thank you for your reply.

Could you explain the following for me please? :)

The Palo Alto Networks Firewall will create a sliding sequence window starting with the original ACK (the window size is based on the type of traffic within the session)


Question:


"original ack" in the case above is the fame 158?

"type of traffc" what does it means?

thank you again and best regards

Hi,

Yes, the original ACK is the first ACK received. If fame 158 is the first ACK , then the window size will be calculated from it.

Am not very sure about the 'type of traffic' mentioned in the article, however, it should follow the normal sliding window mechanism.

However, that would be session based, that is, the packets for a particular session are expected to come within the window range calculated.

Please mark helpful if yes.

Regards,

Ramya

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!