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: http://blogs.isaserver.org/pouseele/2006/10/08/solving-the-secure-ftp-dilemma-with-isa-server-2004-and-2006/). 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
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
ASKER
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
Thanks
tmg-rules.JPG
tmg-ftps.JPG
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
Thanks
tmg-rules.JPG
tmg-ftps.JPG
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.
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.
ASKER
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
Thanks
tmg-rules.JPG
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
Thanks
tmg-rules.JPG
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.
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.
ASKER
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!
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!
ASKER
Sorry, I misread your post.
Rather than removing the filter I removed the FTP protocol from the 'bottom' rule.
I'll carry on testing,
Rather than removing the filter I removed the FTP protocol from the 'bottom' rule.
I'll carry on testing,
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.
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.
ASKER
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!
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!
ASKER
Some Extra info from the TMG/ISA logs. The Result code on the denied connections is:
0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_D
0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_D
ASKER
There's also:
0x80074e21 FWX_E_ABORTIVE_SHUTDOWN against the Outbound FTPS rule
0x80074e21 FWX_E_ABORTIVE_SHUTDOWN against the Outbound FTPS rule
Hi,
the error "0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_D
Do you have only one TMG server or are you using an array of multiple TMG servers with NLB enabled !?
the error "0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_D
Do you have only one TMG server or are you using an array of multiple TMG servers with NLB enabled !?
ASKER
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?
tmg-log.xls
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?
tmg-log.xls
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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!
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!
ASKER
Didn't fix the problem per se, but good suggestions throughout. Problem will (hopefully) be fixed by change of location.
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.