DHCP server failing to add ARP entry?
I have a box running Freeradius as a backend to pfSense. I'd like to use FR as a DHCP server. With Alan's help I set up DHCP and EAP on separate sql modules. It works OK when pfSense is serving IPs (FR fails to add an ARP entry but pfSense's DHCP server overrides/ignores FR's anyway). When I turn off the DHCP server on pfSense and try to run exclusively FR's, I get the following key message in my debug: "Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)" I read the doco for FR's DHCP server and used the command: "sudo setcap cap_net_admin=ei /usr/sbin/freeradius" and tried eip as well but it had no effect. I'm running: "sudo freeradius -X" as well, just to make sure the privileges are OK. Here is the debug output from a sample connection attempt - http://pastebin.com/raw/acNazHPA . I probably set up my dhcp server incorrectly. Here's an example of my sites-enabled/dhcp_static : http://pastebin.com/raw/S1mb4bFc One thing I did not do is obey the comments at the top of that file instructing to call setfib because I thought the comments implied it was unnecessary when a config doesn't have multiple interfaces. It won't surprise me if many of those server settings are completely incorrect and that is the source of my problem. More info - when I run: "arp -s some_ip some_mac" I get: "SIOCSARP: Operation not permitted" So that's a pretty big clue corresponding to my debug output. However when I run it as sudo it works, obviously. And I run freeradius as sudo so I presumed along with the set capabilities it _should_ work, right? The only other time I found a mailing list response referring to my problem the two solutions were: (i) set broadcast = no in the dhcp server (ii) find out why the arp setting isn't working I'm trying to work out (ii) but the OP never responded in that thread so there was no resolution from them. Thanks, Toby
On Nov 6, 2016, at 7:02 AM, Toby Walsh <walshtj@gmail.com> wrote:
I have a box running Freeradius as a backend to pfSense. I'd like to use FR as a DHCP server. With Alan's help I set up DHCP and EAP on separate sql modules. It works OK when pfSense is serving IPs (FR fails to add an ARP entry but pfSense's DHCP server overrides/ignores FR's anyway). When I turn off the DHCP server on pfSense and try to run exclusively FR's, I get the following key message in my debug:
"Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I read the doco for FR's DHCP server and used the command:
"sudo setcap cap_net_admin=ei /usr/sbin/freeradius"
As the docs say, that's a Linux command. pfSense is FreeBSD. The command might do something for Linux compatibility, but it's most likely that it won't work.
I'm running:
"sudo freeradius -X"
as well, just to make sure the privileges are OK. Here is the debug output from a sample connection attempt - http://pastebin.com/raw/acNazHPA .
If it runs as root, it should have permission to update the ARP table entry.
One thing I did not do is obey the comments at the top of that file instructing to call setfib because I thought the comments implied it was unnecessary when a config doesn't have multiple interfaces.
It isn't necessary for ARP.
So that's a pretty big clue corresponding to my debug output. However when I run it as sudo it works, obviously. And I run freeradius as sudo so I presumed along with the set capabilities it _should_ work, right?
On FreeBSD, you should just run it as root. It should be able to update the ARP table entries. There is code in the server to create raw DHCP packets, which should mean that it isn't necessary to update the ARP tables. But that code is Linux only. The code for FreeBSD is more complex, and no one has gotten around to implementing it yet. Alan DeKok.
Sorry, I wasn't clear - the hardware is a small server running as an ESXi box. I have one VM running pfSense and one VM running Ubuntu Server. Freeradius is running on the Linux VM. So when I've switched off pfSense's DHCP and switched on FR's, the ARP update should be on the Linux VM, right? They're communicating through a virtual switch, so I want them on the same subnet but different hosts/IPs (with everything on my network served/configured hopefully by FR/mysql and routed by pfSense). Thanks, Toby On Sun, 6 Nov 2016 21:28 Alan DeKok, <aland@deployingradius.com> wrote:
On Nov 6, 2016, at 7:02 AM, Toby Walsh <walshtj@gmail.com> wrote:
I have a box running Freeradius as a backend to pfSense. I'd like to
use FR
as a DHCP server. With Alan's help I set up DHCP and EAP on separate sql modules. It works OK when pfSense is serving IPs (FR fails to add an ARP entry but pfSense's DHCP server overrides/ignores FR's anyway). When I turn off the DHCP server on pfSense and try to run exclusively FR's, I get the following key message in my debug:
"Failed adding ARP entry: Failed to add entry in ARP cache: Operation not permitted (1)"
I read the doco for FR's DHCP server and used the command:
"sudo setcap cap_net_admin=ei /usr/sbin/freeradius"
As the docs say, that's a Linux command. pfSense is FreeBSD. The command might do something for Linux compatibility, but it's most likely that it won't work.
I'm running:
"sudo freeradius -X"
as well, just to make sure the privileges are OK. Here is the debug output from a sample connection attempt - http://pastebin.com/raw/acNazHPA .
If it runs as root, it should have permission to update the ARP table entry.
One thing I did not do is obey the comments at the top of that file instructing to call setfib because I thought the comments implied it was unnecessary when a config doesn't have multiple interfaces.
It isn't necessary for ARP.
So that's a pretty big clue corresponding to my debug output. However when I run it as sudo it works, obviously. And I run freeradius as sudo so I presumed along with the set capabilities it _should_ work, right?
On FreeBSD, you should just run it as root. It should be able to update the ARP table entries.
There is code in the server to create raw DHCP packets, which should mean that it isn't necessary to update the ARP tables. But that code is Linux only. The code for FreeBSD is more complex, and no one has gotten around to implementing it yet.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Nov 6, 2016, at 8:47 AM, Toby Walsh <walshtj@gmail.com> wrote:
Sorry, I wasn't clear - the hardware is a small server running as an ESXi box. I have one VM running pfSense and one VM running Ubuntu Server. Freeradius is running on the Linux VM. So when I've switched off pfSense's DHCP and switched on FR's, the ARP update should be on the Linux VM, right?
Yes.
They're communicating through a virtual switch, so I want them on the same subnet but different hosts/IPs (with everything on my network served/configured hopefully by FR/mysql and routed by pfSense).
Hmm... that might work. I've had issues with virtual switches, tho. Alan DeKok.
Thanks Alan. So given you've established I'm on Linux I'm sure I'm trying to set up a fairly vanilla configuration from that perspective: Freeradius with mysql and DHCP? Surely there are many, many others who have this successfully working. My network configuration looks like this: ESXi Freeradius on Linux VM <- ESXi pfSense VM -> Unifi switch on pfSense LAN -> Unifi AP -> Client test device At the stage of failure to write the ARP entry, the device has requested an IP via DHCP. It's passed successfully down the chain to FR but for whatever reason hits a branch of dhcpd.c where something is wrong and it fails. It seems when I try to mess directly with arp from the command line it's difficult to trigger "operation not permitted" besides trying to interact with it with insufficient privileges. But I'm wondering if it is possible that some of the parameters passed to fr_dhcp_add_arp_entry are incorrect in such a way as to trigger a permission error? The end goal for me is to have: (i) client devices receive IP addresses from a server (ii) be EAP authorised from a server (iii) be assigned a VLAN (or some other way to be able to easily filter groups of devices through firewall rules/schedules in pfSense or otherwise). It seems FR does all I need in theory, I'm just struggling to set it up correctly. I can get the server working with (ii) no problem. I can get it assigning attributes such that (iii) should work, although pfSense is not receiving the tagged attributes despite the Unifi stuff configured to pass it on. With your help I got (i) and (ii) to both serve at the same time through two sql modules. Now I'm just trying to get (i) to succeed, then I can work on (iii). If (iii) doesn't work I can try another approach, which is set up multiple wlan networks on the Unifi and filter/schedule through those and use FR to authorise access to specific ssids only for certain clients. The big question I guess is your comment about virtual switches - maybe that actually is causing me problems with (i). But given my complete lack of networking knowledge I would not at all be surprised that I've just configured my DHCP server incorrectly (source IP, router address, server address, subnet mask, whatever). Toby On 6 November 2016 at 21:52, Alan DeKok <aland@deployingradius.com> wrote:
On Nov 6, 2016, at 8:47 AM, Toby Walsh <walshtj@gmail.com> wrote:
They're communicating through a virtual switch, so I want them on the same subnet but different hosts/IPs (with everything on my network served/configured hopefully by FR/mysql and routed by pfSense).
Hmm... that might work. I've had issues with virtual switches, tho.
On Nov 6, 2016, at 6:26 PM, Toby Walsh <walshtj@gmail.com> wrote:
Thanks Alan.
So given you've established I'm on Linux I'm sure I'm trying to set up a fairly vanilla configuration from that perspective: Freeradius with mysql and DHCP? Surely there are many, many others who have this successfully working. My network configuration looks like this:
It should work. Many others use it.
At the stage of failure to write the ARP entry, the device has requested an IP via DHCP. It's passed successfully down the chain to FR but for whatever reason hits a branch of dhcpd.c where something is wrong and it fails.
To be clear: FreeRADIUS asks for the ARP table to be updated, and the OS returns "no". The solution is to fix the OS so that it believes FreeRADIUS has the permission to make this change.
It seems when I try to mess directly with arp from the command line it's difficult to trigger "operation not permitted" besides trying to interact with it with insufficient privileges. But I'm wondering if it is possible that some of the parameters passed to fr_dhcp_add_arp_entry are incorrect in such a way as to trigger a permission error?
Maybe. It's unlikely, unless the Linux people changed the way their AP works.
It seems FR does all I need in theory, I'm just struggling to set it up correctly.
You're struggling to convince the OS to let FreeRADIUS do it's work. FreeRADIUS itself is working fine. When you're driving a car, you don't try to fix the gas gauge when it reads "empty". You put gas in the tank. i.e. the error from FreeRADIUS is a side effect. The real problem is the OS.
The big question I guess is your comment about virtual switches - maybe that actually is causing me problems with (i). But given my complete lack of networking knowledge I would not at all be surprised that I've just configured my DHCP server incorrectly (source IP, router address, server address, subnet mask, whatever).
Virtual switches are fine for sending normal traffic between VMs or containers. Doing anything more complex is likely to not work. Alan DeKok.
To any others who come across the same problem, I found the solution buried in an old thread: my radiusd.conf had: user = freerad group = freerad I have no idea if I set this or it was the default. I tried setting it to "radius", that also didn't work. The old thread had it set to "nobody", I'm not sure if I tried that. If I commented it out, the ARP table is successfully updated. On 7 November 2016 at 08:40, Alan DeKok <aland@deployingradius.com> wrote:
To be clear: FreeRADIUS asks for the ARP table to be updated, and the OS returns "no".
The solution is to fix the OS so that it believes FreeRADIUS has the permission to make this change.
Hi,
To any others who come across the same problem, I found the solution buried in an old thread: my radiusd.conf had:
user = freerad group = freerad
I have no idea if I set this or it was the default. I tried setting it to "radius", that also didn't work. The old thread had it set to "nobody", I'm not sure if I tried that. If I commented it out, the ARP table is successfully updated.
if its commented out then the process runs as root alan
Noted, thanks. Instead I uncommented the user and group 'freerad' and modified the /etc/sudoers file to give 'freerad' permission to run /usr/sbin/arp. Hopefully that's an acceptable solution. It seems to work although I still get ARP failures (and then successes, in the same DHCP handshake). On Mon, 7 Nov 2016 at 16:30 <A.L.M.Buxey@lboro.ac.uk> wrote:
To any others who come across the same problem, I found the solution buried in an old thread: my radiusd.conf had:
user = freerad group = freerad
if its commented out then the process runs as root
alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Toby Walsh