SOHO network with DHCP and static routing?

May 15, 2008 8:09 PM

In a home network, I'm using static routing on a router connected to my ISP connection, and added an additional router using DHCP. From the DHCP side, I'm able to connect to the internet, but am unable to reach any of the static addresses, nor can any of the static IPs reach through to the DHCP side. (How) can this be made to work?

This is similar, but not identical to an earlier question. My difference is that I only have one public IP. Here's a quick outline:

cable modem (DHCP) --> Linksys (static routing; 192.168.100.1) --> Belkin (DHCP, 192.168.101.1)

I'm running a couple of internet-accessible services (web, svn, ftp) on a PC, hence the static routing. A file server is also located on the static side. PCs connected to the DHCP router are able to connect to the internet through the gateway at 192.168.1.1, but aren't able to see any other addresses on that subnet, so I can't reach my subversion server, file shares, make VNC connections, etc.

I should probably be able to figure this out myself, but networking gives me a headache and I haven't been able to put the right search terms together. Thanks for any help.

posted by Ickster to computers & internet (8 comments total)

You're double-NATting and you really, really don't want to do that unless you're the kind of person who doesn't get headaches from networking. I'm guessing your Linksys device doesn't have a DHCP server enabled on it? If that's the case:

Take your Belkin device, turn off all the routing features, give it a DHCP address range in the 100 network, unplug the "WAN" port completely. Connect the Linksys to the Belkin's "LAN" port instead.

If you have a DHCP server enabled on the Linksys, add one more step:
Disable DHCP on the Belkin.
posted by majick at 8:45 PM on May 15

You shouldn't need a router just so you can have some static IPs. Double NAT is bad. (It can thwart applications which try to punch through the NAT, like games.)

I have DHCP enabled on my router, but sometimes use static IPs. Never had a problem yet, maybe its just luck.

Some routers (e.g., Linksys I think, but don't hold me to it) let you explicitly specify a Dynamic and Static range. (I.e., 192.168.0.1 - 192.168.0.100 are dynamic, while .101 and up are static.)

Don't know why stuff behind the belkin can't get to linksys stuff (Assuming your netmask is 255.255.255.0) But you should definitely _not_ be able to get behind the belkin from the linksys, unless you've set up manual port forwarding or DMZ on the Belkin.
posted by blenderfish at 11:13 PM on May 15

it sounds like you mean "static IP addresses" rather than "static routing" - these terms are not interchangeable... also, the network description you've provided don't seem to make sense... it looks to me like this is the setup

internet --- (?.?.?.?) cable modem (?.?.?.?) --- (?.?.?.?) Linksys (192.168.100.1) --- (192.168.100.?) Belkin (192.168.101.1) --- (192.168.101.?) PC

which doesn't include the 192.168.1.1 you're using as the gateway address for devices behind the Belkin... hmmm, and depending on the setup of your cable modem you're potentially *triple* NAting traffic from the PC...

is there any specific reason for having distinct networks for static and DHCP supplied addresses? if you enable DHCP service on the Linksys, it should only be serving addresses in part of the 192.168.100.x block, say 192.168.100.100 up to 192.168.100.254, which menas that you can put the services that require a static IP into the bottom part of that range (192.168.100.10 or whatever) in order to have a nice flat network where everything can see everything else, and you can still forward inbound connections to a known address for your public svn/ftp/whatever...
posted by russm at 11:13 PM on May 15

Like everybody says, you don't need two routers for this setup.

In the (extremely unlikely) case you can't configure one of the two you already have to only serve dynamic addresses in part of the subnet, you can run a simple dhcp server (google dnsmasq) on one of your other machines.
posted by ghost of a past number at 12:54 AM on May 16

Thanks for the answers everyone; I'll be trying to sort this out later this evening.

One thing that's confusing to me is that I was assuming (I know, I know) that static IPs and DHCP would need to exist on different subnets, because a device handing out DHCP leases wouldn't have any knowledge of devices configured with static addresses, leading to potential conflicts. Is the addressing system more robust than I'd assumed, or am I still not getting it?

(russm; that gateway address was a typo. It's 192.168.100.1.)
posted by Ickster at 6:40 AM on May 16

My Linksys router doesn't care that some connected devices (laptops) are DHCP, while others (home computer, network printer) are assigned static. If the device requests a specific IP, the router allows it; if the device requests an IP via DHCP, the router gives it one. I've done this on several different brands of router and never really had a problem with it. Just make sure that the DHCP server is set to assign addresses on the same network and subnet as any static ones. For example if DHCP assigns 192.168.0.101-255, use a static in the range of 192.168.0.2-99, making sure the subnet mask for both are the same (typically 255.255.255.0). IP 192.168.0.1 is reserved, so don't use it.

Easiest thing to do is to set everything up with DHCP, then on any system you want to remain static, take the current DHCP settings and enter them back in manually, specifying an IP address. Refresh networking and you ought to be set. Turn the second router into a hub if you need more ports, by turning off DHCP on that router.
posted by caution live frogs at 6:54 AM on May 16

Doh. While biking in to work after my last comment, I must've bumped my head or something, because it finally came clear to me. I had a bad preconception in my head (see my previous comment) and it just came loose allowing me to understand the answers everyone has given me.

Thanks!
posted by Ickster at 7:48 AM on May 16

One thing that's confusing to me is that I was assuming (I know, I know) that static IPs and DHCP would need to exist on different subnets, because a device handing out DHCP leases wouldn't have any knowledge of devices configured with static addresses, leading to potential conflicts. Is the addressing system more robust than I'd assumed, or am I still not getting it?

The mechanism by which IPs are assigned (DHCP or by you punching them in manually) is distinct from the mechanism by which IPs are _used_ (ARP). Basically, all DHCP is required to do is to pick an address that it reckons isn't in use, mark it in use locally for some length of time (the lease time) and send the address and that lease time to the client. But it _doesn't_ affect the actual operation of the router. It's non-binding. This is why a DHCP server can be run on any machine in the network, without having special configuration on the router; it's just an information service.

The _actual_ IP 'assignment' is done by ARP. The meat of what ARP does is let a machine, when it knows there is a local (i.e., in its subnet) IP it wants to talk to, find the ethernet address for that IP. The ethernet address is globally unique, and is what the actual networking hardware understands. It does this discovery, in pretty much the simplest way imaginable, by broadcasting "Hey? Who is 192.168.1.69?" to all the clients on the subnet. The client who believes he _is_ 192.168.1.69 (either due to getting that address from DHCP or due to you assigning a static address) responds with a "Hey, it's me." That reply packet comes back from the ethernet address of the affirmative party, which the originating party can then make a note of, and use when it wants to talk to that IP.

The actual ethernet routing is achieved because a switch remembers all ethernet addresses which are attached to each port. (a 'hub' has no memory--it just broadcasts all packets to everyone.) So, when I want to talk to a machine at an IP in my subnet, I ARP, so I now have the machine's ethernet address. Then I send a packet to that address. When the packet gets to the switch, it looks up which port that ethernet address was last seen on, and sends it along.

If a request is for an address outside your subnet, your machine knows it needs to send it to the machine with the 'gateway' IP, which in turn sends it to the outside world.

Anyway, hope this clarifies more than it confuses.
posted by blenderfish at 11:46 AM on May 16