Path: csiph.com!aioe.org!bofh.it!news.nic.it!robomod From: Michael Stone Newsgroups: linux.debian.user Subject: Re: Mixing and Matching DHCP and static IPs Date: Tue, 26 Dec 2017 17:00:02 +0100 Message-ID: References: X-Mailbox-Line: From debian-user-request@lists.debian.org Tue Dec 26 15:50:23 2017 Old-Return-Path: X-Amavis-Spam-Status: No, score=-8.7 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, FOURLA=0.1, LDO_WHITELIST=-5, MDO_CABLE_TV3=0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no X-Policyd-Weight: DYN_NJABL=ERR(0) NOT_IN_SBL_XBL_SPAMHAUS=-1.5 BL_NJABL=ERR(-1.5) CL_IP_EQ_HELO_IP=-2 (check from: .debian. - helo: .harad.mathom. - helo-domain: .mathom.) FROM/MX_MATCHES_NOT_HELO(DOMAIN)=0; rate: -5 Mail-Followup-To: debian-user@lists.debian.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-PGP-Fingerprint: 02D5 315F F11F 1861 860E 1E02 F61A ACDC FA11 FFDE User-Agent: NeoMutt/20170113 (1.7.2) X-Mailing-List: archive/latest/730093 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/62b1a052-ea52-11e7-9b6a-00163eeb5320@msgid.mathom.us Approved: robomod@news.nic.it Lines: 80 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Tue, 26 Dec 2017 10:49:09 -0500 X-Original-Message-ID: <62b1a052-ea52-11e7-9b6a-00163eeb5320@msgid.mathom.us> X-Original-References: <20171225152341.nw2qpopnabjaeviw@kazuki.local> Xref: csiph.com linux.debian.user: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