Idea Details

Option in File Transfers (JOBF) to define in which direction the connection is established

Last activity 06-13-2019 10:09 AM
jamcl01's profile image
06-22-2018 11:37 AM

Due to internal regulations, one of our customers wants to open their firewall only in one direction. For the Automic File Transfer (#JOBF), that means, an IP-connection is only possible from the destination-agent to the source-agent.


The normal behavior of a JOBF is to first establish a connection from the source- to the destination-agent. If this is not possible, e.g. because the firewall allows only connection in the opposite direction, the JOBF waits for the network timeout and only then opens the connection in this opposite direction. The effect is, that in case of this firewall configuration, files transfers take longer. With a large number of files, this sums up to unacceptably long runtimes of JOBFs.


Therefore, the JOBF should have an option to decide in which direction the connection is initially established.


E.g., a new checkbox could be edited to the Transfer Settings

"Transfer Settings" settings of a JOBF


10-16-2018 07:16 AM

Hi Carsten_Schmitz,

I totally agree with you and I also reject the idea Security by Obscurity. My previous answer does not reflect my opinion, instead it should only show how some others are thinking.

Kind regards


10-16-2018 06:55 AM

Sorry to take that a step (or six ) further, but since you said it ...


security by obscurity


While I know this as a common line of thinking, I fully reject this. Not because Security by Obscurity doesn't work (fwiw, it doesn't), but specificially, because there is no demostratable security gain when chosing TCP-DROP over TCP-REJECT. There is only home-made problems for legitimate users diagnosing their connectivity problems, as I think this thread clearly shows. Or, as the guy who wrote Putty put it (no pun intended ):


Many people advocate configuring packet filters with a mostly-closed policies that drop packets that they do not know to be safe. This leads to problems for users that are hard for them to diagnose while offering no additional security.

With REJECT, you do your scan and categorise the results into "connection established" and "connection rejected".


With DROP, you categorise the results into "connection established" and "connection timed out".


This also easily leads to the train of thought where people drop ICMP Ping on the Internet, which is a clear RFC violation, and such hosts should not be allowed on the internet.




10-16-2018 05:43 AM

There can be security reasons that you only allow one direction in the firewall, e.g. from the internal network to a DMZ.


And the reason that the firewall discards the packages instead of sending a reset could also be part of the security: security by obscurity.

07-13-2018 06:27 AM

I'm honestly not sure it works in all cases. The agent name is NOT neccessarily the DNS name of the server. Is it known whether the agent does DNS resolves and if so, if it actually honors the hosts file? I was under the impression the engine relays the IP addresses to the source and target agents without ever using DNS.


At least when the agent is behing a NAT, the true destination IP needs to be specified in the agents .ini file, because the IP provided by (I assume) the engine does not work. At least in those cases, there is definetly no DNS resolution going on. A TCP-RETURN would still work regardless, because that's on IP level.




07-13-2018 05:43 AM

To avoid the delay generated by the timeout of the firewall, you can define unreachable destinations for the agents in the [HOSTS]-section. Doing that, the establishment of the communication fails and the direction of the communication immediately changes.


U2000063 Connection to Agent 'AGENTNAME1' with connection data 'dummy.not.reachable' not possible.

U0011124 Selection started with filter '/uc4_transfer_dmz/20180304/*' ...

Here an example for the [HOSTS]-section:


; Overwrite IP destination in case of IP NATing problems (e.g. firewalls)
; <UC4-name>=<dns-name> or
; <UC4-name>=<ip-addr>


Nevertheless I support the idea.

07-12-2018 09:02 AM

Hi Krum_Ganev,


I'm far from being certain on the internals of their file transfers, but the bi-directional part of communication may be taken care of by stateful firewalls. Statefulness of firewalls is oftentimes implied, and means that once one side initiates a communication, the return traffic is permitted through. But I don't know for sure ... guess Automic will just have to figure it out


Cheers to you too,


07-12-2018 08:55 AM

You are correct Carsten_Schmitz and this is how Automic is handling the connection.

The sending agent tries to establish a connection to the receiving agent. If this attempt fails (for example, because of Firewall settings), it notifies the Automation Engine. The FT request is then sent to the receiver which now tries to establish a connection to the sender. After the connection has been established, the receiving agent transfers the FT request to the sender.


But in all cases the communication is Bi-directional.
Again as per documentation :

Automation Engine sends the complete file transfer request (including wildcard specifications in partially qualified file transfers) to the source agent. The sending agent is responsible for resolving the request (determining the files).

As far I was able to understand the initial request it was to have the connection allowed only in one direction which is not possible in the current setup.


Another interesting thing can be found in UC_HOSTCHAR_DEFAULT and the explanation of FT_ASYNC_QUIT_MAX/MIN/NUM.


07-12-2018 07:59 AM

Having thought somewhat more about the security: I don't think it changes matters to have that selector, at least it doesn't make matters worse, won't it?


In my understanding, at this time, the engine instructs agent A to talk to agent B. Failing that, it instructs agent B to talk to agent A. It doesn't matter which agent is sender and which is receiver. A switch to skip the first attempt and go directly to the fallback option doesn't affect the security in my view.


Not saying it's secure right now, just that it won't get any worse by having such a switch?

07-12-2018 07:50 AM

the JOBF waits for the network timeout


That option might be nice (not sure about the security implications, as per Krum_Ganev 's remark), BUT:


In the mean time, why not configure the firewall correctly?


Waiting for a timeout only becomes neccessary because the firewall discards the packages (TCP-DROP).


Instead, one can configure a firewall to block an outgoing connection with a TCP-RETURN, where it sends a TCP RST packet, or an ICMP unreachable packet. The client then knows that it won't get through, and doesn't even need to wait for a timeout.

07-09-2018 02:17 PM



As far as i am able to understand the file transfer protocol used by Automic your request seems imposible.

I want to mention that i am not an expert, just a newbie.


For the FileTransfer you have always two sides - source and destination. Automic is using p2p (i may be terribly wrong about this).

Source agent is dialing the destination agent via the ports they are configured to work (2300 for example).

Source agent introduce himself to the destination agent using secure keys, the destination agent accept the introduction (at this point you have one way connection). Now its time for destination agent to send his key to the source agent.

After confirmation for correct keys the connection is established. You have now bi-directional communication from source to destination.

Please note that Automation Engine plays realy small part (almost none) for initiating a connection (socked thread) for Managed File Transfer.

Having said that your request seems highly unlikely without total redisign of the filetransfer protocol used by Automic.

One way connection will not allow the exchange of the security keys.


You have full right to rebut my view over this topic.


Cheers from sunny Bulgaria,

Krum Ganev