| copyright | lastupdated | ||
|---|---|---|---|
|
2017-04-25 |
{: #osi}
What layer of the OSI model does the Secure Gateway service represent?
The Secure Gateway service represents layer 4 of the OSI model.
{: #tls}
What version of TLS does the Secure Gateway service support?
The Secure Gateway service supports TLS version 1.2.
{: #disabled}
Why would you want to disable a gateway or destination?
You might want to disable a destination or gateway for one of the following reasons:
- You create a destination, but you have not set up the security. In this case, you might disable the destination until its security is set up.
- You do not want the service to be available to users because you are making some updates to the service. In this case, you might temporarily disable the necessary gateways and wait for the service to be updated.
- You have set up all your gateways and destinations on the front end, but your backend is still building. In this case, you would disable your gateways or destinations until the backend build is complete.
For more information on disabling a gateway or a destination, see how to manage your Secure Gateway service instance.
{: #automation-spaces}
A customer environment has one org and three spaces. One space is for development, another for staging, and the final one for production. Should the customer create a single Secure Gateway instance or multiple (e.g., one for each space). If the customer can create multiple gateways, are there any considerations for reusing a Node.js application to create a gateway and destination in each space?
- You can create a single Secure Gateway instance for all three spaces. However, you must remember the gateway and destination limitations for your specific plan.
- There are no additional considerations for reusing a Node.js application as no service bindings are required by Secure Gateway.
{: #automation-orgs}
A customer environment has three orgs: one for development, one for staging, and one for production. Is a Secure Gateway service instance required for each org and is the configuration available to all spaces within that org?
- You are not required to have a Secure Gateway service instance in each org. You could have an instance in one org and use the gateways within that instance from all of your other environments. With this setup, you must remember the gateway and destination limitations for your specific plan.
- You can have a Secure Gateway service instance in each org and the configuration will be available to all your spaces.
{: #app-space}
Do you need to run the Node.js app in the same {{site.data.keyword.Bluemix_notm}} space as the Secure Gateway service?
No, you do not need to run your app in the same {{site.data.keyword.Bluemix_notm}} space as the Secure Gateway service.
{: #server-logs}
Can you retrieve error logs for the Secure Gateway server?
Error logs on the server cannot be retrieved. Only errors that are made at the time of the request can be seen.
{: #states}
What are the different lifecycle states of gateways and destinations?
The 1.7.0 release introduced a new tiered plan pricing model. With this model came the ability to mark both Gateways and Destinations as 'Active' or 'Inactive'. Part of the new plan billing structure charges the user for the number of Gateways and Destinations that they have.
- Inactive items are not billed
- Inactive Destinations do not have a provisioned cloud port.
- All Destinations within an inactive gateway will also be inactive and cannot be reactivated until their Gateway is also set Active.
- Inactive items are considered Non Functional. Inactive items cannot be in the any of the Functional states.
When a gateway or destination is marked active it will be billed. Active states for Gateways and Destinations are below:
- Enabled - the gateway or destination is ready for use under normal circumstances.
- Disabled - the gateway or destination has been disabled.
- Gateways - clients will be unable to flow data to the disabled gateway.
- Destinations - clients will be unable to create connections to these disabled destinations.
{: #data-size}
How do I know the data activities through Secure Gateway Client?
On SecureGateway Client, change the log level to TRACE. The following information will be displayed after requests are sent.
Data size sent from request application:
[TRACE] Connection #<connection ID> transmitted data: <size> bytes
Data size sent from destination:
[TRACE] Connection #<connection ID> received data: <size> bytes
{: #connect-num}
How do I get the real-time connection information, the data size sent and received from Secure Gateway Client?
- On Secure Gateway client interactive command line:
Type
sto print the connection status details. - On Secure Gateway client UI, click the Connection Information menu
The following connection statistics would be displayed:
- Overall data size transmitted.
- Overall data size received.
- The number of total connections.
- Real-time active connections.
Note: The number of Current Connections on Secure Gateway UI is not rendered in real-time. Please use the above ways on Secure Gateway client to retrieve the real-time connection information.
{: #secure-app}
What are the recommended configurations to make my connections more secure?
Enable Mutual Authentication for both sides of on-premise destinations makes Secure Gateway more secure. On User Authentication side, enable mutual authentication to restrict the access of Secure Gateway cloud node by authenticating using a client certificate when the request is over TLS/HTTPS. On Resource Authentication side, enable mutual authentication to provide appropriate credential when connecting to destination endpoint, ensure secure/encrypted access to on-premise resource. Please see Configuring Mutual Authentication and Node.js TLS Mutual Authentication for more information.
The Secure Gateway cloud host and port of an on-premise destination is in the public space; therefore it is allowed everyone to access by default. To control the traffic accessing on Secure Gateway, set iptable rules to only allow access by a specific range of IPs and ports to secure on-premise resources. Please see IP Table Rules for more information about how to configure the iptable rules on Secure Gateway.
Configure Access Control List support to allow or restrict access to on-premises resources would make the on-premises destinations more secure by specifying the access right on the specific destination host and port. It is recommended to define the allowed or restrict HTTP/S routes on the ACL entries as well to enhance the security of on-premises destination. Please see Access Control List and HTTPS/Route Control using the ACL for more information.
It is recommended to set the UI password to restrict the access of Secure Gateway Client UI. Please see Interacting with the Client for more details about how to set the password using startup configuration or interactive commands on Secure Gateway Client terminal command line.