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 1 of 2  [1] 2  Next page →

#190258 — Mixing and Matching DHCP and static IPs

Greetings and Merry Christmas / Happy Hannukah / insert appropriate 
greeting here

There's no way to describe this with all the relevant info in a short 
way, so I'll try instead to make this as entertaining a read as I can.

For the first time ever I have tried to introduce a machine with a 
static IP to my network and it has exposed what I have a horrible 
feeling is going to turn out to be an embarrassing gap in my knowledge. 
Some machines in my network can communicate with the new machine, and 
some can't. I have an "inner network" and an "outer network" and the 
inner can't see the new machine while the outer can. Details below.

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

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.

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

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.

Once I introduce the PI, (by plugging it into the switch, in case that 
isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
the LAN of my AirStation. For example, from my main Stretch desktop, I 
cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
the firewall at 192.168.1.1.

If I SSH into the firewall, and then try to SSH from _there_ to 
192.168.1.3, I can connect no problem. And I log in to the PI to find it 
bright eyed and bushy tailed, and able to connect to the internet (which 
it must do through the firewall just as all traffic from the AirStation 
does). But if I can't see it from the LAN, I can't use it for the 
purpose I spent the last week of my life building it for... :(

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? I would also expect that if it did not know 
that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
forwarding, just as it does every packet that is destined for the 
internet -- and I would expect the firewall to be able to forward them, 
since it can clearly see the PI.

Can anyone guess what might be wrong with the setup that is preventing 
me from being able to reach 192.168.1.3 from inside the AirStation LAN? 
And how I could fix it? Google turned up the static-routes option of 
dhcpd, which it appears could be used to tell the AirStation about the 
route to 192.168.1.3, but A) I can't figure out how to use that to 
advise a route that doesn't require a gateway and B) the man page 
strongly discourages use of that feature (saying words to the effect of 
"no clients respect this feature, it's useless")...

Once I can get the LAN to see the PI, I plan to install dnscache on the 
PI and modify the DHCP server setup on the firewall to supply the PI as 
the DNS server to the AirStation.

Thanks in advance,

Mark

[toc] | [next] | [standalone]

#190259

On Tue, Dec 26, 2017 at 12:23:41AM +0900, Mark Fletcher wrote:
> Greetings and Merry Christmas / Happy Hannukah / insert appropriate 
> greeting here
> 
> There's no way to describe this with all the relevant info in a short 
> way, so I'll try instead to make this as entertaining a read as I can.
> 
> For the first time ever I have tried to introduce a machine with a 
> static IP to my network and it has exposed what I have a horrible 
> feeling is going to turn out to be an embarrassing gap in my knowledge. 
> Some machines in my network can communicate with the new machine, and 
> some can't. I have an "inner network" and an "outer network" and the 
> inner can't see the new machine while the outer can. Details below.
> 
> 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, 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> Once I introduce the PI, (by plugging it into the switch, in case that 
> isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
> the LAN of my AirStation. For example, from my main Stretch desktop, I 
> cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
> the firewall at 192.168.1.1.
> 
> If I SSH into the firewall, and then try to SSH from _there_ to 
> 192.168.1.3, I can connect no problem. And I log in to the PI to find it 
> bright eyed and bushy tailed, and able to connect to the internet (which 
> it must do through the firewall just as all traffic from the AirStation 
> does). But if I can't see it from the LAN, I can't use it for the 
> purpose I spent the last week of my life building it for... :(
> 
> 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? I would also expect that if it did not know 
> that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
> forwarding, just as it does every packet that is destined for the 
> internet -- and I would expect the firewall to be able to forward them, 
> since it can clearly see the PI.
> 
> Can anyone guess what might be wrong with the setup that is preventing 
> me from being able to reach 192.168.1.3 from inside the AirStation LAN? 
> And how I could fix it? Google turned up the static-routes option of 
> dhcpd, which it appears could be used to tell the AirStation about the 
> route to 192.168.1.3, but A) I can't figure out how to use that to 
> advise a route that doesn't require a gateway and B) the man page 
> strongly discourages use of that feature (saying words to the effect of 
> "no clients respect this feature, it's useless")...
> 
> Once I can get the LAN to see the PI, I plan to install dnscache on the 
> PI and modify the DHCP server setup on the firewall to supply the PI as 
> the DNS server to the AirStation.
> 
> Thanks in advance,
> 
> Mark
> 


1) You talk too much.
Solution: be precise but not chatty. Get to the point.

2) Your network setup is overly complicated.
Solution: simplify! Also very important: complexity is the enemy of security.
Your set up should be straight forward that any issue becomes apparent
without any effort.

Forget about your caching dns server ( at least for now) It is just another
layer of complexity in your preexisting mess.

-H

-- 
Henning Follmann           | hfollmann@itcfollmann.com

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

#190262

Henning Follmann wrote:

> 1) You talk too much.
> Solution: be precise but not chatty. Get to the point.
> 
> 2) Your network setup is overly complicated.
> Solution: simplify! Also very important: complexity is the enemy of
> security. Your set up should be straight forward that any issue becomes
> apparent without any effort.
> 
> Forget about your caching dns server ( at least for now) It is just
> another layer of complexity in your preexisting mess.

very good summary :)

Mark can start by drawing a diagram of the setup, configuring the DHCP an
DNS and firewall properly.
Ad DHCP Mark, you can setup a range with static and a range with dynamic IP
addresses. All that has static address must still be in the DNS to be
resolved.

I did not get it at which level you split the network in two
(internal/external or private/public) - I assume this is the firewall. It
also means the firewall has 2 interfaces - one for internal and one for
external network. You need a good IP-tables setup to make interconnect
possible.

What I describe is the most simple scenario and as Henning mentioned forget
the dns caching for now, until all this stands. I advise start with
DNS/DHCP in the internal (private) network.

regards

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

#190264

> Henning Follmann wrote:
> 
> > 1) You talk too much.

And you are rude. Solution: learn some manners. If you don't have the 
attention span to read more than a few lines of prose, I'm not 
interested in your attempts to make that my problem. As others have 
demonstrated, plenty people do.

> > 
> > 2) Your network setup is overly complicated.
> > Solution: simplify! Also very important: complexity is the enemy of
> > security. Your set up should be straight forward that any issue becomes
> > apparent without any effort.
> > 

Nah -- it works fine, and has done for ages, except for this one problem 
which introducing the machine that will be the DNS cache has revealed.

> > Forget about your caching dns server ( at least for now) It is just
> > another layer of complexity in your preexisting mess.

There's no point in forgetting the DNS caching, it's the only reason I'm 
doing any of this, otherwise I already have a perfectly functioning 
network protected by a simple layer of security and there would be 
nothing to do. And where would the fun in that be? :)

Mark

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

#190266

On Mon, Dec 25, 2017 at 06:00:00PM +0100, deloptes wrote:
> Henning Follmann wrote:
> 
> Mark can start by drawing a diagram of the setup, configuring the DHCP an
> DNS and firewall properly.
> Ad DHCP Mark, you can setup a range with static and a range with dynamic IP
> addresses. All that has static address must still be in the DNS to be
> resolved.

Hmmm it seems like you think I'm saying my network is fundamentally 
broken. It isn't -- works fine except for the one problem of not being 
able to reach the PI from the AirStation LAN. If I could just convince 
the AirStation's WAN side that 192.168.1.3 is on the same subnet as it, 
I'd be away.

> 
> I did not get it at which level you split the network in two
> (internal/external or private/public) - I assume this is the firewall. It
> also means the firewall has 2 interfaces - one for internal and one for
> external network. You need a good IP-tables setup to make interconnect
> possible.
> 

split -- there are essentially two splits because there are two 
firewalls -- one of which I want and one I can't turn off. The firewall 
I set up sits at the outermost edge of the network (obviously) and has 2 
interfaces. The other is at the AirStation, which regards its WAN port 
as the outside but that is actually connected to the inside of the real 
firewall.

Firewall, iptables etc -- Yep set that up ages ago. That's been working 
for a year or so. And the two interfaces of the firewall were covered in 
my original post.

> What I describe is the most simple scenario and as Henning mentioned forget
> the dns caching for now, until all this stands. I advise start with
> DNS/DHCP in the internal (private) network.

Again if I drop the dns caching, I would be back to the network I've 
been running up to now which certainly works but continues to have the 
problem I'm trying to solve which is what happens when the ISP changes 
their DNS addresses. My firewall will smoothly switch gears but the 
AirStation won't. The caching DNS server is designed to fix that. Having 
the DHCP server on the firewall pass root DNS servers like 8.8.8.8 to 
the AirStation would dodge the issue, but the advice I got on this forum 
in the past was set up a local DNS cache, and I thought that sounded 
like a fun toy, so here I am.

Mark

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

#190269

On Monday 25 December 2017 19:54:10 Mark Fletcher wrote:

> On Mon, Dec 25, 2017 at 06:00:00PM +0100, deloptes wrote:
> > Henning Follmann wrote:
> >
> > Mark can start by drawing a diagram of the setup, configuring the
> > DHCP an DNS and firewall properly.
> > Ad DHCP Mark, you can setup a range with static and a range with
> > dynamic IP addresses. All that has static address must still be in
> > the DNS to be resolved.
>
> Hmmm it seems like you think I'm saying my network is fundamentally
> broken. It isn't -- works fine except for the one problem of not being
> able to reach the PI from the AirStation LAN. If I could just convince
> the AirStation's WAN side that 192.168.1.3 is on the same subnet as
> it, I'd be away.
>
Have you looked at the AirStations web page? There may be a bridge option 
that is not turned on. But that will mean you'll need the devils own 
firewall because that will allow drive by hackers free access to your 
home network.  And Grandpa Gene here may do odd things, but thats NOT 
one of them.

> > I did not get it at which level you split the network in two
> > (internal/external or private/public) - I assume this is the
> > firewall. It also means the firewall has 2 interfaces - one for
> > internal and one for external network. You need a good IP-tables
> > setup to make interconnect possible.
>
> split -- there are essentially two splits because there are two
> firewalls -- one of which I want and one I can't turn off. The
> firewall I set up sits at the outermost edge of the network
> (obviously) and has 2 interfaces. The other is at the AirStation,
> which regards its WAN port as the outside but that is actually
> connected to the inside of the real firewall.
>
> Firewall, iptables etc -- Yep set that up ages ago. That's been
> working for a year or so. And the two interfaces of the firewall were
> covered in my original post.
>
> > What I describe is the most simple scenario and as Henning mentioned
> > forget the dns caching for now, until all this stands. I advise
> > start with DNS/DHCP in the internal (private) network.
>
> Again if I drop the dns caching, I would be back to the network I've
> been running up to now which certainly works but continues to have the
> problem I'm trying to solve which is what happens when the ISP changes
> their DNS addresses. My firewall will smoothly switch gears but the
> AirStation won't. The caching DNS server is designed to fix that.
> Having the DHCP server on the firewall pass root DNS servers like
> 8.8.8.8 to the AirStation would dodge the issue, but the advice I got
> on this forum in the past was set up a local DNS cache, and I thought
> that sounded like a fun toy, so here I am.
>
> Mark


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#190282

Mark Fletcher wrote:

> split -- there are essentially two splits because there are two
> firewalls -- one of which I want and one I can't turn off. The firewall
> I set up sits at the outermost edge of the network (obviously) and has 2
> interfaces. The other is at the AirStation, which regards its WAN port
> as the outside but that is actually connected to the inside of the real
> firewall.

Looks like Airstation is WLAN router - I would put it infront of the
firewall and DMZ to the firewall

something like this

[intranet] <---> eth1 [firewall] eth0 <----> [extranet]
                                  ^--(DMZ)-> [AirStation/WLAN]

or you can turn off the firewall there completely 

AT home I have a router with WLAN from the Telco and my setup looks like
following

[intranet] <---> [firewall] <-- (DMZ) --> [Router + WLAN] <---> WAN
                                                  ^-----------> WLAN

The DNS problem looks like you have to (again) work on the AirStation.

If you can not manage the AirStation - throw that crap away.

regards

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

#190288

Le 26/12/2017 à 12:10, deloptes a écrit :
> 
> Looks like Airstation is WLAN router - I would put it infront of the
> firewall and DMZ to the firewall

And lose the protection provided by the firewall to wireless devices ? 
Sounds like a great idea.

> or you can turn off the firewall there completely

And push your logic to the limit : remove the protection for all 
devices, not only wireless ones.

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

#190300

Pascal Hambourg wrote:

> And lose the protection provided by the firewall to wireless devices ?
> Sounds like a great idea.
> 

It is more dangerous having the WLAN behind your firewall. I hope you
understand this.

>> or you can turn off the firewall there completely
> 
> And push your logic to the limit : remove the protection for all
> devices, not only wireless ones.

your firewall will protect you anyway - devices using WLAN should have
firewalls enabled anyway on their end.

If you think you are smarter, I don't mind, but you were the one that asked
the question.

regards

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

#190263

2017-12-25 16:23 keltezéssel, Mark Fletcher írta:
> Can anyone guess what might be wrong with the setup that is preventing 
> me from being able to reach 192.168.1.3 from inside the AirStation LAN? 
> And how I could fix it? Google turned up the static-routes option of 
> dhcpd, which it appears could be used to tell the AirStation about the 
> route to 192.168.1.3, but A) I can't figure out how to use that to 
> advise a route that doesn't require a gateway and B) the man page 
> strongly discourages use of that feature (saying words to the effect of 
> "no clients respect this feature, it's useless")...
First check the routing on RPi. If it has only one (default) route to
the gateway (192.168.1.1) then it will not reach your 'internal' network.

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

#190268

Le 25/12/2017 à 16:23, Mark Fletcher a écrit :
> 
> There's no way to describe this with all the relevant info in a short
> way

Yes there is a way. You really talk too much.

> so I'll try instead to make this as entertaining a read as I can.

You failed. Ther result is just long and boring.

> 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.
(...)
> Once I introduce the PI, (by plugging it into the switch, in case that
> isn't obvious) I find I cannot reach it (by ping or by SSH) from inside
> the LAN of my AirStation. For example, from my main Stretch desktop, I
> cannot ping or SSH to the PI at 192.168.1.3.

What happens when you try ?

> If I SSH into the firewall, and then try to SSH from _there_ to
> 192.168.1.3, I can connect no problem. And I log in to the PI to find it
> bright eyed and bushy tailed, and able to connect to the internet (which
> it must do through the firewall just as all traffic from the AirStation
> does). But if I can't see it from the LAN, I can't use it for the
> purpose I spent the last week of my life building it for... :(

What is the netmask configured on the Pi ? Can you show the full routing 
table on the Pi ?
What are the subnet and netmask advertised by the DHCP server running on 
the firewall ?
Can you display the full routing table of the Airstation, including 
routes on the WAN interface ?

Did you run a packet sniffer on the firewall and the Pi to look what's 
going on ?

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

#190290

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

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

You seem to have set up a situation of double-NAT.  This means that
while 11.x can easily talk to a device on the 1.x network, the opposite
is not true.

> Once I introduce the PI, (by plugging it into the switch, in case that 
> isn't obvious) I find I cannot reach it (by ping or by SSH) from inside 
> the LAN of my AirStation. For example, from my main Stretch desktop, I 
> cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to 
> the firewall at 192.168.1.1.
>
> If I SSH into the firewall, and then try to SSH from _there_ to 
> 192.168.1.3, I can connect no problem. And I log in to the PI to find it 
> bright eyed and bushy tailed, and able to connect to the internet (which 
> it must do through the firewall just as all traffic from the AirStation 
> does). But if I can't see it from the LAN, I can't use it for the 
> purpose I spent the last week of my life building it for... :(

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

>
> 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? I would also expect that if it did not know 
> that, it would send packets for 192.168.1.3 to 192.168.1.1 for 
> forwarding, just as it does every packet that is destined for the 
> internet -- and I would expect the firewall to be able to forward them, 
> since it can clearly see the PI.


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.


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

iQEcBAEBAgAGBQJaQjN0AAoJEI4R3fMSeaKBphsH/2LEj+7f49OPmcpz3HO/yjqU
bewELs1d0pWNWS6Tx92Wgy0RyL5j0NEqJIaz/FmmFu3gQ2wF2EZGwM7e1eUl3EJX
E0tdd1/pFDfBX54inKKWIwF1egj/vo4AVl8KzjXRRL7FWfp+pB0wm96f/yjj6qXV
knA6LuH6utJyI/jPqc3oyRUbB2KsTIvfLfyY5YhaN4uAZLWsk+ylKowYm13rys2d
8Lx7bi3ATRb6gR2UGQWY+6ddMOVtMp+b0FH0GUFp3NX3ppbqZkM2uTviBqxppzAZ
zLK5QewjMu99KhrVJcPAFTO/B8tfwUgP/cC0aCFJjkkkaqIOPVVKPp3g4V60mHE=
=0FzT
-----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]

#190291

[Multipart message — attachments visible in raw view] — view raw

On Tue, Dec 26, 2017 at 20:40 Dan Purgert <dan@djph.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Fletcher wrote:
> > [...]
> > 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
>
> You seem to have set up a situation of double-NAT.  This means that
> while 11.x can easily talk to a device on the 1.x network, the opposite
> is not true.


That’s what I expected, but that is not what I am getting — machines on
11.x can easily talk to 192.168.1.1 (and hence to the internet) but not to
192.168.1.3. There is no requirement for the PI to be able to initiate
connections back the other way.

>
> > Once I introduce the PI, (by plugging it into the switch, in case that
> > isn't obvious) I find I cannot reach it (by ping or by SSH) from inside
> > the LAN of my AirStation. For example, from my main Stretch desktop, I
> > cannot ping or SSH to the PI at 192.168.1.3. I can both ping and SSH to
> > the firewall at 192.168.1.1.
> >
> > If I SSH into the firewall, and then try to SSH from _there_ to
> > 192.168.1.3, I can connect no problem. And I log in to the PI to find it
> > bright eyed and bushy tailed, and able to connect to the internet (which
> > it must do through the firewall just as all traffic from the AirStation
> > does). But if I can't see it from the LAN, I can't use it for the
> > purpose I spent the last week of my life building it for... :(
>
> 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).
>

So the trick would be to discourage it from thinking of 192.168.1.3 as
bogus... Do you think the earlier suggestion of having the PI’s IP address
handed out by the DHCP server on the firewall but using DHCP reservation to
make sure the PI gets a specific address would fix that?

Anyway I still have trying that ahead of me so will report back when I have.


> >
> > 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? I would also expect that if it did not know
> > that, it would send packets for 192.168.1.3 to 192.168.1.1 for
> > forwarding, just as it does every packet that is destined for the
> > internet -- and I would expect the firewall to be able to forward them,
> > since it can clearly see the PI.
>
>
> 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.
>

Except for some reason it doesn’t seem to (or, rather, that is what APPEARS
to be the case but without answering some of Pascal’s earlier questions I
can’t say for certain that is what is going on). We know that 1.1 can reach
1.3, but 11.anything doesn’t seem to be able to, even though they can reach
1.1 . I just don’t know why yet.

Mark

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

#190301

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

Mark Fletcher wrote:
> --001a113ec1c0f4dccb05613d0b84
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Dec 26, 2017 at 20:40 Dan Purgert <dan@djph.net> wrote:
>
>>
>> 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).
>>
>
> So the trick would be to discourage it from thinking of 192.168.1.3 as
> bogus... Do you think the earlier suggestion of having the IP address
> handed out by the DHCP server on the firewall but using DHCP
> reservation to make sure the PI gets a specific address would fix
> that?

Unlikely, since it is the Airstation's firewall making the determination
that the 1.0/24 network is bogus.

> [...]
>>
>> 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.
>>
>
> Except for some reason it doesn't seem to (or, rather, that is what
> APPEARS to be the case but without answering some of Pascal's earlier
> questions I can't say for certain that is what is going on). We know
> that 1.1 c an reach 1.3, but 11.anything doesn't seem to be able to,
> even though they can reach 1.1 . I just don.t know why yet.

Again, this points to the idea that perhaps the Airstation has a
firewall preventing access to "bogus" networks. I assume that the
Airstation does not have any capabilities to run ping / traceroute tests
from somewhere in its administration menus?

If it DOES allow that, it may be helpful to try pinging directly from
the airstation.

Also, since I probably missed it, what is the "firewall" device that's
handing out the 1.0/24 network (make and model please)?

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

iQEcBAEBAgAGBQJaQl0LAAoJEI4R3fMSeaKBSd8H/iQzt50XajYC6cKsTGQPxnd2
k2e2ww+A23El8IYUTyNq25XrT9jl3KTXgRyeu2FHZ6NhuWxJDMbrnzYalruopMnP
tV4URBcgbKA6rsa4SM5iqJdgpCtWQ+FtvnI7fJmuf5Mz9tgpV1M3oGdgyKh32kXd
kUO3Gye6iATL17Eb8IVet6D7HBHnZbODWNJSrMsH2iM0I6+obUqY7LYr7cVndPVi
+2+sYc76mhHX+nXLwH+0kPORBC36qO0z2LQQnjWyPiyn6NymMdFGLvgdxaZIWl1g
wWB0UHNwPMe1e/C1hvBU4vGc/xo5aRZ3jJTCI/ib2NPgePOlWhGWkJ7hD7lfiE0=
=S4d8
-----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]

#190308

On Tue, Dec 26, 2017 at 02:31:05PM -0000, Dan Purgert wrote:
> >> 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.
> >>
> >
> > Except for some reason it doesn't seem to (or, rather, that is what
> > APPEARS to be the case but without answering some of Pascal's earlier
> > questions I can't say for certain that is what is going on). We know
> > that 1.1 c an reach 1.3, but 11.anything doesn't seem to be able to,
> > even though they can reach 1.1 . I just don.t know why yet.
> 
> Again, this points to the idea that perhaps the Airstation has a
> firewall preventing access to "bogus" networks. I assume that the
> Airstation does not have any capabilities to run ping / traceroute tests
> from somewhere in its administration menus?
> 
> If it DOES allow that, it may be helpful to try pinging directly from
> the airstation.

I don't think I'm gonna have much luck with that. The Web interface is 
fairly bog standard -- and what is there is in Japanese, which doesn't 
help... I can read Japanese, but slowly, with errors... With all that 
said, I have spent enough time squinting at that interface to be fairly 
sure it doesn't offer that functionality.

> 
> Also, since I probably missed it, what is the "firewall" device that's
> handing out the 1.0/24 network (make and model please)?
> 

Yeah that was in the TLDR original post. It's a mini-ITX PC running LFS. 
It came with Windows 10, and I ripped it out of Windows' evil clutches 
and installed LFS on it. Before bringing the PI into the picture, this 
box had been acting as my firewall, DHCP server for the AirStation, and 
occasional VPN server for me for about a year with no problems.

Mark

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

#190292

Le 26/12/2017 à 12:33, Dan Purgert a écrit :
> 
> Mark Fletcher wrote:
>> [...]
>> 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
> 
> You seem to have set up a situation of double-NAT.  This means that
> while 11.x can easily talk to a device on the 1.x network, the opposite
> is not true.

Good thing, the OP just wants to talk to 192.168.1.x from 192.168.11.x, 
not the opposite.

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

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

> I would also expect that if it did not know
>> that, it would send packets for 192.168.1.3 to 192.168.1.1 for
>> forwarding, just as it does every packet that is destined for the
>> internet -- and I would expect the firewall to be able to forward them,
>> since it can clearly see the PI.

A firewall usually has filtering rules. Do these rules allow packets to 
be forwarded from the LAN interface back to the same interface ?
Also, this would cause asymmetric routing (the server would send reply 
packets directly to the client), which may not work well with stateful 
filtering as the firewall would see only one direction of the communication.

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

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

#190298

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.

> 
> > I would also expect that if it did not know
> > > that, it would send packets for 192.168.1.3 to 192.168.1.1 for
> > > forwarding, just as it does every packet that is destined for the
> > > internet -- and I would expect the firewall to be able to forward them,
> > > since it can clearly see the PI.
> 
> A firewall usually has filtering rules. Do these rules allow packets to be
> forwarded from the LAN interface back to the same interface ?
> Also, this would cause asymmetric routing (the server would send reply
> packets directly to the client), which may not work well with stateful
> filtering as the firewall would see only one direction of the communication.
> 

Fair question re routing rules. I asked myself the same question last 
night before the original post, and checked (because my memory isn't 
what it once was). 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 only refuses if the incoming interface is the 
external interface (the internet-facing one). I didn't exactly do that 
deliberately but the effect is the one I need here, I believe.

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

Mark

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

#190302

Le 26/12/2017 à 14:55, Mark Fletcher a écrit :
>>
>>>> I would also expect that if it did not know
>>>> that, it would send packets for 192.168.1.3 to 192.168.1.1 for
>>>> forwarding, just as it does every packet that is destined for the
>>>> internet -- and I would expect the firewall to be able to forward them,
>>>> since it can clearly see the PI.
>>
>> A firewall usually has filtering rules. Do these rules allow packets to be
>> forwarded from the LAN interface back to the same interface ?
>> Also, this would cause asymmetric routing (the server would send reply
>> packets directly to the client), which may not work well with stateful
>> filtering as the firewall would see only one direction of the communication.
> 
> Fair question re routing rules.

Filtering rules, not routing rules.
Routing rules determine how a packet should be routed.
Filtering rules such as iptables rules determines whether a packet 
should be dropped or accepted.

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

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

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

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>

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

#190303

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

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

#190310

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.

The only exception is for /31 prefixes on "point to point" links. Such 
networks contain only a pair of address, so the usual rule would reserve 
them as network and broadcast addresses and and leave no usable host 
address, making the prefix useless in practice. Instead, both addresses 
are used as host addresses for the nodes at each end of the point to 
point link, and there are no network and broadcast addresses (pointless 
on a point to point link). This exception was created to avoid the use 
of /30 prefixes on such point to point links which would waste half of 
the addresses. Note that old devices and systems may not support this.

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

IIUC, you declared subnet 192.168.1.0/30 or /29 in the DHCP server 
configuration. But what subnet or prefix lenght did you set up on the 
interface configuration of the firewall and server ?

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

Sorry for the extra burden.
Running a packet sniffer on another (e.g. Debian) machine on the 
external subnet would only capture broadcast packets, except if your 
ethernet switch supports a "mirror port" feature which mirrors incoming 
traffic on all ports to a special port for monitoring purpose.
Using iptables LOG rules in raw/PREROUTING and mangle/POSTROUTING on the 
router and the server would log only IPv4 packets, not ARP packets which 
could provide valuable information. Maybe by combining the two you could 
gather enough data.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web