I’m a programmer. I write web apps. Or used to. I did this successfully for a dozen years without knowing what a router was. I did this successfully trusting that my mail would be delivered without knowing how it works. This is no longer going to be the case for many programmers. Bc migrating to the cloud is going to force you to understand what a virtual network is, bc you can’t create a Virtual Private Cloud(VPC) without understanding a virtual network, b/c all cloud resources exist in a VPC. And your networking experience with your home router is not going to prepare you for the number of possibilities available. Much less what they are called, so you don’t sound stupid, and you know what keyword to look in Google how to do it in the AWS or Azure consoles.

This is what I knew about networking before I took networking and systems administration this past years. And I think it is more than most non-networking related programmers.

Your computer gets a IP address from DHCP

router NAT makes all your devices inside look like 1 IP address

web pages serve on TCP port 80 and 443, telnet is 23, SSH is 22, FTP is 21, clear SMTP is 25

When your computer sends a packet computer in your home network, it sends it with MAC address of the computer, and IP address of that computer.

When your computer sends a packet(it is actually called a ethernet frame) to internet, it sends it with MAC address of router, but IP address of destination IP. It distinguishes between which MAC address, using that 2 funny configuration item you never understood why you needed to enter, called a subnet mask and gateway address. If the packet’s destination’s address ANDed with subnet mask, equals the computer’s address ANDed with subnet mask, the packet is sent to the destination computer’s MAC address, otherwise it sends it to the gateway address’s MAC address. Simple if-else logic.

Include in your knowledge today, if your computer has more than 1 NIC(virtual or physical), it now has a routing table built in. It just uses it for your apps, not for forwarding packets received on a interface not meant for itself. And the default gateway is what routers call: the next hop on default route.

Here is what you’re going to need to know about networking, b/c of the skeumorphic design of cloud providers like AWS and Azure, is catered to networking professionals.

1) Edge Firewalls. How routing works to get to internet provider. 2) ACL rules on router. 3) Host based firewall. 4) Basic router networking design for egress to internet, including understanding routing tables and how they are used.

The design network professionals are familiar with

However, routers play a much larger part of networking for a networking professionals’s life, than it ever does inside a VPC or VM host, or in the example above. But I won’t delve into that here.

What you are looking at above is a simple office network, if they feel they have the manpower to keep internet servers in the office. There is only 3 subnets belonging to the company, in this example.

Subnets are basically groups of computers that can talk to each other without a router. 2 subnets above (with all the Windows machines) have private address ranges, which means the internet doesn’t recognize the private addresses and doesn’t know what to do with them, but your routers can be programmed to communicate with each other’s private subnet.

A router does this with internal entries called a routing table, which is which port to send the packet, if the address starts with such and such. So the 2 private subnets have addresses that start with different values, and the routers sends the packets between and destined for the other private subnets this way.

Packets sent to internet(green), are disguised by the router using a process called NAT, where it renames the source of the packet as it’s own internet IP address, and keeps a journal of all the packets it does this for using source port numbers as a ID, so it can reset the original address and port number when it receives a response back that ID port. This NAT system has secondary effect of blocking outside computers from starting a conversation with a computer in private subnet (red).

The 3rd subnet is what was called a DMZ in my day and age. The AWS cloud provider call this a public subnet. Like all subnets, the group of computers inside a subnet can communicate with each other. But unlike the computers in the private subnet, there is a method for the computers on internet to initiate the conversation(yellow). One way to design this is to have the DMZ subnet consists of public addresses, as in the above example. OR in the case of AWS, you should think of them as using a mechanism called Static NAT, which each private IP address, upon reaching router, the address is replaced with it’s personal public IP address. And vice versa.

BUT typically computers in the DMZ cannot initiate communicate with the private addresses, bc the router should block it with either with NAT or ACL, but the route has to exist. Typically, the computers in private network can initiate conversation to DMZ, if communication is necessary.

This is not true in AWS Cloud, which most designs have the “Public” subnet able to initiate speaking with the private subnet. This indirection provides some level of difficulty of getting access to send packets seemingly originating from DMZ, to be accepted from the private subnet, and therefore a little more security to the private subnet. In the cloud provider, the public subnet has to be able to initiate conversation with the private subnet, if you want console access to any VM inside the private subnet (though I can’t say the last sentence with 100% certainty. To administer VM in private subnet, you can do it via access a VM in public subnet. But now since console emulators exist on webpages, these may be able access the VM in private subnet, thru channels that are opaque to me, and cloud providers may have services such as VPN gateways that give access to the private subnet, bypassing the public subnet).

Each VM has, though the name is different on each platform, a simple ACL based firewall in front of each VM, where fine grained control can be used to further block more ports and computers, to allow only a few, such as allowing only incoming port 80 on webserver.

Desktop or Server Virtual networks in hypervisor hosts are similar to both physical networks and virtual networks within cloud services, but different.

By default, there are no routers in virtual networking of VM hypervisors, not used in Cloud implementations.

Even playing with VMs will likely not prepare you fully to configure Cloud virtual networks, as VMWare, Virtualbox, and HyperV by default assign all new VM to a NAT component, making the VM networking calls seem like it is coming from your computer. This gives the same illusion of seamlessness that DHCP from your home router provides, with your home computer booting up and automatically having internet. Most of the VM platforms will give you options how the VM is plugged into a network: like VMware give you bridging (VM pretends it is plugged physically in same network as the host), and host only (the VM and host look like they are plugged directly to each other, via a virtual NIC added to host that has it’s own IP address). Vmware also has something called a LAN segment which is basically a ethernet switch, plugged no where else. Vmware hides networking behind a single menu item called virtual network. Virtualbox has similar features, called respectively NAT, Bridged adapter, host only, and internal only. And networking is integral to virtualbox, as when you create a VM, you have to pick what kind of network it is connected to. Fortunately NAT is default. Virtual Networking is more prominent in virtual boxes’ UI. HyperV takes it a step further, by calling their connection completely skeumorphic for network professional by calling them: default switch (is NAT), external switches (which are bridged to physical or virtual NIC), internal switches(which your host looks like it is plugged into and has IP addresses), and private switch which the VMs are plugged into but not the Host (so no virtual ethernet adapter, with IP address, to ping the VMs with). And provides a virtual SAN, too.

How VM are connected to host and network, is less geared toward network engineers, but understanding networking helps

The above is essential to understanding desktop VM networking capabilities, and yet is completely useless for understanding cloud virtual networks, bc cloud networks mimic network traffic appliances like routers. This would seem to be counter-intuitive, since the cloud is simply services such as VM, virtualized to run on another provider’s hardware.

There are no built in provided routers for VM, bc there is no need for it, except as skeumorphic representations of a network appliance that has no purpose inside a VM architecture. You can download a VM, that acts like a router. But I assure you that this only serves the purpose to simulate a physical network, and has no place practically inside a VM host. But if your purpose is to simulate a physical network device such as to learn how to configure it, you can do that. Cisco routers exist as crippled VM. GNS runs smaller VMs of routers for you to configure, inside a VM.

The skeumorphism of networking in cloud provides, provides some confusion b/c it hides the additional accessibility and firewall rules to each VM to access each other’s VM’s services, as networking devices and services. So if you want to hide a machine from being directly accessed by internet, instead of a checkbox, of VMs or VM groups it can access, or the internet, what you get is routing tables, switches, firewall rules, and network ACL’s. So if you want your application to behave predictable, you need to know how the network appliances work and are configured, so you can predict what they mean, when they want you to add a route to 0.0.0.0/0. This is the part which is going to be difficult to understand, without a networking background.

Cloud virtual networks configurations are skeumorphic to what network professionals are familiar with, though the connectivity functionality can be distilled in the grid

Above is how the typical physical networking implementation, is probably going to be represented in cloud VPC network. And what their names are in AWS. And below that representation, is a grid, where it can be as simple as it could be (but isn’t).

Below is one way you can restrict access, but if you did defined the Network Security Group rules to deny/accept access control by subnet address, that would make administration easier. You have to create a separate subnet, but then you can just add VM to the subnet, like it was a group, and rules to the subnet, then apply to the VM.

I didn’t want to draw second subnet, but I think you can get idea of how security groups, can do explicitly, what routing rules, NAT, and ACL can do by defacto in a public and private subnet. But even using network security groups, requires you to know what a 0.0.0.0/0 means.

Me? I haven’t decided which I like more, to control network access. My brain has been conditioned in last 18months to building the routing tables, the right way. It pervades too much of my mindspace.