trents_blog/docs/posts/sandbox-iot-network.md

---
title: "Sandbox IOT Network"
date: 2024-04-27
draft: false
tags: ["RaspberryPi",  "linux", "router", "wireguard", "tasmota"]
authors: ["trent"]
post: 34
---
date: 2024-04-27


## Introduction
This is a scheme for connecting your smart devices to an sandboxed subnet
such that they cannot reach or be reached from anywhere outside of their subnet,
with the only exception being that each smart device can reach, and be reached
from an application server.

Using a wireguard tunnel between the application server and (wifi) ap server both enables the
flow of traffic between the application server and smart devices on the sandboxed
subnet, but also encrypts the mqtt traffic.


<figure>
  <img src=../../photos/iot_sandbox_network.png width="100%" />
  <figcaption>iot sandbox network</figcaption>
</figure>

## Hostapd
First install `hostapd` on your RaspberryPi. The relevant config file is
`/etc/hostapd/hostapd.conf`.  And then start/enable hostapd with `systemctl`.

## Describe Wifi AP interface
Without explicitly routing traffic between eth0 and wlan0, no devices connecting
to the wifi ap will be able to reach, or be reached from, the internet or your
home network.
```conf
# /etc/network/interfaces.d/wlan0

auto wlan0
iface wlan0 inet static
        address 10.0.8.1
        network 10.0.8.0
        netmask 255.255.255.0
        broadcast 10.0.8.255
```

## Install and configure dnsmasq (for dhcp)
Each device connecting to the wifi ap will need to know its' ip address,
therefore you can use dnsmasq for dhcp service.

Assuming you can figure out how to navigate the tasmota webui of each device
well enough to set the hostname and figure out the mac addr,
on the RaspberryPi wifi ap install dnsmasq and edit the config file.
```conf
# /etc/dnsmasq.conf
listen-address=10.0.8.1
interface=wlan0
dhcp-range=10.0.8.150,10.0.8.200
dhcp-host=bedroomlight,34:ab:95:c5:27:15,10.0.8.2
dhcp-host=kitchenlight,40:f5:20:11:a9:5d,10.0.8.3
dhcp-host=bathroomlight,70:03:9F:C5:7C:4C,10.0.8.4

```

## Create Wireguard Tunnel Between Application Server and Wifi AP
The wireguard tunnel both encrypts traffic between the application
server and the wifi ap server, but also enables communication between the
dashboard application server and the smart devices.  The devil is in the
configuration details.

I think you need to enable forwarding in sysctl on the wifi ap server so
that traffic can pass between `wlan0` and `wg0` (but I'm not entirely positive).
```conf
# /etc/sysctl.conf
net.ipv4.ip_forward=1
```

Configure wg-quick@wg0 on the wifi ap server as follows.
```conf
# /etc/wireguard/wg0.conf
[Interface]
Address = 10.88.1.1/24
PrivateKey = <private key>
ListenPort = 4449

[Peer]
PublicKey = <public key>
AllowedIPs = 10.88.1.2/32
```

Configure wg-quick@wg0 on the application server as follows.
** The magic is in the `AllowedIPs` value. **
```conf
[Interface]
Address = 10.88.1.2/24
PrivateKey = <private key> 

[Peer]
PublicKey = <public key>
AllowedIPs = 10.0.88.0/24,10.0.8.0/24
Endpoint = 192.168.1.88:4444
PersistentKeepalive = 25
```

## Next Step
The next step, not represented in the diagram, is to attach your
application server to a second wireguard tunnel such that it can be
reached from your client devices.

Note that you can also double-nat the application server in this scheme, because why not?
Everything happens inside wireguard tunnels. In my diagram the application server
is an virtual machine that is double-natted on an `libvirt` subnet.