This article explains why the TCP Windows Scaling Factor on ASIC-based systems is incorrectly reflected in the session table. As a result of this, re-transmitted packets are dropped due to the TCP sequence check.

For Windows Scaling Factor (WSF) to be correctly installed in a session on ASIC-based platforms, set flow tcp-syn-check is required.

Otherwise, only the WSF of the first SYN is installed correctly, the WSF from SYN-ACK is not processed, and the firewall installs a default WSF of 3.

This can result in the firewall dropping re-transmitted packets due to the TCP sequence check.

Windows Scaling Factor (WSF) is used to determine the TCP Window size.

The TCP Window size is used to inform the TCP peer about how many bytes can be sent before receiving an acknowledgement.

Consider the following scenario:

PC-1 (10.1.1.2)-----Firewall-------PC-2 (20.1.1.2)

The following flow commands are configured:

PC-1 transmits TCP SYN to PC-2 with a WSF of 9:

• PC-1 informs PC-2 that it is able to handle the window size of 2^9 * window_size.

• The firewall installs a WSF of 9 in the session wing from 20.1.1.2 > 10.1.1.2.

PC-2 transmits TCP SYN-ACK to PC-1 with a WSF of 7:

• PC-2 informs PC-1 that it is able to handle the window size of 2^7 * window_size.

• The firewall should install a WSF of 7 in the session wing from 10.1.1.2 -> 20.1.1.2; instead it installs a WSF of 3.

A sample output of get session id xxxx is below:

ns5400-> get session id 2000063
id 2000063(001e84bf), flag 00200440/0000/0003/0000, vsys id 0(Root)
policy id 1, application id 0, dip id 0, state 0
current timeout 1520, max timeout 1800 (second)
status normal, start time 4983, duration 0
session id mask 0, app value 0
ethernet2/1(vsd 0): 10.1.1.2/47898->20.1.1.2/20011, protocol 6 session token 3 route 3
  gtwy 20.1.1.2, mac 000009209dd4, nsptn info 0, pmtu 1500
  flag 800801, diff 0/0
  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
ethernet2/2(vsd 0): 10.1.1.2/47898<-20.1.1.2/20011, protocol 6 session token 4 route 5
  gtwy 10.1.1.2, mac 00000920a63d, nsptn info 0, pmtu 1500
mac 00000920a63d, nsptn info 0
  flag 800800, diff 0/0
  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
Saturn hardware session:
chip 0,slot 2,idx 11,flag 0x40,diff (0/0),pid 1,time (4983/180/152),ssid 2000063
 7(1):10.1.1.2/47898->20.1.1.2/20011,6,token:3,l2:(b:31:1),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:3194, vect:0, fin_seq:0x790DB4DD, fst:0, flag:0,wsf 3   !!!!! WSF of 3 !!!!!
 8(1):10.1.1.2/47898<-20.1.1.2/20011,6,token:4,l2:(a:21:2),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:1, vect:0, fin_seq:0x00000000, fst:0, flag:0,wsf 0
hw sess:0x88000b00, ext hw sess:0x88000b80, cnt:758
shadow sess:0x040c1468, hash:003801fd, hash1:001c3a5b, shadow flag:0x10
  nat_flag:0x40, next id:00000000(0), next id1:00000000(0), prev id:00000000(0), prev id1:00000000(0)
  twin 0x98000b00, forw1 0x0, forw2 0x0, sw sess:0x469b0b10, policy 0x57b6b680

Twin hardware session :
chip 1,slot 2,idx 11,flag 0x40,diff (0/0),pid 1,time (4983/180/80),ssid 2000063
 7(1):10.1.1.2/47898->20.1.1.2/20011,6,token:3,l2:(a:30:1),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:1, vect:0, fin_seq:0x00000000, fst:0, flag:0,wsf 0
 8(1):10.1.1.2/47898<-20.1.1.2/20011,6,token:4,l2:(b:21:2),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:89, vect:0, fin_seq:0xFE6DBBB0, fst:0, flag:0,wsf 9 !!!!! This is correctly reflected from the Syn packet !!!!!
hw sess:0x98000b00, ext hw sess:0x98000b80, cnt:398
shadow sess:0x084611b8, hash:003801fd, hash1:001c3a5b, shadow flag:0x10
  nat_flag:0x40, next id:00000000(0), next id1:00000000(0), prev id:00000000(0), prev id1:00000000(0)
  twin 0x88000b00, forw1 0x0, forw2 0x0, sw sess:0x469b0b10, policy 0x57b6b680

But with set flow tcp-syn-check, WSF is shown with the correct value of 7:

Saturn hardware session:
chip 0,slot 2,idx 9,flag 0x40,diff (0/0),pid 1,time (3144/180/178),ssid 2000063
 7(1):10.1.1.2/47898->20.1.1.2/20011,6,token:3,l2:(b:31:1),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:224, vect:0, fin_seq:0x790DB4DD, fst:0, flag:0,wsf 7 !!!!! WSF is 7 !!!!!
 8(1):10.1.1.2/47898<-20.1.1.2/20011,6,token:4,l2:(b:21:2),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:1, vect:0, fin_seq:0x00000000, fst:0, flag:0,wsf 0
hw sess:0x88000900, ext hw sess:0x88000980, cnt:889
shadow sess:0x040c13f8, hash:003801fd, hash1:001c3a5b, shadow flag:0x10
  nat_flag:0x40, next id:00000000(0), next id1:00000000(0), prev id:00000000(0), prev id1:00000000(0)
  twin 0x98000900, forw1 0x0, forw2 0x0, sw sess:0x469b0b10, policy 0x57b6b680

Twin hardware session :
chip 1,slot 2,idx 9,flag 0x40,diff (0/0),pid 1,time (3144/180/179),ssid 2000063
 7(1):10.1.1.2/47898->20.1.1.2/20011,6,token:3,l2:(b:30:1),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:1, vect:0, fin_seq:0x00000000, fst:0, flag:0,wsf 0
 8(1):10.1.1.2/47898<-20.1.1.2/20011,6,token:4,l2:(b:21:2),vl:0,sa:0,vsd:0,L2 xl:1
      bcnt:89, vect:0, fin_seq:0xFE6DBBB0, fst:0, flag:0,wsf 9
hw sess:0x98000900, ext hw sess:0x98000980, cnt:891
shadow sess:0x08461148, hash:003801fd, hash1:001c3a5b, shadow flag:0x10
  nat_flag:0x40, next id:00000000(0), next id1:00000000(0), prev id:00000000(0), prev id1:00000000(0)
  twin 0x88000900, forw1 0x0, forw2 0x0, sw sess:0x469b0b10, policy 0x57b6b680

For Windows Scaling Factor (WSF) to be correctly installed in a session on ASIC-based platforms, enable set flow tcp-syn-check.


Workaround:

• Disable TCP Sequence check:

  set flow no-tcp-seq-check

• Configure a static WSF for the session in the reverse direction:

  set flow syn-ack-wsf < >

• Enable TCP MSS on the firewall. The result is that the TCP 3-way handshake will be processed by the CPU:

  set flow all-tcp-mss <  >