NetFoundry Platform Architecture
Introduction
Multi-cloud model of cloud computing where an organization utilizes a combination of clouds (two or more private clouds or a combination of public and private clouds) to distribute applications and services comes with complexity in networking.
1. MPLS VPNs / Private lines are costly and take time to establish. They are not an option for B2B multi-cloud networks. Translating VRFs for micro-segmented networks is a challenge or is not feasible across multiple cloud providers
2. VPNs on the other hand are inherently prone to attacks due to open ports / IPs that are listening for traffic. VPNs do not support mesh and do not support micro-segmentation. VPNs lack strong authentication and authorization
3. Management is a nightmare in both the above solution options.
NetFoundry provides a best-in-class secure, agile, and simple solution to the complex multi-cloud networking challenge.
This article will guide you on the steps to establish a Zero Trust Private connection between two or more cloud locations ( Public/ Private Datacenters) via the NetFoundry Zero Trust Network as a Service.
In our lab setup, we have considered an intercloud setup between AWS Singapore and Azure Pune. The test applications are hosted both at AWS Singapore and Azure Pune. The hosted edge routers are provisioned at AWS Singapore and Azure Pune.
In this test scenario, we are provisioning customer edge routers at AWS and Azure. The apps/servers at AWS and Azure are expected to communicate with each other via the NetFoundry network. They are not reachable over the internet.
Pre-requisites :
1. The edge routers and endpoints need to reach the NetFoundry controller and NF-hosted edge routers for registration and operations. Please make sure to have the required ports, IPs, and URLs reachable if you have firewall ACL policies.
2. NetFoundry traffic should be bypassed from proxy or any deep packet inspection in between since it involves mTLS and E2E encryption.
The guide has the details.
https://support.netfoundry.io/hc/en-us/articles/4402361752717-Firewall-Requirements
Step 1. Create your NetFoundry account
If you are an existing customer having a NetFoundry Cloud account, proceed to step 2. Else get an account.
For additional information or assistance please see our Support Hub article Product v7-Create and Manage Networks.
Step 2 - Create edge routers
Edge Router Connectivity Diagram
A) Provision a NetFoundry-hosted Edge Router
NetFoundry-hosted Edge Routers provide data transport as part of the fabric for endpoints and customer edge routers to dial to the fabric. At least one publicly accessible Edge Router is required for endpoints and edge routers to create a fabric. Having a min of two hosted ERs is a best practice for redundancy and smart routing.
NetFoundry-hosted Edge Routers provide data transport as part of the fabric for endpoints and customer edge routers to dial to the fabric. At least one publicly accessible Edge Router is required for endpoints and edge routers to create a fabric. Having a minimum of two hosted ERs is a best practice for redundancy and smart routing.
Provision a min of 2 NetFoundry hosted edge routers in the region strategic to Cloud Resources. Refer to the instructions for provisioning "NetFoundry-Hosted Edge Router" in the article.
Note that a new " Teams / Growth" account would have self-provisioned NetFoundry-Hosted Edge Routers based on the geo selected during the signup and the step can be skipped.
Snapshot of two NF-hosted routers provisioned in an enterprise account
To learn more about Edge Routers go to the Create and Manage Edge Routers article on the NetFoundry Support Hub.
B) Provision On-prem DC [Private Cloud] or any Public Cloud Customer Edge Router
Customer self-hosted Edge Routers act as ingress/ egress routers for customers to reach the hosted services on their premise or datacentre.
In this test scenario, we are provisioning two customer edge routers, one at AWS and the other at Azure. The apps/servers at AWS and Azure are expected to communicate with each other via the NetFoundry network.
Refer to the deployment guide below if you wish to provision a Customer-hosted Edge Router in a branch office or a Private cloud.
Create and Register AWS / Azure / OCI / any Public Cloud Edge Router
Use the below deployment guides to provision a Customer-hosted Edge Router into your AWS / Azure/ GCP/ OCI.
Step 3 - Creating services
The service definition provides the details of what device, or devices) will be utilized to provide access to services, either on the device(Zero Trust Client SDK Application) or on the network connected to the device (via its LAN, for example). The service also defines how the endpoints acting as clients to the service will access the service. Also, the service hosting details are provided.
- From your Network Dashboard page, navigate to Services.
- Under the Services tab, click on the + sign at the upper right to add a service.
- Choose the type of your service. Clicking on Advanced Services allows you to create services with IP/Port ranges.
- Select Advanced Service as the service type and give the service a name. Give your service a service attribute (optional). Service Attributes are tags applied to a service. The same tag can be applied to other services to form a group of services.
- In the Edge Router Attributes field, specify the public ( ex NF Hosted) edge routers participating in this service. If all edge routers are participating in this service, then leave this field blank.
- The Client intercept configuration is the section used to denote how the Client Endpoints that will be utilizing this service need to access it. There can be a hostname or IP Address or IP subnet specified, along with the application port numbers or port ranges. Multiple individual ports or port ranges can be configured. The hostname can be any contrived hostname to be utilized by the Client user. The protocol - TCP or UDP or both may be allowed.
- The Destination Configuration is used to configure the terminating endpoints and the destination details if forwarding is disabled. Select one or more endpoints to host the service by the individual endpoint names or endpoint group attributes. Select protocol/address/port forwarding if the destination is reachable on the same hostname / IP / protocol/port or ports as in the client intercept configuration.
-
If the destination IP / hostname/port is different from the client configuration, you can disable forwarding of IP / hostname or port or protocol and provide the details. The NetFoundry local DNS will resolve the client configuration to the destination configuration. Ensure that the application/destination is reachable on the IP / port/port range/protocol as specified in the destination configuration.
- Hit Create to complete the process.
Example - Service for AWS
Example - Service for Azure
For additional information or assistance please see our Support Hub article Create and Manage Services.
Step 4: Creating an AppWAN
The AppWAN defines the services that can be accessed by one or more client endpoints.
- From your Network Dashboard page, navigate to AppWANs.
- Under the AppWANs tab, click on the + sign at the upper right to add an AppWAN.
- Give your AppWAN a name.
- In the Service Attributes field, specify the services or service attributes to be associated with this AppWAN.
- In the Edge Router Attributes field, specify the edge routers or edge router attributes to be associated with this policy.
- In the Endpoint Attributes field, specify the endpoints or endpoint attributes to be associated with this policy.
- Hit Create to complete the process.
Note: Use of endpoint/service/edge router attribute will select all endpoints/services/edge routers having that specific attribute. The @ symbol is used to tag Individual endpoints/services/edge routers and the # symbol is used to tag a group of endpoints/services/edge routers.
A) APPWAN 'AZ-AWS' is created to allow the Azure Pune Edge router to connect to the HTTP server in AWS.
B) APPWAN 'AWS-AZ' is created to allow the AWS Singapore Edge router to connect to the Nginx server in Azure.
For additional information or assistance please see our Support Hub article Create and Manage AppWANs.
Step 5 - Cloud Configuration
| Azure Subnet: 10.29.29.0/24 | AWS Subnet: 172.29.29.0/24 | ||
| Edge Router | 10.29.29.4 | Edge Router | 172.29.29.218 |
| NF Ziti Suffix: 100.64.0.0/10 | |||
| Cloud | Hostname | IP |
| AWS | hello.nf | 172.29.29.16 |
| Azure | az.mum.nginx | 10.29.29.6 |
AZURE CONFIGURATION
- Enable “IP forwarding” on the Netfoundry gateway that acts as a client-side endpoint.
- Define Route for the AWS subnet, 100.64.0.0/10 [Ziti-suffix], Internet-bound traffic in the router table
- Configure security group to allow port 53, 3389, 80 in-bound to edge router instance.
- Azure Edge router IP 10.29.29.4 is configured as DNS for the Windows machine from which AWS Hello world demo Server is accessed.
AWS CONFIGURATION
- Disable “source & destination check” on the Netfoundry gateway that acts as a client-side endpoint.
- Define Route for the Azure subnet, 100.64.0.0/10 [Ziti-suffix], Internet-bound traffic in the router table
- Configure security group to allow port 53, 3389, 80 inbound to edge router instance.
- AWS Edge router IP 172.29.29.218 is configured as DNS for the Windows machine from which Azure Nginx Server is accessed.
Step 6 - Test your application access from AWS to Azure and vice-versa
Inter-cloud Application access
HTTP access to the AWS Hello world demo Server from Azure
Once the Service, AppWAN configuration is completed in the NetFoundry console, you will be able to make HTTP access to the AWS Hello world demo Server from Azure.
The application or server is accessed via a private hostname that is not reachable via the internet. The application is therefore dark to the outside world and reachable only within the NetFoundry network.
HTTP access to Azure Nginx Server from AWS
Once the Service, AppWAN configuration is completed in the NetFoundry console, you will be able to make HTTP access to Azure Pune Nginx Server from AWS Singapore PC.
The application or server is accessed via a private hostname that is not reachable via the internet. The application is therefore dark to the outside world and reachable only within the NetFoundry network.