Weird blocking behaviour..

[dagibbs]

Greetings.

I have a user who is using a specific protocol - FTP with explicit TLS or otherwise known as FTPES (not to be confused with SFTP or SCP), and for some reason my firewall is blocking it.

The PA identifies the transaction as SSL - which I would expect - but both FTP and SSL is explicitely in my allowed protocol/application rukle - yet the transaction is bouncing past this rule and hitting my "bad application" rule.

I can only assume that the PA is identifying this as some form of encrypted tunnel and matching it against the bad appications - but I can't tell WHICH application it's matching it as - the traffic log only shows the packets as "SSL" and denies them.

Does anyone know how I could delve a bit deeper into this and find out what it's matching as so I can put an explicit permit into the firewall ruleset? I've worked around it by adding a user specific/destination specific "any/any" rule for now, but I don't like doing that.

Thanks for any input.

Cheers.

[pkruse]

Good morning,

The problem with esftp and other encrypted ftp clients is that the control session is encrypted and we are not able to identify it as a child of the initiating parent session. On possible work around would be to setup a static NAT for the initiating IP and then you could create explicit ip to ip rules to accommodate the return session request. Naturally this would not be practical in an environment where several nodes would be using this app and the need for individual static NAT rules exhausted your available pool.

There is no work around when the need is to allow an ecrypted control session through a NAT of many to one.

~Phil

[dagibbs]

pkruse wrote:
Good morning,
The problem with esftp and other encrypted ftp clients is that the control session is encrypted and we are not able to identify it as a child of the initiating parent session. On possible work around would be to setup a static NAT for the initiating IP and then you could create explicit ip to ip rules to accommodate the return session request. Naturally this would not be practical in an environment where several nodes would be using this app and the need for individual static NAT rules exhausted your available pool.
There is no work around when the need is to allow an ecrypted control session through a NAT of many to one.
~Phil

Phil.

I'm not so concerned with identifying the session as a child of the parent link - the firewall appears to be identifying the esftp sesion as SSL, which is fine - but I've got SSL explicitely allowed, and yet the firewall still blocks the session - and I can't figure out why if it's identifying it as SSL.

I've put in a work around by placing an explicit rule from the user concerned to the destintion concerned (thankfully, it's only one site!) with a blanket "allow" - but I'd still like to know why the SSL identified session bypasses my "default "allow" rule and blocks.

Cheers

[skrall]

You probably need to open a support ticket find the root problem. Did you look at the traffic using the CLI?

show session all filter source <ip>

show session id <xxxxx>

One other thing to try is set up a packet filter for the ip in question.

Then look at the global counters using the packet filter to see stats specific to your traffic flow.

Steve Krall