On Tue, Dec 26, 2017 at 01:05:03PM +0100, Pascal Hambourg wrote: > Le 26/12/2017 à 12:33, Dan Purgert a écrit : > > > > > 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? > > Being plugged to the same switch is not enough. The routing table must also > contain a direct route to the destination.
Thank you for confirmation of this. I suspected as much, but didn't have any facts, and if that is the case then this is almost certainly what is wrong, because I recognise I did nothing to tell the AirStation about this. Now I just need to figure out the best way to get that information into the AirStation's routing tables, preferably in a way that will survive reboots of the various machines involved -- perhaps the DHCP settings changes I've already been pointed at will have the effect of doing so. I've been battling a totally unrelated printing problem today but will advise as soon as I have tried 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. > > A firewall usually has filtering rules. Do these rules allow packets to be > forwarded from the LAN interface back to the same interface ? > Also, this would cause asymmetric routing (the server would send reply > packets directly to the client), which may not work well with stateful > filtering as the firewall would see only one direction of the communication. > Fair question re routing rules. I asked myself the same question last night before the original post, and checked (because my memory isn't what it once was). The firewall's routing rules are (amongst other rules which I don't believe relevant -- and external interface name elided): iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD ! -i <external interface> -m conntrack --ctstate NEW -j ACCEPT ...which I think should allow it to route from the inside interface to the inside interface. It only refuses if the incoming interface is the external interface (the internet-facing one). I didn't exactly do that deliberately but the effect is the one I need here, I believe. > > No, the airstation having been given an address 192.168.1.x/24 will know > > that it can directly reach any host 192.168.1.1 through 192.168.1.254 > > inclusive. > > Maybe I missed something but I read no evidence in the OP's posts that the > netmask on the Airstation WAN side is actually /24. If for instance the mask > was set to /30 instead, 192.168.1.3 would be considered by the Airstation as > a broadcast address and would explain why it does not work. > The netmask is 255.255.255.252. I just tried changing it to 248, ie zeroing out one more bit, but that did not help. (changed it by changing the netmask supplied by the firewall's DHCP server and then checking in the AirStation's web interface that the netmask had indeed changed). Mark
