Sai Charan

This is yet another note to self on setting up my home network to isolate ‘smart’ and other IoT devices into isolated networks in their own subnets, but having a functional UX for the family.

Contents

1. End Goal
2. Choosing a version of DD-WRT
3. Virtual Interface (WLAN) and VLAN Setup
4. mDNS Setup for Media Devices
5. Static Route
6. Firewall
7. Caveat
8. Conclusion
9. Acknowledgements

End Goal

Here’s an outline of the end goal in ASCII art:

                                               / WLAN B1 (10.2.2.1/24) - Miscl. Devices
                                              / 
ISP -- Gateway/Router-A ---- Gateway/Router-B ---- WLAN B2 (10.3.3.1/24) - IoT Devices
             |                  (DD-WRT)      \
             |              [10.1.1.100/32]    \ LAN B3 (10.4.4.1/24)
          WLAN A1                                    |          |
       (10.1.1.1/24)                             AppleTV   Chromecast
       |     |     |
       Mobile Phones

Choosing a version of DD-WRT

The version of firmware recommended on DD-WRT’s router database is quite a bit dated, and using the bleeding edge beta from the forums isn’t always dependable, so I’ve recently started picking up builds recommended on flashrouter.

Virtual Interface (WLAN) and VLAN Setup

Router-B runs DD-WRT firmware in the Gateway mode. The basic setup itself is a straight forward adaptation of Guest Wi-Fi setup on dd-wrt wiki. Basically, Wireless > Basic Settings > new Virtual interface with AP Isolation enabled, and running a Unbridged network configuration with NAT, Net Isolation and DNS redirection enabled. In addition, I have a VLAN setup for LAN B3 with one of the physical LAN ports on the router. Similar configuration for the VLAN, can be configured under Setup > Networking. The IP Address/subnet here will be that of the interface, eg. 10.x.y.z/24. At the bottom of Setup > Networking > DHCPD, I setup a different DHCPD for each of the WLANs, and VLAN.

mDNS Setup for Media Devices

These rely on mDNS broadcasts to allow client devices to discover services. However, by default these broadcasts don’t are local to the subnet of the (AppleTV/Chromecast) device. A solution for cross subnet/interface broadcasts would be the avahi-daemon. Fortunately, DD-WRT supports installing tools such as this via Entware opkg command. I have Entware running off a tiny flash drive setup as described in installing Entware followed by opkg update && opkg upgrade && opkg install avahi-utils. Here’s my /opt/etc/avahi/avahi-daemon.conf ¹:

[server]
use-ipv4=yes
use-ipv6=no
check-response-ttl=no
use-iff-running=no
allow-interfaces=br0,vlan2,vlan6
allow-point-to-point=yes
enable-dbus=no

[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes

[reflector]
enable-reflector=yes
reflect-ipv=no

[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3

[wide-area]
enable-wide-area=yes

This snippet in Administration > Commands > Save Startup will auto start avahi-daemon:

# Start avahi/mDNS
echo "nogroup:x:114:nobody" >> /etc/group
/opt/etc/init.d/rc.unslung start

And save the following with ‘Save Firewall’. [The TTL bit was a nice find][1].

# Chromecast/AppleTV mDNS advertisements on vlan6 (AppleTV/Chromecast), from WAN
iptables -I INPUT -p udp --dport 1900 -i `get_wanface` -j ACCEPT
iptables -I INPUT -p udp --dport 1900 -i vlan6 -j ACCEPT
iptables -I FORWARD -p udp --dport 5353 -i `get_wanface` -j ACCEPT
iptables -I FORWARD -p udp --dport 5353 -i vlan6 -j ACCEPT
iptables -I INPUT -p udp --dport 5353 -i `get_wanface` -j ACCEPT
iptables -I INPUT -p udp --dport 5353 -i vlan6 -j ACCEPT

# Increase IP TTL so it can go an extra hop
iptables -t mangle -A PREROUTING -d 239.255.255.250 -j TTL --ttl-inc 1
iptables -t mangle -A PREROUTING -d 224.0.0.251 -j TTL --ttl-inc 1

I verified avahi-daemon/mDNS working by firing up Tildesoft’s Discovery app and looking for my devices and also by firing up YouTube app for casting and the phone’s AirPlay to mirror the screen. The devices are now discoverable by phones and other clients.

However, the actual AirPlay mirroring and casting don’t work :-)

Static Route

mDNS discovery responses contain the IP/Port of the service so clients know how to reach these devices.

_googlecast._tcp.
    Chromecast-xyz
        10.4.4.4:8009
        ...

Starting with a simple traceroute 10.4.4.4 in WLAN A1 in subnet 10.1.1.1/24, it was clear that the network did not know how to route the packets destined for 10.4.4.4. So a friend suggested adding a static route in Gateway/Router-A for packets bound to 10.4.4.0/24 with Gateway 10.1.1.100. And traceroute went until the gateway, and stopped at that with 100% packet loss.

Firewall

The final piece of the puzzle was in figuring out the firewall rules. I started off with a catchall rule that accepted all forwarded traffic to vlan2 (which is the default WAN interface on DD-WRT devices; run get_wanface in an SSH session into your router to check).

Then I added ports 8008, 8009, and high ports as a FORWARD rule, an adaptation from ², including this to the ‘Save Firewall’ script. Note that I had also added TCP ports based on a packet type from a Wireshark packet capture of the session that failed to connect with firewall enabled for UDP packets.

# https://blog.g3rt.nl/allow-google-chromecast-host-firewall-iptables.html
# Punch a hole out of the router into the private 'WAN'
iptables -I FORWARD -i vlan2 -p tcp --dport 7000 -j ACCEPT
iptables -I FORWARD -i vlan2 -p tcp -m multiport --sports 32768:61000 -m multiport --dports 32768:61000 -j ACCEPT
iptables -I FORWARD -i vlan2 -p tcp -m multiport --dports 8008:8009 -j ACCEPT
# van6: Media Center
iptables -I FORWARD -i vlan6 -p tcp --dport 7000 -j ACCEPT
iptables -I FORWARD -i vlan6 -p tcp -m multiport --sports 32768:61000 -m multiport --dports 32768:61000 -j ACCEPT
iptables -I FORWARD -i vlan6 -p tcp -m multiport --dports 8008:8009 -j ACCEPT

Caveat

We have some early Wemo light switches which did not really play nice with AP and Net Isolation on the Virtual Interfaces, so for the corresponding VAP, these are disabled.

Conclusion

And, that’s all folks. With this, I have devices isolated in their own networks/subnets that are firewalled off, but still usable across subnets for casting/AirPlay mirroring.

Acknowledgements

Thanks to the DD-WRT contributors, community for the very usable software and readable documentation. Thank you to the authors of https://www.shackleton.io and https://blog.gert.nl for the very helpful tips. Many thanks to @zyxmon and @ryzhovau of Entware for quickly fixing a bug with avahi-utils on DD-WRT.

And of course, to my family, for bearing with many, many, many network disruptions!

References