SynchroKnot Automatic Network Address Translation [NAT] Enablement allows for transparent access to Infrastructure Engine and Virtual Machine Consoles [HTML5/Java], Log Panorama and more from behind NAT [Network Address Translation] without having to configure anything on the client-side or server-side.
This feature allows for secure and easy setup & access from behind standard NATs so that tenants can have direct access, or access from their VPNs without accessing the actual provider network. This feature brings about flexibility and simplicity, while at the same time allows the service providers to securely keep the tenants separated.
Excerpt from the SynchroKnot Manual: The Infrastructure Engine can be accessed by all tenants in the 10.xxx.xxx.xxx range corresponding to the 28.xxx.xxx.xxx range IP address given to the Spatial Fabric Satellite. Eg. https://10.9.0.1/SynchroKnot.sknt
To access the SynchroKnot Infrastructure Engine on a Spatial Fabric Satellite from the above description, the IP address of the machine used to access the Infrastructure Engine from the web browser must be in the 10.x.x.x range for security reasons.
If you have a tenant behind a transparent NAT in the 172.x.x.x range for example, and it is pointed to the 10.x.x.x range to access the Infrastructure Engine, then the access is possible but with certain limitations.
The Infrastructure Engine will not know about the 172.x.x.x range from where the request is coming in as it is on the other side of NAT. Therefore, the response[s] given would still be pointing to the 10.x.x.x range.
This would cause the http and other requests & redirects such as Cross Domain Ajax, the opening of new tabs for websocket based HTML5 console access, Java based console access, Log Panorama …. and much more to NOT work.
Example scenarios without the use of SynchroKnot Auto NAT Enablement:
■ Scenario A Works:
[ web browser in 10.x.x.x range ] –> [ Infrastructure Engine in 10.x.x.x range ]
Different types of redirects sent from the Infrastructure Engine work transparently.
■ Scenario B Does Not Work:
[ web browser in 172.x.x.x range ] –> [ NAT ] –> [ Infrastructure Engine in 10.x.x.x range ]
[ web browser in 192.x.x.x range ] –> [ NAT ] –> [ NAT ] –> [ Infrastructure Engine in 10.x.x.x range ]
Different types of redirects sent from the Infrastructure Engine are pointing in the 10.x.x.x. The web browsers in 172 & 192 ranges behind single and double NATs will trigger the redirect in the 10.x.x.x range but will not be able reach the destination in the 10.x.x.x range.
The SynchroKnot Auto NAT Enablement feature transparently addresses this issue and allows full access just as if you were accessing the Infrastructure Engine from the 10.x.x.x network.
The above Scenario A and B would work with SynchroKnot Auto NAT Enablement. This should work with any transparent NAT [eg. with IPtables etc].
This unique solution was possible with the combination of partly server-side + partly server-side-embedded-client-side functionality [which is unique to SynchroKnot].
One does not have to touch the transparent firewall!
Eg. If you were using IPtables to DNAT and SNAT/Masquerade on a transparent NAT box in between, then simply set the 172.x.x.x range to point to 10.x.x.x. range. That’s it. No need for further reconfiguration, updating the rules for mapping/unmapping/remapping ports, IP addresses etc.