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