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

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, 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,
> 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.


Henning Follmann           | hfollmann@itcfollmann.com

Reply to: