Request a Consultation

CheckPoint Consulting Blog

Welcome back! As i discussed in my last blog, I have been helping a customer migrate to a cloud provider for EPM. The migration itself has proceeded well, but netowrking has been quite the ordeal.  Ideally in the cloud world you would want to establish an fairly flexible tunnel that supports routing of a sufficiently wide subnet to allow for flexibility in architecture.  One of the "features" of the cloud is the flexibility for scaling capacity on demand. The cloud provider wanted to scope subnets that allowed for hosts that exist today, and hosts they may have to "add" in an on-demand scenario without having to reconfigure the vpn tunnel. The network provider was not prepared to handle this. They have not become "cloud centric" in their thinking.  Their standards still required 1:1 mapping between any Cloud Provider host and an IP address on the client side of the tunnel. This requires DNS to be managed for the client side addresses at the client.  The cloud provider has foo.cloudserver.net(10.0.1.2) and on the client side they have foo.myclientserver.net (192.1.0.2) and network address translation (NAT) is used to manage the mapping between the netowrks. Each time a server is added o the cloud side, the client must also add an ip address, firewall exceptions, routing changes, and DNS updates on their side. Not a flexible model. 

The cloud provider typically manages the DNS for the servers it provides. It does this by publicly publishing private addresses. What this means is, a server that is foo.cloudserver.net, can be resolved by any user with an internet connection using Internet facing DNS servers, but only a client with a VPN tunnel and the right routing could reach the servers. This allows the Cloud provider to add servers on-demand, and update its DNS Servers. The customers would be able to resolve the new servernames and get reach them without doing anything additional on thier network. Of course this violates the outdated security policies of both the network provider and the client. Corporate policy simply has not caught up with technological solutions.  For the client this means for every server in the Cloud Providers network, there is matching IP address on the client network that uses NAT to pass traffic from foo.myclientserver.net >><< foo.cloudserver.net.  Anytime the cloud provider adds a server in the future, the client must work with their netowrk vendor to procure a new ip address, update their local DNS, and update the VPN configuration to account for the new host.

Tune in next time for fins with SSL Certificates…...