{
#
#  When the server receives a reply to a request it proxied
#  to a home server, the request may be massaged here, in the
#  post-proxy stage.
#
}
post-proxy \{
{
        #  If you want to have a log of replies from a home server,
        #  un-comment the following line, and the 'detail post_proxy_log'
        #  section, above.
}#       post_proxy_log
{
        #  Uncomment the following line if you want to filter replies from
        #  remote proxies based on the rules defined in the 'attrs' file.
}#       attr_filter.post-proxy
{
        #
        #  If you are proxying LEAP, you MUST configure the EAP
        #  module, and you MUST list it here, in the post-proxy
        #  stage.
        #
        #  You MUST also use the 'nostrip' option in the 'realm'
        #  configuration.  Otherwise, the User-Name attribute
        #  in the proxied request will not match the user name
        #  hidden inside of the EAP packet, and the end server will
        #  reject the EAP request.
        #
}        eap
{
        #
        #  If the server tries to proxy a request and fails, then the
        #  request is processed through the modules in this section.
        #
        #  The main use of this section is to permit robust proxying
        #  of accounting packets.  The server can be configured to
        #  proxy accounting packets as part of normal processing.
        #  Then, if the home server goes down, accounting packets can
        #  be logged to a local "detail" file, for processing with
        #  radrelay.  When the home server comes back up, radrelay
        #  will read the detail file, and send the packets to the
        #  home server.
        #
        #  With this configuration, the server always responds to
        #  Accounting-Requests from the NAS, but only writes
        #  accounting packets to disk if the home server is down.
        #
}#       Post-Proxy-Type Fail \{
#                       detail
#       \}
\}


