General Computing
networking ip lan subnet
Updated Sat, 27 Aug 2022 22:22:55 GMT

How to give device on modem’s subnet a second IP on the routers subnet?

Im new to network stuff so please excuse me if I miss something obvious

I have a modem with the subnet/DCHP 192.168.1.x and a device on it with the local IP This device acts as a server and broadcasts services like MiniDLNA. The problem is that these services cant be directly added, they have to be found on the local area network. All of my devices are connected to my Wi-Fi router which has a different subnet of 10.0.0.x, so it seems that devices looking for the MiniDLNA server will only look in the 10.0.0.x range.

My current planned solution is to somehow forward an unassigned IP on the 10.0.0.x range straight to the server. I did some googling and tried to assign a static route on my router both ways but neither worked properly. How can I achieve this result?

My router is a Netgear R7000 and my modem is a AT&T Pace 5268AC. Id prefer to not have to install custom firmware if possible.

Im also open to any other solutions as long as they have the desired effect of making the server discoverable. There are other services that behave the same way, so MiniDLNA config isnt a perfect solution, but would be appreciated. Connecting the server straight to the router currently isnt possible.

(Duplicated question from network engineering exchange because home networks arent allowed there)


Although it is possible to route individual IP addresses like that (kind of), it won't really help here.

(It would only help if the discovery process worked by individually probing every IP address in the subnet but that's not how service discovery generally works.)

Your media server uses SSDP broadcast packets for discovery, both from the device searching, and from the device advertising itself. For broadcast packets, it's not the addresses that matter, it's the concept of "broadcast domain" it roughly corresponds to the boundaries of the subnet but always stops at the first router.

Even if you configure the router to route some subnet addresses elsewhere, that doesn't extend the reach of broadcast packets because they'd still have to cross a router and routers normally don't forward such packets.

(Well, that's not entirely true technically those are multicast packets, which could be routed in theory but most home routers can't do that, and the packets often have TTL=1 so the same restriction applies anyway. For many multicast-based discovery protocols like SSDP or mDNS or LLMNR it's fine to think of them as using local broadcast.)

So your options are:

  • a) Reconfigure the Netgear to only act as a bridge (access point mode), leaving the AT&T modem as your only router and as your only subnet.

  • b) Directly connect the media server to both networks (if it has two Ethernet interfaces)... or just move it to the network it needs to be in.

  • c) If the media server physically can't be connected to the Netgear, use a pair of 802.1Q VLAN capable switches to actually extend the subnet to where the server is, over the same physical cable as the Netgear is using for the WAN uplink. Switches (bridges) do extend the broadcast domain.

  • d) Find some software that could relay SSDP advertisements (or multicast packets) across subnets. If this were mDNS, I'd try the relay capabilities in Linux's avahi-daemon mDNS service; for SSDP I'd probably look for some generic UDP broadcast/multicast relay tool.

Comments (2)

  • +0 – I'm going to try changing the router to bridge mode. I'm assuming this will cause problems because of DCHP/changing of IPs. is there any way I can minimize the time without internet without manually refreshing the DCHP on every device? Also worth mentioning is that I'm gonna change the modem to probably — Jun 20, 2022 at 01:37  
  • +0 – Reduce the DHCP lease time issued by Netgear as part of your preparation. Once all devices have e.g. a 5-minute lease from Netgear, they will take only 2-3 minutes to get a new lease from the modem afterwards. — Jun 20, 2022 at 06:15  

External Links

External links referenced by this document: