NATe: A Tax-Free Alternative to Cloud NAT Gateways

NATe: A Tax-Free Alternative to Cloud NAT Gateways

by | Mar 18, 2021 | AWS, Azure, Connectivity, Network Architecture, Network Edge Plugins, VNS3 Features

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?

If You’re Using Cloud Platform NAT Gateway(s), You’re Overspending on Cloud Deployments.

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.

Pre COVID-19
54%
of enterprises planned IT budget increases
Post COVID-19
84%
of enterprises expect IT budget decreases

Where to Start?

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
* Price includes runtime fees (on-demand t3.nano $.0052 / hr) + NATe subscription ($0.005 / hr)

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
* Price includes runtime fees (on-demand t3.nano $0.0052 / hr) + NATe subscription ($0.005 / hr)

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).

What is a NAT Gateway?

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.

NATe to the Rescue!

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:

AWS Free*
AWS PAYG
Azure Free* / PAYG
* No subscription premium but total throughput limited to 50mbps

What is a NATe?

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.

Cohesive-Networks_NATe-Network-Diagram_20210318

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:

  • High Performance – run on the smallest instance sizes to maximize value or larger instance for greater total throughput
  • Secure – access to a firewall to allow additional and orthogonal policy enforcement for traffic flows
  • Control – access logs, network tools like tcpdump, status information
  • Customize – leverage the Cohesive Networks Plugin system to add L4-L7 network services to the NATe instance like NIDs, WAF, Proxy, LB, etc.
  • Automate – fully automate the deployment of VNS3 NATe instances as part of your existing deployment framework leveraging the RESTful API to reduce implementation costs.
  • Failover – NATe can be configured in a number of HA architectures to provide the same level of insurance needed for critical infrastructure via instance auto recovery, auto scale groups, and Cohesive Networks’ own Peering and HA Container functionality
  • Upgrade – NATe is fully upgradeable to fully licensed VNS3 controllers deployed as a single application security controller or part of secure network edge mesh

Still Not Convinced?

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.

Introducing the VNS3 Plugin Manager

Introducing the VNS3 Plugin Manager

by | Mar 4, 2021 | Network Edge Plugins, VNS3 Features

About the VNS3 Edge Plugin System

The recent release of VNS3 5.0 is the culmination of years of learning from our users what a modern, reliable, and secure network requires. This newest version of VNS3 provides a customizable platform for your cloud networking needs, including enterprise owned encryption, workforce VPN management, network segmentation, multi-cloud federation, and more. We at Cohesive never presumed to know exactly which web application firewall your organization uses, or which network intrusion detection system you wanted to use, so we started building our VNS3 plugin system back in 2014. Our goal is to provide our clients with the ability to fully customize their network edge for their unique use case on the solid foundation of VNS3. Our clients brought their Nginx WAF configurations, their Suricata rules, and their organizational expertise, and were able to plug it into VNS3, providing a uniform network edge for their enterprise.

VNS3 Plugin Manager Features

As we continue to build the plugin system with our clients, we’ve noticed there are two types of users that utilize it most: technical users who are comfortable creating network functions in containers and less technical users who simply want to install a plugin and perhaps edit said plugin’s configuration file. Here is where the Plugin Manager comes in:

The plugin manager provides a simple UI console for managing your plugin’s configuration. This includes creating your plugin’s firewall policy, directly editing plugin configuration files, viewing logs, and even the ability to run plugin commands. If the plugin provides a UI, you can access it directly from the plugin manager UI.

The plugin manager is the next step forward for VNS3 continuing to provide a fully customizable networking platform for your cloud edge. Now you can seamlessly manage your network edge plugins all in one place, allowing your organization to take full advantage of our combined expertise.

What’s Next for the Plugin Manager

As a little teaser of our product roadmap, the VNS3 Plugin platform will soon allow you to install your plugins directly on VNS3, including third party plugins vetted by Cohesive Networks. This will allow your organization to take advantage of our expertise and the lessons we’ve learned from other clients. Want to set up Datadog monitoring with VNS3? Install the Datadog plugin. Need intrusion detection? Grab the plugin provided by Zeek. Check out our currently available plugins and installation tutorials on our documentation site here.

Our claim: VNS3 will always be the most customizable network edge device for your cloud networking needs. Hold us to it.

Managing DNS for Remote VPN Users in AWS Route53 with VNS3

Managing DNS for Remote VPN Users in AWS Route53 with VNS3

by | Jan 28, 2021 | AWS, Connectivity, VNS3 Features

Managing DNS can be a fairly complex and daunting task. Installing and configuring Bind takes time and knowledge and requires maintenance. Infoblox is expensive and likely overkill for smaller projects. Cloud vendors like AWS have simplified offerings that allow ease of use and scale with your needs. They offer public and private zone management with features like split horizon. Split horizon allows Domain Name Systems to provide different information based on the source address of the requestor. For example, if you are coming from the internet at large you would receive the public IP address of the named system you are looking up, but if you were in the same private subnet as that system you would receive it’s private IP address. This allows you to define the how users get to systems depending on where they are.

Let’s take the example of a remote VPN connection. With VNS3 People VPN you can easily connect your workforce to your cloud assets, be they across regions and or vendors. Giving you a secure entry point to your companies computational resources. VNS3 makes it easy to push DNS settings to connected clients so that they are told that their DNS server is the address of the VNS3 security controller. So now we have connected clients making DNS calls to VNS3. But hold on VNS3 isn’t a DNS server. Well it can be through it’s plugin system, but thats a different topic for another blog post. In this scenario we can divert all incoming DNS traffic through use of the VNS3 firewall.

Cohesive Networks VNS3 Controller Connectivity
Lets say that our VNS3 overlay address space is 172.16.0.0/24, this is what we are using for our remoteVPN users, and our VPC is 10.0.0.0/24. In this case there are two addresses that we care about. 172.16.0.253 is the Virtual IP of the VNS3 security controller and 10.0.0.2 which is the AWS VPC Route53 Resolver or DNS endpoint. In AWS the DNS endpoint will always be the .2 for your VPC address space. So our firewall rules will look like this:

PREROUTING_CUST -i tun0 -p tcp -s 172.16.0.0/24 –dport 53 -j DNAT –to 10.0.0.2:53
PREROUTING_CUST -i tun0 -p udp -s 172.16.0.0/24 –dport 53 -j DNAT –to 10.0.0.2:53

Here we are saying that traffic coming in on the tun0 interface (overlay network) from 172.16.0.0/24 (overlay address space) bound for UDP and TCP port 53 (DNS) should be forwarded to 10.0.0.2 on UDP and TCP port 53 (AWS VPC DNS endpoint).

Ok so now that we have our remote VPN DNS requests being diverted to the VPC DNS endpoint we need to configure our responses. In Route53 you can configure any zone name you want so long as it isprivate. For public zones you will need to own the domain name. But for private zones you can do whatyou want. This can be very useful where you might have a secure IPSec connection to a partner network and want to use DNS names that reflect your partners name and configure addresses across your tunnels. You can set up as many private zones as you want. Once they have been setup it is now just a mater of associating them with the VPC that your VNS3 security controller resides in. you will now have custom DNS naming for your remote workforce.

New VNS3 Firewall Features in VNS3 4.11

New VNS3 Firewall Features in VNS3 4.11

by | Oct 22, 2020 | VNS3 Features

The VNS3 Firewall is a wrapper around Linux’s “iptables”. The VNS3 firewall abstracts away the concept of tables, removing a variable and making the process more user-friendly. Today we’ll take a look at some of the newest features of the VNS3 firewall.

For those unfamiliar, below is a short synopsis of how the VNS3 firewall works. You can also read our full Firewall Overview article here: https://cohesiveprod.wpenginepowered.com/firewall-overview-with-vns3

Each firewall rule is comprised of three parts:

  1. The chain (PREROUTING_CUST, INPUT_CUST, FORWARD_CUST, OUTPUT_CUST, or POSTROUTING_CUST)
  2. The conditions (packet parameters to match on), and
  3. The target (after the -j option; the action to be taken on the packet)

Packets entering VNS3 traverse the chains in a particular order. The chain determines at what point during packet processing a rule will be matched and an action taken on the packet. Certain conditions and targets may only be used in certain chains.

If a packet does not match any rule in a chain, the default action is ACCEPT, which simply sends the packet along to the next step.

A rule’s conditions determine which packets will be matched; all conditions of a rule must be met before an action will be taken. If any condition is not met, the packet will be checked against the next rule in the chain.

When a packet matches all conditions of a rule, the target operation is carried out and the packet moves on to the next step. That packet will NOT be checked against any other rules in that chain.

These basic conditions (as well as many more) are available:

  • -s <ip or cidr> : Matches the source address of the packet. Accepts an IP, a CIDR, or a comma-separated list of either.
  • -d <ip or cidr> : Same as the above, but matches the destination address.
  • -p <protocol> : Matches the protocol of the packet. (-p Also offers the additional –dport <port> and –sport <port> options if applicable to the protocol specified.)
  • -i <interface> : Matches the incoming interface by name. Not available in OUTPUT or POSTROUTING.
  • -o <interface> : Matches the outgoing interface by name. Not available in INPUT or PREROUTING.

The diagram below details the order of the steps packets take as they traverse VNS3.

VNS3 Firewall Map

Example: Pre-routing Firewall Rule

Lets take a look at a few examples, starting with this PREROUTING firewall rule:

PREROUTING_CUST -i eth0 -s 172.31.0.0/16 -j DROP

This rule matches packets entering on the eth0 interface (-i eth0) with a source inside the 172.31.0.0/16 network (-s 172.31.0.0/16). The DROP target causes matched packets to be discarded without any reply.

If the above rule is the only PREROUTING rule you have in place, any packet entering on VNS3’s eth0 interface with any source outside the 172.31.0.0/16 network will not be affected; the default ACCEPT action will be taken and the packet will move on to the next step.

Immediately after the PREROUTING chain, the destination IP of the packet is used to determine whether an attempt will be made to forward the packet or if VNS3 itself is the destination. If the packet’s destination IP is one on an interface belonging to VNS3, it will be sent to the INPUT chain. If the packet’s destination is any other address, an eventual outgoing interface is chosen and the packet is sent on to the FORWARD chain.

As an example, TCP port 8000 traffic for the VNS3 Web UI and API traverses the INPUT chain, as do response packets from VNS3’s configured DNS and time servers, among other internal services.

Following a routing decision to determine the outgoing interface and before being sent to the POSTROUTING chain, packets leaving VNS3 (including Web UI and API responses) traverse the OUTPUT chain.

With the following FORWARD rules in place, all traffic between the 10.0.0.0/24 and 192.168.0.0/24 networks is allowed, and nothing else.

FORWARD_CUST -s 10.0.0.0/24 -d 192.168.0.0/24 -j ACCEPT

FORWARD_CUST -s 192.168.0.0/24 -d 10.0.0.0/24 -j ACCEPT

FORWARD_CUST -j DROP

Only a packet with a source inside 10.0.0.0/24 and destination inside 192.168.0.0/24 (or vice-versa) would match one of the first two rules; those would skip over the DROP rule and be sent on to the POSTROUTING chain. Anything with a source or destination not matching those two networks is dropped by the third rule.

This is a basic example of how to configure whitelisting; the DROP rule at the end with no conditions matches all packets and defines a default action for the chain.

New Features: Masquerade-Once and GeoIP

Let’s take a brief look at a couple newer features of the VNS3 firewall: MASQUERADE-ONCE and geoip.

For this example, our local network is 192.168.0.0/24, and our goal is to SNAT all traffic outbound from the 192.168.0.0/24 network to the address on VNS3’s internet-facing interface.

The firewall rule could look like this:

POSTROUTING_CUST -s 192.168.0.0/24 -o eth0 -j MASQUERADE-ONCE

We recommend using MASQUERADE-ONCE over MASQUERADE where possible because it is more performant. It does this by calculating the source IP based on the -o outgoing interface only once – when the rule is created. This allows use of the connection tracking table to shorten the time packets spend traversing firewall rules.

The “geoip” module condition was added to the VNS3 firewall to allow users to block/allow traffic by country of origin/destination. The example rule below firewall blocks all traffic originating from Australia(AU), Canada(CA), and Japan(JP).

PREROUTING_CUST -m geoip –src-cc AU,CA,JP -j DROP

For more information about “geoip” blocking check out the Max Mind API. For more information about the VNS3 firewall, check out our documentation. If you have any questions please reach out to Cohesive Support via email at support@www.cohesive.net or through our contact us page.

Things I Like About VNS3: Network Interface Auto Discovery and Configuration

by | Oct 1, 2020 | VNS3 Features

Cloud virtual machines, including network appliances like VNS3, can have additional network interfaces added to them dynamically. If you have ever worked on actual computer hardware you will appreciate how much EASIER this is! No screwdriver required. 

However, in the cloud, even though Amazon, Azure, Google, etc.. have made adding interfaces really easy, there is usually some non-trivial work to do for getting those interfaces configured in your virtual appliance. Search via a web browser for “Add additional network interfaces, AWS, ?” (where “?” is replaced by your favorite vendor of datacenter network products (Cisco, Juniper, F5, etc..).

What you will find are instructions which include steps for remote shell into the device (get security keys, port 22 access), bring up a command line terminal and use a variety of operating system or vendor specific configuration commands. 

NOT WITH VNS3. Let’s take a look. 

Here is a link to a 3m30s video which shows the whole process (skip to the last 20 seconds) if you don’t want to read any further.

Here is how simple it is:

1. Go to VNS3 Interfaces page to verify interface is not already attached.

2. In the Amazon (or Azure or Google) portal, attach a new interface to the VNS3 Controller.

VNS3 Add interface page

3. Go back to the VNS3 Interfaces page, and within seconds you will see the new interface attached, and configured with its private ip address and its public ip (if there is one).

VNS3 Interface added

That’s it.  In our example “eth1” is now attached and configured!

No remote shell. No command line. No operating system or product configuration commands.

(Note: By default we bring new interfaces into the system in a disabled state.)

If you want a little more context please take a look at the video link at the top of this post.

Another Think I Like About VNS3: Pricing Model

by | Sep 22, 2020 | VNS3 Features

Cohesive Networks and its Application Security Controller “VNS3” have plotted a course to customer success that was “born in the cloud.” Since VNS3 did not start life as a piece of “metal” we have been able to respond to customer needs in a way that legacy network providers could not. 

One of these responses is our pricing, which is dictated by the network complexity (and is tied to network value) but does NOT include a premium for increased network performance. At the end of the day network performance is tied to the power of the underlying networking hardware. Traditional network vendors have always gotten a “twofer” in this dimension. As the cost of the underlying hardware goes up, the cost of the software inside increases as well. So as you the customer put more money into making the networking software perform faster, the vendor gets paid a premium as well. 

The cloud made this “separation of concerns” more obvious. A network appliance running on an AWS t3.micro has the same software composition as the same appliance running on a c4.4xlarge. As such, why should the price of the software component go up dramatically as the virtual machine price increases?

You can make the argument that the larger machine lets you run that many MORE connections, so it is implicitly a value/price per connection….which in some uses cases may be true. But what if you have a “small network” that you want to run at maximal performance? What then?

To make the point here is a popular legacy vendor’s cloud router pricing:
Cloud Vendor Pricing

As the instance size goes up from t2.medium to c4.4xlarge, the AWS price per hour goes up 75 cents per hour and the network vendor’s price goes up $1.87 per hour! The vendor ends up charging more than double for increased scale than Amazon. 

I would argue this is an artifact of “metal thinking” – and is necessary to avoid dramatic negative effects upon the “on the ground” pricing where such pricing has been the norm.

Cohesive instead lets you start with a small network and scale up the complexity of your network. If that network complexity does not grow we do not TAX you for the money you spend to increase that network’s performance. 

Here is our Lite edition pricing for comparison:

VNS3 Pricing Table

As the infrastructure price goes up the VNS3 network appliance price is flat.

As the size of your network grows, your price per hour grows for the VNS3 value. Our experience is that at scale we tend to be about ½ the price of the cloud vendor platform functions, without even taking into account the flexible work value creation that comes from visibility, support, plugins, and more.  And if that isn’t enough, we usually come in at 1/3 to ¼ of the price of the “metal makers” at scale since we do not ever have to defend our “ground based business.”

Give it a test drive – see how the price/performance curve feels to you. 

On the topic of “ground based business” – Cohesive will be making a metal device for data center DMZs or corporate office locations.  We would expect for many customer deployments the price would be…..FREE! And for others it would be at cost of goods + 10%. Think of a piece of metal with many more capabilities than a Cisco ASA or Meraki – but you know, free. Let us know if you want to know more about that in future.