Re: Mixing and Matching DHCP and static IPs
On Tue, Dec 26, 2017 at 03:43:50PM +0100, Pascal Hambourg wrote:
> > >
>
>
> > 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 should work with ICMP echo (ping) and UDP (used for DNS). But IIRC it
> would not work with TCP (used by SSH) because the firewall does not see the
> reply packets (including the SYN/ACK in the 3-way handshake) sent by the
> server directly to the client, so the subsequent packets from the client
> would be flagged in the INVALID state and not accepted by these rules.
Oh-ho. Well that is probably at play here then. I am getting excited, it
feels like we may be closing in on the problem.
> > >
> > 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).
>
> Netmask 255.255.255.252 with network 192.168.1.0 (or 192.168.1.0/30) implies
> that 192.168.1.3 is a broadcast address and cannot be used as a unicast host
> address. Even though the Airstation accepted to forward packets sent to this
> address, the packets would be sent on the WAN link to the broadcast ethernet
> address (ff:ff:ff:ff:ff:ff) and discarded by the server for this reason (a
> packet must not have a unicast IP address and a broadcast ethernet address).
>
> With netmask 255.255.255.248 (192.168.1.0/29), the broadcast address is
> 192.168.1.7 and 192.168.1.3 is considered as a unicast host address so the
> above issue should disappear.
>
Unfortunately when I changed it to 248, and made sure the AirStation had
updated, that made no difference.
At the risk of further advertising my ignorance, 3 as an 8-bit binary is
00000011, and 252 in binary is 11111100, so why doesn't that mask "fit"
with that address? (if you'll pardon my poor terminology) Put another
way, why do I need to zero out another bit of the mask to make .3 a
unicast address?
> But why do you bother with such narrow subnets and just don't use
> 255.255.255.0 (/24) ? It has been reported that some devices and OSes don't
> behave well with "unusual" netmasks (having values other than 255 and 0).
>
Totally fair question. No good reason these days. I am happy to change
it. In the early days of this setup (when I first built my firewall, so
something like a year ago at least) I did this because I wanted to see
if I had properly understood how a netmask worked. The goal at that time
was 50% learn, 50% get a working setup. I was thinking, if I set it the
way I had, and it worked the way I thought it did, it should work. It
worked, and I concluded I understood it. I see now the flaw in that
logic.
> Also, I recommend that you run a packet capture on the firewall and the
> server to see what's going on when you try to communicate to the server from
> the internal network.
>
> tcpdump -nei <interface>
>
Yes, this is going to be my next port of call (after I've opened up the
netmask to 255.255.255.0). Since both the PI and the firewall are LFS I
will probably have to build the tcpdump program for them both as there
is nothing installed on either of them that isn't strictly needed. I'll
report back when I have done that, if I don't figure something else out
in the meantime.
Mark
Reply to: