FTP weird behaviour

cancel
Showing results for 
Search instead for 
Did you mean: 

FTP weird behaviour

L4 Transporter

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)  

 

policies.jpg

 

 

 

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

 

good rule.jpg

 

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?

 

Bad rule.jpg

10 REPLIES 10

L5 Sessionator

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

 

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. 

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

I attach the details connection.

 

detail.jpg

 

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.

 

deny.jpg 

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?

 

 

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

 

Tom Piens
PANgurus - (co)managed services and consultancy

Hi reaper,

 

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

 

 

Hi,

 

Please let us know the  TAC findings/outcome. 

did you get back from TAC on this?

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!