Category: Networking

Google’s Cloud NAT gateway

Google Cloud NAT is just 3 gcloud commands and a shell script
Thanks to Yuvraaj at crave.io for the following

Google launched something called Cloud NAT Gateway that charges for bandwidth to do NAT. It makes it more expensive to run than going with external IP (at least in the low volumes that I do). I found this blog entry by Yuvraaj at Crave.io that allows you to enable NAT in a few steps. I’ve documented the commands below so I can refer to them in the future if I need them and in case the crave.io blog entry is no longer available or I can’t find it for some reason.

Create or edit this file/script that runs everytime the machine is booted

/etc/rc.local
#!/bin/bash

set -x

# Turn on IP forwarding
sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward"
# Turn on the route
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Setup Route in GCP Routing table

gcloud compute routes create no-ip-internet-route --network default --destination-range 0.0.0.0/0 --next-hop-instance nat-gateway --next-hop-instance-zone us-west1-b --tags no-ip --priority 800

Setup networking tags for VMs that need this 

gcloud compute instances add-tags <existing-instance> --tags no-ip

VLAN tagging

So in the process of moving my IOT devices to its own VLAN, I ended up moving all of my endpoint devices onto its own VLAN as well, on a separate network than my servers. storage and networking infrastructure.

Originally this started off with just the wifi devices on the new VLAN but after I was done doing that, it just felt like some wired devices had to be moved too, the ones that weren’t a server per se.

You could argue this was a useless endeavour since all the devices have access to the servers and vice versa. It just feels cleaner. There’s probably a better technical reason I can’t think of right now.

So after I setup the devices VLAN and pointed the SSID at it, the wired devices became my next target. There were a couple of wired PCs that was obviously going on the new VLAN, but they were connected to a Fortinet switch in another room instead of the Meraki stack. So I had to log into that switch, create the VLANs/descriptions, and apply the corresponding VLANs to the physical switchports. Those went easy enough surprisingly.

It was when I got to my HTPC that I ran into some learning opportunities. In reality, the HTPC also functioned as a Hyper V server where one of my DNS servers resided. The server had to be on the server VLAN (cuz of its IP address) while the HTPC technically should be on the devices VLAN.

Long story short, there are a couple ways of doing this. In the end I put the switchport in trunk mode, with no native VLAN declared. Then in Hyper V Manager, set the virtual switch to the devices VLAN. Then in the VM settings, set the VLAN ID to the server VLAN.

The other way works as well I think. If you set the native VLAN for the trunk port, then you don’t need to declare a VLAN ID on the virtual switch. And you just set the VLAN ID on the VM.

Isolating IOT devices to its own VLAN

I’ve put this off long enough and finally today I decided to move my IOT devices (speaker, camera, lock) to their own VLAN.

What made me procrastinate wasn’t the creation/moving them to a VLAN, that’s easy enough with my Meraki network stack. All it takes is the creation of a new VLAN, a new SSID and VLAN tag it, and firewall rules to block it from accessing the rest of the network. What made me procrastinate was the thought that quite often the phone needs to be on the same network, can access the IOT device and I wasn’t about to switch my phone to using the IOT SSID everytime I needed to use IOT.

Turns out that’s not entirely true at all… the camera was happy being in its own VLAN with no access to my phone… the app just treated it like a remote device as if I was connecting to it when I wasn’t at home.

The lock was a little more finicky. I recall there was a setting for the Auto Unlock to recognize you were home based on your phone connecting to the home wifi. Turns out it now allows you to pick a different wifi than the SSID the lock is connected to.

Finally the speaker was what made me hesitate the most. And rightly so. As I moved all the IOT devices to their own subnet/VLAN, Spotify wasn’t able to detect/connect to the speaker unless I switched to the IOT SSID, or allowed IOT VLAN access to the rest of my LAN.

First I tried to write firewall rules to allow/deny traffic in the SSID. This had limited success. Then I took a step backwards by trying to write allow/deny rules in the ACL of the switch cuz that’s what the internet said. But this made no sense as I finally came to my senses and wrote the firewall rules in the… firewall.

I had three goals so I wrote three rules:

  1. I wanted every device regardless of their IOT to use my DNS servers (for now anyways, this may change when I add guest network).
  2. I wanted devices outside of the IOT network to be able to ping IOT devices (like Spotify on my phone to detect the speaker).
  3. I wanted IOT devices to not be able to ping anything outside of its VLAN.

I may need to tighten this down a bit more as I add more VLANs but for now this works as I intended. IOT is banished in its own VLAN. I can still access IOT devices. But they can’t initiate any traffic outside of its VLAN.