On Fri, Sep 4, 2015 at 2:38 PM, Alan DeKok <aland@deployingradius.com> wrote:

On Sep 4, 2015, at 12:16 PM, Jason Alderfer <jha2@emu.edu> wrote:

...

2. With the above in place, caching appears to work correctly. All expected attributes are in the cache, and on session resumption they are read correctly from the cache, however they are not sent back in the final reply. See below.

You're not putting anything into session-state. So when you're taking the reply attributes from the &session-state, nothing is there.

There's a lot of moving parts here.

a) attributes which need to be saved across multiple Access-Challenges MUST be put into the "session-state" list.

b) you must set Cached-Session-Policy some time BEFORE the session finishes, so that the TLS session is cached, with the policy.

c) on session resumption, the Cached-Session-Policy is read from the cache and put back into the reply list. The "inner tunnel" isn't executed.

d) if the next packet is an Access-Accept, you can key off of Cached-Session-Policy in the post-auth section, to set your reply attributes

e) if the next packet is an Access-Challenge, you MUST copy Cached-Session-Policy to &session-state, so that it can be used in the next Access-Accept

Success! The crucial missing piece was wrapping my policy processing code in a "Post-Auth-Type Challenge" so it would be called on session resumption, and setting values in session-state, not reply, like so: Post-Auth-Type Challenge { if ( reply:Cached-Session-Policy ) { if ( reply:Cached-Session-Policy =~ /vlan=(.+)/ ) { update session-state { Reply-Message += "Cached policy:%{reply:Cached-Session-Policy}" Tunnel-Private-Group-ID := "%{1}" Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 } } } } Thanks for your help with this, Alan. I appreciate your time. Jason Alderfer