In keeping with the recent addition of the freeradius-client library, I think we should rename the libraries in the server, too: libradius -> libfreeradius-radius libeap -> libfreeradius-eap The directory names can stay the same, but the names of the targets can change. Objections? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi, Just had a thought. Currently with internal EAP proxying copy_request_to_tunnel = yes use_tunneled_reply = yes Mean that when the contents of the eap packet is proxied internally the attributes from the radius packet get copied to the proxy request. And that the final set of reply attributes is taken directly from the reply attributes sent back from the internal proxy. Which means you can use DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Autz-Type := "Eap-Internal" Autz-Type eap-internal { mschap # Grab NT-Password from directory for use in MSChap-V2 ldap # Read Authorisation groups from SQL Server sql } Which speeds things up a great deal when doing EAP... Unfortunately this breaks anything which relies on Packet-Src-IP-Address / Client-IP-Address As they will be 127.0.0.1 *sigh* Can you see any way of getting round this ? Need Client-IP-Address to determine which set of proxies the request is coming in form... -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote: ...
Autz-Type eap-internal { mschap # Grab NT-Password from directory for use in MSChap-V2 ldap # Read Authorisation groups from SQL Server sql }
Which speeds things up a great deal when doing EAP...
In the CVS head, I'm looking into adding a "tunnel is ready for credentials" flag inside of the EAP module. It will normally return "updated" during ssl setup, and "ok" when the current packet needs authentication credentials.
Unfortunately this breaks anything which relies on Packet-Src-IP-Address / Client-IP-Address
As they will be 127.0.0.1 *sigh*
Can you see any way of getting round this ?
Hmm.... src/main/util.c has request_alloc_fake(), which initializes the tunneled request. It may be worth changing it to copy the outer tunnel source/dest IP's and ports. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hmm.... src/main/util.c has request_alloc_fake(), which initializes the tunneled request. It may be worth changing it to copy the outer tunnel source/dest IP's and ports.
So @@ -385,8 +385,8 @@ */ request->packet->sockfd = -1; request->packet->src_ipaddr.af = AF_INET; - request->packet->src_ipaddr.ipaddr.ip4addr.s_addr = htonl(INADDR_LOOPBACK); - request->packet->dst_ipaddr = request->packet->src_ipaddr; + request->packet->src_ipaddr.ipaddr.ip4addr.s_addr = oldreq->packet->src_ipaddr.ipaddr.ip4addr.s_addr + request->packet->dst_ipaddr = htonl(INADDR_LOOPBACK);; request->packet->src_port = request->number >> 8; /* @@ -408,7 +408,7 @@ * Fill in the fake reply, based on the fake request. */ request->reply->sockfd = request->packet->sockfd; - request->reply->dst_ipaddr = request->packet->src_ipaddr; + request->reply->dst_ipaddr = request->packet->dst_ipaddr; request->reply->dst_port = request->packet->src_port; request->reply->id = request->packet->id; request->reply->code = 0; /* UNKNOWN code */ ? Would it be worth making this change in the cvs head ? -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote: ...
So
@@ -385,8 +385,8 @@ ... ?
Something like that, yes.
Would it be worth making this change in the cvs head ?
Very likely. I'll see what I can do. Oh, the EAP module now returns "ok" in the authorize section for the TLS methods, and "updated" or "noop" otherwise. This allows the outer tunnel sessions to avoid all of the nasty DB accesses for the TLS setup packets. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Would it be worth making this change in the cvs head ?
Very likely. I'll see what I can do.
Excellent, thanks.
Oh, the EAP module now returns "ok" in the authorize section for the TLS methods, and "updated" or "noop" otherwise. This allows the outer tunnel sessions to avoid all of the nasty DB accesses for the TLS setup packets.
<g> It makes EAP authentication insanely fast. This will probably be the thing that gives people the biggest speed boost upgrading *** > 2.0.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On May 2, 2007 10:48:34 AM +0200 Alan DeKok <aland@deployingradius.com> wrote:
In keeping with the recent addition of the freeradius-client library, I think we should rename the libraries in the server, too:
libradius -> libfreeradius-radius libeap -> libfreeradius-eap
The directory names can stay the same, but the names of the targets can change.
Objections?
I like the current names. -frank
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Frank Cusack