Proxied Access-Challenge requests are missing AVPs
Hi list, I have a FreeRADIUS 3.0.3 proxy which forward all Cisco WAPs Wireless-802.11 authentication requests to a Windows NPS server. Clients use PEAP to authenticate. What I'm seeing is that the Access-Challenge from the NPS is forwarded without any AVPs, and of course the WAP silently drops it. Please find below the debug output and the relevant configuration files attached. Couldn't find really anything helpful in the ML archive. Could you please give me any suggestion of what could be wrong? Please let me know if further information is needed. Thank you in advance for your kind assistance. - leonardo Received Access-Request Id 111 from 10.97.6.140:1645 to 10.97.63.5:1812 length 216 User-Name = 'mbianchi' Framed-MTU = 1400 Called-Station-Id = 'DC-A5-F4-FE-BE-71:WRES-DEV' Calling-Station-Id = 'ac22.0ba5.9688' Cisco-AVPair = 'ssid=WRES-DEV' Service-Type = Login-User Cisco-AVPair = 'service-type=Login' Message-Authenticator = 0x98e4b1c896994939e0de6e25c17b96a0 EAP-Message = 0x0201000b016c6172656e61 NAS-Port-Type = Wireless-802.11 Cisco-NAS-Port = '374' NAS-Port = 374 NAS-Port-Id = '374' NAS-IP-Address = 10.97.6.140 NAS-Identifier = 'dev-rto004-r1-ap-1' (1) # Executing section authorize from file /etc/raddb/sites-enabled/default-bsn (1) authorize { (1) [preprocess] = ok (1) linelog_auth : EXPAND /var/log/radius/linelog_auth.log (1) linelog_auth : --> /var/log/radius/linelog_auth.log (1) linelog_auth : EXPAND %S, %{User-Name}, %{NAS-Identifier}(%{NAS-IP-Address}):%{NAS-Port-Id}, Calling-Station-Id: %{Calling-Station-Id}, Packet-Type: %{Packet-Type}, Service-Type: %{Service-Type} (1) linelog_auth : --> 2015-09-10 13:44:55, mbianchi, dev-rto004-r1-ap-1(10.97.6.140):374, Calling-Station-Id: ac22.0ba5.9688, Packet-Type: Access-Request, Service-Type: Login-User (1) [linelog_auth] = ok (1) suffix : No '@' in User-Name = "mbianchi", looking up realm NULL (1) suffix : No such realm "NULL" (1) [suffix] = noop (1) if (!updated) (1) if (!updated) -> TRUE (1) if (!updated) { (1) if (NAS-Port-Type == Wireless-802.11) (1) if (NAS-Port-Type == Wireless-802.11) -> TRUE (1) if (NAS-Port-Type == Wireless-802.11) { (1) update control { (1) &Proxy-To-Realm := 'my.domain.org' (1) } # update control = noop (1) } # if (NAS-Port-Type == Wireless-802.11) = noop (1) ... skipping else for request 1: Preceding "if" was taken (1) } # if (!updated) = noop (1) } # authorize = ok (1) Proxying request to home server 10.44.16.110 port 1812 Sending Access-Request Id 226 from 0.0.0.0:46821 to 10.44.16.110:1812 User-Name = 'mbianchi' Framed-MTU = 1400 Called-Station-Id = 'DC-A5-F4-FE-BE-71:WRES-DEV' Calling-Station-Id = 'ac22.0ba5.9688' Cisco-AVPair = 'ssid=WRES-DEV' Service-Type = Login-User Cisco-AVPair = 'service-type=Login' Message-Authenticator = 0x98e4b1c896994939e0de6e25c17b96a0 EAP-Message = 0x0201000b016c6172656e61 NAS-Port-Type = Wireless-802.11 Cisco-NAS-Port = '374' NAS-Port = 374 NAS-Port-Id = '374' NAS-IP-Address = 10.97.6.140 NAS-Identifier = 'dev-rto004-r1-ap-1' Proxy-State = 0x313131 Waking up in 0.3 seconds. Waking up in 0.4 seconds. Received Access-Challenge Id 226 from 10.44.16.110:1812 to 10.97.63.5:46821 length 95 Proxy-State = 0x313131 Session-Timeout = 30 EAP-Message = 0x010200061920 State = 0x1c5503ba00000137000102000a2c106e0000000000000000000000000000000c6d95d8e4 Message-Authenticator = 0xe5ba33c9fca2c5534a4e1302650ae8ca Sending Access-Challenge Id 111 from 10.97.63.5:1812 to 10.97.6.140:1645 (1) Finished request Waking up in 0.3 seconds. Waking up in 3.0 seconds. (0) Cleaning up request packet ID 110 with timestamp +12 Waking up in 1.6 seconds.
What I'm seeing is that the Access->Challenge from the NPS is forwarded without any AVPs, and of course the >WAP silently drops it.
? there shouldnt be many AVPs in an access challenge anyway. Your FR should be configured to strip such things out too. Do you need to use NPS anyway? Maybe incorrect shared secret between the FR and NPS? Alan
On 10 Sep 2015, at 18:46, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
What I'm seeing is that the Access->Challenge from the NPS is forwarded without any AVPs, and of course the >WAP silently drops it.
? there shouldnt be many AVPs in an access challenge anyway. Your FR should be configured to strip such things out too.
Well the only weird one is Session-Timeout. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On gio, 2015-09-10 at 18:46 +0100, Alan Buxey wrote:
What I'm seeing is that the Access->Challenge from the NPS is forwarded without any AVPs, and of course the >WAP silently drops it.
? there shouldnt be many AVPs in an access challenge anyway. Your FR should be configured to strip such things out too.
Do you need to use NPS anyway? Maybe incorrect shared secret between the FR and NPS?
Alan
Unfortunately NPS is requirement. Double checked that shared is correct.
On 10 Sep 2015, at 15:57, Leonardo Arena <rnalrd@gmail.com> wrote:
Hi list,
I have a FreeRADIUS 3.0.3 proxy which forward all Cisco WAPs Wireless-802.11 authentication requests to a Windows NPS server. Clients use PEAP to authenticate.
What I'm seeing is that the Access-Challenge from the NPS is forwarded without any AVPs, and of course the WAP silently drops it.
Please find below the debug output and the relevant configuration files attached.
Couldn't find really anything helpful in the ML archive.
Could you please give me any suggestion of what could be wrong?
Weird, unless you list a filter module in post-proxy the response should be forwarded. You're using a very out of date version of v3.0.x though, try 3.0.9 and see if you still see the same issue. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On gio, 2015-09-10 at 18:47 +0100, Arran Cudbard-Bell wrote:
On 10 Sep 2015, at 15:57, Leonardo Arena <rnalrd@gmail.com> wrote:
Hi list,
I have a FreeRADIUS 3.0.3 proxy which forward all Cisco WAPs Wireless-802.11 authentication requests to a Windows NPS server. Clients use PEAP to authenticate.
What I'm seeing is that the Access-Challenge from the NPS is forwarded without any AVPs, and of course the WAP silently drops it.
Please find below the debug output and the relevant configuration files attached.
Couldn't find really anything helpful in the ML archive.
Could you please give me any suggestion of what could be wrong?
Weird, unless you list a filter module in post-proxy the response should be forwarded. You're using a very out of date version of v3.0.x though, try 3.0.9 and see if you still see the same issue.
I'm using default attr-filter module (see below) and AFAICS it's used only by inner-tunnel, and I don't have any post-proxy file. I'll give a shot with 3.0.9 although with 3.0.4 clients.conf changed syntax IIRC and that's why we stick with 3.0.3. Upgrading clients.conf in 200+ installations does not look an attractive option. :) Thanks! - leo /etc/raddb/mods-enabled# cat attr_filter # -*- text -*- # # $Id: 1caff077b2429c948a04777fcd619be901ac83dc $ # # This file defines a number of instances of the "attr_filter" module. # # attr_filter - filters the attributes received in replies from # proxied servers, to make sure we send back to our RADIUS client # only allowed attributes. attr_filter attr_filter.post-proxy { key = "%{Realm}" filename = ${modconfdir}/${.:name}/post-proxy } # attr_filter - filters the attributes in the packets we send to # the RADIUS home servers. attr_filter attr_filter.pre-proxy { key = "%{Realm}" filename = ${modconfdir}/${.:name}/pre-proxy } # Enforce RFC requirements on the contents of Access-Reject # packets. See the comments at the top of the file for # more details. # attr_filter attr_filter.access_reject { key = "%{User-Name}" filename = ${modconfdir}/${.:name}/access_reject } # Enforce RFC requirements on the contents of Access-Challenge # packets. See the comments at the top of the file for # more details. # attr_filter attr_filter.access_challenge { key = "%{User-Name}" filename = ${modconfdir}/${.:name}/access_challenge } # Enforce RFC requirements on the contents of the # Accounting-Response packets. See the comments at the # top of the file for more details. # attr_filter attr_filter.accounting_response { key = "%{User-Name}" filename = ${modconfdir}/${.:name}/accounting_response }
On 11 Sep 2015, at 09:20, Leonardo Arena <rnalrd@gmail.com> wrote:
On gio, 2015-09-10 at 18:47 +0100, Arran Cudbard-Bell wrote:
On 10 Sep 2015, at 15:57, Leonardo Arena <rnalrd@gmail.com> wrote:
Hi list,
I have a FreeRADIUS 3.0.3 proxy which forward all Cisco WAPs Wireless-802.11 authentication requests to a Windows NPS server. Clients use PEAP to authenticate.
What I'm seeing is that the Access-Challenge from the NPS is forwarded without any AVPs, and of course the WAP silently drops it.
Please find below the debug output and the relevant configuration files attached.
Couldn't find really anything helpful in the ML archive.
Could you please give me any suggestion of what could be wrong?
Weird, unless you list a filter module in post-proxy the response should be forwarded. You're using a very out of date version of v3.0.x though, try 3.0.9 and see if you still see the same issue.
I'm using default attr-filter module (see below) and AFAICS it's used only by inner-tunnel, and I don't have any post-proxy file.
I'll give a shot with 3.0.9 although with 3.0.4 clients.conf changed syntax IIRC and that's why we stick with 3.0.3. Upgrading clients.conf in 200+ installations does not look an attractive option. :)
clients.conf from 3.0.3 should be compatible with 3.0.9. It'll just issue a few warnings. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On ven, 2015-09-11 at 11:19 +0100, Arran Cudbard-Bell wrote:
On 11 Sep 2015, at 09:20, Leonardo Arena <rnalrd@gmail.com> wrote:
On gio, 2015-09-10 at 18:47 +0100, Arran Cudbard-Bell wrote:
On 10 Sep 2015, at 15:57, Leonardo Arena <rnalrd@gmail.com> wrote:
Hi list,
I have a FreeRADIUS 3.0.3 proxy which forward all Cisco WAPs Wireless-802.11 authentication requests to a Windows NPS server. Clients use PEAP to authenticate.
What I'm seeing is that the Access-Challenge from the NPS is forwarded without any AVPs, and of course the WAP silently drops it.
Please find below the debug output and the relevant configuration files attached.
Couldn't find really anything helpful in the ML archive.
Could you please give me any suggestion of what could be wrong?
Weird, unless you list a filter module in post-proxy the response should be forwarded. You're using a very out of date version of v3.0.x though, try 3.0.9 and see if you still see the same issue.
I'm using default attr-filter module (see below) and AFAICS it's used only by inner-tunnel, and I don't have any post-proxy file.
I'll give a shot with 3.0.9 although with 3.0.4 clients.conf changed syntax IIRC and that's why we stick with 3.0.3. Upgrading clients.conf in 200+ installations does not look an attractive option. :)
clients.conf from 3.0.3 should be compatible with 3.0.9. It'll just issue a few warnings.
Unfortunately this does not seem to be case: /etc/raddb# rc-service radiusd start * Caching service dependencies ... [ ok ] * /var/run/radiusd: correcting mode * /var/run/radiusd: correcting owner * Starting Freeradius ... * start-stop-daemon: failed to start `/usr/sbin/radiusd' * Failed to start radiusd [ !! ] * ERROR: radiusd failed to start /etc/raddb# radiusd -X [...] /etc/raddb/clients.conf[1]: No 'ipaddr' or 'ipv4addr' or 'ipv6addr' configuration directive found in client 127.0.0.1/8 Am I missing anything? - leo
Unfortunately this does not seem to be case:
Hm, this shouldn't have been removed until v3.1.0. I've added it back. You can use v3.0.x HEAD if you want to continue using old style clients, but it might be better to fixup your clients.conf file. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On ven, 2015-09-11 at 13:12 +0100, Arran Cudbard-Bell wrote:
Unfortunately this does not seem to be case:
Hm, this shouldn't have been removed until v3.1.0. I've added it back. You can use v3.0.x HEAD if you want to continue using old style clients, but it might be better to fixup your clients.conf file.
Thank you! I'm importing the GIT patch into the package. Also 3.0.9 fixed my issue. Thanks! - leo
On ven, 2015-09-11 at 14:28 +0200, Leonardo Arena wrote:
On ven, 2015-09-11 at 13:12 +0100, Arran Cudbard-Bell wrote:
Unfortunately this does not seem to be case:
Hm, this shouldn't have been removed until v3.1.0. I've added it back. You can use v3.0.x HEAD if you want to continue using old style clients, but it might be better to fixup your clients.conf file.
Thank you! I'm importing the GIT patch into the package. Also 3.0.9 fixed my issue.
Thanks!
- leo
hum, seems the patch does not compile: src/main/client.c: In function 'client_afrom_cs': src/main/client.c:968:3: error: too many arguments to function 'fr_pton' if (fr_pton(&c->ipaddr, name2, 0, true, true) < 0) { ^ In file included from /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/radiusd.h:29:0, from src/main/client.c:29: /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/libradius.h:709:6: note: declared here int fr_pton(fr_ipaddr_t *out, char const *value, ssize_t inlen, bool resolve); ^ scripts/boiler.mk:630: recipe for target 'build/objs/src/main/client.lo' failed make: *** [build/objs/src/main/client.lo] Error 1 Not really my field here. Seems that fr_pton expects 4 arguments, but may be I read it wrong, given my very poor C knowledge. Thanks! - leo
hum, seems the patch does not compile:
src/main/client.c: In function 'client_afrom_cs': src/main/client.c:968:3: error: too many arguments to function 'fr_pton' if (fr_pton(&c->ipaddr, name2, 0, true, true) < 0) { ^ In file included from /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/radiusd.h:29:0, from src/main/client.c:29: /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/libradius.h:709:6: note: declared here int fr_pton(fr_ipaddr_t *out, char const *value, ssize_t inlen, bool resolve); ^ scripts/boiler.mk:630: recipe for target 'build/objs/src/main/client.lo' failed make: *** [build/objs/src/main/client.lo] Error 1
Not really my field here. Seems that fr_pton expects 4 arguments, but may be I read it wrong, given my very poor C knowledge.
Works fine for me.. and the build system. https://travis-ci.org/FreeRADIUS/freeradius-server/builds/79835362 Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On ven, 2015-09-11 at 13:52 +0100, Arran Cudbard-Bell wrote:
hum, seems the patch does not compile:
src/main/client.c: In function 'client_afrom_cs': src/main/client.c:968:3: error: too many arguments to function 'fr_pton' if (fr_pton(&c->ipaddr, name2, 0, true, true) < 0) { ^ In file included from /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/radiusd.h:29:0, from src/main/client.c:29: /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/libradius.h:709:6: note: declared here int fr_pton(fr_ipaddr_t *out, char const *value, ssize_t inlen, bool resolve); ^ scripts/boiler.mk:630: recipe for target 'build/objs/src/main/client.lo' failed make: *** [build/objs/src/main/client.lo] Error 1
Not really my field here. Seems that fr_pton expects 4 arguments, but may be I read it wrong, given my very poor C knowledge.
Works fine for me.. and the build system.
https://travis-ci.org/FreeRADIUS/freeradius-server/builds/79835362
Thank you. I can confirm that builds against HEAD also for me. I look forward to 3.0.10 release. :) - leo
On 11 Sep 2015, at 14:21, Leonardo Arena <rnalrd@gmail.com> wrote:
On ven, 2015-09-11 at 13:52 +0100, Arran Cudbard-Bell wrote:
hum, seems the patch does not compile:
src/main/client.c: In function 'client_afrom_cs': src/main/client.c:968:3: error: too many arguments to function 'fr_pton' if (fr_pton(&c->ipaddr, name2, 0, true, true) < 0) { ^ In file included from /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/radiusd.h:29:0, from src/main/client.c:29: /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/libradius.h:709:6: note: declared here int fr_pton(fr_ipaddr_t *out, char const *value, ssize_t inlen, bool resolve); ^ scripts/boiler.mk:630: recipe for target 'build/objs/src/main/client.lo' failed make: *** [build/objs/src/main/client.lo] Error 1
Not really my field here. Seems that fr_pton expects 4 arguments, but may be I read it wrong, given my very poor C knowledge.
Works fine for me.. and the build system.
https://travis-ci.org/FreeRADIUS/freeradius-server/builds/79835362
Thank you. I can confirm that builds against HEAD also for me. I look forward to 3.0.10 release. :)
Alan D was making noises about it being today. But i'm guessing that depends on workload. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sep 11, 2015, at 8:44 AM, Leonardo Arena <rnalrd@gmail.com> wrote: ...
In file included from /home/larena/aports-2.7-stable/main/freeradius3/src/freeradius-server-3.0.9/src/freeradius-devel/radiusd.h:29:0, from src/main/client.c:29:
Please use v3.0.x from git. Do NOT apply random patches to older versions of the server. We're releasing 3.0.10 soon, which will be based on the v3.0.x branch from git. Alan DeKok.
On Sep 11, 2015, at 4:20 AM, Leonardo Arena <rnalrd@gmail.com> wrote:
I'm using default attr-filter module (see below) and AFAICS it's used only by inner-tunnel, and I don't have any post-proxy file.
I suggest using the v3.0.x branch from git. It will become 3.0.10 very soon. There is NO situation where the server will remove all attributes from a proxied Access-Challenge. If it happens in 3.0.3, it's a bug. Which apparently has since been fixed. Alan DeKok.
participants (4)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Leonardo Arena