Unable to connect to on-premise REST service from K2 Cloud, although SDA was configured.
K2 Cloud Secure Data Access (SDA) requires initial installation with help of K2 Cloud Operations/Professional Services. This part involves the initial pairing of gateway node in K2 Cloud tenant environment (runs as a service on the K2 Cloud node) and Controller node deployed as a VM in client's environment (more details). Pairing is configured between internal controller node in on-premise network (IP address of Access Controller VM) and external address or addresses where FQDN of K2 Cloud tenant server(s) must be used along with ports 808 or 808 and 809 (these ports are predetermined and you should use 808 for single node cloud environments or 808 and 809 for two node environments).
As part of SDA deployment, a predetermined set of ports gets opened on the K2 Cloud side and it can be further used by the client to enable access to different on-premise services. Predetermined set of External Node Bind Ports and Callback Ports can be found in the "Overview, Installation, and Configuration of K2 Cloud Secure Data Access" document. With this in place the K2 Cloud client has control over a controller node web UI which allows them to set up Reverse Access Rules (two rules have to be setup for each on-premise LOB system for production K2 Cloud Environments which always have two nodes, and one for the rest of environments with one node).
Let's consider an example of exposing an on-premise REST web service using SDA. Assuming you have a single node K2 Cloud environment you can pick up a predetermined K2 External Node Bind Port 17001 and, as you have only one node, you will need to use Callback Port 17101.
External Node Bind Ports are ports on which the Gateway will accept connections from K2 Cloud and which is used in the K2 Service Instance configuration. Callback ports are open from K2 Cloud side to be reachable by Controller Node from on-premise client's network and they also can be tested by K2 Support using telnet from within the K2 network. This is the port on which data payload is returned to the gateway from the controller/LOB system.
Your reverse access rule in this scenario will look as follows:
Rule Name = K2_Cloud+Node_FQDN:808
Internal Service Address = FQDN of LOB server, e.g. your IIS server FQDN
Internal Service Port = port of LOB system in on-prem, e.g. 443
External Node Bind Address = 0.0.0.0
External Node Bind Port = 17001 - this will be the port through which K2 Cloud will be connecting to LOB system (it actually will be hitting local gateway service listening on this port)
Callback Address = 0.0.0.0 Callback Port = 17101 - this will be the port through which the controller returns data from LOB system back to K2 Cloud, so it is reachable from the client network/K2 internal network
If initial setup was not performed correctly you won't be able to access any on-premise service through SDA. If it is only one which cannot be accessed then you should review SDA reverse access rules configured for it. In case of a single node K2 Cloud environment you will need one rule pointing to the callback port with a lower number corresponding to the first node (e.g. for External Node Bind Port 170001 you will need to pick a port 17101 out of 17101 and 18101 Callback Ports pair).
For the HTTPS REST service you will also need to ensure connectivity through the FQDN name associated with its HTTPS certificate, that requires adding a hosts file entry on the K2 Cloud side which will ensure resolution of this FQDN into K2 Cloud node loop-back IP address (127.0.0.1). With the entry in place the SDA service will be intercepting traffic directed to FQDN + External Node Bind Port and ensuring further communication with the on premise server. You can add hosts file entry requesting this through K2 support ticket.
It is also recommended to ensure that for the HTTPS rest service within its swagger.json file host value should be specified as FQDN of the server.