You might wonder why we really need a separate discussion for a VCN networking design in respect to OIC SFTP running in the Oracle Services Network. There are many reasons to have it and in this blog we will discuss about some key points and customer requirements when it comes to access the OIC SFTP. I need to tell you that what we are going to present next are networking configurations and topologies already deployed in my customers OCI production networks.
Let’s dig into details and specifics of this solution.
Once an OSN OIC instance is provisioned it comes with an SFTP server that is accessed by the customer using a hostname. The OIC SFTP server is also assigned with a public IP address from the OSN public IP space. That being said, the SFTP server is reachable over the Internet. So, each and every time when a new OIC will be provisioned, the associated SFTP server will have a different public IP address. This is the first important point, each and every public IP address assigned to our SFTP servers needs to be whitelisted in the on-premises firewall(s). Well, even if it appears to be a simple task in most of the cases it will take a lot of time to be implemented since internal tickets needs to be opened with the security teams handling the on-premises perimeter firewalls.
Another important aspect raised by our customers is how to simply and reliable restrict the access to OIC SFTP when the requests are originated let’s say from all over the world?
If the OIC SFTP is used by our customers’ customers, how we can present the service in a transparent way. The transparent way in this context means that the end customers should not perform any action when a new SFTP is deployed and continue to use the initial SFTP configuration (no new public IP address, no new hostname).
Among others, the above requests are the most important when it comes accessing the OIC SFTP over the Internet.
The solution we proposed to accomplish the above requests was to use the Public Flexible Load Balancer in a subnet of a customer VCN. The solution is depicted in the following networking diagram:
Worth to mention that we can insert the OCI Network Firewall or any other OCI Marketplace firewall in-between Internet Gateway and the LBaaS or between the LBaaS and the NAT Gateway or both.
The usage of the Internet Gateway in this discussion is quite clear (to receive the Internet SFTP originated sessions) but what is the scope of NAT Gateway. In order for this solution to work, we need LBaaS to be able to communicate with the OIC SFTP servers (by using their public IP addresses):
1) Backend servers health-check:
When the LBaaS performs the health-check, the source IP address is the private one assigned to the LBaaS from the subnet where it is deployed, so using the NAT Gateway the private IP address of the LBaaS will be source NAT-ed and the new source IP address will the one assigned to the NAT Gateway (129.158.241.125 in our case). In this way the health-check traffic will be transported over the OCI Backbone network to reach individual OIC SFTP servers.
2) Internet SFTP user traffic;
After the Internet user SFTP traffic is received on any of the LBaaS listeners configured depicted by the blue, orange and green lines above, all using the public IP address of the LBaaS as a destination (129.80.242.192), the public source IP address will be NAT-ed by the LBaaS using its private IP address and the destination IP address will be one of the OIC SFTP servers (based on the Listener configuration). The the NAT Gateway will do a SNAT for the traffic to reach the SFTP server over the OCI Backbone.
3) Secure the source IP address of the traffic on OIC SFTP;
Finally, we can use the whitelisting in the OIC SFTP to permit connections only from the public IP address of the NAT Gateway since all the traffic received will have the NAT Gateway public IP address as source.
After the backend servers are configured, each for specific environment (Prod, NonProd, UAT) we should have the health check in OK status:
A successful health check proves that the above networking construct is a valid one and can be implemented.
The last verification we need to perform is to connect to each and every Listener to confirm that the SFTP user traffic is correctly handled:
And yes, the user SFTP OIC traffic can be handled correctly by our LBaaS.