Threat Management Gateway FTPS

I'm trying to configure outbound FTPS in threat management gateway. I'm at the point where the connection authenticates but then won't LIST (followed: Does anyone have any other articles/info on configuring FTPS in ISA/TMG?

Status:                      Connecting to xx.xx.xx.xx:21...
Status:                      Connection established, waiting for welcome message...
Response:               220
Command:               AUTH TLS
Response:               234 AUTH command ok. Expecting TLS Negotiation.
Status:                      Initializing TLS...
Status:                      Verifying certificate...
Command:               USER ilgblog
Status:                      TLS/SSL connection established.
Response:               331 Password required for ilgblog.
Command:               PASS ********
Response:               230 User logged in.
Command:               SYST
Response:               215 Windows_NT
Command:               FEAT
Response:               211-Extended features supported:
Response:               LANG EN*
Response:               UTF8
Response:               AUTH TLS;TLS-C;SSL;TLS-P;
Response:               PBSZ
Response:               PROT C;P;
Response:               CCC
Response:               HOST
Response:               SIZE
Response:               MDTM
Response:               211 END
Command:               OPTS UTF8 ON
Response:               200 OPTS UTF8 command successful - UTF8 encoding now ON.
Command:               PBSZ 0
Response:               200 PBSZ command successful.
Command:               PROT P
Response:               200 PROT command successful.
Status:                      Connected
Status:                      Retrieving directory listing...
Command:               PWD
Response:               257 "/" is current directory.
Command:               TYPE I
Response:               200 Type set to I.
Command:               PASV
Response:               227 Entering Passive Mode (xx,xx,xx,xx,xx,xx).
Command:               LIST
Response:               125 Data connection already open; Transfer starting.
Response:               550 The specified network name is no longer available.
Error:                        Failed to retrieve directory listing
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Bruno PACIIT ConsultantCommented:

Everything looks like you successfully open the TCP session on port 21 with the FTP server but fail to initiate the TCP session on port 20 of the server...

FTP uses 2 TCP ports: 21 and 20

TCP 21 is used to pass commands, so as you can show us a FTP dialog log that means this TCP session works well.
TCP 20 is used to pass data results of FTP commands. As an example, if you use LS or GET command the result is obtain throught the TCP 20 session.

Your problem looks really like you are not able to reach the TCP 20 port of the server. Can you tell us what is configured in your ISA rule ? Are there any other firewall behing your ISA server ?

By the way, I saw you use PASSIVE mode in your FTP session. That's ok because in PASSIVE mode the TCP session on port 20 is initiated by the FTP client.
If you come to use ACTIVE mode you have to know that in this case the TCP 20 session is initiated by the FTP server to the FTP client ! If there are any other firewall to go through the ACTIVE mode is more complicated to configure because you have an outgoing TCP session and an incoming TCP session to open.

Have a good day.
PatrickK_WAuthor Commented:
Thanks PaciB

I hadn't read anything about Port 20. I've added that to the Custom Protocol I created as part of the link I posted but it didn't fix the problem.

At the moment the protocol is configured for 1024-65535 and 20-21 because of:
"# It is also recommended that ... you can specify all unprivileged ports > 1023 (1024 - 65534).
# With the above protocol definition, ... If you have to support SecureNAT clients too, you need to adjust the above protocol definition by moving the FTPS Data connection from the Secondary Connections to the Primary Connections section."

As the rule is 'to' only one IP this shouldn't be too much of a security risk.

There IS another firewall/router behind the TMG server, but the server is in the DMZ

At the moment there is only one server to connect to and I've tested from just behind a router and it works in PASV

Bruno PACIIT ConsultantCommented:
Hi again,

This article explains well the active and passive ftp modes.

By the way I was wrong, in passive mode the TCP 20 port on server is not used...

In the screens shots, I see the ISA rule with FTP protocol defined, I don't see the "FTPS" protocol in the rule...

If you have created a FTPS protocol definition by yourself using the same ports than builtin FTP protocol definition, and used the both protocols in the same rule there might be a conflict... You can not have 2 protocols definition using the same ports a having different behaviors.
The buitlin FTP protocol definition uses a "FTP Access Filter" DLL that listen to FTP dialog to react dynamically.
You might have conflict between protocols: when ISA sees an incoming traffic on TCP 21 port it may think it is associated with builtin FTP protocol and give it to the FTP filter. This one will then refuse the traffic is the content of the TCP session doesn't match with FTP standard dialog...

If you are forced to create your own FTPS protocol definition that uses same ports than standard FTP protocol then you probably should disable the FTP filter on the builtin FTP protocol definition.

Have a good day.
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

PatrickK_WAuthor Commented:
That was my mistake on the capture!

I think the custom rule should handle all the FTPS traffic to the one IP address and the generic rule should handle the 'normal' FTP traffic, which it does.

The FTP Filter is enabled on the FTP rule but not on the FTPS rule

Bruno PACIIT ConsultantCommented:
Hi again,

Can you try disabling the FTP filter on the 'normal' FTP protocol definition ?
As I said before, there might be a protocol definition conflict and the FTP filter may refuse the traffic.

May be the best way to check if there's a conflict is to temporarily change the TCP port numbers on 'standard' FTP protocol definition to ensure it won't be concerned by FTPS traffic. That's not a solution, just a test.

I'll be able to take a look on a TMG 2010 server tonight...

Have a good day.
PatrickK_WAuthor Commented:
Thanks PaciB

That worked. I've re-enabled it for now because I need to test that, with that removed, uploading works.

Thanks for your help so far. Just need to get my head aroud it too!
PatrickK_WAuthor Commented:
Sorry, I misread your post.

Rather than removing the filter I removed the FTP protocol from the 'bottom' rule.

I'll carry on testing,
Bruno PACIIT ConsultantCommented:
Whatever the way (removing FTP from rule or changing FTP protocol settings) the important thing is that it now works...

That proove the fact that there's a conflict between the normal FTP protocol definition and the FTPS definition.
The bad news is that you can not have the both protocols in your rules.

The good news is that your FTPS protocol definition will probably also allow classical FTP traffic because your rule doesn't use any "filter" and then can only react against TCP port numbers, and TCP port numbers are the same for FTP and FTPS.

Happy to have been helpful.

Have a good day.
PatrickK_WAuthor Commented:
Okay, unfortunately, despite my testing it working yesterday evening, this morning it no longer works again.

After removing FTP from the allow outbound rule, all FTP worked. Uploads, downloads etc. When the customer tested it it stopped working.

Back to the drawing board!
PatrickK_WAuthor Commented:
Some Extra info from the TMG/ISA logs. The Result code on the denied connections is:

PatrickK_WAuthor Commented:
There's also:

0x80074e21 FWX_E_ABORTIVE_SHUTDOWN against the Outbound FTPS rule
Bruno PACIIT ConsultantCommented:

the error "0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED" is strange...
Do you have only one TMG server or are you using an array of multiple TMG servers with NLB enabled !?
PatrickK_WAuthor Commented:
No, just one TMG server in a DMZ, with the TMG acting as a gateway for the client.

It seems like the reply from the FTP server is coming from a different address, although the log says its the connection from the internal address to the external address that is being denied.

I've check for any other deny rules that are applicable, although from what I've read on the internet the empty rule column means it's not a rule that is causing the deny.

I'm not familiar enough with TMG really. We had to use TMG because it's an EBS installation.

Whilst I appreciate your help greatly, do you think any other experts will see this? Or do they tend to ignore questions that already have an expert?


Bruno PACIIT ConsultantCommented:
Hi again,

You're right, experts will almost always ignore questions that already have many answers...

May be you should ask your question again in a different way...

Something like "How to allow FTPS traffic through a TMG gateway ?"

About the the "FWX_E_TCP_NOT_SYN_PACKET_DROPPED" error that means that TMG have received a IP packet that is a part of a dialog in a TCP session that TMG doesn't know...

Typically, this occurs when outgoing traffic takes a path and incoming traffic comes back from another path. TMG manages TCP sessions. When a computer initiate a TCP session with a server, TMG sees the initiate request packate and expect the answer packet to come back from the same path.
Here, it looks like TMG has received an answer to a request it has not seen before...
In this case the packet is immediatly rejected and no TMG rule is tested.

Check your IP routes on your client and server. Taking traffic captures simultaneously on client and server would be a good way to see how things go bad...

Good luck

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
PatrickK_WAuthor Commented:
Thanks for your help PaciB

Another thing I failed to mention (I thought I had in the original question) is that the TMG is double-natted and they have two WAN connections.

The TMG is in the DMZ and the router load balancing is configured to use only one WAN connection for that server.

The customer will be moving to new a new building soon and will have multiple static IPs so we can remove the double natting. I also think they'll have just one leased line so hopefully that will stop this problem.

Thanks for your assistance!
PatrickK_WAuthor Commented:
Didn't fix the problem per se, but good suggestions throughout. Problem will (hopefully) be fixed by change of location.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Forefront ISA Server

From novice to tech pro — start learning today.