2

I have a private LAN set up for my personal computer, printer, et cetera and have a separate guest network configured for Internet connected appliances and devices. The guest network is configured as a virtual adapter with AP/Net isolation in unbridged mode with a separate DHCP server and it works great.

The YouTube phone app and website allow you to connect to a smart TV on the same network and put the video that you're watching on the TV.

I'd like to be able to connect all of my "smart" devices to a guest network and still be able to use the functionality to, say, watch a video on the TV from a device connected to the private network in a typical firewalled DMZ fashion. The objective is that if a smart device were to become compromised, that it wouldn't be able to open a hole into my private network. What is the preferred way to configure this sort of routing/topology using DD-WRT?

Giacomo1968
  • 55,001
Alan Samet
  • 133
  • 1
    Most Miracast and screen casting services work on the same subnet via broadcast domain. You shouldn't be worried about smart TV's etc being compromised, they are firmware based devices. and next to impossible even with physical access to the tv etc to re-write the software that runs on it. Firmware devices are usually programmed at the factory via j-tag. even if they do have firmware revision updates later, they are usually encrypted in some way to stop modification to the file. – Tim_Stewart Mar 10 '18 at 19:21
  • Most modern flash-based processors support self programming instructions and use DMA fetch operations which increase the risk of compromise by way of DMA injection. It is entirely possible for vulnerabilities to exist that would allow self reprogramming of flash memory. Aside from that, other devices, such as an Android-based media device (firestick, chromecast, et cetera) that has an app that's been given network access is a far greater risk than the SmartTV itself. – Alan Samet Mar 27 '18 at 16:05
  • 1
    I think you may be mistaken. can you provide the source you learned this from? Unless I'm just misunderstanding you, or the acronym your using. DMA (direct memory access), has nothing to do with flash space, or flash programming. The flash chips you find in consumer products, like routers, tv's, phones etc have a pin on the chip that activates it for the flash programming mode, usually 3.3v or 5vdc. The devices that allow you to program through it's software have the pin-programming-mode safe-guarded through the use of checksums, and or encrypted firmware files. – Tim_Stewart Mar 27 '18 at 19:31
  • 1
    Nearly all modern microcontrollers support some set of self-programming instructions and it generally provides the functionality for you to do over-the-air firmware updates. On the Atmel AVR 8-bit microcontrollers, it's done through the SPM/LPM instructions. On the STM32 Microcontrollers, it's through the flash interface registers. Over-the-air/network firmware updates are not performed through JTAG or similar interfaces. The "pin" you're referring to on STM32's is typically a 2-bit combination of boot0/1 that will load a built-in bootloader, but once again, not how things work in the field. – Alan Samet Mar 28 '18 at 23:13
  • This is starting to sound like paranoia. You will find neither of these micro-controllers in any of these products. If they were used, do you NOT think the manufacturer would enable the bit-lock for SPM/LPM? I am not familiar with the STM32, but i would assume there is also a safe-guard for this. The processors being used in t.v's and smart devices have complimentary flash space, in a external chip. with circuitry to re-program the flash space if the engineers intended it for later. Why are you so worried about it? – Tim_Stewart Mar 28 '18 at 23:57

1 Answers1

3

This is a valid concern - it's understandable to keep smart devices on guest network, but then their local connection to other devices/computers on host network will mostly fail (depending upon firewall and use of broadcasts by the devices).

Here is how I was able to get around this on dd-wrt. There are multiple steps and couple of alternatives.
Here I'm assuming that the smart devices are on guest network and they need to be able to be discovered by and communicate with machines on the host network... but reciprocal setup is also possible using the mechanisms described below.

  1. First we need to configure host/guest boundary. Use iptables to block all NEW packets coming from guest to host (or at least from the smart devices), but allow ALL packets to go from host to guest. This way any communication started by host (to guest) will be allowed but not vice versa. This should be a safe enough arrangement.

  2. Many smart devices let others discover themselves using broadcasts, and the problem is that broadcasts are not relayed between subnet/interface boundaries as a rule. So even if we configure iptables to allow broadcasts from guest to host (or, say, open all traffic between guest and host networks), device discovery will not work.

    So, if we can somehow find a mechanism to forward the broadcasts from the smart devices to our host-network machines like phones/computers, the machines will reply to individual devices, connections will be established and communication will work.

    I was able to find two ways to do this and am explaining those below (for more details, see my answer on the dd-wrt forum).

bcrelay

This is a very simple utility that happens to be there on dd-wrt as well :). As the name suggests, it simply reads broadcast messages from one interface, and sends them out to another interface. Doesn't have many options, but at least it can run as a daemon.

With this I was able to relay the broadcast messages coming from the devices on my guest network to the machines on my host network, and the machines were able to discover the devices and communicate with them. But I eventually settled with samplicator as explained below.

samplicator

https://github.com/sleinen/samplicator

This is an interesting tool that can receive UDP datagrams on a given port and send them to a set of receivers. I found which ports are being used by the devices for sending broadcasts and then I ran samplicator on a spare Linux machine on those ports. samplicator started sending those packets to targeted devices I specified in its config file.

In the meantime, in iptables, I allowed NEW packets from guest to host on only those ports (and only to targeted devices). Thus these packets are now able to reach their target hosts and the communication picks up. One good thing in using samplicator is that I'm not sending unnecessary broadcasts to host network (such as DHCP)!

I've omitted a few details here. One of these ways should work in the cases such as described by you.

manisar
  • 68