+ #
+ # The shared secret use to "encrypt" and "sign" packets between
+ # FreeRADIUS and the home server.
+ #
+ # The secret can be any string, up to 8k characters in length.
+ #
+ # Control codes can be entered vi octal encoding,
+ # e.g. "\101\102" == "AB"
+ # Quotation marks can be entered by escaping them,
+ # e.g. "foo\"bar"
+ # Spaces or other "special" characters can be entered
+ # by putting quotes around the string.
+ # e.g. "foo bar"
+ # "foo;bar"
+ #
+ secret = testing123
+
+ ############################################################
+ #
+ # The rest of the configuration items listed here are optional,
+ # and do not have to appear in every home server definition.
+ #
+ ############################################################
+
+ #
+ # You can optionally specify the source IP address used when
+ # proxying requests to this home server. When the src_ipaddr
+ # it set, the server will automatically create a proxy
+ # listener for that IP address.
+ #
+ # If you specify this field for one home server, you will
+ # likely need to specify it for ALL home servers.
+ #
+ # If you don't care about the source IP address, leave this
+ # entry commented.
+ #
+# src_ipaddr = 127.0.0.1
+
+ # 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.
+ #
+ # We STRONGLY recommend that this flag be set to "yes"
+ # for ALL home servers. Doing so will have no performance
+ # impact on the proxy or on the home servers. It will,
+ # however, allow administrators to detect problems earlier.
+ #
+ # allowed values: yes, no
+ require_message_authenticator = yes
+
+ #
+ # If the home server does not respond to a request within
+ # this time, this server will initiate "zombie_period".
+ #
+ # The response window is large because responses MAY be slow,
+ # especially when proxying across the Internet.
+ #
+ # Useful range of values: 5 to 60
+ response_window = 20
+
+ #
+ # If you want the old behavior of the server rejecting
+ # proxied requests after "response_window" timeout, set
+ # the following configuration item to "yes".
+ #
+ # This configuration WILL be removed in a future release
+ # If you believe you need it, email the freeradius-users
+ # list, and explain why it should stay in the server.
+ #
+# no_response_fail = no
+
+ #
+ # If the home server does not respond to ANY packets during
+ # the "zombie period", it will be considered to be dead.
+ #
+ # A home server that is marked "zombie" will be used for
+ # proxying as a low priority. If there are live servers,
+ # they will always be preferred to a zombie. Requests will
+ # be proxied to a zombie server ONLY when there are no
+ # live servers.
+ #
+ # Any request that is proxied to a home server will continue
+ # to be sent to that home server until the home server is
+ # marked dead. At that point, it will fail over to another
+ # server, if a live server is available. If none is available,
+ # then the "post-proxy-type fail" handler will be called.
+ #
+ # 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 of 2.0, FreeRADIUS supports RADIUS layer "status
+ # checks". These are used by a proxy server to see if a home
+ # server is alive.
+ #
+ # These status packets are sent ONLY if the proxying server
+ # believes that the home server is dead. They are NOT sent
+ # if the proxying server believes that the home server is
+ # alive. They are NOT sent if the proxying server is not
+ # proxying packets.
+ #
+ # If the home server responds to the status check packet,
+ # then it is marked alive again, and is returned to use.
+ #
+ ############################################################
+
+ #
+ # Some home servers do not support status checks via the
+ # Status-Server packet. Others may not have a "test" user
+ # configured that can be used to query the server, to see if
+ # it is alive. For those servers, we have NO WAY of knowing
+ # when it becomes alive again. Therefore, after the server
+ # has been marked dead, we wait a period of time, and mark
+ # it alive again, in the hope that it has come back to
+ # life.
+ #
+ # If it has NOT come back to life, then FreeRADIUS will wait
+ # for "zombie_period" before marking it dead again. During
+ # the "zombie_period", ALL AUTHENTICATIONS WILL FAIL, because
+ # the home server is still dead. There is NOTHING that can
+ # be done about this, other than to enable the status checks,
+ # as documented below.
+ #
+ # e.g. if "zombie_period" is 40 seconds, and "revive_interval"
+ # is 300 seconds, the for 40 seconds out of every 340, or about
+ # 10% of the time, all authentications will fail.
+ #
+ # If the "zombie_period" and "revive_interval" configurations
+ # are set smaller, than it is possible for up to 50% of
+ # authentications to fail.
+ #
+ # As a result, we recommend enabling status checks, and
+ # we do NOT recommend using "revive_interval".
+ #
+ # The "revive_interval" is used ONLY if the "status_check"
+ # entry below is "none". Otherwise, it will not be used,
+ # and should be deleted.
+ #
+ # Useful range of values: 60 to 3600
+ revive_interval = 120
+
+ #
+ # The proxying server (i.e. this one) can do periodic status
+ # checks to see if a dead home server has come back alive.
+ #
+ # If set to "none", then the other configuration items listed
+ # below are not used, and the "revive_interval" time is used
+ # instead.
+ #
+ # If set to "status-server", the Status-Server packets are
+ # sent. Many RADIUS servers support Status-Server. If a
+ # server does not support it, please contact the server
+ # vendor and request that they add it.
+ #
+ # If set to "request", then Access-Request, or Accounting-Request
+ # packets are sent, depending on the "type" entry above (auth/acct).
+ #
+ # Allowed values: none, status-server, request
+ status_check = status-server
+
+ #
+ # If the home server does not support Status-Server packets,
+ # then the server can still send Access-Request or
+ # Accounting-Request packets, with a pre-defined user name.
+ #
+ # This practice is NOT recommended, as it may potentially let
+ # users gain network access by using these "test" accounts!
+ #
+ # If it is used, we recommend that the home server ALWAYS
+ # respond to these Access-Request status checks with
+ # Access-Reject. The status check just needs an answer, it
+ # does not need an Access-Accept.
+ #
+ # For Accounting-Request status checks, only the username
+ # needs to be set. The rest of the accounting attribute are
+ # set to default values. The home server that receives these
+ # accounting packets SHOULD NOT treat them like normal user
+ # accounting packets. i.e It should probably NOT log them to
+ # a database.
+ #
+ # username = "test_user_please_reject_me"
+ # password = "this is really secret"
+
+ #
+ # Configure the interval between sending status check packets.
+ #
+ # Setting it too low increases the probability of spurious
+ # fail-over and fallback attempts.
+ #
+ # Useful range of values: 6 to 120
+ check_interval = 30
+
+ #
+ # Configure the number of status checks in a row that the
+ # home server needs to respond to before it is marked alive.
+ #
+ # If you want to mark a home server as alive after a short
+ # time period of being responsive, it is best to use a small
+ # "check_interval", and a large value for
+ # "num_answers_to_alive". Using a long "check_interval" and
+ # a small number for "num_answers_to_alive" increases the
+ # probability of spurious fail-over and fallback attempts.
+ #
+ # 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
+ }
+
+ #
+ # Connection limiting for home servers with "proto = tcp".
+ #
+ # This section is ignored for other home servers.
+ #
+ limit {
+ #
+ # Limit the number of TCP connections to the home server.
+ #
+ # The default is 16.
+ # Setting this to 0 means "no limit"
+ max_connections = 16
+
+ #
+ # Limit the total number of requests sent over one
+ # TCP connection. After this number of requests, the
+ # connection will be closed. Any new packets that are
+ # proxied to the home server will result in a new TCP
+ # connection being made.
+ #
+ # Setting this to 0 means "no limit"
+ max_requests = 0
+
+ #
+ # The lifetime, in seconds, of a TCP connection. After
+ # this lifetime, the connection will be closed.
+ #
+ # Setting this to 0 means "forever".
+ lifetime = 0
+
+ #
+ # The idle timeout, in seconds, of a TCP connection.
+ # If no packets have been sent over the connection for
+ # this time, the connection will be closed.
+ #
+ # Setting this to 0 means "no timeout".
+ idle_timeout = 0
+ }
+
+}
+
+# Sample virtual home server.
+#