Using IBM Aspera Sync and IBM Aspera Drive with Reverse Proxy

Using Sync and Drive with reverse proxy offers the following advantages:

  • Allows large Sync transfers to make use of Proxy's round-robin load-balancing feature, thereby spreading the load, increasing efficiency, and providing a form of high availability. For details, see Load Balancing.
  • Allows Drive users outside a corporate network firewall to sync with internal corporate storage.

Configuring Sync for Reverse Proxy with Round-Robin Load Balancing

Normally, the SQL database used by async is located on the transfer server. However, when using reverse proxy in a round-robin load-balancing configuration, async can connect to multiple servers. The database must be stored in a remote NFS mount.

To configure async to store the database in a remote storage, run the following command on each of the round-robin servers:

# asconfigurator -x "set_node_data;async_db_dir,remote_dir"

Note that async proxy sessions are always logged to syslog.

Configuring Drive for Reverse Proxy with Round-Robin Load Balancing

External Aspera Drive users can view and transfer files and directories on internal Aspera servers (usually IBM Aspera Shares or IBM Aspera Faspex, although IBM Aspera Enterprise Server, Connect Server, or Point-to-Point Client can also be used) through Reverse Proxy with additional configuration. In the following diagram, the external Drive user connects to the internal Shares or Faspex server (through Reverse Proxy) through which they can access content on the load-balanced internal Aspera servers.



  1. On the internal Aspera server, set the value for <server_name> in aspera.conf as the IP address or hostname of the Proxy server by running the following command:
    # asconfigurator -x "set_server_data;server_name,proxy_address"
  2. On the internal Aspera server, choose or create an Aspera transfer user (a system user that has a docroot configured in aspera.conf) and then associate the transfer user with a Node API username and password. For more information, see the admin guide for your Aspera server. To create a system user, assign a docroot, and associate the transfer user with a Node API user, run the following commands:
    # useradd username
    # asconfigurator -x "set_user_data;user_name,username;absolute,docroot_path"
    # /opt/aspera/bin/asnodeadmin -a -u node_api_username -p node_api_passwd -x username
  3. On the load-balanced internal Aspera servers, configure the database storage as described in the previous section for Aspera Sync.
  4. On the Proxy server, create a user account that has the same username as the transfer user on the internal Aspera server.
  5. On the Proxy server, configure the transfer user with the Aspera public key by running the following commands:
    # mkdir /home/username/.ssh
    # cat /opt/aspera/proxy/var/aspera_tokenauth_id_rsa.pub > /home/username/.ssh/authorized_keys
    # chown -R username:username  /home/username/.ssh
    # chmod 700 /home/username
    # chmod 700 /home/username/.ssh
    # chmod 600 /home/username/.ssh/authorized_keys
  6. On the Proxy server, create a new SSH key pair for the transfer user to authenticate to the internal Aspera server. Run the following command in the .ssh folder to create a key pair. For key_type, specify either RSA (rsa) or ED25519 (ed25519). At the prompt for the key-pair's filename, press ENTER to use the default name id_rsa or id_ed25519, or enter a different name, such as your username. For a passphrase, you can either enter a password or press return twice to leave it blank:
    # ssh-keygen -t key_type

    Retrieve the public key from /home/username/.ssh/key_name.pub and append it to the transfer user's authorized_keys file on the internal Aspera server by using a process similar to the previous step.