Planning the deployment
LiquidFiles is server software, like a web or mail server, and needs to be installed somewhere where it can run 24x7 to function properly.
A typical production installation of LiquidFiles looks like this:
The LiquidFiles appliance is typically deployed in a DMZ, next to your mail and web server. For normal usage, it will also need to be reachable from the Internet.
For test installations, you can deploy LiquidFiles on pretty much any system, including running on VMware or similar virtualization platforms on your Mac or PC. Please beware though that similarly to a web server, LiquidFiles needs to be running and connected for anyone to be able to download any files from it.
LiquidFiles is a virtual appliance, meaning that it will come ready with it's own operating system, all the required components and the application itself. It is not possible to install LiquidFiles on an already running and installed system. It needs to be installed as a separate server. It aims to be as flexible as possible, and you have three basic installation options.
Just like any server, you can use the downloadable ISO image to burn a CD and install on pretty much any available physical server.
This installation option is likely to provide the maximum performance as there's no other resources competing with the available resources (CPU, memory and disks).
All data is kept within your environment for maximum security and performance.
This is the most popular installation option. Using your existing VMware, Microsoft Hyper-V, Citrix Xen or similar virtual platform, you can install LiquidFiles as another virtual server.
While the performance is not going to be as great as a dedicated physical server, in the overwhelmingly majority of cases it's going to be adequate performance and you will get the typical virtual server benefits of sharing physical server space, power, cooling, etc.
All data is kept within your environment for maximum security and performance.
If you want to use the benefits of running LiquidFiles in the Cloud, you can either deploy LiquidFiles in any of the available Amazon EC2 data centres, or deploy in any other cloud server provider that offers you to run your own virtual system where you can install your own system using an ISO image.
Performance and Security is going to be similar to your other virtual servers in your chosen cloud provider.
The following table outlines the network connections that the LiquidFiles requires to operate (IP addresses assumed to be as in the network diagram above).
|Protocol / Function||source||destination||port||description|
|http(s)||any||10.0.2.10||80 & 443||http and https is allowed from anywhere. This is how all files are uploaded and downloaded and all normal user interaction is via http or https.|
|DNS||10.0.2.10||DNS server||53 (UDP)||The appliance needs DNS to function properly.|
|10.0.2.10||any / email relay server||25||The appliance needs to send emails, either via an email relay server or directly to the Internet.|
|updates||10.0.2.10||any||80 & 443||The appliance downloads updates over http and https.|
|admin||10.0.1.0/24||10.0.2.10||222||Use specific management ip's if you can for ssh access to the appliance.|
|LDAP||10.0.2.10||LDAP server||389/636||If LDAP authentication is enabled, the appliance needs connections to the LDAP server.|
|NTP||10.0.2.10||any / ntp server||123 (UDP)||If NTP time synchronisation is enabled, if NTP pool authentication is enabled the destination needs to be any.|
|Emaildrop||any||10.0.2.10||25||If you have enabled Emaildrops.|
|FTPdrop (FTP)||any||10.0.2.10||21, 44000-44100||If you have configured FTPdrops and wish to use FTP.|
|FTPdrop (SFTP/SCP)||any||10.0.2.10||22||If you have configured FTPdrops and wish to use SFTP/SCP.|
In most cases, if deployed behind a firewall or similar, you will also need to configure the firewall for address translation — translating a public address to the private 10.0.2.10 address. You will also mostly certain need to configure DNS so that a published DNS points to the public ip address of the Filetransfer appliance.
Restricting outgoing http/https
Some companies wish to limit outgoing ip access from a certain ip address instead of enable outgoing http and https for any external ip address. Unfortunately that's not really possible since LiquidFiles is using download mirrors for a few functions and these change from time to time.
If it makes things easier in your environment, you can configure a Proxy in Admin → System → Network and that will make all outgoing connections use the proxy instead of going direct.
If you don't have or want to use a proxy, you will need to enable unrestricted outgoing connections on TCP port 80 (http) and TCP port 443 (https) from the LiquidFiles system towards the Internet for LiquidFiles to operate properly. With a proxy, the proxy needs to permit unrestrcted outgoing connections on TCP port 80 (http) and 443 (https).
The following is a list of all connections performed by LiquidFiles during normal operation:
- License and LiquidFiles update checking by connecting to https://license.liquidfiles.com.
- LiquidFiles updates are downloaded using https from the Amazon S3 cloud. (Amazon does not specify their IP address ranges for S3, these are most likely not static as data centers are added to the Amazon AWS cloud space).
- When Remote support is enabled it's using TCP Port 443 for connection to access.liquidfiles.com (please note that we use port 443 becuase it's often already opened, but we are not using https so if you check for valid https using an ips or content inspection firewall the support connection will likely fail).
- System updates are downloaded from a range of CentOS download mirrors, EPEL download mirrors & Amazon S3 using https.
- ClamAV updates are downloaded from a range of randomized http servers around the world.
- If geolocation/maps integration has been enabled (it's enabled on default in Admin → Settings), it will use connections to https://geoip.liquidfiles.com for ip based geolocation lookups.
Some organisations like to use different names for internal and external resources, giving resources like LiquidFiles names like liquidfiles.company.com and liquidfiles.local for external and internal use respectively, just like they would if LiquidFiles was an intranet application.
LiquidFiles is a little bit different from most other applications though as it sends email referencing itself (something a webmail system for instance never would do). And one of the key architectural decisions with LiquidFiles is — don't break how emails normally work. Consider the following message:
From: <email@example.com> To: <firstname.lastname@example.org> CC: <email@example.com> Subject: You're fired Homer, you're fired. Here's a link to your letter of dismissal: https://liquidfiles.powerplant.com/message/6Q6U1D9LynIrcxmD0SrN0r
If we assume that firstname.lastname@example.org and email@example.com are internal users and firstname.lastname@example.org is external. If we sent a link with the URL to the LiquidFiles system as https://liquidfiles.local, email@example.com would not be able to reach it. If we split the email and sent individual emails to firstname.lastname@example.org and email@example.com with links to https://liquidfiles.local and firstname.lastname@example.org with a link to https://liquidfiles.powerplant.com, none of the receipients would see who else is copied on the message, one of the key functions of the email header. We therefore have to send the same email to everyone.
Our only workable option is to make the same name resolvable and reachable from everywhere. In this example that would be: liquidfiles.powerplant.com.
Depending on our infrastructure, this could be accomplished by:
- Making sure that the public ip address for the LiquidFiles system is routable everywhere
- Use split view/dual DNS to either provide the external or internal ip address for the LiquidFiles system depending on the location of the user.
In most cases, split view or dual DNS configuration is the preferable option. This will enable you to use an external ip address for liquidfiles.company.com for external users, and an internal ip address for internal users. If we use the same ip address both internally and externally, we often end up having to address translate external addresses when trying to make them reachable in a DMZ from internal addresses. But whatever method you are comfortable with, as long as you can use the same name (liquidfiles.company.com) from anywhere, it really doesn't matter how you achieve it.
Another thing that often causes issues, primarily with test installations in large enterprises, is delivering emails.
LiquidFiles has two options when delivering emails:
- Direct delivery — use DNS to lookup the mail server for each recipient and deliver the email directly with SMTP. This is the same functionality as any email server on the Internet would use to send emails.
- Use an Email relay server — send all emails to a configured email relay server. Let the email relay server deliver all emails on behalf of the LiquidFiles system.
The reason why this sometimes can be challenging is that with 1) connections from the inside out is often firewalled in large enterprises, so the LiquidFiles system can't connect to the required SMTP servers and deliver the emails. And with 2) the typical email server configuration does not permit the unrestricted email relaying LiquidFiles requires.
To expand on the latter. When the LiquidFiles system sends an email, the email header looks something like this:
From: <email@example.com> To: <firstname.lastname@example.org> CC: <email@example.com> Subject: You're fired
But could just as easily be:
From: <firstname.lastname@example.org> To: <email@example.com> CC: <firstname.lastname@example.org> Subject: What took you so long?
The From field is going to be the email address of the user who is sending the message in LiquidFiles and the To, CC and BCC fields are going to be whatever the logged in user has entered. Usually the From field is what's causing issues as it can be an internal user (like email@example.com above) or an external user (firstname.lastname@example.org). We can therefore not place any limitations on either the From or the To field.
If we compare this how the email header looks when sending from something like Outlook. In Outlook the From field is always going to be the same. In most email servers, the user will have to authenticate to relay (send) the email and when they authenticate, they have to send as the user they authenticated as. So if the email above was composed by email@example.com using Outlook to send through his local Ms Exchange server, Outlook would authenticate as firstname.lastname@example.org and allow him to send the email. But email@example.com could not authenticate as firstname.lastname@example.org and then enter email@example.com in the From field. The email server would not permit this.
If we instead compare the LiquidFiles email to how say a NAS server email alert email looks. This is again different in that the To field is always the same. In the email server we can configure emails to always be allowed to something like firstname.lastname@example.org so that all devices that sends monitoring emails can send them to this address.
And this is where it is sometimes difficult to test LiquidFiles in environments that are locked down. LiquidFiles needs to be permitted to send emails From anyone and To anyone. This is of course unless you are building a strict internal system, in which case you can limit to only be permitted From and To the specific addresses you permit. But in the overwhelmingly majority of cases, you will have to permit the LiquidFiles system to send From anyone and To anyone.
There are typically two options to achieve this when using the email relay option:
- Configure the email server you are relaying through to permit the ip address of the LiquidFiles system unrestricted email relay permissions.
- Configure a user in the email server (email@example.com) unrestricted email relay permissions in the mail server.
In both cases, please refer to your email server configuration for instructions how to configure unrestricted email relaying for the LiquidFiles system.
The only other option is to not use an internal email server to relay the emails and instead use a public available email relay service like ElasticEmail. Mandrill (by the same company as Mailchimp) is a service specifically built to relay emails from system like LiquidFiles. In case of a strict locked down network, you would only need to open connections from the ip address of the LiquidFiles system to smtp.mandrillapp.com instead of permitting unrestricted SMTP access, or change the configuration of your mail server. So this may well be the simplest option.
If you run into problems with email delivery, please see the Troubleshooting Email Delivery article.
Please continue on the System Requirements page.