Multiple access-request + access-accept packets in one conversation.
Hi Freeradius Users, I will appreciate some help here. We are running FR3.0.11 + ldap + 802.1x peap + gtc. When client tries to get on the network for the first time, everything is good. Server issues cert, client accepts, vlan id is attached to access-accept packet, and client gets an ip. The whole exchange is fast and only consists of 8 request packets. http://pastebin.com/P35eNW4C However , when client tries to re-authenticate -- communication between client and a server grows to 100 + request packets while server responds with multiple access-accept packets and none of them contain Tunnel-Id ( not cached ?) http://pastebin.com/y1HGF4PP When i disable cache subsection of eap module, and client tries to re-authenticate, i also get a very long conversation (100+ requests ) involving multiple access-request and access-accept messages, however access-accept messages return with Tunnel-id attribute. Can someone point me in the right direction as to why communication is so long and involves multiple access-accept packets when client tries to re-authenticate and what needs to be done with cache so it works properly and caches Tunnel-Id. Thanks
On Jun 1, 2016, at 3:27 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
I will appreciate some help here. We are running FR3.0.11 + ldap + 802.1x peap + gtc.
When client tries to get on the network for the first time, everything is good. Server issues cert, client accepts, vlan id is attached to access-accept packet, and client gets an ip. The whole exchange is fast and only consists of 8 request packets.
OK...
However , when client tries to re-authenticate -- communication between client and a server grows to 100 + request packets while server responds with multiple access-accept packets and none of them contain Tunnel-Id ( not cached ?)
It's not cached unless you configure the "persist_dir". See the eap module configuration for more information. Just set "persist_dir", and the attributes in the Access-Accept should be cached. The caching has been re-done in v3.1, so that it's a lot cleaner and easier to understand. It's just too hard to fix v3.0 at this point. Alan DeKok.
Hi Alan, Thanks for response. Below are mine cache configurations and i actually see .vps and .asn1 entries created in /var/log/radius/tlscache/. cache enable = yes max_entries = 255 name = "EAP module" persist_dir = "${logdir}/tlscache" } .vps files only contain User-Name attribute. So is this a know issue where 3.0.X doesn't cache all atributes ? Is this related to the fact that conversation between client and server becoming too long during renegotiation ? On Wed, Jun 1, 2016 at 4:11 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 1, 2016, at 3:27 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
I will appreciate some help here. We are running FR3.0.11 + ldap + 802.1x peap + gtc.
When client tries to get on the network for the first time, everything is good. Server issues cert, client accepts, vlan id is attached to access-accept packet, and client gets an ip. The whole exchange is fast and only consists of 8 request packets.
OK...
However , when client tries to re-authenticate -- communication between client and a server grows to 100 + request packets while server responds with multiple access-accept packets and none of them contain Tunnel-Id ( not cached ?)
It's not cached unless you configure the "persist_dir". See the eap module configuration for more information.
Just set "persist_dir", and the attributes in the Access-Accept should be cached.
The caching has been re-done in v3.1, so that it's a lot cleaner and easier to understand. It's just too hard to fix v3.0 at this point.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 1, 2016, at 4:23 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Thanks for response. Below are mine cache configurations and i actually see .vps and .asn1 entries created in /var/log/radius/tlscache/.
The debug log you posted shows that "persist_dir" wasn't configured, and that it wasn't caching entries.
cache enable = yes max_entries = 255 name = "EAP module" persist_dir = "${logdir}/tlscache" }
.vps files only contain User-Name attribute.
So is this a know issue where 3.0.X doesn't cache all atributes ?
Yes. You will need to set Cached-Session-Policy in the original reply. It will then be copied to the reply of the resumed session. You can use key off of that to figure out which reply attributes to send back. It's not perfect, by any means. To be honest, you might just try upgrading to v3.1.x from github. The caching is a *lot* cleaner there.
Is this related to the fact that conversation between client and server becoming too long during renegotiation ?
No. The re-negotiation isn't long. It jus re-negotiates over and over and over. Alan DeKok.
Thanks, I will try upgrading to version 3.1. Could the certificate be the reason for re-negotiation over and over again ? On Wed, Jun 1, 2016 at 4:34 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 1, 2016, at 4:23 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Thanks for response. Below are mine cache configurations and i actually see .vps and .asn1 entries created in /var/log/radius/tlscache/.
The debug log you posted shows that "persist_dir" wasn't configured, and that it wasn't caching entries.
cache enable = yes max_entries = 255 name = "EAP module" persist_dir = "${logdir}/tlscache" }
.vps files only contain User-Name attribute.
So is this a know issue where 3.0.X doesn't cache all atributes ?
Yes.
You will need to set Cached-Session-Policy in the original reply.
It will then be copied to the reply of the resumed session. You can use key off of that to figure out which reply attributes to send back.
It's not perfect, by any means.
To be honest, you might just try upgrading to v3.1.x from github. The caching is a *lot* cleaner there.
Is this related to the fact that conversation between client and server becoming too long during renegotiation ?
No. The re-negotiation isn't long. It jus re-negotiates over and over and over.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 1, 2016, at 4:54 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Thanks,
I will try upgrading to version 3.1.
Could the certificate be the reason for re-negotiation over and over again ?
No. If there were certificate problems, it would complain about certificate problems. Alan DeKok.
From the debugs that i posted earlier, does anything stand out to you as to why negotiation keeps looping?
Thanks Sent from my iPhone
On Jun 1, 2016, at 7:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 1, 2016, at 4:54 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Thanks,
I will try upgrading to version 3.1.
Could the certificate be the reason for re-negotiation over and over again ?
No. If there were certificate problems, it would complain about certificate problems.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hey Alan, After doing some packet captures, it turned out that our juniper switch kept initiating access-request packets causing endless loop. We used other juniper switch with a different software version. Everything worked well. Thanks again for pointing us in a right direction. On Wed, Jun 1, 2016 at 7:44 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
From the debugs that i posted earlier, does anything stand out to you as to why negotiation keeps looping?
Thanks
Sent from my iPhone
On Jun 1, 2016, at 7:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 1, 2016, at 4:54 PM, Vlad Kratsberg <vkratsberg@gmail.com> wrote:
Thanks,
I will try upgrading to version 3.1.
Could the certificate be the reason for re-negotiation over and over again ?
No. If there were certificate problems, it would complain about certificate problems.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (2)
-
Alan DeKok -
Vlad Kratsberg