Luke works for a company that uses a home grown application called Apollo that lives in AWS, and is accessed by employees over the Internet. His company has chosen this particular app, and a few of its users for a pilot involving a NetFoundry AppWAN to secure its access. Since AppWANs are designed to be application specific, Luke will build a single AppWAN for Apollo end users. Pilot users will be granted access to the AppWAN.
We want to use NetFoundry for the following benefits
- Protect Apollo from unauthorized access, DDoS attacks, and vulnerability scanning from the Internet at large. Only employees with access to the AppWAN should reach the application server. To everyone else, the server is dark (invisible). This not only protects the app from unauthorized access from the Internet, but also from unauthorized access from within the company network.
- Improve network performance to Apollo, compared with native Internet. Many times users who hit the app from the Internet complain of congestion during peak hours, making the app slow and frustrating to use. Mobile users who are traveling long distances also complain that their company apps are slow to access. NetFoundry networks employ techniques to improve network speeds and compensate for congestion, making the application respond faster, and giving the user an improved quality of experience.
Since there are other people using the app that are not in this pilot, Luke will leave it open to the Internet, but create a private IP address just for pilot users, registered to a pilot DNS name. If the pilot is successful, Luke's company will migrate all users over to the AppWAN, and take Apollo off of the Internet entirely.
The details of the internals are not relevant in this story, only to say that Luke wants to deliver user traffic directly to an ALB (Application Load Balancer) by way of an AppWAN. The production ALB lives on a small /28 public subnet for a total of 14 IPs available for auto-scaling. Luke will create a second, private ALB for the pilot. Putting it on a private subnet makes it unreachable from the Internet, which is what Luke is after.
Deploying the AppWAN
The private Apollo ALB is on a private subnet, which is not reachable from the Internet. To reach it over an AppWAN, Luke will install a NetFoundry Gateway inside of the VPC, also on a private subnet. Gateways only require outbound Internet access to connect to a NetFoundry Network. Keeping it on a private subnet protects the gateway from unwanted Internet attacks.
Luke has asked 10 remote employees to install a NetFoundry client on their laptops. The client is how they will reach the Apollo AppWAN.
The pilot will also include a small office with 25 employees that use Apollo from their desktop computers. Office employees check their email and access their internal company applications over Citrix. Luke wants to keep this Internet connection in place, and only re-route traffic for Apollo over the AppWAN. All other traffic must continue onto the Internet as usual.
Since these office computers stay put, it's far simpler to use a NetFoundry gateway at the office location to access the Apollo AppWAN, rather than install clients on all of the office computers. The gateway is installed in the office as the default route on the LAN.
Both clients and gateways examine the destination IP address of every packet they receive. Packets destined for the Apollo ALB are directed over the AppWAN, while everything else continues on to the internet untouched.
Objectives of the deployment
- Non-pilot users continue to access Apollo using the production URL
- Pilot users access Apollo using the pilot URL (though they can still reach it using the production URL if they need to)
- Remote users will use a client so they can remain mobile and access Apollo from anywhere
- Office computers are not mobile, and therefore can use an office gateway to reach Apollo
Luke will take the following steps to create the AppWAN from the console
- Log into the NetFoundry Console and navigate to the AppWANs page
- Create a new AppWAN - select "Cloud Hosted Application"
- Create and name the AppWAN (called "Apollo app")
- Create an egress gateway for the VPC where Apollo resides (called "vpc-ac1d4080")
- Add a service for "10.100.200.16/28 TCP port 443" to the VPC gateway
- Create three new clients (called "pilot user 1", "pilot user 2", "pilot user 3")
- Create one new gateway for the office site (called "South Tryon Office, CLT")
Once the AppWAN is created, Luke will proceed with the following steps
- Launch a NetFoundry gateway in a private subnet inside the Apollo VPC -See Launch a NetFoundry gateway in AWS Cloud
- Share client details with pilot users, so they can install the client on their laptops - See Install a NetFoundry client on Windows, Install a NetFoundry client on MacOS
- Share office gateway details with the IT coordinator to deploy a vCPE gateway at the office - See Launch a NetFoundry vCPE gateway on a hypervisor
- Share DNS information with pilot users so they can test their access to the app (out of band)
Post-Pilot advanced deployment options
- Add a core site, such as a datacenter, so that resident employees can also reach the app over the same AppWAN
- Create a second AppWAN for the DevOps team to securely access the entire VPC
- Make the VPC gateway highly available with a second cloud gateway
- Make the office gateway highly available with a second vCPE gateway
Add a core site, such as a datacenter, so that resident employees can also reach the app over the same AppWAN
Create a second AppWAN for the DevOps team to securely access the entire VPC
A second AppWAN for the DevOps team can also use the Apollo VPC gateway, so there's no need to stand up a second one. Just create a new AppWAN, with a service that covers the entire /16 CIDR range of the VPC, and add clients for the team.
- Create and name the AppWAN (called "Apollo devops")
- Add a service for "10.100/16" to the Apollo VPC gateway
- Create a client for each member of the DevOps team
Make the VPC gateway highly available with a second cloud gateway
Highly available (HA) gateways use two gateway instances for redundancy. When you create an HA gateway, you can assign services to it, which will be protected if one instance fails or is down for maintenance. You may choose how the service is protected, by selecting either "active/standby", or "round-robin" modes when you create the HA gateway.