Skip past navigation linksSecure Global Desktop 4.40 Administration Guide > Security > Using SGD With Firewalls

Using SGD With Firewalls

Firewalls can be used to protect various parts of a network. To use SGD you must configure your firewalls to allow packets to be sent between client devices and your SGD servers, and between your SGD servers and your application servers, as shown in the following diagram.

Diagram showing the network connections required by SGD

You might also need to configure the DNS names of web servers and SGD servers and configure SGD for use with proxy servers.

Topics on this page include the following:

Firewalls Between Client Devices and SGD Servers

Client devices never connect directly to application servers. Instead they connect to SGD using HTTP (Hypertext Transfer Protocol) or HTTPS (HTTP over Secure Sockets Layer) and the SGD Adaptive Internet Protocol (AIP). SGD then connects to the application servers on the user's behalf.

A client device must also be able to connect to any SGD server in the array because a user's SGD session and a user's application sessions can be hosted on different SGD servers.

The following table lists the ports you might need to open to allow connections between client devices and SGD servers.

Source Destination Port Protocol Purpose
Client SGD Web Server 80 TCP Standard, unencrypted HTTP requests and responses.

Used to display webtops and for web services.

Client SGD Web Server 443 TCP Secure, encrypted HTTPS requests and responses.

Used to display webtops and for web services.

Client SGD server 3144 TCP Standard, unencrypted AIP connections.

Used for control and application display updates.

Client SGD server 5307 TCP SSL-based secure, encrypted AIP connections.

Used for control and application display updates.

Ports 80 and 443 are the Internet-standard ports for HTTP and HTTPS. Port 443 is only used if HTTPS is enabled on the SGD Web Server. You can configure the SGD Web Server to use any port you want. If you use your own web server with SGD, you must still open the ports used by the SGD Web Server because this web server provides the web services needed to access SGD.

In a default installation, ports 3144 and 5307 must both be open in the firewall. The SGD Client initially makes a secure connection on port 5307, but once the user has authenticated, the connection is downgraded to a standard connection on port 3144.

If you enable SGD security services and use only HTTPS, only ports 443 and 5307 must be open in the firewall.

If it is not possible to open the required ports, you can use firewall traversal to direct all SGD traffic through a single port, usually port 443. See Firewall Traversal (Firewall Forwarding) for details.

Ports 3144 and 5307 are registered with the Internet Assigned Numbers Authority (IANA) and are reserved for use only by SGD.

Firewall Traversal (Firewall Forwarding)

Where it is not possible to open the required ports between client devices and SGD servers, you can use firewall traversal to give users access to SGD using a single port, usually port 443. With firewall traversal, you configure the SGD servers to listen on port 443. The SGD servers then forward all traffic that is not AIP traffic to the SGD Web Server. For this reason, firewall traversal is sometimes called firewall forwarding.

If you are using firewall traversal, you must not use connection definitions to downgrade a user's connection to a standard connection. With firewall traversal, a user's connection to SGD must always be secure.

To configure an SGD for firewall traversal:

  1. Log in as superuser (root) on the primary SGD server in the array.
  2. Ensure that no users are logged in to SGD and that there are no application sessions (including suspended application sessions) running in the array.
  3. Enable SGD security services.

    See Securing Connections Between Client Devices and SGD Servers for details.

  4. Secure the SOAP connections to each SGD server.

    See Securing the SOAP Connections to an SGD Server for details.

  5. Configure SGD to use TCP port 443 for encrypted connections.
    1. In the SGD Administration Console, click the Global Settings » Communication tab.
    2. In the Encrypted Connections Port field, type 443.
    3. Click Save.

    Alternatively, use the following command:

    Skip past command syntax or program code# tarantella config edit --array-port-encrypted 443

    Use the following command to check that the change to the port number has taken effect.

    Skip past command syntax or program code# tarantella config list --array-port-encrypted
  6. Configure each SGD Web Server in the array to bind to localhost:443.
    1. On each SGD server in the array, edit the Apache configuration file.

      The configuration file is /opt/tarantella/webserver/apache/version/conf/httpd.conf.

    2. Change the <IfDefine SSL> directive in SSL Support section.

      Change Listen 443 to Listen 127.0.0.1:443.

    3. Save the changes.
  7. Configure each SGD server in the array to forward HTTP traffic to localhost:443
    1. In the SGD Administration Console, click the Secure Global Desktop Servers tab and select an SGD server.
    2. Click the Security tab.
    3. In the Firewall Forwarding URL field, type https://127.0.0.1:443.
    4. Click Save.
    5. Repeat these steps for each SGD server in the array.

    Alternatively, use the following command:

    Skip past command syntax or program code# tarantella config edit --array --security-firewallurl https://127.0.0.1:443

    Use the following command to check that firewall forwarding URL has taken effect:

    Skip past command syntax or program code# tarantella config list --server serv --security-firewallurl
  8. Restart each SGD Web Server in the array.
    Skip past command syntax or program code# tarantella webserver restart --ssl
  9. Restart each SGD server in the array.

    Restart the primary SGD server last.

  10. Ensure that users connect to SGD using an HTTPS URL.

    Users might have to edit their client profiles to ensure that the SGD Client uses the correct URL.

Firewalls Between SGD Servers

A network might contain firewalls between the SGD servers in an array, for example, if you have multiple offices each containing an SGD server. The SGD servers in an array must be able to connect to any other member of the array.

The following table lists the ports you might need to open to allow connections between SGD Servers.

Source Destination Port Protocol Purpose
SGD server Another SGD server 515 TCP Used when moving print jobs from one SGD server to another using the tarantella print move command.
SGD server Another SGD server 5427 TCP Used for connections between SGD servers to allow array replication and sharing of both static and dynamic data across the array.

Port 5427 is registered with IANA and is reserved for use only by SGD.

Firewalls Between SGD Servers and Application Servers

Client devices never connect directly to application servers. Instead they connect to SGD using HTTP or HTTPS and the SGD AIP protocol. SGD then connects to the application servers on the user's behalf.

The ports used for connections between SGD servers and application servers depends on the application type and the connection method used to log in to the application server . Other ports are needed to provide support while using applications.

The following table lists the ports you might need to open to allow connections between SGD Servers and application servers.

Source Destination Port Protocol Purpose
SGD server Application server 22 TCP Used to connect to X and character applications using Secure SHell (SSH).
SGD server Application server 23 TCP Used to connect to Windows, X and character applications using Telnet.
Application server SGD server 137 UDP Used for WINS services with client drive mapping. The server binds to this port at start-up only if WINS services are enabled.
Application server SGD server 139 TCP Used for client drive mapping services. The server binds to this port at start-up, whether or not client drive mapping services are enabled.
SGD server Application server 512 TCP Used to connect to X applications using rexec.
Application server SGD server 515 TCP Used to send print jobs from the application server to an SGD server.
SGD server Application server 3389 TCP Used to connect to Windows applications configured to use the Microsoft Remote Desktop Protocol (RDP) protocol.
SGD server Application server 3579 TCP Used for connections between the primary SGD server and the SGD load balancing service on an application server.
Application server SGD server 3579 UDP Used for connections between the SGD load balancing service on an application server and the primary SGD server.
SGD server Application server 5999 TCP Used to connect to Windows applications, if the application configured to use the Wincenter protocol and the connection method is Telnet. The Wincenter protocol is no longer supported but might be used by legacy Windows application objects.
Application server SGD server 6010 and above TCP Used to connect X applications to the protocol engines on the SGD server.

Ports 137 and 139 might be used by products providing Windows file and print services, such as Samba. You only need to open these ports if you are using client drive mapping.

For X applications, port 6010 and above is only used if the connection method for X applications is Telnet. If the connection method is SSH, the connections use port 22. If you enable audio for X applications, all ports must be open between the application server and SGD. This is because the SGD audio daemon connects to the SGD server on random ports. This applies even if the connection method is SSH.

Port 3579 is registered with IANA and is reserved for use only by SGD. You only need to open these ports if you are using SGD Advanced Load Management.

Other Firewalls

SGD needs to make connections to any authentication services and directory services you might be using.

The following table lists the ports you might need to open to allow connections between SGD Servers and other services.

Source Destination Port Protocol Purpose
SGD server Windows server 88 TCP or UDP Used to authenticate users from a Microsoft Windows domain.
SGD server Windows server 137 UDP Used to authenticate users from a Microsoft Windows domain.
SGD server Windows server 139 TCP Used to authenticate users from a Microsoft Windows domain.
SGD server LDAP directory server 389 TCP Used to authenticate users, or to assign applications to users, using an LDAP directory.
SGD server Windows server 464 TCP or UDP Used to allow users to change their password if it has expired.
SGD server LDAP directory server 636 TCP Used to authenticate users, or to assign applications to users, using a secure connection (LDAPS) to an LDAP directory.
SecurID Authentication Manager SGD server 1024 to 65535 UDP Used to authenticate users using SecurID.
SGD server Windows server 3268 TCP Used to authenticate users from a Microsoft Windows domain.
SGD server SecurID Authentication Manager 5500 UDP Used to authenticate users using SecurID.

Ports 88, 464 and 3268 are only required if you are using Active Directory authentication. Ports 88 and 464 can use either the TCP or UDP protocol depending on the packet size and your Kerberos configuration, see Active Directory Authentication for details.

Ports 137 and 139 are only required if you are using Windows Domain Authentication.

Ports 389 and 636 are only required if you are using LDAP Authentication or Directory Services Integration.

Ports 1024 to 65535 are only required if you are using SecurID Authentication. For the RSA SecurID Authentication Manager to communicate with an SGD server (acting as an Agent Host), all ports from 1024 to 65535 must be open from the Internet Protocol (IP) addresses of the Master and Slave Authentication Managers to the IP addresses of all Agent Hosts.

Port 5500 is only required if you are using the SecurID authentication. For the RSA SecurID Authentication Manager to communicate with an SGD server (acting as an Agent Host), port 5500 must be open from the IP addresses of the Host Agents to the IP addresses of the Master and Slave Authentication Managers.

Related Topics