Weird blocking behaviour..

Reply
Highlighted
L4 Transporter

Weird blocking behaviour..

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.

L4 Transporter

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

Highlighted
L4 Transporter

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

Highlighted
L4 Transporter

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

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 Live Community as a whole!

The Live Community thanks you for your participation!