Re: Mixing and Matching DHCP and static IPs
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
Reply to: