Poor FTP performance for file transfers through FWSM

Oleg Tipisov · ‎07-17-2012

Introduction
Scenario 1
Scenario 2

Introduction

This short article adds some more info to the excellent Single TCP Flow Performance on Firewall Services Module (FWSM)

Scenario 1

Customers often face with poor FTP performance when traffic goes through FWSM even though SEQ randomization is disabled via MPF and SACK/WSCALE are enabled. This is due to the fact that MPF settings may not work for secondary channels (CSCtc22079) and SEQ randomization remains enabled for them, which in turn breaks SACK (CSCeb16752). The impact depends on whether active or passive FTP is used and interface security levels as SEQ randomization depends on security levels.

Also, other factors play important role here. MPF "set connection random-sequence-number disable" works for data channels if xlate is created by control channel traffic, 'n' ("no random") flag is set in it by MPF and data channel uses this same xlate. So, it doesn't work if PAT is used (new xlate is created for data channel) or no xlate exists (when "xlate-bypass" is enabled).

Below are few simple tests that explain this behavior in more details. Client 192.3.3.2 on inside will download files by ftp from 10.48.66.200 on outside.

Configuration is trivial:

interface Vlan75

nameif inside

security-level 100

ip address 192.3.3.99 255.255.255.0

interface Vlan100

nameif outside

security-level 50

ip address 192.0.2.2 255.255.255.0

access-list ALLIP extended permit ip any any

class-map ALLIP

match access-list ALLIP

policy-map global_policy

class ALLIP

set connection random-sequence-number disable

service-policy global_policy global

1. Routing case with xlate-bypass OFF (default)

In this case everything works fine and SEQ randomization remains disabled for both control and data connections. The only minor problem is that we don't see data-channel SYN in inside capture, which is a capture bug.

Xlate is created when NAT is not configured and "xlate-bypass" is OFF. 'n' flag is set in it by MPF:

FWSM# show xlate debug

Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,

o - outside, r - portmap, s - static

1 in use, 1 most used

NAT from inside:192.3.3.2 to outside:192.3.3.2 flags Ini idle 0:02:16 timeout 3:00:00 connections 2

FWSM# show conn detail

2 in use, 2 most used

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

B - initial SYN from outside, b - State bypass, C - CTIQBE media,

D - UDP DNS, d - dump, E - outside back connection, F - outside FIN,

f - inside FIN, G - group, g - MGCP, H - H.323, h - H.225.0,

I - inbound data, i - incomplete, J - GTP, j - GTP data, K - GTP t3-response,

k - Skinny media, L - ARP Incomplete, M - SMTP data, m - SIP media, N - service-accelerated, n - GUP,

O - outbound data, P - inside back connection, p - PISA policy enabled, q - SQL*Net data,

R - outside acknowledged FIN,R - UDP SUNRPC, r - inside acknowledged FIN,

S - awaiting inside SYN, s - awaiting outside SYN, T - SIP, t - SIP transient,

U - up, X - xlate creation bypassed, W - WAAS Session

Network Processor 1 connections

Network Processor 2 connections

TCP outside 10.48.66.200:21 inside 192.3.3.2:33472 idle 0:00:00 Bytes 3170 FLAGS - UOI

TCP outside 10.48.66.200:20 inside 192.3.3.2:33474 idle 0:00:00 Bytes 5189588 FLAGS - UBI

FWSM# show capture inside

10281 packets seen, 6242 packets captured

1: 07:01:28.608890 802.1Q vlan#75 P0 192.3.3.2.33472 > 10.48.66.200.21: S 4227396356:4227396356(0) win 65535 <mss 1460,nop,nop,sackOK>

2: 07:01:28.608890 802.1Q vlan#75 P0 10.48.66.200.21 > 192.3.3.2.33472: S 3723748055:3723748055(0) ack 4227396357 win 5840 <mss 1380,nop,nop,sackOK>

...

21: 07:03:30.730070 802.1Q vlan#75 P0 192.3.3.2.33474 > 10.48.66.200.20: S 1621994482:1621994482(0) ack 4012372554 win 65535 <mss 1460,nop,wscale 0,nop,nop,[|tcp]>

22: 07:03:30.730070 802.1Q vlan#75 P0 10.48.66.200.20 > 192.3.3.2.33474: . ack 1621994483 win 92 <nop,nop,timestamp 123448469[|tcp]>

FWSM# show capture outside

10281 packets seen, 6242 packets captured

1: 07:01:28.608890 802.1Q vlan#100 P0 192.3.3.2.33472 > 10.48.66.200.21: S 4227396356:4227396356(0) win 65535 <mss 1380,nop,nop,sackOK>

2: 07:01:28.608890 802.1Q vlan#100 P0 10.48.66.200.21 > 192.3.3.2.33472: S 3723748055:3723748055(0) ack 4227396357 win 5840 <mss 1460,nop,nop,sackOK>

...

21: 07:03:30.730070 802.1Q vlan#100 P0 10.48.66.200.20 > 192.3.3.2.33474: S 4012372553:4012372553(0) win 5840 <mss 1460,sackOK,timestamp[|tcp]>

22: 07:03:30.730070 802.1Q vlan#100 P0 192.3.3.2.33474 > 10.48.66.200.20: S 1621994482:1621994482(0) ack 4012372554 win 65535 <mss 1380,nop,wscale 0,nop,nop,[|tcp]>

23: 07:03:30.730070 802.1Q vlan#100 P0 10.48.66.200.20 > 192.3.3.2.33474: . ack 1621994483 win 92 <nop,nop,timestamp 123448469[|tcp]>

2. Routing case with xlate-bypass ON

In this case xlate is not created and SEQ are still randomized in inside to outside direction for data channel traffic. They would be randomized in outside to inside direction should inside interface have lower security level than the outside one. So, the impact depends on interface security levels.

Also, note the flag 'X' in "show conn detail" output.

FWSM# show xlate debug

Flags: D - DNS, d - dump, I - identity, i - inside, n - no random,

o - outside, r - portmap, s - static

0 in use, 1 most used