0

I've got a similar issue to Allow two subnets to talk to each other over a wireless bridge

where my ISP's Modem/Router was the DHCP server and everything on my network was on the 192.168.1.x subnet, but I bought a second Netgear router to replace a Wifi repeater as I wanted a more reliable signal but also better parental controls.

Unfortunately to be able to use parental controls, the second router (connected to the ISP modem/router via Ethernet) forces me to configure it over a WAN connection to my modem/router and use a new 192.168.2.x subnet with it acting also as a DHCP server.

Now my devices connected to my modem/router on 192.168.1.x can't see everything else connected to the Netgear on 192.168.2.x.

What's the best way to resolve this? Configure both modem/router and Netgear router to use a subnet mask of 255.255.224.0? Or is there more to it than that? Sorry I'm at the limit of my networking knowledge!!

As per comment below, adding routing table screenshots... Routing Tables

Static route as defined in ISP router... static route

It's definitely a security issue - turned on logging for both dropped and accepted packages on the Netgear and can see the following as an example and 192.168.1.108 is the Squeezebox and 192.168.2.118 is the Squeezebox server - just can't understand why switching the firewall off doesn't resolve...

Apr 19 09:08:14 kernel: DROP IN=eth0 OUT=br0 SRC=192.168.1.108 DST=192.168.2.118 LEN=44 TOS=0x00 PREC=0x00 TTL=62 ID=2339 PROTO=TCP SPT=40533 DPT=3483 SEQ=2752079445 ACK=0 WINDOW=3000 RES=0x00 SYN URGP=0 OPT (020405B4)

Well I've tried everything I can think of - disable firewall, white listing the IP and still no luck...I also noticed the SPT (assume that's source port) changes in the log, so I added a whitelist range of 20000:50000 in the white list, but still packets are dropped??

0

The subnet mask informs devices about whether direct communication is possible ("direct" here means "at Ethernet/MAC layer"). However, it doesn't physically make those communications possible – and in your case, they are not, because there is a router in the middle.

Generally, the subnet mask trick would only work if you switched the Netgear into "bridge" mode and put all devices on a single network with no isolation between them – which indeed is the usual suggestion when people just want a second Wi-Fi access point and have no actual need for the routing functionality.

But as you've stated, you specifically want a router in order to keep the two subnets separate. So using a broader subnet mask is generally the wrong choice because it's the opposite of what you want, and it won't work anyway with a router in the middle.

Method 1

There's an exception to the above: you can use a broader subnet mask if the middle router supports the "Proxy ARP" feature. Enabling this makes the router respond to direct ARP queries on behalf of devices on the "other side", essentially tricking devices into thinking that they're sending packets directly to the other device, while in reality they're talking to a router.

So if the Netgear supports "Proxy-ARP", enable it only on the WAN interface (facing the ISP-router), and then you can configure devices on 192.168.1.x to use a broader subnet mask such as /22 (255.255.252.0) or indeed even /19 (255.255.224.0), although the latter is unnecessarily broad.

Note that the 192.168.2.x side is not changed, as it can already successfully send packets to the ISP-router's subnet due to the Netgear being directly connected to both subnets.

Method 2 and 2½

Routers can already forward traffic between different subnets without any of this proxy-ARP trickery; indeed that's what routers do. Usually the main configuration that is necessary is to tell each side about which router to use for reaching which subnet.

So what you should do is configure a "static route" towards 192.168.2.0 on your ISP-issued router. In the route settings page, fill in the Netgear 'WAN' (192.168.1.x) address as the "gateway" to use.

If the ISP-router makes this impossible, you can also configure the same route on each 192.168.1.x computer individually; that's the second option. (Windows/Linux/macOS support route configuration via ip route or route commands, but other devices usually don't.)

The reverse route does not need to be added manually – the Netgear already has an automatic route to 192.168.1.0 because it is directly attached to that subnet, after all.


There's a slight downside to the second method above (i.e. configuring a route on the ISP-router) – it means all packets from 192.168.1.x to 192.168.2.x first go towards the ISP-router and are bounced back towards the Netgear. It isn't the most efficient data path, but it'll do.

The other two methods do not have this problem. On the other hand, configuring routes on individual computers can be a lot of manual work, meanwhile proxy-ARP is usually not available on low-end routers. (Also, proxy-ARP is the duct tape of networking and I shouldn't have listed it as the first option or possibly even at all, but it'll do.)

  • Many thanks Grawity - will try those methods and update how I get on :) – Colin M Apr 17 at 12:56
  • Hi Grawity, I tried method 2 as no Proxy-ARP was on the Netgear, but still not having any luck and wonder if you can help troubleshoot further please? I've configured the routing on the ISP router (Zyxel VMG8924-B10A) with a destination IP of 192.168.2.0, Subnet 255.255.255.0, Use Gateway IP set to yes, Gateway IP address 192.168.1.121 (address of the Netgear router) and interface Default/br0. The Netgear is connected to the WAN port on the Zyxel, but I've set that to be a LAN port (it doesn't work at all if it's configured as a WAN port). Any ideas or things to check please? – Colin M Apr 18 at 20:22
  • The Netgear's firewall. I forgot to mention that, but as it thinks you're trying to access it "from the internet" (from WAN interface) it's probably set up to block incoming connections by default... – grawity Apr 18 at 20:48
  • Good thought but that hasn't helped - I disabled the firewall on the Netgear completely and no luck. I think it's incredibly close to working but something still not quite right - for example my Squeezebox connected to Zyxel on a wired connection will get an IP address of 192.168.1.x and finds the correct IP address of the Squeezbox server sitting on the 192.168.2.x subnet, but won't connect to it. – Colin M Apr 18 at 22:00
  • Could you append them to the main question post, formatted? – grawity Apr 19 at 6:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.