Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #190258 > unrolled thread

Mixing and Matching DHCP and static IPs

Back to article view | Back to linux.debian.user

Contents

  Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-25 16:30 +0100
    Re: Mixing and Matching DHCP and static IPs Henning Follmann <hfollmann@itcfollmann.com> - 2017-12-25 17:00 +0100
      Re: Mixing and Matching DHCP and static IPs deloptes <deloptes@gmail.com> - 2017-12-25 18:10 +0100
        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 01:50 +0100
        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 02:00 +0100
          Re: Mixing and Matching DHCP and static IPs Gene Heskett <gheskett@shentel.net> - 2017-12-26 02:50 +0100
          Re: Mixing and Matching DHCP and static IPs deloptes <deloptes@gmail.com> - 2017-12-26 12:20 +0100
            Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 12:50 +0100
              Re: Mixing and Matching DHCP and static IPs deloptes <deloptes@gmail.com> - 2017-12-26 15:30 +0100
    Re: Mixing and Matching DHCP and static IPs Nemeth Gyorgy <friczy@freemail.hu> - 2017-12-25 18:30 +0100
    Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 02:40 +0100
    Re: Mixing and Matching DHCP and static IPs Dan Purgert <dan@djph.net> - 2017-12-26 12:50 +0100
      Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 13:10 +0100
        Re: Mixing and Matching DHCP and static IPs Dan Purgert <dan@djph.net> - 2017-12-26 15:50 +0100
          Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 16:30 +0100
      Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 13:10 +0100
        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 15:00 +0100
          Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 15:50 +0100
            Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 16:10 +0100
              Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 16:40 +0100
                Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-27 16:10 +0100
                  Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-27 18:20 +0100
                    Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-28 13:10 +0100
                      Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-28 15:40 +0100
                        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-28 17:00 +0100
          Re: Mixing and Matching DHCP and static IPs Dan Purgert <dan@djph.net> - 2017-12-26 16:20 +0100
            Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 16:30 +0100
        Re: Mixing and Matching DHCP and static IPs Dan Purgert <dan@djph.net> - 2017-12-26 16:10 +0100
          Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-26 16:20 +0100
          Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 16:50 +0100
    Re: Mixing and Matching DHCP and static IPs Michael Stone <mstone@debian.org> - 2017-12-26 17:00 +0100
      Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 17:10 +0100
        Re: Mixing and Matching DHCP and static IPs Michael Stone <mstone@debian.org> - 2017-12-26 17:30 +0100
          Re: Mixing and Matching DHCP and static IPs Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-26 17:30 +0100
        Re: Mixing and Matching DHCP and static IPs Mark Fletcher <mark27q1@gmail.com> - 2017-12-27 13:00 +0100

Page 2 of 2 — ← Prev page 1 [2]

#190342

On Tue, Dec 26, 2017 at 04:33:57PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 16:05, Mark Fletcher a écrit :
> > 
> > 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?
> 
> The IPv4 protocol specification gives a special meaning to the first and
> last addresses in a subnet. The first address is the "network address" and
> the last address is the "broadcast address". Both are reserved and cannot be
> used as unicast host address.
> 

I never acknowledged this part -- thanks for this explanation, which I 
did not previously know. Totally explains why 192.168.1.3 was not 
working -- or one reason why, anyway.

In another update -- a couple of developments in the last couple of 
hours. First of all Google dug up an English-language manual for my 
AirStation -- or at least a model close enough to the one I have to be 
useful. Using that I was able to discover a ping tool in the web 
interface which I didn't know was there, which lets me ping test from 
the Airstation to any address.

The second development was that sometime after changing the IP address 
being given to the PI by the DHCP server on the firewall to an address 
outside the DHCP allocation range, I accidentally turned off the 
firewall machine (or at lesat put it to sleep) while physically moving 
it to make room for the PI beside it. After bringing it back up and 
leaving my network alone for a bit, I then used the above ping test 
feature on the AirStation and -- could ping to 192.168.1.6! A check from 
my Stretch desktop inside the AirStation LAN showed that can also now 
ping to the PI. This represents major progress.

However, I still cannot ssh from the Stretch desktop to the PI (although 
I still CAN ssh from the firewall to the PI, and I can still ssh from 
the Stretch desktop to the firewall).

My network had an otherwise quiet moment a few minutes ago, and I was 
able to try the ping test and note that, when pinging 192.168.1.1 the 
light on the ethernet port on the PI does not flash, as I would expect, 
but when pinging to 192.168.1.6 the ethernet ports on both the PI and 
the firewall flash. I take this as evidence that what Pascal said might 
be happening, is happening -- the AirStation for some reason still 
doesn't know it can reach 192.168.1.6 directly and so is sending packets 
to 192.168.1.1 for forwarding to 192.168.1.6 -- and the firewall machine 
is obliging, but that is only working properly for ping packets and not 
for TCP protocols like SSH.

I'm building tcpdump on both the firewall and the PI... If this turns 
out to be right I will need to figure out how to manipulate the routing 
table of the AirStation. Is it possible for the DHCP server to 
communicate static routings to clients? I read that it is but also read 
that almost no clients accept that so it is basically useless... True?

Mark

[toc] | [prev] | [next] | [standalone]

#190349

Le 27/12/2017 à 16:07, Mark Fletcher a écrit :
> 
> my Stretch desktop inside the AirStation LAN showed that can also now
> ping to the PI. This represents major progress.
> 
> However, I still cannot ssh from the Stretch desktop to the PI (although
> I still CAN ssh from the firewall to the PI, and I can still ssh from
> the Stretch desktop to the firewall).
> 
> My network had an otherwise quiet moment a few minutes ago, and I was
> able to try the ping test and note that, when pinging 192.168.1.1 the
> light on the ethernet port on the PI does not flash, as I would expect,
> but when pinging to 192.168.1.6 the ethernet ports on both the PI and
> the firewall flash. I take this as evidence that what Pascal said might
> be happening, is happening -- the AirStation for some reason still
> doesn't know it can reach 192.168.1.6 directly and so is sending packets
> to 192.168.1.1 for forwarding to 192.168.1.6 -- and the firewall machine
> is obliging, but that is only working properly for ping packets and not
> for TCP protocols like SSH.

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

> I'm building tcpdump on both the firewall and the PI... If this turns
> out to be right I will need to figure out how to manipulate the routing
> table of the AirStation. Is it possible for the DHCP server to
> communicate static routings to clients?

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.

[toc] | [prev] | [next] | [standalone]

#190385

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

[toc] | [prev] | [next] | [standalone]

#190392

Le 28/12/2017 à 13:01, Mark Fletcher a écrit :
> 
> 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?

The authoritative sources are the RFCs. Not the easiest to read though.
However they will only describe what happens on the wire :
client sends DISCOVER.
server sends OFFER.
client sends REQUEST.
server sends ACK.

Client messages contain options that the clients requests. Server 
messages contain option values. Now what is done with the option values 
is up to the client.

> 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"?

Yes.

> 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...

Classful addressing assumes that the netmask is implicity tied to the 
address. E.g. with private ranges :
10.0.0.0 => class A => netmask 255.0.0.0
172.17.0.0 => class B => netmask 255.255.0.0
192.168.1.0 => class C => netmask 255.255.255.0

Classless addressing does not assume any implicit relation between the 
address and the netmask, so the netmask must always be explicit.

Since 192.168.1.0 is class C, the classful netmask matches the actual 
netmask, so it's fine to use static-routes for this subnet.

> I noticed the connection attempt to the PI arriving first at the
> firewall, then the firewall sending the AirStation an ICMP redirect.

As expected. But the Airstation behaves as a router, and IIRC a router 
may ignore ICMP redirect. Even though, an ICMP redirect can be accepted 
only when the suggested address is directly reachable. At the moment, 
this is not the case otherwise the Airstation would not have sent the 
original packet to the firewall.

> 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.

I do not remember if it has been mentioned, but doesn't the Airstation 
support static IP configuration on its WAN interface ?

[toc] | [prev] | [next] | [standalone]

#190406

On Thu, Dec 28, 2017 at 03:31:11PM +0100, Pascal Hambourg wrote:
> Le 28/12/2017 à 13:01, Mark Fletcher a écrit :
> > 
> > Beyond the man pages for DHCPD is
> > there a good reference anyone can recommend for exactly what happens
> > when a DHCP request is made?
> 
> The authoritative sources are the RFCs. Not the easiest to read though.
> However they will only describe what happens on the wire :
> client sends DISCOVER.
> server sends OFFER.
> client sends REQUEST.
> server sends ACK.
> 
> Client messages contain options that the clients requests. Server messages
> contain option values. Now what is done with the option values is up to the
> client.
> 
Thanks. 

> > 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...
> 
> Classful addressing assumes that the netmask is implicity tied to the
> address. E.g. with private ranges :
> 10.0.0.0 => class A => netmask 255.0.0.0
> 172.17.0.0 => class B => netmask 255.255.0.0
> 192.168.1.0 => class C => netmask 255.255.255.0
> 
> Classless addressing does not assume any implicit relation between the
> address and the netmask, so the netmask must always be explicit.
> 
> Since 192.168.1.0 is class C, the classful netmask matches the actual
> netmask, so it's fine to use static-routes for this subnet.
>

Thank you for this explanation.
 
> > I noticed the connection attempt to the PI arriving first at the
> > firewall, then the firewall sending the AirStation an ICMP redirect.
> 
> As expected. But the Airstation behaves as a router, and IIRC a router may
> ignore ICMP redirect. Even though, an ICMP redirect can be accepted only
> when the suggested address is directly reachable. At the moment, this is not
> the case otherwise the Airstation would not have sent the original packet to
> the firewall.
> 

Right, except that now...

> > 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.
> 
> I do not remember if it has been mentioned, but doesn't the Airstation
> support static IP configuration on its WAN interface ?
> 

Probably. You'd think so, wouldn't you? While poking around again in the 
(Japanese language) web interface attempting to answer this question, I 
stumbled across one button I had not attempted to press before. It was 
labelled in two kanji characters I couldn't translate and the 
English-language manual didn't mention it. When I asked my wife (who is 
Japanese) to translate it her translation was so generic I could make no 
sense of it (this often happens with technical things in Japanese -- 
very vague / generic translations are used. Ancient languages don't lend 
themselves well to technojargon. I can assume Mandarin has the same 
problem). So I thought screw it what's life about and pressed it. The 
AirStation's internet access instantly died a horrible death. 

Panicing only slightly, I pressed the button I had been pressing to 
force the AirStation to dump its configuration and re-approach the DHCP 
server (I'd been alternating this with restarts of the entire 
AirStation). After a suitably long pause, internet connectivity was 
back. And now the AirStation can route directly to the PI, and I can 
roll back my iptables changes on the firewall, and everything works the 
way it is supposed to.

So it turns out that button means "stop jerking Mark around and start 
co-operating", or probably more properly "forget everything you know 
about the world outside your WAN interface, including stuff you don't 
forget when you get shut down and restarted".

So I have finally arrived at the end of this journey with 2 successful 
outcomes -- things are working, and they are working for reasons I 
understand. Thank you Pascal in particular, but also deloptes, Dan P, 
Dan R, Marc, Sven and Paul for your contributions too. Much appreciated 
and I have learned a lot.

Mark

[toc] | [prev] | [next] | [standalone]

#190305

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Fletcher wrote:
> 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.


If the airstation is getting its IP address via DHCP, you don't have to
give it any further routing information for the 192.168.1.0 subnet.  It
was provided all of that information by the DHCP server itself.

The airstation's routing table will look something like this:

0.0.0.0/0 via 192.168.1.1, via eth0 ("WAN", whatever)
192.168.1/0 is directly connected, eth0 ("WAN", whatever)
 
>> 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).

This is the absolute most key piece of information that was required to
help troubleshoot your problem ... 

255.255.255.252 is /30, meaning you only had two usable addresses
(192.168.1.1, and 192.168.1.2 -- 192.168.1.3 was the broadcast.  Strange
that you could ssh from the firewall device to this IP address, but no
matter).  

Switch everything - airstation, upstream firewall, rpi, anything else to
/29 (255.255.255.248), and restart their relevant interfaces.  Don't
forget to update any iptables rules, etc. that may have triggered on the
netmask.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaQmR3AAoJEI4R3fMSeaKBBtEH/2leUCp7olulBfNWCFpdRxmB
vH7gwM3p79bPzrIc7lp4v18OHA3NYn2SNXEl6eSsj1pbbibDt+bkCzMiegDrtjg8
0NBrmr4PL/QbUBUzEkbbm6SeZazSRcu033uOHxLJu1JAUD/6C89c2DjhEzPMnvyP
FK6nTfTnfdLs65XTuH+O96R6WgIPRL8ijWTpl47LGPD7vrTwrb211GYCnfiqeKX+
lNarnIcKZFYdkMuP94I9lPVSe+7Tj6YIlRKmALfzaUTTpfLa7UyRO2j4cJ50caRS
UzBGsC+ITdiOVXw9U6vLm3r6DHQ8kGkBz9kGvyuD04T4vvJ6BHcHM4Gk3JnPkx4=
=WOxz
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#190307

On Tue, Dec 26, 2017 at 03:02:46PM -0000, Dan Purgert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> >> 
> > 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).
> 
> This is the absolute most key piece of information that was required to
> help troubleshoot your problem ... 
> 
> 255.255.255.252 is /30, meaning you only had two usable addresses
> (192.168.1.1, and 192.168.1.2 -- 192.168.1.3 was the broadcast.  Strange
> that you could ssh from the firewall device to this IP address, but no
> matter).  
> 
> Switch everything - airstation, upstream firewall, rpi, anything else to
> /29 (255.255.255.248), and restart their relevant interfaces.  Don't
> forget to update any iptables rules, etc. that may have triggered on the
> netmask.
> 
> 
OK -- although to Pascal's point, I think I'll go with 255.255.255.0 -- 
no reason not to. But nonetheless that is what I will do next. Will 
advise (tomorrow -- it's past my bedtime now).

Mark

[toc] | [prev] | [next] | [standalone]

#190304

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pascal Hambourg wrote:
> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
>> [...]
>> Sounds like perhaps the airstation is blocking client devices from
>> talking to "bogus" network addresses.  This is generally a feature of
>> consumer gear to stop you from trying to ask the internet for
>> information about a RFC1918 address (as they are private / not routable
>> on the internet).
>
> What do you mean by "ask the internet for information about a RFC1918 
> address" ? Sending an IP packet is not asking the internet for any 
> information.

No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
192.168.11.0/24), you "ask" your gateway for assistance in getting the
packet to its intended destination.

Now, since RFC1918 space is not routable on the internet, and consumer
gear is meant to be "easy", some assumptions are made - such that "no,
they'll never want to use this to talk to an upstream RFC1918 network,
so we can safely block it and keep them from asking ISP gateways for
networks that don't actually exist".

This doesn't cause any problems in the setup for "getting to the
internet" since the destination IP address is not RFC1918. 

> [...]
>> 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.

That could also be possible, but I made the assumption that it was the
"default(tm)" subnet from a generic residential gateway device.  Also,
since he can apparently ssh into the rpi from whatever the firewall
device is, it is not likely to be a broadcast address.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJaQmGlAAoJEI4R3fMSeaKBdlQH/jQBLzNvC2DQI7psM8c0Gz7T
uVpnxlkrpB5+A18iVwpevzlosswsE/5QwaBF5MTFWWBZ5l27f2q2qIs2r8qiwAZ6
poIT6cNa8FrP6Vk7N5K0E5/b3hYCtsv4f3YiReS6z5t7dWWJhsDRmXrb59InHS08
SJZDuV6/4d+8wUOzPpCLoLRVWDn3IhR9rljFcoVOLfHVs28PxdeHiH38YQw/D/b2
6yIy0OqRJZjP0QI+SV09liTJEKIoL9Lo57mmSmM7KnCciSRpgFZChb3wTQ1ajavq
ANQQ4bRFRNltHiUC69J4iuO2r3Ojw4azmOcRL6pNsOkEaQIeorm25e+xPtI/W/Q=
=fsYJ
-----END PGP SIGNATURE-----

-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

[toc] | [prev] | [next] | [standalone]

#190306

On Tue, Dec 26, 2017 at 02:50:44PM -0000, Dan Purgert wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Pascal Hambourg wrote:
> > Le 26/12/2017 à 12:33, Dan Purgert a écrit :
> >> [...]
> >> Sounds like perhaps the airstation is blocking client devices from
> >> talking to "bogus" network addresses.  This is generally a feature of
> >> consumer gear to stop you from trying to ask the internet for
> >> information about a RFC1918 address (as they are private / not routable
> >> on the internet).
> >
> > What do you mean by "ask the internet for information about a RFC1918 
> > address" ? Sending an IP packet is not asking the internet for any 
> > information.
> 
> No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
> 192.168.11.0/24), you "ask" your gateway for assistance in getting the
> packet to its intended destination.
> 
> Now, since RFC1918 space is not routable on the internet, and consumer
> gear is meant to be "easy", some assumptions are made - such that "no,
> they'll never want to use this to talk to an upstream RFC1918 network,
> so we can safely block it and keep them from asking ISP gateways for
> networks that don't actually exist".
> 
> This doesn't cause any problems in the setup for "getting to the
> internet" since the destination IP address is not RFC1918. 

This is a fascinating sub-thread of the discussion. What I think you are 
saying is that, as consumer gear, the AirStation is assuming that if it 
is asked to route to a "private" IP address, it essentially refuses, 
because that can't be right. I think the BUT here, though, is that I can 
ssh from a machine on the inner network (connected to a LAN port of the 
AirStation) to the firewall at the outermost edge of my network (that 
is, from 192.168.11.x to 192.168.1.1) and that works. From what you are 
saying, it shouldn't -- UNLESS, the AirStation makes an exception 
specifically for 192.168.1.1 because that is what it has been told its 
default gateway is.

Mark

[toc] | [prev] | [next] | [standalone]

#190311

Le 26/12/2017 à 15:50, Dan Purgert a écrit :
> 
> Pascal Hambourg wrote:
>> Le 26/12/2017 à 12:33, Dan Purgert a écrit :
>>> [...]
>>> Sounds like perhaps the airstation is blocking client devices from
>>> talking to "bogus" network addresses.  This is generally a feature of
>>> consumer gear to stop you from trying to ask the internet for
>>> information about a RFC1918 address (as they are private / not routable
>>> on the internet).
>>
>> What do you mean by "ask the internet for information about a RFC1918
>> address" ? Sending an IP packet is not asking the internet for any
>> information.
> 
> No, but if you don't know how to get somewhere (e.g. 192.168.1.0/24 from
> 192.168.11.0/24), you "ask" your gateway for assistance in getting the
> packet to its intended destination.

The host does not really "ask" anything to the router ("gateway" is 
deprecated). It justs sends the packet to it. Also, from its routing 
table it knows how to get to the destination : through the router. What 
happens beyond the router is irrelevant to the host as long as the 
packet is forwarded to the destination in the end.

E.g. the following routing table :
default via 192.168.0.1 dev eth0  proto static
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.238

does not mean "I don't know how to route anything else than 
192.168.0.0/24". It means "192.168.0.0/24 is directly reachable, and all 
the rest is reachable through the router at 192.168.0.1.

> Now, since RFC1918 space is not routable on the internet, and consumer
> gear is meant to be "easy", some assumptions are made - such that "no,
> they'll never want to use this to talk to an upstream RFC1918 network,
> so we can safely block it and keep them from asking ISP gateways for
> networks that don't actually exist".

This assumption seems wrong. ISP networks use RFC1918 addresses, and 
such devices may be used on private networks

>> 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.
> 
> That could also be possible, but I made the assumption that it was the
> "default(tm)" subnet from a generic residential gateway device.  Also,
> since he can apparently ssh into the rpi from whatever the firewall
> device is, it is not likely to be a broadcast address.

But the Air-station may be misled by a wrong DHCP netmask into believing 
that 192.168.1.3 is a broadcast address.

[toc] | [prev] | [next] | [standalone]

#190313

On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:
>I run a home network with what might be slightly unusual topology. At
>the centre of it is a Buffalo Airstation which services a bunch of
>iDevices, a couple of Androids, a Windoze laptop, 

It's bad enough having to read a really long post without having to also 
see juvenile things like "windoze" scattered throughout...

>and a mini ITX machine
>running Stretch, and its wired ethernet ports also service a NAS and my
>main Debian Stretch desktop. Until very recently I ran a cable from the
>AirStation's WAN port to another mini ITX PC, this one running LFS,
>which acts as my firewall (I don't trust the firewall in the
>AirStation). The firewall runs a DHCP server to supply the AirStation
>with an IP address. The AirStation runs its own DHCP server on its LAN
>side, giving out IP addresses in the range 192.168.11.0/24, which is how
>all my machines except the firewall get their IP addresses. The firewall
>gets its external-facing interface IP via DHCP from my ISP and is static
>IP on its internal-facing side.

This is unnecessarily complicated, and will make your life harder than 
it needs to be. The best thing would be to not use the airstation as a 
router at all, just use it as a switch + wireless access point in a flat 
configuration, with the router plugged into the switch. Ignore the "wan" 
port on the airstation and turn off any dhcp or other services that it 
is providing.

>Recently I threw together LFS on a Raspberry PI and decided to use it as
>a caching DNS server. My plan is to run dnscache on it. The list may
>remember a thread I started a few months ago about the best way to solve
>DNS worries I had back then; I got some good advice at that time and
>this is me implementing said advice -- at long last I have some time off
>work and time to work on this.

Honestly, this will probably end up being slower overall than not having 
a caching DNS server, because the PI is slow and you're adding latency 
to all requests without significantly speeding up cached requests.

>If the PI is going to be useful as a caching DNS server for my network, it
>needs to not be in danger of having its IP address changed -- especially
>since it is going to need to be sitting outside the AirStation's LAN
>(since the AirStation insists it is the DNS server for its LAN, but
>actually merely forwards on all DNS queries to whatever DNS server it
>has been given in its WAN setup).

A DNS server will always have a range of IPs that it is configured to 
use, if you assign an IP statically outside that range there is no 
danger of "having its IP changed". You don't need to put a device on a 
new subnet to achieve that goal.

>So I bought myself an ethernet switch -- a Netgear ProSAFE Gigabit
>Switch to be precise -- and have configured the PI to have a static IP
>on the same subnet as the firewall and the IP address given to the
>AirStation by the firewall. To be concrete, the internal-facing firewall
>interface is 192.168.1.1 (static, works), the DHCP server I set up on
>the firewall gives out 192.168.1.2 to the AirStation (works), and I have
>configured the PI to use 192.168.1.3 (static, partly works). So inside
>AirStation LAN is 192.168.11.0/24, outside AirStation LAN is
>192.168.1.1, .2 and .3 -- note the third octet difference for internal
>and external. All 3 of AirStation WAN port, PI and firewall
>internal-facing interface are plugged into the switch. I ran the switch
>for a couple of days with just the firewall and the AirStation plugged
>in (ie the switch was strictly unnecessary at that stage) and the
>network suffered no apparent ill effects. So the switch appears to be in
>good working order.

This will not work the way you think it will. Devices on the airstation 
will have packets go directly to 192.168.1.3 (because the airstation 
knows how to get to anything on 192.168.1.0/24) (you never actually 
specified the netmask for 192.168.1., hopefully that's correct). The 
packets returning from 192.168.1.3 will go to 192.168.1.1 because 
192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the 
default route instead. The firewall at 192.168.1.1 will drop those 
packets because they don't form a valid session. To make this work, 
192.168.1.3 (and any other device on 192.168.1.0/24) would need a static 
route to 192.168.11.0/24 via 192.168.1.2. This will be a pain to 
maintain, and offers no advantage over simply having a flat network and 
abandoning the routing functionality of the airstation.

Mike Stone

[toc] | [prev] | [next] | [standalone]

#190315

Le 26/12/2017 à 16:49, Michael Stone a écrit :
> 
> This is unnecessarily complicated, and will make your life harder than 
> it needs to be. The best thing would be to not use the airstation as a 
> router at all, just use it as a switch + wireless access point in a flat 
> configuration, with the router plugged into the switch. Ignore the "wan" 
> port on the airstation and turn off any dhcp or other services that it 
> is providing.

The most important part is "turn off any DHCP service it provides". 
Othewise it will get in the way of the other DHCP server.

> This will not work the way you think it will. Devices on the airstation 
> will have packets go directly to 192.168.1.3 (because the airstation 
> knows how to get to anything on 192.168.1.0/24) (you never actually 
> specified the netmask for 192.168.1., hopefully that's correct). The 
> packets returning from 192.168.1.3 will go to 192.168.1.1 because 
> 192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the 
> default route instead.

As any SOHO router, it is likely that the Airstation masquerades 
forwarded connections, so other nodes on its WAN side do no see the real 
192.168.11.x addresses but only the WAN side address of the Airstation, 
192.168.1.2.

I guess that even the firewall does not have a special route for 
192.168.11.0/24, as it is not supposed to see that address range.

[toc] | [prev] | [next] | [standalone]

#190317

On Tue, Dec 26, 2017 at 05:04:34PM +0100, Pascal Hambourg wrote:
>As any SOHO router, it is likely that the Airstation masquerades 
>forwarded connections, so other nodes on its WAN side do no see the 
>real 192.168.11.x addresses but only the WAN side address of the 
>Airstation, 192.168.1.2.

Yes, double NAT is another even worse option. :)

[toc] | [prev] | [next] | [standalone]

#190318

Le 26/12/2017 à 17:20, Michael Stone a écrit :
> On Tue, Dec 26, 2017 at 05:04:34PM +0100, Pascal Hambourg wrote:
>> As any SOHO router, it is likely that the Airstation masquerades 
>> forwarded connections, so other nodes on its WAN side do no see the 
>> real 192.168.11.x addresses but only the WAN side address of the 
>> Airstation, 192.168.1.2.
> 
> Yes, double NAT is another even worse option. :)

I prefer to refer to this as "cascaded NAT", because "double NAT" could 
be confused with destination NAT and source NAT performed at the same 
time by a single device.

[toc] | [prev] | [next] | [standalone]

#190336

On Tue, Dec 26, 2017 at 05:04:34PM +0100, Pascal Hambourg wrote:
> Le 26/12/2017 à 16:49, Michael Stone a écrit :
> > 
> > This is unnecessarily complicated, and will make your life harder than
> > it needs to be. The best thing would be to not use the airstation as a
> > router at all, just use it as a switch + wireless access point in a flat
> > configuration, with the router plugged into the switch. Ignore the "wan"
> > port on the airstation and turn off any dhcp or other services that it
> > is providing.
> 
> The most important part is "turn off any DHCP service it provides". Othewise
> it will get in the way of the other DHCP server.

I don't see any setting to turn that off in the AirStation web 
interface. I considered this approach in the very first place a year 
ago, and rejected it for that reason.

> 
> > This will not work the way you think it will. Devices on the airstation
> > will have packets go directly to 192.168.1.3 (because the airstation
> > knows how to get to anything on 192.168.1.0/24) (you never actually
> > specified the netmask for 192.168.1., hopefully that's correct). The
> > packets returning from 192.168.1.3 will go to 192.168.1.1 because
> > 192.168.1.3 does not know how to get to 192.168.11.0/24 and uses the
> > default route instead.
> 
> As any SOHO router, it is likely that the Airstation masquerades forwarded
> connections, so other nodes on its WAN side do no see the real 192.168.11.x
> addresses but only the WAN side address of the Airstation, 192.168.1.2.
> 
> I guess that even the firewall does not have a special route for
> 192.168.11.0/24, as it is not supposed to see that address range.
> 

You guess correctly Pascal, that's a known limitation of the approach 
that I consider irrelevant. There is no need to initiate connections 
into the "inner LAN" from the firewall, and connections can be initiated 
the other way with no problems.

Mark

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web