Deploying a VyOS AWS VPC NAT Instance

The easiest way to provision NAT internet access for a private AWS VPC subnet is to create a NAT gateway.  If you choose to create your VPC with the AWS VPC creation wizard, you can select a scenario that creates one for you automatically.  On the other hand, you can create a NAT gateway from the AWS console too.  The Amazon Virtual Private Cloud User Guide has a section covering NAT gateways with everything you need to know, including a comparison of NAT gateways and NAT instances.

I am going to deploy a NAT instance.  A NAT instance provides more configuration flexibility and for my use case will be less expensive.  On the other hand, it requires manual maintenance, for the instance type I will use, has less bandwidth, and without additional work, doesn't provide for high availability.  Finally, I want to experiment with VyOS so I will use it as the platform for my NAT instance.  I hope to make use of the same instance for IPSec VPN too.

The Amazon Virtual Private Cloud User Guide also has a section covering NAT instances that explains how to deploy a NAT instance using an Amazon Linux Machine Image (AMI) configured to run as a NAT instance.  Even though Amazon has specifically prepared their AMI for use a NAT instance, I want to use VyOS.  So I followed the Amazon NAT instance instructions but substituted a VyOS AMI for the Amazon Linux pre-configured AMI.

VyOS is a Linux-based operating system for routers and firewalls that allows you to configure all network functions via a single unified command line interface just like in classic hardware routers. It includes static and dynamic routing (OSPF, RIP, and BGP), stateful firewall and NAT, various VPN options (IPsec, OpenVPN, PPTP, L2TP), DHCP server and more. The system is fully open source and extensible.  To learn more about VyOS, visit the VyOS web site.  The VyOS AWS AMI can be found here.

I am not going to replicate the steps outlined in the Amazon VPC User Guide other than to stress three things that are covered there.  

1. You must disable source/destination checking for your instances as described in the instructions.
2. If you did not assign a public IP address to your NAT instance during launch, you need to associate an Elastic IP address with it.
3. Update the main route table to send traffic to the NAT instance.

I had assumed that I needed to build the NAT instance with two network interfaces, one for incoming traffic and another for outgoing traffic.  That's typical.  I couldn't understand why the VyOS device only included a single network interface.  I assumed I'd just tack on a second network interface, attach it to the private subnet as eth1, and then route traffic to the public subnet via eth0.  I took a look at the Amazon pre-configured NAT instance and noticed that it only had one network interface as well.

At that point it dawned on me that since my private and public subnets were both part of the same VPC network, I really only needed one network interface.  In my case, the VPC network space is the class B space at 10.0.0.0/16 with a class C public subnet at 10.0.0.0/24 and a class C private subnet at 10.0.1.0/24.  Given those networks, a single interface will be able to address both incoming and outgoing traffic.  I had never thought about a one network interface NAT.  Usually the inside and outside networks are truly separate networks so two interfaces are required.  Not here.

In the AWS VPC world you use security groups, which exist outside of instances, and which handle typical firewall concerns.  You use route tables to handle routing concerns.  Given those two facts, the only thing that the VyOS NAT instance needs to do is handle the NAT function itself.

From the VyOS command line:

$ configure

# set nat source rule 100 outbound-interface 'eth0'

# set nat source rule 100 source address '10.0.1.0/24'

# set nat source rule 100 translation address 'masquerade'

# commit

# save

Saving configuration to '/config/config.boot'...

Done

# exit

$

You will need to substitute your private subnet CIDR specification for 10.0.1.0/24 in the example above.

In my case I have been thinking about using 10.0.0.0/16 instead to allow for the possibility that I might create other private subnets down the road, in which case specifying the entire 10.0.0.0/16 network would allow me to use the NAT as configured without making additional changes.  I am not too concerned about the fact that the public subnet at 10.0.0.0/24 would be covered by that rule since I wouldn't be routing through the NAT instance from that subnet in any event.  For now though, I'm going to leave things as set forth above.

This is a somewhat lengthy post for what amounts to three lines of configuration code plus one command to get into configuration mode and three to make the changes permanent and then exit configuration mode.

This was a very good learning exercise for me and a splendid introduction to VyOS.