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


Groups > linux.debian.user > #190302

Re: Mixing and Matching DHCP and static IPs

From Pascal Hambourg <pascal@plouf.fr.eu.org>
Newsgroups linux.debian.user
Subject Re: Mixing and Matching DHCP and static IPs
Date 2017-12-26 15:50 +0100
Message-ID <v0YIh-3B9-7@gated-at.bofh.it> (permalink)
References <v0CRs-5tB-1@gated-at.bofh.it> <v0VU5-1Bu-9@gated-at.bofh.it> <v0Wdr-1YJ-9@gated-at.bofh.it> <v0XVU-33a-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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>

Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

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

csiph-web