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 192.168.11.0/24, 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 192.168.1.1 (static, works), the DHCP server I set up on
the firewall gives out 192.168.1.2 to the AirStation (works), and I have
configured the PI to use 192.168.1.3 (static, partly works). So inside
AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
192.168.1.1, .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 192.168.1.3. I can both ping and SSH to
the firewall at 192.168.1.1.
If I SSH into the firewall, and then try to SSH from _there_ to
192.168.1.3, 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 192.168.1.1 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
192.168.1.1 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
192.168.1.3 directly, which I would expect it to since it is plugged
into the same switch as it and 192.168.1.1 -- 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 192.168.1.3 to 192.168.1.1 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 192.168.1.3 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 192.168.1.3, 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,
Mark
Reply to: