Dropping RADIUS accounting packets based upon NAS IP Address
Hi, UoY provides eduroam availability at a number of NHS sites in the area who all use Cisco wireless controllers. I was just testing our new Grimsby connection ( remote controller pushes auth and accounting packets down a RADSEC tunnel to our Tier 1 eduroam servers) when I noticed that in addition to accounting packets relating to the eduroam SSID I was seeing accounting packets from other devices which had different NAS-IP-Address IP addresses to the one I was expecting. I know its their problem to fix but is there any way in FR 3.0.15 I can drop packets with a NAS IP Address != the one I should be seeing? We dump accounting / auth info into a postgres db and into our logstash service and I'd rather not have accounting info I shouldn't be seeing in there ... Rgds Alex
On Jan 5, 2018, at 9:30 AM, Alex Sharaz via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I was just testing our new Grimsby connection ( remote controller pushes auth and accounting packets down a RADSEC tunnel to our Tier 1 eduroam servers) when I noticed that in addition to accounting packets relating to the eduroam SSID I was seeing accounting packets from other devices which had different NAS-IP-Address IP addresses to the one I was expecting.
I know its their problem to fix but is there any way in FR 3.0.15 I can drop packets with a NAS IP Address != the one I should be seeing?
That's generally not a good idea. The NAS will not see responses from the RADIUS server, and think that the RADIUS is down.
We dump accounting / auth info into a postgres db and into our logstash service and I'd rather not have accounting info I shouldn't be seeing in there ...
preacct { if (NAS-IP-Address != "good") { ok return } ... everything else ... } And then do the same at the top of the "accounting" section. This will cause the server to ACK the bad accounting packets. But no further processing will take place. Alan DeKok.
Cool! Many thanks A On 5 January 2018 at 15:39, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 5, 2018, at 9:30 AM, Alex Sharaz via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
I was just testing our new Grimsby connection ( remote controller pushes auth and accounting packets down a RADSEC tunnel to our Tier 1 eduroam servers) when I noticed that in addition to accounting packets relating to the eduroam SSID I was seeing accounting packets from other devices which had different NAS-IP-Address IP addresses to the one I was expecting.
I know its their problem to fix but is there any way in FR 3.0.15 I can drop packets with a NAS IP Address != the one I should be seeing?
That's generally not a good idea. The NAS will not see responses from the RADIUS server, and think that the RADIUS is down.
We dump accounting / auth info into a postgres db and into our logstash service and I'd rather not have accounting info I shouldn't be seeing in there ...
preacct { if (NAS-IP-Address != "good") { ok return }
... everything else ...
}
And then do the same at the top of the "accounting" section. This will cause the server to ACK the bad accounting packets. But no further processing will take place.
Alan DeKok.
Many thanks, worked a treat A On 5 January 2018 at 16:19, Alex Sharaz <alex.sharaz@york.ac.uk> wrote:
Cool!
Many thanks A
On 5 January 2018 at 15:39, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 5, 2018, at 9:30 AM, Alex Sharaz via Freeradius-Users < freeradius-users@lists.freeradius.org> wrote:
I was just testing our new Grimsby connection ( remote controller pushes auth and accounting packets down a RADSEC tunnel to our Tier 1 eduroam servers) when I noticed that in addition to accounting packets relating to the eduroam SSID I was seeing accounting packets from other devices which had different NAS-IP-Address IP addresses to the one I was expecting.
I know its their problem to fix but is there any way in FR 3.0.15 I can drop packets with a NAS IP Address != the one I should be seeing?
That's generally not a good idea. The NAS will not see responses from the RADIUS server, and think that the RADIUS is down.
We dump accounting / auth info into a postgres db and into our logstash service and I'd rather not have accounting info I shouldn't be seeing in there ...
preacct { if (NAS-IP-Address != "good") { ok return }
... everything else ...
}
And then do the same at the top of the "accounting" section. This will cause the server to ACK the bad accounting packets. But no further processing will take place.
Alan DeKok.
participants (2)
-
Alan DeKok -
Alex Sharaz