Re: Mixing and Matching DHCP and static IPs
On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:
> 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
>
1) You talk too much.
Solution: be precise but not chatty. Get to the point.
2) Your network setup is overly complicated.
Solution: simplify! Also very important: complexity is the enemy of security.
Your set up should be straight forward that any issue becomes apparent
without any effort.
Forget about your caching dns server ( at least for now) It is just another
layer of complexity in your preexisting mess.
-H
--
Henning Follmann | hfollmann@itcfollmann.com
Reply to: