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