Linking two interfaces on same subnet using dnsmasq

Question

I'm trying to configure my RPi to give me access to devices conencted either of eth0 or wlan1.

Desired function is this:

• User connects to RPi AP via wlan1 and is given an IP
• Separate device connects to RPi via eth0 and is given an IP
• User can access configuration interface of eth0 connected device via local IP address

So far I have managed to get my eth0 and wlan1 adapters configured to give IPs on two different subnets with the below dnsmasq and dhcpcd configurations;

# dnsmasq.conf
interface=wlan1
dhcp-range=wlan1,192.168.4.2,192.168.4.99,24h

interface=eth0
dhcp-range=eth0,192.168.5.1,192.168.5.99,24h

listen-address=::1,127.0.0.1,192.168.5.1,192.168.4.1

# dhcpcd.conf
#wlan1 IP configuration
interface wlan1
static ip_address=192.168.4.1/24
nohook wpa_supplicant

#eth0 configuration
interface eth0
static ip_address=192.168.5.1/24
nohook wpa_supplicant

However, I cannot access the eth0 connected device when I am connected via wifi, presumably because it is on a different subnet. I have attempted to configure dnsmasq to have eth0 and wlan1 on the same subnet, but seems eth0 is not assigned an IP when I try this:

# dnsmasq.conf
interface=wlan1
dhcp-range=wlan1,192.168.4.2,192.168.4.100,24h

interface=eth0
dhcp-range=eth0,192.168.4.102,192.168.4.200,24h

listen-address=::1,127.0.0.1,192.168.4.1,192.168.4.101

# dhcpcd.conf
#wlan1 IP configuration
interface wlan1
static ip_address=192.168.4.1/24
nohook wpa_supplicant

#eth0 configuration
interface eth0
static ip_address=192.168.4.101/24
nohook wpa_supplicant

How do I achieve what I want to do?

Answer 1

What you describe in "desired function" is a network bridge, except perhaps it is unidirectional in some sense, which is essentially a router: Instead of an uplink, you have another subnet on the eth interface. You could also consider it technically similar to an access point.

You should stay with the two subnets. Trying to shove them together is not a simpler solution.

You could use the linux virtual bridge, for this, but I think it is more commonplace to use IP forwarding and NAT. This is done with iptables; the standard series of commands would be something like:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan -j ACCEPT

The difference between this and a router or hotspot is that these would involve network address translation (NAT); you will see lots of examples of this using ip masquerade.

However, sans NAT this then requires that the connected parties have their own routing configured properly -- standard OS software will set up a route to the subnet of the interface they connect to a DHCP server through, but (unless you find a way to do this with dnsmasq, I don't know whether it is possible via the protocol¹) this tells the client system nothing about the other subnet.

Quick fix on a linux client would be to add a route (or make the one to the pi bigger as per the footnote here):

ip route add 192.168.4.0/24 dev wlan0

That's presuming wlan0 is what is connected to the Pi. If you can't configure the clients, you will have to use NAT or the wider CIDR.

In case it is confusing about the "wider CIDR" in relation to the "two subnets", my point is that from the perspective of the Pi's routing, there should be two distinct subnets, one on each interface. That's done with the dhcpcd.conf you have using 192.168.4.1/24 and 192.168.5.1/24. I presume you understand how CIDRs work (if not you need to), but these are both 256 addresses wide, with no overlap. Hence if you look at ip route you should see one for each.

But if possible (this depends on whether DCHP allows for this, which it would be a bit silly if it didn't -- you'll have to figure out how to configure dnsmasq to do it), what you want clients on both interfaces to believe in is:

192.168.0.0/16

This CIDR is twice as wide in terms of bits (32 - 16 = 16 vs. 32 - 24 = 8), and 256 times wider in terms of addresses (so, 65536). It includes both 192.168.4.0/24 and 192.168.5.0/24.

This way, the clients will configure their own routing to use the link to the for that entire wider range. Eg., 192.168.4.10 will send packets to the Pi for 192.168.5.42, and because of the forwarding rules, those will passed straight through as is to the other interface.²

The potential problem with this is clients might not be able to correctly connect with others on their own subnet. If that matters, some more complex iptables rules will be needed.

---

1. What would make it apply is if the CIDR used by the DHCP server were sufficient to include both subnets, eg. 192.168.0.0/16.

2. You don't have to use /16; 15 bits will cover up to 192.168.7.255 so you could use /27.