Creating a isolated IOT network with the UniFi Dream Machine

Over the last couple years the amount of IOT devices we have at home has increased quite dramatically, and it seems very Xmas holiday we get new smart plugs or smart lights. Also with having 2 young children i can see the amount of IOT devices that we have is only going to increase.

I first heard about Ubiquiti about a year ago, and straightaway I was impressed at how good their networking products were. I was immediately drawn to the Unify Dream Machine, however after reading some of the initial reviews, and with the COVID pandemic I put everything on the back burner.

A few weeks ago, and after reading some of the online reviews of the latest firmware I decided to take the plunge and get the dream machine. Even though its only been a few days, I must say I am impressed.

One of the things I wanted to have was to separate network my ever expanding IOT devices, which include:

  • Amazon Echo’s
  • Google Home mini
  • Various Smart plugs and lights
  • Ring Door Bell and Chime

The only device I had any really issue with was the Google Home Mini, but more on that later. The initial steps were as follows:

  • Create a separate network
  • Create a separate WIFI network attached to the network
  • Create some firewall rules to ensure the IOT devices are unable to communicate with any of the other networks

I already have a LAN network setup and WIFI for my normal devices, so the first step is to create a separate network, log into the Unify controller, go to settings, Networks and local network, Click on “Create New Local Network” and click on the Advanced option.

Give your Network a name, leave the network purpose as corporate , and a VLAN no, and supply a Gateway IP/Subnet and DHCP range, the rest can be left as default. Don’t forget to click “Done” at the bottom of the page.

Next, click on Wi-Fi networks, then “create New Wi-Fi Network” and once again click on the advanced option.

once you are in the WIFI creation page, you give the WIFI name, ensure the network is enabled, select the security protocol and provide a password for the WIFI Network.

Further down on the same page, under the advanced setting section, enable VLAN usage and enter the VLAN ID, and click done at the bottom of the screen.

Almost done, the IOT network has been created and associated to a WIFI network. You should now be able to add devices to this network. Last step is to ensure the IOT devices cannot communicate with the rest of the network.

Under “Internet Security” click on firewall.

Select LAN, and click on “Create New Rule”.

Under Type of connection select LAN in. Give the Network rule a description, and ensure it is enabled. Under Rule applied, selct “Before Predefined Rules” and under Action select “Drop”. Under Source device select “Network” and the name of the network you created earlier.

Further down on the same page under “Destination Type” select “Network” and lastly under “Network” Select the network your normal devices are on and click on “Apply”.

Once you’ve clicked apply, you should now see your new firewall rule, which will ensure the IOT devices are not able to connect to the rest of the network.

I managed to set up all my IOT devices on the new IOT WIFI except for the pesky Google Home Mini.

In order to get this up and running I had to create a temp firewall rule which allows the established IOT devices to communicate with the eatablished LAN devices. This rule will be disabled later and will not allow communication between any new IOT, and the LAN network. The following firewall rules were configured:

  • Type: Lan In
  • Description: “give it a description”
  • Rule Applied: Before Predefined Rule
  • Action: Accept
  • Source Type: Network
  • Network: IOT-Devices
  • Destination Type: Network
  • Network: LAN

Under Advanced enabled “Match State Established” and “Match State Related” and selected apply.

You need to ensure the new rule you have created has a lower priority than the first rule. you can do this by dragging the new rule above the original rule.

After creating this rule, I was able to setup the Google Home Mini without any problem. After setup I disabled the new rule, and the Google Mini was still working without a hitch.

I hope you find this useful, there is so much more you can do with the UDM, such as:

  • Rate limit networks (Great for IOT devices)
  • Setting up a Guest Networks
  • Traffic Analysis
  • WIFI Blackout Windows
  • IDS and IPS Configuration
  • Creating Honeypots on each network

The Unify Dream Machine is brilliant bit of kit, and if you are interested in securing your home network or small office network to consider it.

Azure Firewall Routing

I recently had a customer who had a small Azure environment and was looking to add an Azure Firewall with the following requirements:

  • All traffic between their on-premise environment and Azure via an Azure firewall.
  • All VM to internet traffic should utilise the firewall’s public IP address.

As you may be aware all VM’s in Azure are connected to the internet via the Azure backbone. VM’s do not require a public IP address to connect to the internet. This obviously raises some major security concerns. There are a couple of ways around this, either by using forced tunnelling which lets you redirect all internet traffic back to your on-premise network either via S2S VPN or ExpressRoute for inspection with your on-premise firewall. The other option is to add a firewall in Azure. This allows you to direct all internet traffic via the firewall in Azure, and also allow you to direct all traffic between Azure and on-premise and vice versa via the Azure firewall.

Below is a quick overview of the design. Red is the flow from VM to the internet, Blue is the flow between on-premise and Azure.

In the above example we have a Hub VNet on 10.0.0.0/16 with a S2S VPN and an Azure firewall on 10.0.3.4, and a subnet on 10.0.2.0/24 and a single VM on 10.0.2.4. The spoke Vnet is peered to the hub Vnet with gateway transit enabled. The spoke VNet contains one subnet 10.1.1.0/24 with a single VM on 10.1.1.4.

Next step is to ensure all internet traffic is via the firewall and not directly over the Azure backbone. A quick way to do this is to find which IP address the VM’s are using to access the internet. Log into each VM and open your favourite browser and browse https://www.whatismyip.com/ . Both Vm’s will most likely have the same IP address.

In order to route all internet traffic to the firewall you will need to create a default route to the internet.

First for the hub VNet:

  • Route Table: hubtofirewall
  • Route Name: hubtointernet
  • Address Prefix: 0.0.0.0/0
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4
  • Associated subnet: 10.0.2.0/24

Next the spoke VNet:

  • Route Table: spoketofirewall
  • Route Name: spoketointernet
  • Address Prefix: 0.0.0.0/0
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4
  • Associated subnet: 10.1.1.0/24

To ensure the traffic to the internet is now traversing the firewall you can log back into the VM’s, browse to https://www.whatismyip.com/, you will notice the IP has changed to the firewalls public IP address.

Next step is to route all traffic between Azure and on-premise via the firewall, this involves route traffic destined to the on-premise network to the firewall. In the first route table named hubtofirewall add the following route:

  • Route Name: hubtoonprem
  • Address Prefix: 192.168.1.0/24
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4

Add the same details to the 2nd Route table, changing the name:

  • Route Name: spoketoonprem
  • Address Prefix: 192.168.1.0/24
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4

These routes can be confirmed by viewing the effective routes:

Hubtofirewall

Spoketofirewall

Now that you all traffic from Azure is routed to the firewall the last step is to route the traffic from the gateway to the firewall,

  • Route Table: gateway
  • Route Name: gatewaytohub
  • Address Prefix: 10.0.0.0/16
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4
  • Associated subnet: GatewaySubnet

Finally add the last route to the same Route Table:

  • Route Name: gatewaytospoke
  • Address Prefix: 10.1.0.0/16
  • Next hop type: Virtual Appliance
  • Next Hop Address: 10.0.3.4

Provided the firewall is configured to allow traffic in both directions, all traffic should now traverse the firewall.

Job done 🙂