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:
unset flow no-tcp-seq-check
unset flow tcp-syn-check
set flow tcp-syn-bit-check
PC-1 transmits TCP SYN
to PC-2 with a WSF
of 9:
PC-2 transmits TCP SYN-ACK
to PC-1 with a WSF
of 7:
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 < >