“Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to avoid the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the networks address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.”
Cohesive Networks introduced the NATe offering into our VNS3 lineup of network devices back in March. It lowers operational costs while adding functionality and increasing visibility. Easily deployable and managed, it should be a no brainer once you consider its functional gains and lower spend rate. Some of our large customers have already started the migration and are seeing savings in the tens, hundreds and thousands of thousands of dollars.
The AWS NAT Gateways provide bare bones functionality at a premium cost. They simply provide a drop in NAT function on a per availability zone basis within your VPC, nothing more.No visibility, no egress controls, and lots of hidden costs. You get charged between $0.045 and $0.093 an hour depending on the region. You get charged the same per gigabyte of data that they ‘process’, meaning data coming in and going out. That’s it, and it can really add up. A VPC with two availability zones will cost you $788.40 a year before data tax in the least expensive regions, going up to double that in the most expensive regions. Now consider that across tens, hundreds or thousands of VPCs. That’s some real money.
With Cohesive Networks VNS3 NATe you can run the same two availability zones on two t3a.nano instances with 1 year reserved instances as low as $136.66 per a year, with no data tax as ec2 instances do not incur inbound data fees. It is about a sixth to a tenth of the price depending on the region you are running in.
As a Solutions Architect at Cohesive Networks I’ve worked with enterprise customers around the world and understand the difficulty and challenges to change existing architecture and cloud design. Using cloud vender prescribed architecture is not always easy to replace as there are up and down stream dependancies. The really nice thing about swapping your NAT Gateways with VNS3 NATe devices is that it is really a drop in replacement for a service that is so well defined. It can be programatically accomplished to provide near zero downtime replacement. Then you can start to build upon all the new things that VNS3 NATe gives you.
The process of replacement is very straight forward:
The only downtime will be the 30 or so seconds that it takes to delete the NAT Gateway.
One safeguard we always recommend to our customers to set up a Cloud Watch Recovery Alarm on all VNS3 instances. This will protect your AWS instances from any underlining hardware and hypervisor failures. Which will give you effectively the same uptime assurancesas services like NAT Gateway. If the instance “goes away” the alarm will trigger an automatic recovery, including restoring the elastic ip, so that VPC route table rules remain intact as well as state as restoration occurs from run time cache.
Now you can log into your VNS3 NATe device by going to:
https://<elastic ip>:8000
usename: vnscubed
password: <ec2 instance-id>
Head over to the Network Sniffer page from the link on the left had side of the page and set up a trace for your private subnet range to get visibility into your NATe traffic.
FinOps, Cloud Costs, Repatriation, and most recently the in-depth post by Martin Casado and Sarah Wang from a16z on the cloud/cost paradox are all topics in the news reflecting that we have reached the “Holy Cow, I am spending a ton on cloud!” inflection point.
As I discussed in previous posts there are key distinctions between running “in the cloud” and “on the cloud”; the ability to tune, tweak and manage costs are some of these distinctions. At the end of the day the Cloud Service Providers are businesses out to maximize revenue, not missionaries proselytizing a new design center. Yes, cloud is the newest, and increasingly dominant design center, but never forget cloud service providers are businesses out to maximize revenue.
They are experts at presenting to their customers the “economically defined architecture”. Through their documentation, training, certifications, sku-ing, and feature segmentation they guide the cloud customer to acceptable, best-practice recognizable, deployment architectures. In fact, due to the consistency of the aforementioned assets (training, docs, etc..) they have most likely raised the bar in terms of overall deployment quality for many enterprises. All that said, the amalgam of capabilities and the manner deployed ALSO maximize their revenue. This is not surprising.
When you create a deployment architecture guided by cloud service provider user interface wizards and devops automation template best practices, it is quite possible you are getting a number of constructs your application doesn’t need, despite the fact that some applications might need them. Is this a global scale application and you hope to be the new Netflix? Or is this a supply chain application shared by 12 partners in the midwestern automated sprinkler space?
The cloud service providers are making specific architectural recommendations, that easily convert to IT deployment decisions, that are integrated to their pricing strategies. It is a level of alignment probably not seen in the previous design cycle where you would hire a consultancy to help with a data center deployment of vendor product XYZ.
Cohesive has provided cloud connectivity and security, helping customers get to, through and across the clouds since 2008, as such we have seen a lot of both customer migrations and greenfield development. There are an array of capabilities many of these applications do NOT need. To put it another way “not all of them need all of” cloud vendor-provided autoscale, load balancers, direct connects, transit gateways, nat-gateways, BGP, complex service roles/permissions, global network funnels, lambdas, etc.. Yet, due to a combination of the path of least resistance, peer conformity and even “cool kid behavior”, your team might feel reticence to dispense with any of these constructs. Practically speaking, there is a strong chance that declining default practices and recommendations could create personal risk for them. What if there is an issue, and the initial blowback narrative of an outage is “well Bob said we didn’t need a cloud load balancer”? Even if the root cause analysis shows it wasn’t the load balancing or lack thereof that caused issues – does “Bob” ever get truly “cleared of the charges”.
At the end of the day cloud service providers are extracting billions with a “B” from their customers for what is without argument high quality deployment architectures. But those architectures have some of their own complexity in that they are possibly more complex than what many customers need. Even if you set aside the runtime costs of those components, and some of the inherent complexity, there is another “gotcha”, which is “data taxes”. Increasingly newer offerings have both runtime (price per hour or price per invocation costs for usage) but also added on data taxes on top of the existing cloud egress charges. This is where 3rd party offerings from vendors like Cohesive, (certainly not limited to us) can make a substantial cost difference. Our view on the data taxes is that they are an awful lot of icing on some pretty thin pieces of cake.
I do want to note that our whole business has been built around cloud, and we ourselves use a lot of it, in fact too much of it from a pure costing point of view. We trade off speed for $$$, and while sometimes hard to quantify, we believe in the payoff. Cloud lets us move fast, and when you do so you leave bits of cost lying about via both neglect and opportunism. For the most part we do this with eyes wide open.
That to us is the crux of it. Controlling cloud costs requires a clear headed view by IT management of what their options are. What is the cost of conformity to cloud service provider economically defined architecture? What is the cost of non-conformity? If you are trying to save money, increase your non-conformity. If you are trying to reduce a measure of both actual and perceived risk increase your conformity. BUT, when you are trying to figure out how to cut cloud spend by seven figures (or a multiple of that), understand the structure of the tradeoffs you need to make.
Windows Server Failover Clustering (WSFC) is a powerful technology in the Microsoft arsenal of offerings. Unfortunately, it was designed for data centers under the assumption that it would be running on physical servers with copper wires running between them. Wouldn’t it be nice to be able to bring WSFC capabilities to the public cloud?
From Microsoft’s description, a failover cluster is a group of independent computers that work together to increase the availability and scalability of clustered roles (formerly called clustered applications and services). These clustered servers (called nodes) are connected by physical cables and software. If one or more of the clustered nodes fails, other nodes begin to provide service (a process known as failover). In addition, the clustered roles are proactively monitored to verify that they are working properly. If clustered roles are not working, they are automatically restarted or moved to another node.
Failover clusters also offer Cluster Shared Volume (CSV) functionality, providing a consistent, distributed namespace that clustered roles can use to access shared storage from all clustered nodes. With the Failover Clustering feature users experience a minimum of disruptions in service.
Implementing WSFC in the cloud is difficult because even though we have plenty of software, we lack physical cables. In this example we will use Cohesive Networks VNS3 in order to virtualize the wires necessary to trick WSFC into working.
The configuration documentation for WSFC states that each server needs to run in its own subnet. A /29 works well as you lose the top and bottom addresses for gateway and broadcast, leaving you with 6 available addresses. As we will see, you will assign the first and second low addresses, leaving you with an additional 4 addresses to be used for listeners and or cluster roles.
Our first step is to get our virtual servers to believe that they are in defined subnets even though they are in fact in a flat overlay network. Underneath they can exist in the same VPC subnet or across various VPC/VNETs. This approach allows you to run a cluster across cloud providers and across regions. You can even add members in a data center, just so long as all Windows servers are connected to the same overlay network.
So lets say we have an overlay network of 172.16.8.0/24 and we have carved out three /29s:
172.16.8.56/29
172.16.8.64/29
172.16.8.72/29The above should be done when you import your license, where you can choose custom and define your overlay addresses.
Let’s also assume we have a pair of Active Directory domain controllers assigned 172.16.0.1 and 172.16.0.2.
On each of the cluster windows servers we assign the following VNS3 client packs:
172.16.8.57
172.16.8.65
172.16.8.73dhcp-option DNS 172.16.8.1
dhcp-option DNS 172.16.8.2
script-security 2
route-up "C:\\routes.bat"windows-driver wintunFurther details can be found here:
https://cohesiveprod.wpenginepowered.com/blog/the-new-openvpn-2_5/
Make sure to install the Cohesive Networks Routing Agent which can be found here:
https://cn-dnld.s3.amazonaws.com/cohesive-ra-1.1.1_x86_64.exe
In Windows Network Connections change the name of your Wintun Userspace Tunnel to ‘Overlay’ so it can be referenced as below.
We will create C:\routes.bat as follows:
@echo off
set cidr=172.16.8
set /A a=56
set /A b=%a% + 1
set /A c=%b% + 1
netsh interface ipv4 set address "Overlay" static %cidr%.%b% 255.255.255.248
timeout 1
netsh interface ipv4 add route %cidr%.0/24 "Overlay"timeout 1
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -command "& {Get-NetAdapter -Name Overlay | select -ExpandProperty ifIndex -first 1 }" > tmpFile
set /p INDEX= < tmpFile
del tmpFile
timeout 1
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -command New-NetIPAddress -InterfaceIndex %INDEX% -AddressFamily IPv4 -IPAddress %cidr%.%c% -PrefixLength 29 -DefaultGateway %cidr%.%a%
@echo offNow when you bring up OpenVPN you will see:
At this point we’ve accomplished two very important tasks. First, we have changed the default subnet for our assigned overlay address from a /24 to a /29, which conforms to WSFC’s configuration rule necessitating that all clustered servers be in their own subnet. But since we’re using openVPN here we have an issue: we do not have a default gateway and WSFC insists that we have one. So we can add the next address in our /29 to our virtual interface and set a default gateway for it, in this case the first address in our /29. This address is really just to trick WSFC; while the address will answer traffic its purpose is to simply supply an address in our /29 that has a default gateway set.
Our next step is to set up interface routes in VNS3 so that all traffic within the /29 subnets can reach the actual assigned client pack overlay addresses. In the Routes section of VNS3 you will add an interface route for each /29 as follows:
You now have a route that directs anything in the /29 address space ‘through’ the assigned client pack. So in the example of /56, where 172.16.8.57 is the client pack, and we have added 172.16.8.58 to the virtual Wintun interface, we will tell WSFC to add 172.16.8.58 for our cluster address. Our windows server will now respond to all three addresses.
Let’s try it out:
You will need to install the Failover Clustering feature, and you will need to have all windows servers joined to a domain.
In our example I have named my three servers Cluster-1, Cluster-2 and Cluster-3. From any of these three servers, open up a command window and enter powershell mode:
New-Cluster -Name OverlayCluster1 -Node Cluster-1,Cluster-2,Cluster-3 -NoStorage -StaticAddress 172.16.8.59,172.16.8.67,172.16.8.75 -AdministrativeAccessPoint ActiveDirectoryAndDnsYou should see some activity metering and then a success message.
Now you can connect to a cluster in the Failover Cluster Manager and enter a period to denote this server. With clustername.domain selected under “Cluster Core Resources” expand “Name: Clustername.” Right click on the underlay address that should be labeled “Failed” and select “Remove.” Under “Nodes” you should see your three servers. Under “Networks” you will see each of the overlay /29s as well as each of the underlay subnets. For the underlay subnets, under properties, select “Do not allow cluster network communication on this network.” Your cluster is now ready to add roles. Try it out.
Get-Cluster -Name OCluster1 | Remove-Cluster -Force -CleanupAD
Whether you need to connect multiple cloud instances, communicate with the public internet from private resources, or directly connect to instances in local data centers, chances are you will be using Network Address Translation (NAT) to make that connection. All major cloud providers provide some product or service to provide NAT functionality, and some platforms even provide separate public and private variants. Because cloud instances running in private subnets are unable to access resources like time servers, webpages, or OS repositories without NAT functionality, most users find themselves relying on their cloud platform’s NAT offerings. By simply following their cloud providers’ recommended best practices, users are overpaying for an overcomplicated and inflexible service that a home cable modem does for free. So why pay so much for such a simple network function?
Overspending of any kind in the wake of the economic disruption caused by the COVID-19 pandemic can be deadly for any business. Yes, some have fared better than others during this challenging time but all organizations have revisited projections and budgets in the face of uncertainty. According to Gartner, the pressure is on for budget holders to optimize costs.
Look to the sky! Your cloud bill is likely full of opportunities for savings, especially if your application relies on NAT functionality. Using AWS NAT Gateway pricing as an example, let’s start with the comparative base subscription costs:
| AWS NAT Gateway | VNS3 NATe | |
| Subscription | $0.045 / hour | $0.01 / hour* |
| Data Processing (TAX) | $0.045 / GB | $0.00 / GB |
As you can see from this example, the standalone subscription cost of an AWS NAT gateway is more than the cost of a single t3.medium instance. The already low VNS3 NATe subscription cost will provide you even more savings when you consider the fact that you don’t have to create as many individual NAT gateways, each of which would be accompanied by an additional AWS NAT Gateway subscription. The cost differential here makes NATe an obvious choice at any deployment scale and we even offer a free NATe license for smaller deployments.
VNS3 NATe is also incredibly scalable because we don’t increase our data processing rates as your bandwidth needs scale. Below is a pricing table that shows the total cost of running a single NAT Gateway vs a VNS3 NATe instance as the traffic throughput increases in a given month:
| GB / Month | AWS NAT Gateway | VNS3 NATe |
| 1 | $32.45 | $7.20 |
| 10 | $32.85 | $7.20 |
| 100 | $36.90 | $7.20 |
| 1,000 | $77.40 | $7.20 |
| 5,000 | $257.40 | $7.20 |
| 10,000 | $482.40 | $7.20 |
| 50,000 | $2,282.40 | $7.20 |
| 100,000 | $4,532.40 | $7.20 |
We also have customers who maintain 100s or 1000s of VPCs with NAT requirements of 1-100 GB per month. Those enterprise cloud customer at scale have typically seen costs drop to 1/5 of what they would pay for AWS NAT Gateways. To illustrate this savings, take the example from one of our customers has 1800 VPCs each with a NAT Gateway. The total data processed through these NAT Gateways is low and averages 10GB / month with much more potential savings for deployments that pass more traffic out the NAT device.
| AWS NAT Gateway | VNS3 NATe | |||
| Monthly Runtime | $58,320 | Monthly Runtime | $12,960 | |
| Data Processing (TAX) | $810 | Data Processing (TAX) | $0 | |
| TOTAL PER MONTH | $59,130 | TOTAL PER MONTH | $12,960 |
Total NATe saving per month in this case is $46K and $554K per annum.
Of course, costs savings are not limited to just NAT Gateway spend. Other opportunities for savings include right sizing instances (latest generation instance families are always less expensive), decommissioning unused services/resources (I’m looking at you load balancers), and reviewing storage strategies (such as EBS).
A NAT Gateway is a network service that performs a simple network function: Network Address Translation for cloud-based servers running in a private network (private VPC subnet). Here is the AWS documentation detailing the NAT Gateway functionality. NAT Gateways perform a specific type of NAT called IP Masquerading, where devices in a private IP network use a single public IP associated with the gateway for communication with the public Internet.
This is the same function that your home modem performs for free. You’re likely leveraging this NAT functionality as you read this post. Basically the NAT functionality on a NAT Gateway or your home modem allow devices on a private network (computers, phones, TVs, refrigerators, toothbrushes, etc. in the case of your home network) to access the Internet and receive responses but not allow devices on the public Internet to initiate connection into your private network. All traffic sent from the private network to the public Internet uses the modem’s public IP address.
In response to direct requests by our customers, we created a low-cost, instance-based alternative to NAT Gateways – VNS3 NATe.
Available on AWS PM and Azure MP today:
NATe instances are drop-in replacements from Cohesive Networks for NAT Gateways. Simply launch in a VPC/VNET subnet with an Internet Gateway associated, Stop Src/Dst checking (enable IP forwarding), and update the Route Tables associated with the private Subnets to point 0.0.0.0/0 destinations at the NATe instance-id.
NATe provides all the functionality of a NAT Gateway plus enterprise grade security and controls at a fraction of the cost. Some of the functional highlights of NATe include:
Cohesive’s NATe offers a dramatically more cost-efficient solution to often critical NAT requirements in cloud deployments of all shapes and sizes. NATe is more flexible, more scalable, and easier to manage than first-party cloud NAT gateways that are charging you a premium for the functionality of a standard consumer modem. If you don’t believe us, we launched a free version of our NATe offering in both the AWS and Azure marketplaces so you can launch and configure them and see for yourself!
Have questions about set-up or pricing? Please to contact us.
The AWS Well-Architected Framework
At Amazon, they recommend following the AWS Well-Architected Framework to align plans, architecture, and their cloud best practices. It’s worth reviewing the framework for your own AWS-based projects for an in-depth look.
AWS’ well-architected framework’s 4 pillars
Since Cohesive Networks mainly focuses on networking and security, we’ll highlight parts from AWS’ Framework and other network and security best practices.
The AWS Well-Architected Framework is based around 4 “pillars”:
At Cohesive Networks, we have a process called “ coalescence ,” where we encourage customers to match ideal architectures to the realities of public cloud environments. Cloud users should both account for their current architecture and build with an end architecture in mind.
This way as the realities of cloud creep into the build-out you can be prepared for them. Follow security best practices from the beginning and always architect networks for recovery and connectivity.
Network planning and security highlights from the Well-Architected Framework:
Fitting it together: Mixing in VNS3 for application layer security
Security, customization and control were the 3 big reasons we created the overlay networking and VNS3. As Cohesive began to put its own computing systems into the cloud, we were uncomfortable with the loss of control of our network infrastructure.
VNS3 can help you literally extend enterprise firewall and security rules into the cloud to enclose, isolate, and control all cloud networks. VNS3 offers enhanced network services on top of the cloud platform network. Our customers use VNS3 to enhance VLAN peering, full encryption of data in motion, application layer firewalls, and cross-region peering.
In particular, VNS3:turret can secure applications in micro-perimeters to eliminate east-west vulnerability. These Application Security Controllers are deployed as an encrypted, clustered software-only virtual instances that secure mission critical business systems in public or private cloud. VNS3:turret provides the most comprehensive application security model available today.
This is a first in a series of posts about networking fundamentals.
At Cohesive Networks we have found that not all VNS3 users are networking experts – and that’s ok! Usually customers come to us to solve a problem. It is usually network related, but not always. We often find that business units or operations teams are looking for a solution to a connectivity or security problem, regardless of how the networking piece fits in.
We’re always here to help. Our award-winning support team helps customers solve problems, but also troubleshoots networking troubles. From misconfigured settings on physical network devices to sneaky cloud set up pitfalls, our team is here to help.
1. the OSI Layers
Arguably the OSI layers are foundation for all networking knowledge. The OSI Model (shortened from the Open Systems Interconnection model) evolved in the 1970s and 80s from the early ARPANET and telephone providers. The model describes layers of connectivity and activity based on 7 layers. A similar model, the TCP/IP model is a combined version of the OSI layers.
Essentially, data passes from one connected device to another over a network, from the top of the OSI model down to Layer 1, then back up again to Layer 7. As data passes through each phase, essential functions like encryption and encapsulation occur. Data travels from a software application at Layer 7, down to a router at layer 3, packets bounce between physical hubs at Layer 1, and back up to a router on the other side’s Layer 3, then finally up to a connected application on Layer 7.
How can you remember “Physical/Data Link/Network/Transport/Session/Presentation/Application” in the Layer 7 OSI model? How about “Please Do Not Teach Students Pointless Acronyms.”
2. Packet Switched networks
Packet switched networks are characterized by how they exchange data. Packets , or discreet units of data, are transmitted between devices in a network. Packet switching improves network efficiency and enables more device to communicate reliably on a network.
Packets are made up of “headers” and “payloads” The header contains information about the packet’s destination. Networking devices use the header to direct the packet toward its destination. Once it reaches the final destination, the payload is extracted and used by application software.
Packet-switched networks are generally better because they can transfer data bit by bit, as opposed to a firehose of data. That way, receiving parties can confirm delivery and ask for data to be resent if needed.
3. Hubs vs Switches vs Routers
Hub = Layer 1 (Physical) carry electricity, essentially, hubs send information to all other ports as electricity to everyone connected on that hub.
Switch = Layer 2 (Data) uses packet switching to receive, process, and forward data. A switch, like a hub, carries data from port to port, but a switch keeps a record of MAC addresses of all the devices attached to it.
Router = Layer 3 (Network) directs packets from a source to the destination using specific packet forwarding mechanisms. Routers only send data to other routers using IP addresses. A key difference between a router and a switch is the level of information the device “knows” about the traffic. Switches only look at the Link Layer address, not the IP datagram (or message).
Bonus term:
MAC address = unique identifier assigned to network interfaces for communications at the data link layer of a network segment.
Back to the 7 Layer OSI model – you can determine what tools are appropriate and what data can be manipulated by each layer. For devices, a handy rule of thumb: any data at layer 3 must interact with a router. Data at layer 2 must interact with a switch. Data at layer 1must interact with a hub.
4. Networking at home vs. networking in the cloud
At home, your router connects you to the ISP Network (gateway). A gateway is a term to describe a connection of 2 or more networks connections.
Inside your home, the gateway is between your internet service provider (ISP) network and your network. You have a public IP address given to you by your ISP and an internal one created by your NAT. More on NAT in future posts…
A home router also acts as a Switch for communicating between devices inside your home network. If your network is slow whenever there are more people on the network, your router is likely acting as a hub also. Remember, hubs send data to all devices on a network.
“So when your home router says it’s actually a hub / switch / router — it really is a hub/switch/router.” Want more network layer fun? Read the full article from Louis Cremen: 10 things InfoSec professionals need to know about networking
Bonus: How encapsulation works at the OSI network layers
Recent Comments