| copyright | lastupdated | ||
|---|---|---|---|
|
2017-04-10 |
A destination is a definition of how to connect to a specific on-premises or cloud resource. Once the destination has been created, the {{site.data.keyword.SecureGateway}} servers will provide it with a unique public endpoint where it will listen for connections while the gateway is connected.
From within your new gateway and on the Destinations tab, click the Add Destination button to open the Add Destination panel. There are two methods for creating your destination: a guided setup that shows how each piece fits into the overall architecture and an advanced setup that provides all fields and options on a single panel.
The guided setup does not allow for the configuration of proxy information, server name indicators, or the upload of a destination-specific cert/key pair. After creation, all fields are available via the Edit Destination panel.
{: #dest-types}
The first question to answer when creating your destination is where the resource resides that you need to connect to.
The on-premises destination is for the use case where an application in the public space needs access to a restricted resource located on-premises.
The cloud destination is for the use case where an application located in a restricted network needs access to a resource that is available in a public space.
For both types of destinations, the following information is required:
- Resource Hostname: This is the IP or hostname of the resource you need to connect to.
- Resource Port: This is the port that your resource is listening on.
- Protocol: This is the type of connection your application will be making. See the table below for the various protocol options. For configuring the type of connection your resource is expecting, check the Resource authentication section.
If you have selected a cloud destination you will also need to provide a Client Port. This is the port that the {{site.data.keyword.SecureGateway}} Client will listen on to allow connections to the associated resource hostname and port.
{: #protocols}
This table provides all of the available options for how your application can initiate connections/requests with {{site.data.keyword.SecureGateway}}.
| Protocol | Description |
|---|---|
| TCP | No authentication. Your application can communicate directly with the {{site.data.keyword.SecureGateway}} servers without requiring any certificates. |
| TLS: Server Side | Transport Layer Security (TLS) is enabled and the server provides a certificate to prove its authenticity. |
| TLS: Mutual Auth | The server provides a set of certificates and your application must also provide a certificate as part of its connection. |
| HTTP | TCP connection where the host header is rewritten to match the on-premises hostname. |
| HTTPS | TLS: Server Side connection where the host header is rewritten to match the on-premises hostname. |
| HTTPS: Mutual Auth | TLS: Mutual Auth connection where the host header is rewritten to match the on-premises hostname. |
{: #mutual-auth}
For protocols enforcing mutual authentication, you will need to upload your own certificate or the server will automatically create a self-signed certificate/key pair for your application to use. This pair can be downloaded alongside the server certificate.
{: #user-auth}
The user authentication section is for managing the authorization of your requesting/connecting application with {{site.data.keyword.SecureGateway}}. This field accepts a single certificate which should be the certificate your application will be presenting alongside any connection/request.
{: #resource-auth}
Resource authentication determines how {{site.data.keyword.SecureGateway}} will attempt to connect to the defined resource. Three options are available: None, TLS (server-side), and Mutual Auth. Depending on your choice, different authentication options become available.
Enabling TLS on the connection to your resource is separate from the TLS used for User Authentication. TLS for User Authentication secures the access between your initial requesting application and {{site.data.keyword.SecureGateway}} (e.g., between your {{site.data.keyword.Bluemix_notm}} app and the {{site.data.keyword.SecureGateway}} servers) while TLS for Resource Authentication secures the connection between {{site.data.keyword.SecureGateway}} and your defined resource (e.g., between the {{site.data.keyword.SecureGateway}} client and your on-premises database).
This option becomes available by selecting TLS or Mutual Auth for your Resource Authentication. The name of the field will match the type of destination you have chosen. This field allows for up to 6 certificates to be uploaded in order to validate the certificate of the resource you are connecting to. These files will be added to the CA of connection to the resource and should contain the certificate or certificate chain that your resource will be presenting.
This option becomes available by selecting TLS or Mutual Auth for your Resource Authentication. This is used to allow a separate hostname to be provided to the TLS handshake of the resource connection.
Where the Client Certificate and Key fields appears depends on the type of destination you have chosen. In both situations, the files provided here will be used by the SG Client to identify itself for TLS connections. If no files are uploaded, the {{site.data.keyword.SecureGateway}} servers will automatically generate a self-signed pair with a CN of localhost. For instructions on how to generate a certificate/key pair, click here.
For an on-premises destination, it will appear under Resource Authentication if Resource Authentication: Mutual Auth has been selected. In this case, the client will use this certificate/key pair for its outbound connection to the defined resource. The CA of this connection will contain the certificates provided in the Cloud/On-prem Authentication field.
For a cloud destination, it will appear under User Authentication if a TLS protocol has been selected. In this case, the client will use this certificate/key pair to establish TLS listeners with the file uploaded to the User Authentication in the CA.
To prevent all but specific IP addresses from connecting to your cloud host and port, you can choose to enforce iptable rules on your on-premises destination.
To enforce iptable rules, check the box Restrict cloud access to this destination with iptable rules from the Network Security panel. Once the box is checked, you can begin adding the IPs that should be allowed to connect. If no IPs are provided, all connections to this cloud host and port will be rejected as long as the Restrict cloud access box is checked.
Note: The IPs or ports provided must be the external IP address that the {{site.data.keyword.SecureGateway}} servers will see, not the local IP address of the machine making the request.
When adding rules to iptables, you can provide individual IPs or an IP range along with either a single port or a port range. All ranges provided are inclusive. The following table has some examples as well as how they will resolve within iptables:
| IP Addresses | Ports | Results |
|---|---|---|
| 1.2.3.4 | 5000 | Only IP 1.2.3.4 from port 5000 will be allowed. |
| 1.2.3.4-2.3.4.5 | 5000 | All IPs between 1.2.3.4 and 2.3.4.5 from port 5000 will be allowed. |
| 1.2.3.4 | 5000:10000 | Only IP 1.2.3.4 from ports 5000 to 10000 will be allowed. |
| 1.2.3.4-2.3.4.5 | 5000:10000 | All IPs between 1.2.3.4 and 2.3.4.5 from ports 5000 to 10000 will be allowed. |
| 1.2.3.4 | Only IP 1.2.3.4 from any port will be allowed. | |
| 5000 | Any IP from port 5000 will be allowed. |
Specific rules can also be associated with an application. For more information on creating associated rules, see how to create iptable rules for your app.
If your on-premises destination is located behind a SOCKS proxy, you can configure the proxy settings for your destination in the Proxy Options panel.
To configure the proxy settings, you only need to provide the hostname and port that the proxy is listening on as well as the SOCKS protocol that is being used (4, 4a, 5).
Once your destination has been created, click the settings icon to see the following information:
- The destination ID required to use the API.
- On-premises destinations will have a cloud host and port. This information is required by your application in order to connect to your on-premises resource.
- Cloud destinations will have a client port. This is the port the {{site.data.keyword.SecureGateway}} Client will be listening on in order to connect your on-premises application to your cloud resource.
- The resource host and port this destination is pointed to.
- When the destination was created as well as the user who created it.
- When the destination was last modified as well as the user who modified it.