Enable Static ARP entries not working correctly
-
Nope, it's still not working correctly. The firewall let's you through with a manually set static IP. The Deny unknown clients only influence whether the DHCP server provide a dynamic address to the client or not.
Anybody has a solution for this, other than to create a group with all configured IPs and create a floating rule to allow these only? -
@shakebocaj we need a solution soon! :(
-
The solution is already mentioned. You have a firewall : use it.
If devices have a static IP setup, thus not using DHCP, and falls with the 'accepted IP' list (alias), then access is granted. Ethernet networking as defined last century (1970 ?) doesn't offer you more to 'stop' these kind of connections. The only thing left to do : protect your physical LAN plugs so nobody can plug in.Be aware : IP setup can be done manually. MAC addresses can be modified at will. pfSense, and any other firewall / router out there can not do more to identify a device.
Maybe the captive portal can be a solution ? -
@Gertjan said in Enable Static ARP entries not working correctly:
The solution is already mentioned. You have a firewall : use it.
If devices have a static IP setup, thus not using DHCP, and falls with the 'accepted IP' list (alias), then access is granted. Ethernet networking as defined last century (1970 ?) doesn't offer you more to 'stop' these kind of connections. The only thing left to do : protect your physical LAN plugs so nobody can plug in.Be aware : IP setup can be done manually. MAC addresses can be modified at will. pfSense, and any other firewall / router out there can not do more to identify a device.
Maybe the captive portal can be a solution ?Before v2.5.2 works like a charm blocking vía ARP and Static ARP. Before 2.5.2, not working anymore
-
@pcready-cl said in Enable Static ARP entries not working correctly:
Before v2.5.2 works like a charm blocking vía ARP and Static ARP
ARP is based on the MAC addresses.
In the past, not all hardware did allow that you could change the MAC of a device. These days, its common knowledge, and you often can change it.
So, locking devices down based on MAC addresses is ... and never was, a secure way to filter out unwanted devices.edit : pfSense can't know if a device uses it's original MAC, or some other random MAC. My Phone uses by default a randomized MAC when it connects to an unknown Wifi SSID by default.
-
I noticed the same problem, I have these options in DHCP server:
Deny Unknown Clients: Allow known clients from only this interface
Static ARP: checked Enable Static ARP entries
device is not on the list of DHCP Static Mappings
Results:
pfSense CE 2.6: device with manually set static IP address = no connection to pfSense and Internet
pfSense CE 2.7.2: device with manually set static IP address = there is a connection to pfSense and InternetI tested this on fresh, clean installations of pfSense CE, 2.6 and 2.7.2, only above settings were changed.
My question is - which behavior is correct?
-
@mateusz said in Enable Static ARP entries not working correctly:
Deny Unknown Clients: Allow known clients from only this interface
Static ARP: checked Enable Static ARP entries
device is not on the list of DHCP Static MappingsSo the device won't get a lease.
That is : shouldn't get a lease.But, be aware, I've never played with this option :
-
@Gertjan
Yes, device not getting a lease in both versions, 2.6 and 2.7.2, but in case I set static IP address on this device there is a different behaviour depending on pfSense version. With version 2.6 device cannot communicate with pfSense and therefore Internet. With 2.7.2 device can communicate with pfSense/Internet. -
@mateusz said in Enable Static ARP entries not working correctly:
@Gertjan
Yes, device not getting a lease in both versions, 2.6 and 2.7.2, but in case I set static IP address on this device there is a different behaviour depending on pfSense version. With version 2.6 device cannot communicate with pfSense and therefore Internet. With 2.7.2 device can communicate with pfSense/Internet.Same here, with pfSense+ 24.03-RELEASE (amd64) device can communicate with pfSense/Internet.
-
@mateusz said in Enable Static ARP entries not working correctly:
but in case I set static IP address on this device
In that case the pfSense DHCP server isn't solicited.
If all devices on your LAN have static IP assignments (IP, network,DNS, gateway), you could even shut down the pfSense DHCP server on that LAN. -
@Gertjan
Enabled/disabled DHCP server is not the point. I can deactivate DHCP server but behaviour is the same - in pfSense 2.6 device with static IP address can't communicate with pfSense/Internet, in pfSense 2.7.2 it can. I believe Enable Static ARP entries option works different in both versions. Based on description I thought that only devices from the list of DHCP Static Mappings will be able to talk with pfSense. This works that way in version 2.6 but not in version 2.7.2.Description from GUI:
Enable Static ARP entries
Restricts communication with the firewall to only hosts listed in static mappings containing both IP addresses and MAC addresses. No other hosts will be able to communicate with the firewall on this interface. This behavior is enforced even when DHCP server is disabled.Description from Netgate documentation:
Static ARP:
This checkbox works similar to denying unknown MAC addresses from obtaining leases, but takes it a step further in that it also restricts any unknown MAC address from communicating with this firewall. This stops would-be abusers from hardcoding an unused address on this subnet, circumventing DHCP restrictions. -
@mateusz said in Enable Static ARP entries not working correctly:
in pfSense 2.6 device with static IP address can't communicate with pfSense/Internet
When you install a pfSense with default settings (you change nothing except the password), from the very first beta version 0.9, more then a decade ago, up to latest 2.7.2 (or 24.03) : any device connected to the LAN port can connect to pfSense, and the Internet, if the WAN is also connected.
Remember : pfSense behaves as any router you can buy out there.
Ok, true, if you have a PPPOE connection, you need to create a pppoe setup on your WAN interface.
As my pfSense uses 192.168.1.1/24 on its LAN, and the DHCP server is by default activated on LAN, I can connect my PC to this LAN port, and I have access. This behavior never changed.
If your WAN is "special" or "different", tell us about it.
Things like "Enable Static ARP entries" : I never had to deal with that.
"DHCP Static Mappings" : I use these all the time. And that's why I use ISC, and not KEA (I use a 24.03).@mateusz said in Enable Static ARP entries not working correctly:
denying unknown MAC addresses from obtaining leases
I never had to deal with "deny unknown MAC addresses" as the kids at home are over 8 years old so they know how to bypass that (no, I'm not joking).
-
@Gertjan
I checked once again my configurations on 2.6 and 2.7.2 versions. They are test machines and both have default settings with changes made only in DHCP server service:Deny Unknown Clients: Allow known clients from only this interface
Static ARP: checked Enable Static ARP entries
device is not on the list of DHCP Static MappingsI think there is a misunderstanding and I will try to describe my configuration and my question better.
In both 2.6 and 2.7.2 versions with default settings I connect my test laptop directly to LAN port, also I have WAN with DHCP and as you said I can connect to pfSense and have Internet access.
But when I change settings in DHCP service to mentioned above, pfSense behaves differently depending on its version.
In 2.6 test laptop (with static IP address) connected to LAN port cannot access pfSense and therefore Internet.
But in 2.7.2 the same test laptop (with static IP address) connected to LAN port can access pfSense and Internet.Enabled/disabled DHCP server does not change this behavior.
I know bypassing of "deny unknown MAC addresses" is easy but I am curious why pfSense in different versions behaves differently with the same settings.
-
DHCP : ISC or Kea ?
-
@Gertjan
Still ISC.
