Unregistered device in DHCP high bandwidth use
-
Good day. An unregistered device under VLAN 40 is using high bandwidth. This is screenshot from traffic graph and ARP list showing unregistered device 172.16.141.162:
But VLAN40 only allows registered devices:
And 172.16.141.162 is not registered:
Choosing DHCP Show All Configured Leases will also not include 172.16.141.162:
System Information: 2.8.1-RELEASE (amd64) under VMware Virtual Machine
My understanding is that because VLAN40 is configured to allow known clients from only this interface and that device was not added to VLAN40 DHCP static mapping, then any device trying to connect to VLAN40 will not get a VLAN40 IP Address but instead will get 169.* so I don't have an idea why there's a valid VLAN40 IP address that's assigned to an unregistered device.
Will this happen if a registered device tethers to an unregistered device? We have a lot of users who tethers their registered devices to laptops (for example) to give internet access to their laptops.
Please let me know what settings I need to provide. Thank you
-
@richardsago I think you are misunderstanding that setting. All it does is control the DHCP server behaviour when it comes to handing out DHCP IP adresses. This does not prevent clients from having a static IP address and use the VLAN that way.
ALSO: I have once seen a client that was “a leach” - meaning it started by listening to VLAN broadcasts to learn which IP scope/settings was used by spying on DHCP broadcasts, and then it just picked a silent IP itself and started using that.
Who knows if IPv6 was inspired by those clients when they came up with SLAAC.EDIT: I don’t think it’s possible to prevent Static IPs or Leach clients unless you switch to fully static mode - IE: Create all clients as static leases, and click “Enable Static ARP” in the DHCP scope settings.
It would make sense you could prevent all clients without a proper DHCP IP, but I don’t think you can unless you go fully static. -
@keyser Plus can have firewall rules by MAC address but that would require allowing all authorized devices.
-
Thank you @keyser and @SteveITS for the replies but I don't yet understand the answers. I don't think I can control anyone from manually-changing their device's IP address but if VLAN 40 is completely static mapped and only devices whose MAC Addresses are registered in DHCP are allowed to get VLAN40 IP Address: how to prevent a rogue device that has manually-changed IP address from gaining internet access?
-
@richardsago Just a thought, but block unknown addresses at the firewall. PITA for sure, but secure. If you assign addresses in blocks it should not be that hard to create some range aliases or block them all and allow only assigned addresses.
-
@richardsago
https://docs.netgate.com/pfsense/en/latest/firewall/ethernet-rules.htmlOr allow specific IPs as noted
-
@richardsago said in Unregistered device in DHCP high bandwidth use:
Thank you @keyser and @SteveITS for the replies but I don't yet understand the answers. I don't think I can control anyone from manually-changing their device's IP address but if VLAN 40 is completely static mapped and only devices whose MAC Addresses are registered in DHCP are allowed to get VLAN40 IP Address: how to prevent a rogue device that has manually-changed IP address from gaining internet access?
The fully closed/secure model you are reffering to is what as called “static arp mapping”. Basically you need to do 3 things:
1: Set the DHCP server “Allow known clients from only this interface” setting (Like you have now).
2: Make sure that ALL clients that is allowed access to this VLAN is preregistred as a STATIC DHCP leases on this VLAN (you probably have that already).
3: To prevent clients and unknown clients from using a manual IPs all together you need to tick “enable static ARP” setting under “Other DHCP options“ on your VLAN.
That last one is what “locks” down pfSense to only accept MAC addresses to IP mapppings on this VLAN according to the STATIC DHCP leases.
This also means no new clients can just connect and get a DHCP IP on this VLAN - you have to actually type in the STATIC DHCP lease for the client before it will be allowed access. -
Thank you @AndyRH , @SteveITS , and @keyser for the replies and solutions. I have now enabled "Enable Static ARP" on the affected VLAN.
In case a rogue device is manually-configured to a legitimate IP Address that is currently in use, and so will cause network issue for the legit user: How to address this problem? I'm thinking this may happen soon
-
@richardsago said in Unregistered device in DHCP high bandwidth use:
how to prevent a rogue device that has manually-changed IP address from gaining internet access?
Recap :
Setup a DHCP server for the (V)LAN.
Set up, for each allowed device, a "DHCP Static Mappings" where you assign a MAC+IP for each allowed device.
Enforce 'only known clients' :
With :
add each known MAC address, and make sure others (unknown) are blocked.
Add a firewall rule here (your (V)LAN :
Where you only allow (V)LAN IP addresses from the known devices, as assigned by DHCP (enforced by the "DHCP Static Mappings")Be aware :
A rogue device could assign himself a static IP, an IP that matches the allow IP range, set up with the firewall rule(s) for your interface.
A rogue device could change it's MAC for a known ok'ed MAC address.
Some portable devices can rotate their MAC for some random one on every connect (for privacy reasons ^^), so it was allowed to connect, but later on, it can't anymore (as it changed its MAC). Check your phone, you'll find it, it's a wifi setting. This ode has to be switched off for your network (Wifi).An IPv4 network connection uses an MAC and an IP, and both can be modified by the device's user, and are not under your control.
If the devices are all using Wifi, you know that wifi can use WPA2, or 3, or a FreeRadius to allow the connection. The AP, if it offers this method, will negotiate with the device and the FreeRadius server (can be pfSense) to allow the device wifi connection.
I never used this method myself, but @johnpoz spook about it (uses it ?).edit : Remember : if you want to make it hard for an unknown device to connect, you start by making a setup that is 'hard' (to the admin).
Simple solution only exist on Youtube (and toctoc !). -
@richardsago said in Unregistered device in DHCP high bandwidth use:
Thank you @AndyRH , @SteveITS , and @keyser for the replies and solutions. I have now enabled "Enable Static ARP" on the affected VLAN.
In case a rogue device is manually-configured to a legitimate IP Address that is currently in use, and so will cause network issue for the legit user: How to address this problem? I'm thinking this may happen soon
I'm pretty sure you are entirely covered by my suggested setup.
If you run STATIC ARP, there is no real danger from clients manually configuring an IP because that client will still not work (MAC address not allowed) - but if one does configure an IP that is currently in use, it will of course upset the other client currently using that same IP (IP Conflict on your switch ARP table).
In static ARP setup the Firewall will only bind the listed MAC addresses to the listed IP address you setup in the static lease. Any other combination of MAC -> IP is not going to be able to talk to the firewall because it will refuse to put their combination into the ARP table. So a rogue device will have a MAC address that is unknown and will go nowhere, a registered client that changes their IP from DHCP to another STATIC IP will go nowhere because that combination is also not allowed.
EDIT: But @Gertjan is right about spoofing. If you get an offensive user in that is capable of sniffing or guessing a correct MAC address in an allowed static Lease, then he will be able to connect and receive the static IP from your DCHP.
EDIT2: If you are hellbent on preventing MAC spoofing, you have to introduce a layer of Authentication (802.1x) on your Wired and WiFi connection. This will force the clients to present a valid certificate or a username/password combo before even being assigned an IP address and allowed onto the VLAN. Once you do that, there is no longer any need for locking down your DHCP server and Static ARP your pfSense because you know the identity of all users that are allowed to connect.
-
Thank you @Gertjan and @keyser for the replies and solutions. Because rogue devices with manually-assigned IP Addresses will result in network disruption to legit IP Address owners (even when rogue devices will now no longer get to the internet), I will regularly monitor Diagnostics > "ARP Table" and look for devices under "Interface" column with value of VLAN40 and "Status" that starts with "Expires in". Because these ARP entries will also display the IP Address of the legit IP Address owner that the rogue device has spoofed, I can temporarily-assign a vacant IP Address to the legit IP Address owner using "DHCP Static Mappings". In terms of pinpointing the exact location of the rogue device: I tracked the access point it's connected to but there are many devices in the affected area and so I'll just stick to monitoring and re-assigning IP Addresses to affected users.
-
@richardsago If you have the problem to the extent you have to do surveillance and running mitigation tasks, you REALLY should change your WiFi from PSK to 802.1x (sometimes called Enterprise in WiFi setup)
It’s really easy and if you do not have a radius server for the task, freeradius on PfSense works perfectly for the task (either certificates or username/password) -
Thank you @keyser for the suggestion. I will look into freeradius but will monitor ARP table in the meantime. Thank you and to the others who responded.
Privacy Policy · Cookie Policy