Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

Poor FTP performance for file transfers through FWSM

 

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

 

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:33477 idle 0:00:00 Bytes 2768 FLAGS - UOIX

TCP outside 10.48.66.200:20 inside 192.3.3.2:33479 idle 0:00:00 Bytes 4355752 FLAGS - UBIX

 

FWSM# show capture inside

3877 packets seen, 3877 packets captured

   1: 07:20:49.1769830 802.1Q vlan#75 P0 192.3.3.2.33477 > 10.48.66.200.21: S 1014461232:1014461232(0) win 65535 <mss 1460,nop,nop,sackOK>

   2: 07:20:49.1769830 802.1Q vlan#75 P0 10.48.66.200.21 > 192.3.3.2.33477: S 544882074:544882074(0) ack 1014461233 win 5840 <mss 1380,nop,nop,sackOK>

...

  18: 07:21:17.1797290 802.1Q vlan#75 P0 192.3.3.2.33479 > 10.48.66.200.20: S 3424397221:3424397221(0) ack 4263442013 win 65535 <mss 1460,nop,wscale 0,nop,nop,[|tcp]>

  19: 07:21:17.1797300 802.1Q vlan#75 P0 10.48.66.200.20 > 192.3.3.2.33479: . ack 3424397222 win 92 <nop,nop,timestamp 123715228[|tcp]>

 

FWSM# show capture outside

3877 packets seen, 3877 packets captured

   1: 07:20:49.1769830 802.1Q vlan#100 P0 192.3.3.2.33477 > 10.48.66.200.21: S 1014461232:1014461232(0) win 65535 <mss 1380,nop,nop,sackOK>

   2: 07:20:49.1769830 802.1Q vlan#100 P0 10.48.66.200.21 > 192.3.3.2.33477: S 544882074:544882074(0) ack 1014461233 win 5840 <mss 1460,nop,nop,sackOK>

...

  18: 07:21:17.1797290 802.1Q vlan#100 P0 10.48.66.200.20 > 192.3.3.2.33479: S 4263442012:4263442012(0) win 5840 <mss 1460,sackOK,timestamp[|tcp]>

  19: 07:21:17.1797290 802.1Q vlan#100 P0 192.3.3.2.33479 > 10.48.66.200.20: S 2888881286:2888881286(0) ack 4263442013 win 65535 <mss 1380,nop,wscale 0,nop,nop,[|tcp]>

  20: 07:21:17.1797300 802.1Q vlan#100 P0 10.48.66.200.20 > 192.3.3.2.33479: . ack 2888881287 win 92 <nop,nop,timestamp 123715228[|tcp]>

 

3. PAT case

 

nat (inside) 1 192.3.3.0 255.255.255.0

global (outside) 1 interface

 

In this case SEQ are still randomized in inside to outside direction for data channel traffic. Note the 'n' flag in the xlate that corresponds to control channel connection (set by MPF). This flag isn't present in the xlate that corresponds to data channel connection.

 

FWSM# show xlate debug  

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

       o - outside, r - portmap, s - static

2 in use, 2 most used

TCP PAT from inside:192.3.3.2/33507 to outside:192.0.2.2/26640 flags rni idle 0:00:55 timeout 0:00:30 connections 1

TCP PAT from inside:192.3.3.2/33511 to outside:192.0.2.2/31923 flags ri idle 0:00:08 timeout 0:00:30 connections 1

 

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:33507 idle 0:00:00 Bytes 3202 FLAGS - UOI

TCP outside 10.48.66.200:20 inside 192.3.3.2:33511 idle 0:00:00 Bytes 115669480 FLAGS - UBI

 

FWSM# show capture inside

74949 packets seen, 6242 packets captured

   1: 08:02:22.4262740 802.1Q vlan#75 P0 192.3.3.2.33507 > 10.48.66.200.21: S 1528304370:1528304370(0) win 65535 <mss 1460,nop,nop,sackOK>

   2: 08:02:22.4262740 802.1Q vlan#75 P0 10.48.66.200.21 > 192.3.3.2.33507: S 835007049:835007049(0) ack 1528304371 win 5840 <mss 1380,nop,nop,sackOK>

...

  21: 08:03:10.4310170 802.1Q vlan#75 P0 192.3.3.2.33511 > 10.48.66.200.20: S 3273871469:3273871469(0) ack 2396719870 win 65535 <mss 1460,nop,wscale 0,nop,nop,[|tcp]>

  22: 08:03:10.4310170 802.1Q vlan#75 P0 10.48.66.200.20 > 192.3.3.2.33511: . ack 3273871470 win 92 <nop,nop,timestamp 124343335[|tcp]>

 

FWSM# show capture outside

74950 packets seen, 6242 packets captured

   1: 08:02:22.4262740 802.1Q vlan#100 P0 192.0.2.2.26640 > 10.48.66.200.21: S 1528304370:1528304370(0) win 65535 <mss 1380,nop,nop,sackOK>

   2: 08:02:22.4262740 802.1Q vlan#100 P0 10.48.66.200.21 > 192.0.2.2.26640: S 835007049:835007049(0) ack 1528304371 win 5840 <mss 1460,nop,nop,sackOK>

...

  21: 08:03:10.4310170 802.1Q vlan#100 P0 10.48.66.200.20 > 192.0.2.2.31923: S 2396719869:2396719869(0) win 5840 <mss 1460,sackOK,timestamp[|tcp]>

  22: 08:03:10.4310170 802.1Q vlan#100 P0 192.0.2.2.31923 > 10.48.66.200.20: S 2497569957:2497569957(0) ack 2396719870 win 65535 <mss 1380,nop,wscale 0,nop,nop,[|tcp]>

  23: 08:03:10.4310170 802.1Q vlan#100 P0 10.48.66.200.20 > 192.0.2.2.31923: . ack 2497569958 win 92 <nop,nop,timestamp 124343335[|tcp]>

 

The solution would be to use "norandomseq" option whenever possible:

nat (inside) 1 192.3.3.0 255.255.255.0 norandomseq

In this case 'n' flag will be propagated to all xlates and randomization will not occur.

Documentation bug CSCua62630 was opened to describe this behavior and the workaround.

 

Scenario 2

Problem:

User have an FWSM running in multiple context mode running 3.2(18) code. He has 3 urls that he would like to block as he can't justify the cost of an external URL filtering server.   found a way to filter individual URLs on the ASA but the same configuration does not seem to be available on the FWSM.  At least not on my code.  Does anyone know of any way to do this other than resolving the hostnames and blocking the current IP addresses?

Solution:

You are right, Regex URL filtering on FWSM is only supported from version 4.0.1 onwards.

Here is the sample configuration for your reference:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/mpf_f.html#wp1101685

Command reference:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm41/command/reference/c1.html#wp1889922

2147
Views
0
Helpful
0
Comments