From 6c97d6998fafaa13c0500a58bbe5269cc8eb1a0a Mon Sep 17 00:00:00 2001 From: Daniel STAN Date: Sat, 7 Mar 2015 18:22:40 +0100 Subject: [PATCH] freeradius: ajoute les confs des sites & clients --- freeradius/dynamic_clients.conf | 31 ++ freeradius/modules/rlm_python_fil.conf | 1 + freeradius/modules/rlm_python_nas.conf | 1 + freeradius/modules/rlm_python_wifi.conf | 1 + freeradius/sites-available/dynamic_clients | 17 + freeradius/sites-available/filaire | 20 + freeradius/sites-available/inner-tunnel | 397 ++++++++++++++++++ freeradius/sites-available/wifi | 458 +++++++++++++++++++++ 8 files changed, 926 insertions(+) create mode 100644 freeradius/dynamic_clients.conf create mode 120000 freeradius/modules/rlm_python_fil.conf create mode 120000 freeradius/modules/rlm_python_nas.conf create mode 120000 freeradius/modules/rlm_python_wifi.conf create mode 100644 freeradius/sites-available/dynamic_clients create mode 100644 freeradius/sites-available/filaire create mode 100644 freeradius/sites-available/inner-tunnel create mode 100644 freeradius/sites-available/wifi diff --git a/freeradius/dynamic_clients.conf b/freeradius/dynamic_clients.conf new file mode 100644 index 00000000..f8fb778d --- /dev/null +++ b/freeradius/dynamic_clients.conf @@ -0,0 +1,31 @@ + +# Define a network where clients may be dynamically defined. +client dynamic { + # + # You MUST specify a netmask! + # IPv4 /32 or IPv6 /128 are NOT allowed! + ipv6addr = 0:: + netmask = 0 + + # + # Define the virtual server used to discover dynamic clients. + dynamic_clients = dynamic_clients + + # + # Define the lifetime (in seconds) for dynamic clients. + # They will be cached for this lifetime, and deleted afterwards. + # + # If the lifetime is "0", then the dynamic client is never + # deleted. The only way to delete the client is to re-start + # the server. + lifetime = 3600 +} + +# Le même, en ipv4 +client dynamic { + ipaddr = 0.0.0.0 + netmask = 0 + dynamic_clients = dynamic_clients + lifetime = 3600 +} + diff --git a/freeradius/modules/rlm_python_fil.conf b/freeradius/modules/rlm_python_fil.conf new file mode 120000 index 00000000..d7ab455d --- /dev/null +++ b/freeradius/modules/rlm_python_fil.conf @@ -0,0 +1 @@ +../rlm_python_fil.conf \ No newline at end of file diff --git a/freeradius/modules/rlm_python_nas.conf b/freeradius/modules/rlm_python_nas.conf new file mode 120000 index 00000000..09150afc --- /dev/null +++ b/freeradius/modules/rlm_python_nas.conf @@ -0,0 +1 @@ +../rlm_python_nas.conf \ No newline at end of file diff --git a/freeradius/modules/rlm_python_wifi.conf b/freeradius/modules/rlm_python_wifi.conf new file mode 120000 index 00000000..30280afe --- /dev/null +++ b/freeradius/modules/rlm_python_wifi.conf @@ -0,0 +1 @@ +../rlm_python_wifi.conf \ No newline at end of file diff --git a/freeradius/sites-available/dynamic_clients b/freeradius/sites-available/dynamic_clients new file mode 100644 index 00000000..0da239a4 --- /dev/null +++ b/freeradius/sites-available/dynamic_clients @@ -0,0 +1,17 @@ +# +# This is the virtual server referenced above by "dynamic_clients". + +server dynamic_clients { + # + # The only contents of the virtual server is the "authorize" section. + authorize { + # Hack dégueux: crans_nas est un backend python. Or, rlm_python ne + # fournit pas en entrée les variables "control", uniquement les variables + # "request", du coup on met ce qui nous intéresse là. + update request { + NAS-Identifier = "%{Packet-Src-IP-Address:-%{Packet-Src-IPv6-Address}}" + } + crans_nas + } +} + diff --git a/freeradius/sites-available/filaire b/freeradius/sites-available/filaire new file mode 100644 index 00000000..e9978d89 --- /dev/null +++ b/freeradius/sites-available/filaire @@ -0,0 +1,20 @@ +###################################################################### +# +# Authentification filaire du crans +# +###################################################################### + +server filaire { + authorize{ + preprocess + crans_fil + } + + authenticate{ + crans_fil + } + + post-auth{ + crans_fil + } +} diff --git a/freeradius/sites-available/inner-tunnel b/freeradius/sites-available/inner-tunnel new file mode 100644 index 00000000..9378e132 --- /dev/null +++ b/freeradius/sites-available/inner-tunnel @@ -0,0 +1,397 @@ +# -*- text -*- +###################################################################### +# +# This is a virtual server that handles *only* inner tunnel +# requests for EAP-TTLS and PEAP types. +# +# $Id: inner-tunnel,v 1.6 2008/03/29 21:33:12 aland Exp $ +# +###################################################################### + +server inner-tunnel { + +# Authorization. First preprocess (hints and huntgroups files), +# then realms, and finally look in the "users" file. +# +# The order of the realm modules will determine the order that +# we try to find a matching realm. +# +# Make *sure* that 'preprocess' comes before any realm if you +# need to setup hints for the remote radius server +authorize { + #preprocess + + crans_wifi + # + # The chap module will set 'Auth-Type := CHAP' if we are + # handling a CHAP request and Auth-Type has not already been set + #chap + + # + # Pull crypt'd passwords from /etc/passwd or /etc/shadow, + # using the system API's to get the password. If you want + # to read /etc/passwd or /etc/shadow directly, see the + # passwd module, above. + # + #unix + + # + # Look for IPASS style 'realm/', and if not found, look for + # '@realm', and decide whether or not to proxy, based on + # that. +# IPASS + + # + # If you are using multiple kinds of realms, you probably + # want to set "ignore_null = yes" for all of them. + # Otherwise, when the first style of realm doesn't match, + # the other styles won't be checked. + # + # Note that proxying the inner tunnel authentication means + # that the user MAY use one identity in the outer session + # (e.g. "anonymous", and a different one here + # (e.g. "user@example.com"). The inner session will then be + # proxied elsewhere for authentication. If you are not + # careful, this means that the user can cause you to forward + # the authentication to another RADIUS server, and have the + # accounting logs *not* sent to the other server. This makes + # it difficult to bill people for their network activity. + # + #suffix +# ntdomain + + # + # The "suffix" module takes care of stripping the domain + # (e.g. "@example.com") from the User-Name attribute, and the + # next few lines ensure that the request is not proxied. + # + # If you want the inner tunnel request to be proxied, delete + # the next few lines. + # + #update control { + # Proxy-To-Realm := LOCAL + #} + + # + # This module takes care of EAP-MSCHAPv2 authentication. + # + # It also sets the EAP-Type attribute in the request + # attribute list to the EAP type from the packet. + # + # The example below uses module failover to avoid querying all + # of the following modules if the EAP module returns "ok". + # Therefore, your LDAP and/or SQL servers will not be queried + # for the many packets that go back and forth to set up TTLS + # or PEAP. The load on those servers will therefore be reduced. + # + eap { + ok = return + } + + # + # Read the 'users' file +# files + + # + # Look in an SQL database. The schema of the database + # is meant to mirror the "users" file. + # + # See "Authorization Queries" in sql.conf +# sql + + # + # If you are using /etc/smbpasswd, and are also doing + # mschap authentication, the un-comment this line, and + # configure the 'etc_smbpasswd' module, above. +# etc_smbpasswd + + # + # The ldap module will set Auth-Type to LDAP if it has not + # already been set + #ldap + + # + # If the users are logging in with an MS-CHAP-Challenge + # attribute for authentication, the mschap module will find + # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP' + # to the request, which will cause the server to then use + # the mschap module for authentication. + mschap + + # + # Enforce daily limits on time spent logged in. +# daily + + # + # Use the checkval module +# checkval + + #expiration + #logintime + + # + # If no other module has claimed responsibility for + # authentication, then try to use PAP. This allows the + # other modules listed above to add a "known good" password + # to the request, and to do nothing else. The PAP module + # will then see that password, and use it to do PAP + # authentication. + # + # This module should be listed last, so that the other modules + # get a chance to set Auth-Type for themselves. + # + #pap +} + + +# Authentication. +# +# +# This section lists which modules are available for authentication. +# Note that it does NOT mean 'try each module in order'. It means +# that a module from the 'authorize' section adds a configuration +# attribute 'Auth-Type := FOO'. That authentication type is then +# used to pick the apropriate module from the list below. +# + +# In general, you SHOULD NOT set the Auth-Type attribute. The server +# will figure it out on its own, and will do the right thing. The +# most common side effect of erroneously setting the Auth-Type +# attribute is that one authentication method will work, but the +# others will not. +# +# The common reasons to set the Auth-Type attribute by hand +# is to either forcibly reject the user, or forcibly accept him. +# +authenticate { + # + # PAP authentication, when a back-end database listed + # in the 'authorize' section supplies a password. The + # password can be clear-text, or encrypted. + #Auth-Type PAP { + # pap + #} + + # + # Most people want CHAP authentication + # A back-end database listed in the 'authorize' section + # MUST supply a CLEAR TEXT password. Encrypted passwords + # won't work. + Auth-Type CHAP { + chap + } + + # + # MSCHAP authentication. + Auth-Type MS-CHAP { + mschap + } + + # + # Pluggable Authentication Modules. +# pam + + # + # See 'man getpwent' for information on how the 'unix' + # module checks the users password. Note that packets + # containing CHAP-Password attributes CANNOT be authenticated + # against /etc/passwd! See the FAQ for details. + # +# unix + + # Uncomment it if you want to use ldap for authentication + # + # Note that this means "check plain-text password against + # the ldap database", which means that EAP won't work, + # as it does not supply a plain-text password. + #Auth-Type LDAP { + # ldap + #} + + # + # Allow EAP authentication. + eap +} + +###################################################################### +# +# There are no accounting requests inside of EAP-TTLS or PEAP +# tunnels. +# +###################################################################### + + +# Session database, used for checking Simultaneous-Use. Either the radutmp +# or rlm_sql module can handle this. +# The rlm_sql module is *much* faster +session { +# radutmp + + # + # See "Simultaneous Use Checking Queries" in sql.conf +# sql +} + + +# Post-Authentication +# Once we KNOW that the user has been authenticated, there are +# additional steps we can take. +post-auth { + crans_wifi + + # Note that we do NOT assign IP addresses here. + # If you try to assign IP addresses for EAP authentication types, + # it WILL NOT WORK. You MUST use DHCP. + + # + # If you want to have a log of authentication replies, + # un-comment the following line, and the 'detail reply_log' + # section, above. +# reply_log + + # + # After authenticating the user, do another SQL query. + # + # See "Authentication Logging Queries" in sql.conf +# sql + + # + # Instead of sending the query to the SQL server, + # write it into a log file. + # +# sql_log + + # + # Un-comment the following if you have set + # 'edir_account_policy_check = yes' in the ldap module sub-section of + # the 'modules' section. + # +# ldap + + # + # Access-Reject packets are sent through the REJECT sub-section of the + # post-auth section. + # + # Add the ldap module name (or instance) if you have set + # 'edir_account_policy_check = yes' in the ldap module configuration + # + Post-Auth-Type REJECT { +# attr_filter.access_reject + } + + # + # The example policy below updates the outer tunnel reply + # (usually Access-Accept) with the User-Name from the inner + # tunnel User-Name. Since this section is processed in the + # context of the inner tunnel, "request" here means "inner + # tunnel request", and "outer.reply" means "outer tunnel + # reply attributes". + # + # This example is most useful when the outer session contains + # a User-Name of "anonymous@....", or a MAC address. If it + # is enabled, the NAS SHOULD use the inner tunnel User-Name + # in subsequent accounting packets. This makes it easier to + # track user sessions, as they will all be based on the real + # name, and not on "anonymous". + # + # The problem with doing this is that it ALSO exposes the + # real user name to any intermediate proxies. People use + # "anonymous" identifiers outside of the tunnel for a very + # good reason: it gives them more privacy. Setting the reply + # to contain the real user name removes ALL privacy from + # their session. + # + # If you want privacy to remain, see the + # Chargeable-User-Identity attribute from RFC 4372. In order + # to use that attribute, you will have to allocate a + # per-session identifier for the user, and store it in a + # long-term database (e.g. SQL). You should also use that + # attribute INSTEAD of the configuration below. + # + #update outer.reply { + # User-Name = "%{request:User-Name}" + #} + +} + +# +# When the server decides to proxy a request to a home server, +# the proxied request is first passed through the pre-proxy +# stage. This stage can re-write the request, or decide to +# cancel the proxy. +# +# Only a few modules currently have this method. +# +pre-proxy { +# attr_rewrite + + # Uncomment the following line if you want to change attributes + # as defined in the preproxy_users file. +# files + + # Uncomment the following line if you want to filter requests + # sent to remote servers based on the rules defined in the + # 'attrs.pre-proxy' file. +# attr_filter.pre-proxy + + # If you want to have a log of packets proxied to a home + # server, un-comment the following line, and the + # 'detail pre_proxy_log' section, above. +# pre_proxy_log +} + +# +# 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 + +# attr_rewrite + + # 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 +# } + +} + +} # inner-tunnel server block diff --git a/freeradius/sites-available/wifi b/freeradius/sites-available/wifi new file mode 100644 index 00000000..dca8b894 --- /dev/null +++ b/freeradius/sites-available/wifi @@ -0,0 +1,458 @@ +###################################################################### +# +# Authentification wifi du crans +# +###################################################################### +# + +# Authorization. First preprocess (hints and huntgroups files), +# then realms, and finally look in the "users" file. +# +# The order of the realm modules will determine the order that +# we try to find a matching realm. +# +# Make *sure* that 'preprocess' comes before any realm if you +# need to setup hints for the remote radius server +server wifi { +authorize { + # + # The preprocess module takes care of sanitizing some bizarre + # attributes in the request, and turning them into attributes + # which are more standard. + # + # It takes care of processing the 'raddb/hints' and the + # 'raddb/huntgroups' files. + # + # It also adds the %{Client-IP-Address} attribute to the request. + #preprocess + + # + # If you want to have a log of authentication requests, + # un-comment the following line, and the 'detail auth_log' + # section, above. +# auth_log + + # + # The chap module will set 'Auth-Type := CHAP' if we are + # handling a CHAP request and Auth-Type has not already been set +# chap + + # + # If the users are logging in with an MS-CHAP-Challenge + # attribute for authentication, the mschap module will find + # the MS-CHAP-Challenge attribute, and add 'Auth-Type := MS-CHAP' + # to the request, which will cause the server to then use + # the mschap module for authentication. + #mschap + + # + # If you have a Cisco SIP server authenticating against + # FreeRADIUS, uncomment the following line, and the 'digest' + # line in the 'authenticate' section. +# digest + + # + # Look for IPASS style 'realm/', and if not found, look for + # '@realm', and decide whether or not to proxy, based on + # that. +# IPASS + + # + # If you are using multiple kinds of realms, you probably + # want to set "ignore_null = yes" for all of them. + # Otherwise, when the first style of realm doesn't match, + # the other styles won't be checked. + # +# suffix +# ntdomain + + # + # This module takes care of EAP-MD5, EAP-TLS, and EAP-LEAP + # authentication. + # + # It also sets the EAP-Type attribute in the request + # attribute list to the EAP type from the packet. + # + # As of 2.0, the EAP module returns "ok" in the authorize stage + # for TTLS and PEAP. In 1.x, it never returned "ok" here, so + # this change is compatible with older configurations. + # + # The example below uses module failover to avoid querying all + # of the following modules if the EAP module returns "ok". + # Therefore, your LDAP and/or SQL servers will not be queried + # for the many packets that go back and forth to set up TTLS + # or PEAP. The load on those servers will therefore be reduced. + # + eap { + ok = return + } + + # + # Pull crypt'd passwords from /etc/passwd or /etc/shadow, + # using the system API's to get the password. If you want + # to read /etc/passwd or /etc/shadow directly, see the + # passwd module in radiusd.conf. + # +# unix + + # + # Read the 'users' file +# files + + # + # Look in an SQL database. The schema of the database + # is meant to mirror the "users" file. + # + # See "Authorization Queries" in sql.conf +# sql + + # + # If you are using /etc/smbpasswd, and are also doing + # mschap authentication, the un-comment this line, and + # configure the 'etc_smbpasswd' module, above. +# etc_smbpasswd + + # + # The ldap module will set Auth-Type to LDAP if it has not + # already been set + #ldap + + # + # Enforce daily limits on time spent logged in. +# daily + + # + # Use the checkval module +# checkval + +# expiration +# logintime + + # + # If no other module has claimed responsibility for + # authentication, then try to use PAP. This allows the + # other modules listed above to add a "known good" password + # to the request, and to do nothing else. The PAP module + # will then see that password, and use it to do PAP + # authentication. + # + # This module should be listed last, so that the other modules + # get a chance to set Auth-Type for themselves. + # + #pap + + # + # If "status_server = yes", then Status-Server messages are passed + # through the following section, and ONLY the following section. + # This permits you to do DB queries, for example. If the modules + # listed here return "fail", then NO response is sent. + # +# Autz-Type Status-Server { +# +# } +} + + +# Authentication. +# +# +# This section lists which modules are available for authentication. +# Note that it does NOT mean 'try each module in order'. It means +# that a module from the 'authorize' section adds a configuration +# attribute 'Auth-Type := FOO'. That authentication type is then +# used to pick the apropriate module from the list below. +# + +# In general, you SHOULD NOT set the Auth-Type attribute. The server +# will figure it out on its own, and will do the right thing. The +# most common side effect of erroneously setting the Auth-Type +# attribute is that one authentication method will work, but the +# others will not. +# +# The common reasons to set the Auth-Type attribute by hand +# is to either forcibly reject the user (Auth-Type := Reject), +# or to or forcibly accept the user (Auth-Type := Accept). +# +# Note that Auth-Type := Accept will NOT work with EAP. +# +# Please do not put "unlang" configurations into the "authenticate" +# section. Put them in the "post-auth" section instead. That's what +# the post-auth section is for. +# +authenticate { + # + # PAP authentication, when a back-end database listed + # in the 'authorize' section supplies a password. The + # password can be clear-text, or encrypted. + #Auth-Type PAP { + # pap + #} + + # + # Most people want CHAP authentication + # A back-end database listed in the 'authorize' section + # MUST supply a CLEAR TEXT password. Encrypted passwords + # won't work. + #Auth-Type CHAP { + # chap + #} + + # + # MSCHAP authentication. + Auth-Type MS-CHAP { + mschap + } + + # + # If you have a Cisco SIP server authenticating against + # FreeRADIUS, uncomment the following line, and the 'digest' + # line in the 'authorize' section. +# digest + + # + # Pluggable Authentication Modules. +# pam + + # + # See 'man getpwent' for information on how the 'unix' + # module checks the users password. Note that packets + # containing CHAP-Password attributes CANNOT be authenticated + # against /etc/passwd! See the FAQ for details. + # +# unix + + # Uncomment it if you want to use ldap for authentication + # + # Note that this means "check plain-text password against + # the ldap database", which means that EAP won't work, + # as it does not supply a plain-text password. + #Auth-Type LDAP { + # ldap + #} + + # + # Allow EAP authentication. + eap +} + + +# +# Pre-accounting. Decide which accounting type to use. +# +preacct { + preprocess + + # + # Ensure that we have a semi-unique identifier for every + # request, and many NAS boxes are broken. + acct_unique + + # + # Look for IPASS-style 'realm/', and if not found, look for + # '@realm', and decide whether or not to proxy, based on + # that. + # + # Accounting requests are generally proxied to the same + # home server as authentication requests. +# IPASS + suffix +# ntdomain + + # + # Read the 'acct_users' file +# files +} + +# +# Accounting. Log the accounting data. +# +accounting { + # + # Create a 'detail'ed log of the packets. + # Note that accounting requests which are proxied + # are also logged in the detail file. +# detail +# daily + + # Update the wtmp file + # + # If you don't use "radlast", you can delete this line. +# unix + + # + # For Simultaneous-Use tracking. + # + # Due to packet losses in the network, the data here + # may be incorrect. There is little we can do about it. +# radutmp +# sradutmp + + # Return an address to the IP Pool when we see a stop record. +# main_pool + + # + # Log traffic to an SQL database. + # + # See "Accounting queries" in sql.conf +# sql + + # + # Instead of sending the query to the SQL server, + # write it into a log file. + # +# sql_log + + # Cisco VoIP specific bulk accounting +# pgsql-voip + + # Filter attributes from the accounting response. +# attr_filter.accounting_response + + # + # See "Autz-Type Status-Server" for how this works. + # +# Acct-Type Status-Server { +# +# } +} + + +# Session database, used for checking Simultaneous-Use. Either the radutmp +# or rlm_sql module can handle this. +# The rlm_sql module is *much* faster +session { +# radutmp + + # + # See "Simultaneous Use Checking Queries" in sql.conf +# sql +} + + +# Post-Authentication +# Once we KNOW that the user has been authenticated, there are +# additional steps we can take. +post-auth { + # Get an address from the IP Pool. +# main_pool + + # + # If you want to have a log of authentication replies, + # un-comment the following line, and the 'detail reply_log' + # section, above. +# reply_log + + # + # After authenticating the user, do another SQL query. + # + # See "Authentication Logging Queries" in sql.conf +# sql + + # + # Instead of sending the query to the SQL server, + # write it into a log file. + # +# sql_log + + # + # Un-comment the following if you have set + # 'edir_account_policy_check = yes' in the ldap module sub-section of + # the 'modules' section. + # + #ldap + +# exec + + # + # Access-Reject packets are sent through the REJECT sub-section of the + # post-auth section. + # + # Add the ldap module name (or instance) if you have set + # 'edir_account_policy_check = yes' in the ldap module configuration + # + Post-Auth-Type REJECT { +# attr_filter.access_reject + } +} + +# +# When the server decides to proxy a request to a home server, +# the proxied request is first passed through the pre-proxy +# stage. This stage can re-write the request, or decide to +# cancel the proxy. +# +# Only a few modules currently have this method. +# +pre-proxy { +# attr_rewrite + + # Uncomment the following line if you want to change attributes + # as defined in the preproxy_users file. +# files + + # Uncomment the following line if you want to filter requests + # sent to remote servers based on the rules defined in the + # 'attrs.pre-proxy' file. +# attr_filter.pre-proxy + + # If you want to have a log of packets proxied to a home + # server, un-comment the following line, and the + # 'detail pre_proxy_log' section, above. +# pre_proxy_log +} + +# +# 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 + +# attr_rewrite + + # 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 +# } + +} + +}