On Wed, Dec 27, 2017 at 06:13:41PM +0100, Pascal Hambourg wrote: > Le 27/12/2017 à 16:07, Mark Fletcher a écrit : > > > If you want to check this you can just try to accept any packets forwarded > from the internal interface to itself. > > iptables -A FORWARD -i enp0s20u3 -o enp0s20u3 -j ACCEPT >
Putting this near the beginning of my iptables script, and changing a later command that inserted a rule right at the top of the FORWARD list to always drop ctstate=INVALID packets, resulted in me being able to ssh from my Stretch box to the PI. That means that, if the goal were only to get a working setup, that has now been achieved. However, if you'll indulge me further, I'm now very curious about how I can get the AirStation to have a sensible routing table -- surely it must be possible. Beyond the man pages for DHCPD is there a good reference anyone can recommend for exactly what happens when a DHCP request is made? > > Yes, DHCP has two options : static-routes (classful) and > rfc3442-classless-static-routes (not defined natively in ISC dhcpd AFAIK, > managed by ISC dhclient with a custom script). However if the client does > not even handle the netmask correctly, I doubt that it accepts these > options. > By "not even handle the netmask correctly", do you mean "not even properly infer from a netmask of 255.255.255.0 and IP address of 192.168.1.2 that it should be able to talk directly to any computer in 192.168.1.0/24, and hence not try to send such connections via its default gateway"? I'm going to play with static-routes first -- first will have to read up on the difference between a classful and a classless route... In the meantime I built tcpdump on both the PI and the firewall, fired it up on both and attempted to ssh to the PI from the Stretch desktop machine. This was before modifying the firewall rules. I added a -w option to the tcpdump command suggested by Pascal because my connectivity to both the firewall and the PI is itself by SSH as I don't have enough keyboards and displays to let them all have a console connected -- so if I let them get chatty to stdout the result is more packets to report on... it quickly got out of hand the first time I tried it and at best there would be a lot of noise. So I had it dump the captured packets to files, with minimal screen activity while it did so, and looked at the dumped files after the fact using tcpdump -r <file> | less. I managed to keep the time of the dump fairly short and so there were something like 12 packets in the PI log and 30-odd in the firewall log. I noticed the connection attempt to the PI arriving first at the firewall, then the firewall sending the AirStation an ICMP redirect. Around that time there is a packet that says it came from the AirStation in the PI log, and a response directly from the PI to the AirStation -- which as I'd expect isn't reflected in the firewall log -- so indeed, that initial outreach attempt gets forwarded by the firewall. (I _can_ post the logs, but did not do so so as not to spam the list) The PI's attempt to reply to the AirStation is repeated 3 times over a roughly 3-4 second period, with no sign of anything coming in from the AirStation during that time (in the PI log). Interleaved with that there are attempts from the AirStation to give packets to the firewall for forwarding to the PI, which are NOT matched by packets in the PI log. So it's just like you surmised, Pascal -- the firewall is being involved in the communication at first by the AirStation, it forwards the first packet but doesn't forward subsequent packets because it's expecting to see the PI's reply and never does, at which point my iptables rules as they stood were stepping in and blocking packets. If I change the iptables rules everything starts to behave. So the remainder of the issue becomes, how does one persuade a Buffalo AirStation to properly set its routing table on its WAN side after receiving an IP Address by DHCP? I'll read up about the static-routes next -- got nothing to lose by trying it. Mark