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
