FTP weird behaviour

[soporteseguridad]

Hi,

We realised that our PA is doing something strange with FTP app

We have create and above rule (Servidores a INET 1). All our FTP connections involved should match this rule but we see connections which are jumping this rule and mathicng in another one below (Servidores a INET ftp)  

This is the log traffic (source 192.168.53.182) where all FTP connections should match going to INET. 

But in another rule below we see FTP matches :S Why do we see matches here not in rule above????

The source/destination/NATs are the same for all connections. Any idea?

[santonic]

Destination ports are not in one of those groups from 1st rule?

[soporteseguridad]

In the first rule we have allow FTP app, the high ports are dynamic open by FTP connecting. PA should identify this high ports in ftp connection. 

[TranceforLife]

Correct. It is doing an inspection of the FTP traffic and should allow all dynamic ports agreed between the client and the server for the same session. Could you plz post a "magnifying glass" output for both sessions

[soporteseguridad]

I attach the details connection.

I checked another connections and saw that FW is jumping another rule and appliying the final deny. Its like FTP identify is doing something strange.

 

[TranceforLife]

Hi,

Was it always like that or something is changed and you noticed this behaviour. Is it for all FTP client or just one particular?

[reaper]

just a thought. is there a way for you to trace one single client-server interaction and lay all connections from that client out so you can see when it hits the right and when it hits the wrong rule ?  (specifically so you can see the time information) 

there's a lot of dynamic high ports, these are negotiated as part of the initial ftp connection on port 21. when the ports are negotiated, AppID creates a predict session that knows which ports to expect... maybe the initial session is timing out, taking with it the predict session, before the data connection is set up in some of these cases, making the data connection a standalone session (for active ftp there would be 2 or more sessions with 1 being the control link session and 1 being the data link session)

maybe your TCP timeouts are set very agressive or the session is so  'slow' the timers need to be adjusted slightly

> show session info
...

Session timeout
  TCP default timeout:                           3600 secs
  TCP session timeout before SYN-ACK received:      5 secs
  TCP session timeout before 3-way handshaking:    10 secs
  TCP half-closed session timeout:                120 secs
  TCP session timeout in TIME_WAIT:                15 secs
  TCP session timeout for unverified RST:          30 secs
  UDP default timeout:                             30 secs
  ICMP default timeout:                             6 secs
  other IP default timeout:                        30 secs
  Captive Portal session timeout:                  30 secs
  Session timeout in discard state:
    TCP: 90 secs, UDP: 60 secs, other IP protocols: 60 secs

[soporteseguridad]

Hi reaper,

Session paramethers are configured by default. Its weird because its quite randomly. I just opened a PA case.

[TranceforLife]

Hi,

Please let us know the  TAC findings/outcome. 

[rk20ta]

did you get back from TAC on this?

[Roby_Sreejith]

I am also facing same issue can you share the results