[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Mixing and Matching DHCP and static IPs

Greetings and Merry Christmas / Happy Hannukah / insert appropriate 
greeting here

There's no way to describe this with all the relevant info in a short 
way, so I'll try instead to make this as entertaining a read as I can.

For the first time ever I have tried to introduce a machine with a 
static IP to my network and it has exposed what I have a horrible 
feeling is going to turn out to be an embarrassing gap in my knowledge. 
Some machines in my network can communicate with the new machine, and 
some can't. I have an "inner network" and an "outer network" and the 
inner can't see the new machine while the outer can. Details below.

I run a home network with what might be slightly unusual topology. At 
the centre of it is a Buffalo Airstation which services a bunch of 
iDevices, a couple of Androids, a Windoze laptop, and a mini ITX machine 
running Stretch, and its wired ethernet ports also service a NAS and my 
main Debian Stretch desktop. Until very recently I ran a cable from the 
AirStation's WAN port to another mini ITX PC, this one running LFS, 
which acts as my firewall (I don't trust the firewall in the 
AirStation). The firewall runs a DHCP server to supply the AirStation 
with an IP address. The AirStation runs its own DHCP server on its LAN 
side, giving out IP addresses in the range, which is how 
all my machines except the firewall get their IP addresses. The firewall 
gets its external-facing interface IP via DHCP from my ISP and is static 
IP on its internal-facing side.

Recently I threw together LFS on a Raspberry PI and decided to use it as 
a caching DNS server. My plan is to run dnscache on it. The list may 
remember a thread I started a few months ago about the best way to solve 
DNS worries I had back then; I got some good advice at that time and 
this is me implementing said advice -- at long last I have some time off 
work and time to work on this.

If the PI is going to be useful as a caching DNS server for my network, it 
needs to not be in danger of having its IP address changed -- especially 
since it is going to need to be sitting outside the AirStation's LAN 
(since the AirStation insists it is the DNS server for its LAN, but 
actually merely forwards on all DNS queries to whatever DNS server it 
has been given in its WAN setup).

So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit 
Switch to be precise -- and have configured the PI to have a static IP 
on the same subnet as the firewall and the IP address given to the 
AirStation by the firewall. To be concrete, the internal-facing firewall 
interface is (static, works), the DHCP server I set up on 
the firewall gives out to the AirStation (works), and I have 
configured the PI to use (static, partly works). So inside 
AirStation LAN is, outside AirStation LAN is, .2 and .3 -- note the third octet difference for internal 
and external. All 3 of AirStation WAN port, PI and firewall 
internal-facing interface are plugged into the switch. I ran the switch 
for a couple of days with just the firewall and the AirStation plugged 
in (ie the switch was strictly unnecessary at that stage) and the 
network suffered no apparent ill effects. So the switch appears to be in 
good working order.

Once I introduce the PI, (by plugging it into the switch, in case that 
isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
the LAN of my AirStation. For example, from my main Stretch desktop, I 
cannot ping or SSH to the PI at I can both ping and SSH to 
the firewall at

If I SSH into the firewall, and then try to SSH from _there_ to, I can connect no problem. And I log in to the PI to find it 
bright eyed and bushy tailed, and able to connect to the internet (which 
it must do through the firewall just as all traffic from the AirStation 
does). But if I can't see it from the LAN, I can't use it for the 
purpose I spent the last week of my life building it for... :(

Now is the default gateway the firewall supplies the 
AirStation (ie it supplies itself as the gateway) when the AirStation 
makes a DHCP request, and I'm guessing that is why I can reach from inside the LAN (ie the LAN side of the AirStation). I 
am wondering if the AirStation somehow doesn't know that it can reach directly, which I would expect it to since it is plugged 
into the same switch as it and -- and if so, how I would 
persuade it to know that? I would also expect that if it did not know 
that, it would send packets for to for 
forwarding, just as it does every packet that is destined for the 
internet -- and I would expect the firewall to be able to forward them, 
since it can clearly see the PI.

Can anyone guess what might be wrong with the setup that is preventing 
me from being able to reach from inside the AirStation LAN? 
And how I could fix it? Google turned up the static-routes option of 
dhcpd, which it appears could be used to tell the AirStation about the 
route to, but A) I can't figure out how to use that to 
advise a route that doesn't require a gateway and B) the man page 
strongly discourages use of that feature (saying words to the effect of 
"no clients respect this feature, it's useless")...

Once I can get the LAN to see the PI, I plan to install dnscache on the 
PI and modify the DHCP server setup on the firewall to supply the PI as 
the DNS server to the AirStation.

Thanks in advance,


Reply to: