FTP Transfer and ZBFW Issue

[Ryan.Mountain]

Hi there,

I am having an issue with FTP transfer and the implementation of ZBFW and that it takes several minutes before the transfer actually starts. Can be waiting up to 30+ minutes for the transfer to begin.

Device is using FTP Active mode.

Trying to transfer from a FTP server to Cisco switch which is initiated from the client - zones "inside" to "wan".

Relevant Config:

zone security inside

zone security wan

!

ip access-list extended acl_ftp

 permit tcp any any eq ftp

 permit tcp any any eq ftp-data

 permit tcp any eq ftp any

 permit tcp any eq ftp-data any

!

////(aware I don't really need to specify the layer 7 protocols in the acl as matched in the class-map?)

!

class-map type inspect cmi_ftp

 match protocol ftp

 match access-group name acl_ftp

!

policy-map type inspect pmi_inside-wan

 class type inspect cmi_ftp

  inspect

policy-map type inspect pmi_wan-inside

 class type inspect cmi_ftp

  inspect

!

zone-pair security zp_inside-wan source inside destination wan

 service-policy type inspect pmi_inside-wan

zone-pair security zp_wan_inside source wan destination inside

 service-policy type inspect pmi_wan-inside

!

interface (inside)

 zone-member security inside

interface (wan)

 zone-member security wan

If the action in the policy maps are set to pass instead of inspect. It works straight away without an issue. Also works without the implementation of the ZBFW so narrowed it down to be an issue with inspect actions in the policy maps?

1KB file transfers work without this issue.

I have tried a file around 1.2MB in size and it still runs into this issues (file debugged below)

Router: ISR4321/K9

IOS XE ver: 17.3.4a

Switch: WS-C2960X-24PS-L

IOS ver: 15.2(7)E4

Has anyone come across this before or have a solution/advice to what I could try?

(debug attached)

The switch still tries multiple times but the transfer happens straight away when set to pass.

Thanks in advance

[MHM Cisco World]

I don't know so much in ZBFW but 
FTP can work in two mode active and passive mode and each one have different port.
check if the client use passive and port is change.

[Ryan.Mountain]

The client is using active mode.

On the switch, "no ip ftp passive" mode has been configured.

[MHM Cisco World]

....

[Ryan.Mountain]

Further advancement today:

I ran a packet capture on the router and could see that the issue seemed to be with the FTP Data connection (port 20) and not the FTP Connection (port 21).

The client (switch) would send a [FIN, PSH, ACK] to the server and would "Request: QUIT" on the FTP Data session abruptly... Just when the server was about to send the data over. The server tried to send data then the client send a TCP Reset to the server which resulted in the transfer being aborted. 

It seemed the client closed the TCP session but the firewall was still holding onto the open session. I configured a parameter map and applied it to the policy map...

parameter-map type inspect parmap_ftp

 tcp idle-time 3

!

policy-map type inspect pmi_inside-wan

 class type inspect cmi_ftp

  inspect parmap_ftp

This actually resulted in the transfer happening more or less straight away (after about 6 seconds) as compared to the 30 minute+ wait previously. 

Still confused to why this would matter at all as when a new TCP FTP & FTP Data session open, it will use different source port numbers and not conflict with the existing idle one? 

Either way, the parameter map sorted the issue with the inspect action to the delayed transfer!

[MHM Cisco World]

""let using ACL for only FTP server IP and make match protocol FTP do fine filter""

ip access-list extended acl_ftp

 permit tcp any <FTP Server IP>

!

class-map type inspect cmi_ftp

 match protocol ftp

 match access-group name acl_ftp

!

""adjunct the MSS to be 1360 prevent the fragment""

ip tcp adjust-mss max-segment-size<- 1360

[Ryan.Mountain]

The inside interface already has the max segment size set -> 1452.

Pings works to the ftp server while setting the site and df-bit tag.

I can see in the packet capture the size of the packets were 594 bytes.

[MHM Cisco World]

there are two thing 
1- CPU check the ACL for 20 21 port i.e. the control and data port this utilize CPU and cause slow
2- packet size which is 594 not 1400 !! that make 10 min traffic be 30 min.
the MTU of Inside interface or TCP MSS ? which one you config ?

[Ryan.Mountain]

I can't imagine this would be down to the CPU utilisation as like I have mentioned, FTP works fine when the ZBFW has not been implemented or when the pass action is specified.

Inside interface:

ip tcp adjust-mss 1452

Outside/WAN interface:

ip mtu 1492

Not worried about the packet size as FTP is not a critical application and there will be other factors involved reducing the size.

[MHM Cisco World]

show platform hardware qfp active statistics drop clear

then do test again again  at least three times "test meaning check ftp"

show platform hardware qfp active statistics drop all

Share the output here 

[Ryan.Mountain · Accepted solution]

I started to look more into the size of the packet and why it was so low.

The switch is not sending the TCP option MSS in the TCP handshake so the default size of 536 is being used which is resulting in the sizes being so small.

I went ahead and amended the tcp mss size on the switch --> ip tcp mss 1452

This solved the issue (or at least found another work around) and FTP starts transferring straight away.

I don't know why the small size of the packet effects the ZBFW in this way?

[MHM Cisco World]

First thaks for sharing 

Second please mention that this issue is solved.

[Ryan.Mountain]

I will mark it as solved although it is more of a work around than a solution.

Thank you for your help.