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 | hfollm...@itcfollmann.com