Inner tunnel external proxy fails under stress due to zero vectors

Brian Julin BJulin at clarku.edu
Tue Dec 20 05:06:44 CET 2011


Greetings,

While testing a setup that uses inner tunnel proxying I was
noticing that there were spurious failures if the setup was
stress tested.

I managed to eliminate back-end latency as a possible cause
by testing instead to a simple auth against rlm_passwd (with
NTLM crypts.)  I also tried with both servers running recent
3.0 repo code, so it's a problem that has likely been there at
least from 2.1.10.

After a long dig through the debugs, finally I noticed from
a packet dump that packets with 0x00 vectors were hitting
the wire, and when IDs were recycled that of course results
in false "duplicates" (as well as the other crypto-related
issues with that.)

The packets with the 0x00 vectors were the inner-tunneled
packets emitted from the proxying server.  If I understand things
right, these packets are generated by the EAP modules allocating
a fake request, which is passed back through as if the server
were handling the inner tunnel itself, and then when the proxy
codepath is taken, this "fake" packet is then recycled as the outgoing
request to the home server.

Looking through the source we have this warning in
request_alloc_fake src/main/utils.c:

  /*
   *    This isn't STRICTLY required, as the fake request MUST NEVER
   *    be put into the request list.  However, it's still reasonable
   *    practice.
   */

...however this seems to be just what is happening.  In fact, if
above that I change:

diff --git a/src/main/util.c b/src/main/util.c
index 94ee443..e6a1a26 100644
--- a/src/main/util.c
+++ b/src/main/util.c
@@ -437,7 +437,7 @@ REQUEST *request_alloc_fake(REQUEST *request)
    */
   fake->server = request->server;
 
-  fake->packet = rad_alloc(0);
+  fake->packet = rad_alloc(1);
   if (!fake->packet) {
          request_free(&fake);
          return NULL;

...then the setup passes stress testing just fine.

Trouble is I'm not sure if there are ramifications to doing that...





More information about the Freeradius-Users mailing list