I want to be able to send broadcast packets from guest to host subnet. Is there a way? I can modify or recreate guest network as needed, but I do not want to have host and guest on the same subnet and lose firewall between them.
(What I'm trying to achieve here is the discovery of few 'Web Things' which reside on my guest network, by devices such as phones on my host network).
Last edited by Tuus Vere on Sat Feb 15, 2020 20:44; edited 1 time in total
One thing to note is that the discovery of the 'Web Things' residing on the guest network is to be done by devices (such as phones, and not just Linux computers) residing on the host network. While I'll investigate, I'm not sure if Avahi/mDNS will help in this scenario.
After extensive research I've been able to find two interesting and completely unrelated ways to resolve this issue of mine!
Before explaining these, I just want to reiterate that it is virtually impossible to make routers forward broadcast messages between different subnets/interfaces. Given below are two workarounds to overcome this constraint.
1. 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 web-things on my guest network to the devices on my host network, and the devices were able to discover the things and communicate with them.
It has some limitations or issues as explained below.
Can be demanding on resources (I didn't test that).
All broadcasts are relayed - including DHCP requests etc. - iptables on the router seems to have absolutely no control over both incoming and outgoing messages through bcrelay.
This is something I definitely wanted to avoid.
If you sometimes connect your devices (in tun mode) to your router via OpenVPN server (running on the router), bcrelay will not work - OpenVPN will not relay broadcast messages given to it by bcrelay. I had this constraint of using tun and not tap.
So, in all, bcrelay is a quick and dirty workaround.
2. samplicator. This is an interesting tool that can receive UDP datagrams on a given port and send them to a set of receivers. One of the good things about this is that it has a lenient config file that allows multiple destinations for multiple sources.
And another awesome feature is that it can spoof IP addresses - i.e. the new destination devices (on the host network) will still the IPs of the original web-things!
I didn't try compiling it for dd-wrt because I anyway have a spare Linux machine that is always on.
So, I took the code from github - https://github.com/sleinen/samplicator, compiled it on the Linux machine and, since all my web-things are using only couple of ports to send broadcasts, I ran two samplicate daemons each listening on a specific port, in order to send those packets to only certain devices of my choice.
So, now I'm converting broadcasts-to-unicasts!
This means that OpenVPN is happy now, and on the other hand I'm not pushing too much traffic into my host network (broadcasts are costly - all clients have to read them).
Along with this, I had to open channels between the web-things and devices accordingly using iptables (i.e. through the host-guest and VPN/guest firewalls).
Lastly, after testing, I stopped internet access for those web-things.
samplicator is doing almost exactly what I wanted, and it might be very well possible to have it running on the router-itself, maybe someday I'll give it a try.