Kitz Forum
Computers & Hardware => Networking => Topic started by: burakkucat on December 03, 2021, 11:12:53 PM
-
[Moderator note: This topic has been created by splitting off the following two posts from Weaver's IPv6 - who has or does not have it and who does or does not understand it? (https://forum.kitz.co.uk/index.php/topic,26568.msg445580.html#msg445580) thread.]
Couldn’t agree more. Unfortunately this has never been true, because in IPv4 when a system has DHCPv4 in use, a host can still just allocate itself any address it wants, by static allocation, which could fail catastrophically, or alternatively by just checking to see if a desired IPv4 address is in use and then grabbing it if it’s free. More than unlikely of course.
I have never had a DHCP server on my (IPv4) LAN . . . every device has a static address, assigned by me. Every device on the LAN has a copy of my master "hosts" file. (But this is a digression from the IPv6 topic.)
-
I am moving to a similar setup as Burakkucat has. I have a master document (in XML as it happens) which lists all the IPv4 addresses of everything and I am now changing everything over to being statically configured while at the same time having matching DHCPv4 assignments. The old way of doing everything was to have everything assigned by DHCPv4 with fixed known addresses and a pool of ten IPv4 addresses for known friends visiting. Regularly visiting good friends were allocated outside this pool though, because, by design, the pool members were definitely second class citizens, who were given very rate-limited access to the internet. The DHCP friends’ pool remains in use.
I expect that I will get some more abuse for this. ;) - I was doing some reading about LAN-internal attacks whereby the attacker impersonates a DHCPv4 controller and creates mayhem. This caused a bout of paranoia where I decided to ask myself whether or not I really needed DHCP given the security risks it poses. Friends on the guest SSID cannot attack hosts on either the wired or wireless parts of the LAN because of the L2 firewalling of the WAPs in the guest SSID - guest hosts can only talk to the router, so they can access DHCP (since the default gateway and the DHCP controller are one and the same) and access the internet, and that’s it.
But this has nothing at all to do with IPv6, and I should perhaps ask for this recent slice of the thread to be split off if kitizens wish to discuss IPv4 address assignment (a very worthwhile topic) -- Moderator note: Now done.
-
I'm very dull here. I use a larger subnet with half of it for infrastructure which is statically addressed and the rest DHCP.
A Raspberry Pi functions and DNS and DHCP so resolves local hosts for all devices.
There's a guest and IOT SSID that sits behind its own access point and router. That router has a mapped public IP to avoid dual NAT and can only talk to a single device - the edge router. That has its own IP pool in a different network.
-
I have static addresses for two printers, a WAP and three Youview boxes. The Youview boxes have wireless adaptors and they seem more reliable with static addresses. For everything else I leave DHCP to do its s stuff, which it does perfectly well.
:)
-
I use DHCP, personally I started finding it a pain to manually configure IP's on clients, but on devices where I want the same ip guaranteed, I configure a sticky ip in DHCP.
Plus some devices dont let you manually configure ip's as they cannot be configured, in which case DHCP is your only means of control.
-
My issue too. Infrastructure that DHCP may need is statically addressed for obvious reasons, DHCP server is DNS server so can resolve names.
Keep it simple and, where it makes sense, automated. Implement once and let it run.
-
I am moving to a similar setup as Burakkucat has.
I expect that I will get some more abuse for this. ;) - I was doing some reading about LAN-internal attacks whereby the attacker impersonates a DHCPv4 controller and creates mayhem. This caused a bout of paranoia where I decided to ask myself whether or not I really needed DHCP given the security risks it poses.
Just don't, because once someone is on the internal LAN its game over anyway. For starters, you use IPv6 so couldn't a LAN attack just corrupt RA anyway? You rely on the Internet so much, I don't think complicating it so if you are too ill to work on it nobody else can either is a great idea.
Having a central location deal with IP addressing and DNS is just so much less hassle.
Bearing in mind I'm saying that while pfSense throws a wobbly and refuses to issue IP addresses on the IOT VLAN for some reason, its never done that before. I'm starting to wonder if the OS is corrupted as its been misheaving for a few days doing weird things.
-
I have never had a DHCP server on my (IPv4) LAN . . . every device has a static address, assigned by me. Every device on the LAN has a copy of my master "hosts" file. (But this is a digression from the IPv6 topic.)
How do you deal with mobile devices which need to work when they're away from your LAN? I can remember one Windows (or maybe Mac) version where the static assignment was only supposed to take effect if DHCP fails, but I didn't find it worked properly. For that reason I moved away from static assignment to static DHCP reservations, then once I started doing that I found I might as well do the same for other devices like printer and PVR.
If the concern is a rogue DHCP server either by accident or on purpose, most LAN kit supports some sort of DHCP filtering or snooping so that DHCP requests are only forwarded to designated ports.
-
How do you deal with mobile devices which need to work when they're away from your LAN? I can remember one Windows (or maybe Mac) version where the static assignment was only supposed to take effect if DHCP fails, but I didn't find it worked properly. For that reason I moved away from static assignment to static DHCP reservations, then once I started doing that I found I might as well do the same for other devices like printer and PVR.
If the concern is a rogue DHCP server either by accident or on purpose, most LAN kit supports some sort of DHCP filtering or snooping so that DHCP requests are only forwarded to designated ports.
Same reason I switched to DHCP too, I always used to statically assign but it became far too problematic, especially as I got more devices.
The way I see it is DHCP is also another way to know if someone got on your WiFi somehow as unless they're smart, they will make a request and so show up in the DHCP logs.
If anyone who IS smart gets on your LAN, you're fairly stuffed anyway.
-
How do you deal with mobile devices which need to work when they're away from your LAN?
I only have two mobile/portable devices and both have alternate profiles (using a DHCP client) that I can (manually) select for such occurrences.
-
> anyone who IS smart gets on your LAN, you're fairly stuffed anyway.
Quite. But guests would be wireless and on my guest SSID thus isolated by my WAPs (using L2 filtering). No, the model of attacker I was thinking about is a good friend whom I trust brings a machine that is itself crawling with nasties and tries to attack my LAN, so the attacker is not a human.
> the concern is a rogue DHCP server either by accident or on purpose, most LAN kit supports some sort of DHCP filtering or snooping so that DHCP requests are only forwarded to designated ports.
Indeed, I was interested in that kind of security technology. I can’t use that kind of protection anymore because of Apple spoofing. This is done by the Apple "sleep proxy server" - services provided in say Apple HomePod speaker (iirc), and the Apple TV box. Apple spoofing is very sort-of evil and very clever. When a device wants to sleep, it asks a sleep proxy server to take over the device’s roles while it sleeps and then the sleep proxy server impersonates the snoozing device at the MAC level. That was very vague, because I don’t know the details; I would need to read up on the protocol properly.
Anyway, checking for spoofing is something that some switches offer, but wouldn’t help me because of all the WLAN hosts.
The right thing for me to do concerning untrusted friends’ wired devices is to put them in their own subnet.