-#
-# proxy.conf - proxy radius and realm configuration directives
-#
-# This file is included by default. To disable it, you will need
-# to modify the PROXY CONFIGURATION section of "radiusd.conf".
-#
+# -*- text -*-
+##
+## proxy.conf -- proxy radius and realm configuration directives
+##
+## $Id$
+
#######################################################################
#
# Proxy server configuration
#
#
# Load-balancing and failover between home servers is handled via
-# a "server_pool" section.
+# a "home_server_pool" section.
#
# Finally, The "realm" section defines the realm, some options, and
# indicates which server pool should be used for the realm.
# acct - Handles Accounting-Request packets
# auth+acct - Handles Access-Request packets at "port",
# and Accounting-Request packets at "port + 1"
+ # coa - Handles CoA-Request and Disconnect-Request packets.
+ # See also raddb/sites-available/originate-coa
type = auth
#
- # Configure ONE OF the following three entries:
+ # Configure ONE OF the following entries:
#
# IPv4 address
#
# OR IPv6 address
# ipv6addr = ::1
- # OR hostname, which will do address detection automatically
+ # OR virtual server
+ # virtual_server = foo
+
+ # Note that while both ipaddr and ipv6addr will accept
+ # both addresses and host names, we do NOT recommend
+ # using host names. When you specify a host name, the
+ # server has to do a DNS lookup to find the IP address
+ # of the home server. If the DNS server is slow or
+ # unresponsive, it means that FreeRADIUS will NOT be
+ # able to determine the address, and will therefore NOT
+ # start.
+ #
+ # Also, the mapping of host name to address is done ONCE
+ # when the server starts. If DNS is later updated to
+ # change the address, FreeRADIUS will NOT discover that
+ # until after a re-start, or a HUP.
#
- # Note that we do NOT recommend using hostnames, because
- # it means that the server has to do a DNS lookup to
- # determine the IP address of the home server. If the
- # DNS server is slow or unresponsible, it means that
- # FreeRADIUS will NOT be able to determine the IP
- # address, and will therefore NOT start.
+ # If you specify a virtual_server here, then requests
+ # will be proxied internally to that virtual server.
+ # These requests CANNOT be proxied again, however. The
+ # intent is to have the local server handle packets
+ # when all home servers are dead.
#
- # hostname = localhost
+ # Requests proxied to a virtual server will be passed
+ # through the pre-proxy and post-proxy sections, just
+ # like any other request. See also the sample "realm"
+ # configuration, below.
+ #
+ # None of the rest of the home_server configuration is used
+ # for the "virtual_server" configuration.
#
# The port to which packets are sent.
#
# Usually 1812 for type "auth", and 1813 for type "acct".
# Older servers may use 1645 and 1646.
+ # Use 3799 for type "coa"
#
port = 1812
#
############################################################
+ # RFC 5080 suggests that all clients SHOULD include it in an
+ # Access-Request. The configuration item below tells the
+ # proxying server (i.e. this one) whether or not the home
+ # server requires a Message-Authenticator attribute. If it
+ # is required (value set to "yes"), then all Access-Request
+ # packets sent to that home server will have a
+ # Message-Authenticator attribute.
+ #
+ # allowed values: yes, no
+ require_message_authenticator = no
+
#
# If the home server doesn't respond to the request within
# this time, this server will consider the request dead, and
# respond to the NAS with an Access-Reject.
#
+ # If NO responses are received to any requests sent within this
+ # time period, the home server will be marked "zombie", as below.
+ #
# Useful range of values: 5 to 60
response_window = 20
# called the "zombie" period, because the server is neither
# alive nor dead.
#
+ # If "status_check" below is something other than "none", then
+ # the server will start sending status checks at the start of
+ # the zombie period. It will continue sending status checks
+ # until the home server is marked "alive".
+ #
# Useful range of values: 20 to 120
zombie_period = 40
# As a result, we recommend enabling status checks, and
# we do NOT recommend using "revive_interval".
#
- # If the "status_check" entry below is not "none", then the
- # "revive_interval" entry can be deleted, as it will not be
- # used.
+ # The "revive_interval" is used ONLY if the "status_check"
+ # entry below is not "none". Otherwise, it will not be used,
+ # and should be deleted.
#
# Useful range of values: 60 to 3600
revive_interval = 120
#
# Useful range of values: 3 to 10
num_answers_to_alive = 3
+
+ #
+ # The configuration items in the next sub-section are used ONLY
+ # when "type = coa". It is ignored for all other type of home
+ # servers.
+ #
+ # See RFC 5080 for the definitions of the following terms.
+ # RAND is a function (internal to FreeRADIUS) returning
+ # random numbers between -0.1 and +0.1
+ #
+ # First Re-transmit occurs after:
+ #
+ # RT = IRT + RAND*IRT
+ #
+ # Subsequent Re-transmits occur after:
+ #
+ # RT = 2 * RTprev + RAND * RTprev
+ #
+ # Re-trasnmits are capped at:
+ #
+ # if (MRT && (RT > MRT)) RT = MRT + RAND * MRT
+ #
+ # For a maximum number of attempts: MRC
+ #
+ # For a maximum (total) period of time: MRD.
+ #
+ coa {
+ # Initial retransmit interval: 1..5
+ irt = 2
+
+ # Maximum Retransmit Timeout: 1..30 (0 == no maximum)
+ mrt = 16
+
+ # Maximum Retransmit Count: 1..20 (0 == retransmit forever)
+ mrc = 5
+
+ # Maximum Retransmit Duration: 5..60
+ mrd = 30
+ }
}
+# Sample virtual home server.
+home_server virtual.example.com {
+ virtual_server = virtual.example.com
+}
######################################################################
#
# the same 10 realms, you would need 50 "realm" entries.
#
# In version 2.0, you would need 5 "home_server" sections,
-# 10 'realm" sections, and one "server_pool" section to tie the
+# 10 'realm" sections, and one "home_server_pool" section to tie the
# two together.
#
-server_pool my_auth_failover {
+home_server_pool my_auth_failover {
#
# The type of this pool controls how home servers are chosen.
#
# If there is no Load-Balance-Key in the control items,
# the load balancing method is identical to "load-balance".
#
+ # For most non-EAP authentication methods, The User-Name
+ # attribute provides a good key. An "unlang" policy can
+ # be used to copy the User-Name to the Load-Balance-Key
+ # attribute. This method may not work for EAP sessions,
+ # as the User-Name outside of the TLS tunnel is often
+ # static, e.g. "anonymous@realm".
+ #
+ #
+ # The default type is fail-over.
type = fail-over
#
+ # A virtual_server may be specified here. If so, the
+ # "pre-proxy" and "post-proxy" sections are called when
+ # the request is proxied, and when a response is received.
+ #
+ # This lets you have one policy for all requests that are proxied
+ # to a home server. This policy is completely independent of
+ # any policies used to receive, or process the request.
+ #
+ #virtual_server = pre_post_proxy_for_pool
+
+ #
# Next, a list of one or more home servers. The names
# of the home servers are NOT the hostnames, but the names
# of the sections. (e.g. home_server foo {...} has name "foo".
# home_server = bar.example.com
# home_server = baz.example.com
# home_server = ...
+
+
+ #
+ # If ALL home servers are dead, then this "fallback" home server
+ # is used. If set, it takes precedence over any realm-based
+ # fallback, such as the DEFAULT realm.
+ #
+ # For reasons of stability, this home server SHOULD be a virtual
+ # server. Otherwise, the fallback may itself be dead!
+ #
+ #fallback = virtual.example.com
}
######################################################################
# Realms point to pools of home servers.
#
# For authentication, the "auth_pool" configuration item
- # should point to a "server_pool" that was previously
+ # should point to a "home_server_pool" that was previously
# defined. All of the home servers in the "auth_pool" must
# be of type "auth".
#
# For accounting, the "acct_pool" configuration item
- # should point to a "server_pool" that was previously
+ # should point to a "home_server_pool" that was previously
# defined. All of the home servers in the "acct_pool" must
# be of type "acct".
#
- # If you have a "server_pool" where all of the home servers
+ # If you have a "home_server_pool" where all of the home servers
# are of type "auth+acct", you can just use the "pool"
# configuration item, instead of specifying both "auth_pool"
# and "acct_pool".
# prefix or suffix. User names like "bob" will match this one.
#
#realm NULL {
-# type = radius
# authhost = radius.company.com:1600
# accthost = radius.company.com:1601
# secret = testing123
# This realm is for ALL OTHER requests.
#
#realm DEFAULT {
-# type = radius
# authhost = radius.company.com:1600
# accthost = radius.company.com:1601
# secret = testing123
#}
+
+
+# This realm "proxies" requests internally to a virtual server.
+# The pre-proxy and post-proxy sections are run just as with any
+# other kind of home server. The virtual server then receives
+# the request, and replies, just as with any other packet.
+#
+# Once proxied internally like this, the request CANNOT be proxied
+# internally or externally.
+#
+#realm virtual.example.com {
+# virtual_server = virtual.example.com
+#}
+#
+
+#
+# Regular expressions may also be used as realm names. If these are used,
+# then the "find matching realm" process is as follows:
+#
+# 1) Look for a non-regex realm with an *exact* match for the name.
+# If found, it is used in preference to any regex matching realm.
+#
+# 2) Look for a regex realm, in the order that they are listed
+# in the configuration files. Any regex match is performed in
+# a case-insensitive fashion.
+#
+# 3) If no realm is found, return the DEFAULT realm, if any.
+#
+# The order of the realms matters in step (2). For example, defining
+# two realms "*.example.com" and "*.test.example.com" will result in
+# the second realm NEVER matching. This is because all of the realms
+# which match the second regex also match the first one. Since the
+# first regex matches, it is returned.
+#
+# The solution is to list the realms in the opposite order,. e.g.
+# "*.test.example.com", followed by "*.example.com".
+#
+#
+# Some helpful rules:
+#
+# - always place a '~' character at the start of the realm name.
+# This signifies that it is a regex match, and not an exact match
+# for the realm.
+#
+# - place the regex in double quotes. This helps the configuration
+# file parser ignore any "special" characters in the regex.
+# Yes, this rule is different than the normal "unlang" rules for
+# regular expressions. That may be fixed in a future release.
+#
+# - use two back-slashes '\\' whenever you need one backslash in the
+# regex. e.g. "~*\\.example\\.com", and not "~*\.example\.com".
+# This is because the regex is in a double-quoted string, and normal
+# rules apply for double-quoted strings.
+#
+# - If you are matching domain names, use two backslashes in front of
+# every '.' (dot or period). This is because '.' has special meaning
+# in a regular expression: match any character. If you do not do this,
+# then "~*.example.com" will match "fooXexampleYcom", which is likely
+# not what you want
+#
+# - If you are matching domain names, put a '$' at the end of the regex
+# that matches the domain name. This tells the regex matching code
+# that the realm ENDS with the domain name, so it does not match
+# realms with the domain name in the middle. e.g. "~*\\.example\\.com"
+# will match "test.example.comFOO", which is likely not what you want.
+# Using "~*\\.example\\.com$" is better.
+#
+# The more regex realms that are defined, the more time it takes to
+# process them. You should define as few regex realms as possible
+# in order to maximize server performance.
+#
+#realm "~*\\.example\\.com$" {
+# authhost = LOCAL # not strictly necessary
+# accthost = LOCAL # not strictly necessary
+#}
projects / freeradius.git / blobdiff