Changes to automatically provision,build and run Radius containers for Auth tests.
Changes to cord test server to handle radius server restart requests.
diff --git a/src/test/setup/radius-config/freeradius/sites-available/README b/src/test/setup/radius-config/freeradius/sites-available/README
new file mode 100644
index 0000000..55036f0
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/README
@@ -0,0 +1,335 @@
+1. Virtual Servers.
+
+ FreeRADIUS 2.0 supports virtual servers. This is probably the
+single largest change that is NOT backwards compatible with 1.x.
+
+ The virtual servers do NOT have to be set up with the
+"sites-available" and "sites-enabled" directories. You can still have
+one "radiusd.conf" file, and put the server configuration there:
+
+ ...
+ server {
+ authorize {
+ ...
+ }
+ authenticate {
+ ...
+ }
+ ...
+ }
+ ...
+
+ The power of virtual servers lies in their ability to separate
+policies. A policy can be placed into a virtual server, where it is
+guaranteed to affect only the requests that are passed through that
+virtual server. In 1.x, the policies were global, and it sometimes
+took much effort to write a policy so that it only applied in certain
+limited situations.
+
+
+2. What do we mean by "virtual server"?
+
+
+ A virtual server is a (nearly complete) RADIUS server, just like a
+configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run
+multiple virtual servers at the same time. The virtual servers can
+even proxy requests to each other!
+
+ The simplest way to create a virtual server is to take the all of
+the request processing sections from radius.conf, ("authorize" ,
+"authenticate", etc.) and wrap them in a "server {}" block, as above.
+
+ You can create another virtual server by:
+
+ 1) defining a new "server foo {...}" section in radiusd.conf
+ 2) Putting the normal "authorize", etc. sections inside of it
+ 3) Adding a "listen" section *inside* of the "server" section.
+
+ e.g.
+
+ ...
+ server foo {
+ listen {
+ ipaddr = 127.0.0.1
+ port = 2000
+ type = auth
+ }
+
+ authorize {
+ update control {
+ Cleartext-Password := "bob"
+ }
+ pap
+ }
+
+ authenticate {
+ pap
+ }
+ }
+ ...
+
+ With that text added to "radiusd.conf", run the server in debugging
+mode (radiusd -X), and in another terminal window, type:
+
+$ radtest bob bob localhost:2000 0 testing123
+
+ You should see the server return an Access-Accept.
+
+
+3. Capabilities and limitations
+
+
+ The only sub-sections that can appear in a virtual server section
+are:
+
+ listen
+ client
+ authorize
+ authenticate
+ post-auth
+ pre-proxy
+ post-proxy
+ preacct
+ accounting
+ session
+
+ All other configuration parameters (modules, etc.) are global.
+
+ Inside of a virtual server, the authorize, etc. sections have their
+normal meaning, and can contain anything that an authorize section
+could contain in 1.x.
+
+ When a "listen" section is inside of a virtual server definition, it
+means that all requests sent to that IP/port will be processed through
+the virtual server. There cannot be two "listen" sections with the
+same IP address and port number.
+
+ When a "client" section is inside of a virtual server definition, it
+means that that client is known only to the "listen" sections that are
+also inside of that virtual server. Not only is this client
+definition available only to this virtual server, but the details of
+the client configuration is also available only to this virtual
+server.
+
+ i.e. Two virtual servers can listen on different IP address and
+ports, but both can have a client with IP address 127.0.0.1. The
+shared secret for that client can be different for each virtual
+server.
+
+
+4. More complex "listen" capabilities
+
+ The "listen" sections have a few additional configuration items that
+were not in 1.x, and were not mentioned above. These configuration
+items enable almost any mapping of IP / port to clients to virtual
+servers.
+
+ The configuration items are:
+
+ virtual_server = <name>
+
+ If set, all requests sent to this IP / port are processed
+ through the named virtual server.
+
+ This directive can be used only for "listen" sections
+ that are global. i.e. It CANNOT be used if the
+ "listen" section is inside of a virtual server.
+
+ clients = <name>
+
+ If set, the "listen" section looks for a "clients" section:
+
+ clients <name> {
+ ...
+ }
+
+ It looks inside of that named "clients" section for
+ "client" subsections, at least one of which must
+ exist. Each client in that section is added to the
+ list of known clients for this IP / port. No other
+ clients are known.
+
+ If it is set, it over-rides the list of clients (if
+ any) in the same virtual server. Note that the
+ clients are NOT additive!
+
+ If it is not set, then the clients from the current
+ virtual server (if any) are used. If there are no
+ clients in this virtual server, then the global
+ clients are used.
+
+ i.e. The most specific directive is used:
+ * configuration in this "listen" section
+ * clients in the same virtual server
+ * global clients
+
+ The directives are also *exclusive*, not *additive*.
+ If you have one client in a virtual server, and
+ another client referenced from a "listen" section,
+ then that "listen" section will ONLY use the second
+ client. It will NOT use both clients.
+
+
+5. More complex "client" capabilities
+
+ The "client" sections have a few additional configuration items that
+were not in 1.x, and were not mentioned above. These configuration
+items enable almost any mapping of IP / port to clients to virtual
+servers.
+
+ The configuration items are:
+
+ virtual_server = <name>
+
+ If set, all requests from this client are processed
+ through the named virtual server.
+
+ This directive can be used only for "client" sections
+ that are global. i.e. It CANNOT be used if the
+ "client" section is inside of a virtual server.
+
+ If the "listen" section has a "server" entry, and a matching
+client is found ALSO with a "server" entry, then the clients server is
+used for that request.
+
+
+6. Worked examples
+
+
+ Listening on one socket, and mapping requests from two clients to
+two different servers.
+
+ listen {
+ ...
+ }
+ client one {
+ ...
+ virtual_server = server_one
+ }
+ client two {
+ ...
+ virtual_server = server_two
+ }
+ server server_one {
+ authorize {
+ ...
+ }
+ ...
+ }
+ server server_two {
+ authorize {
+ ...
+ }
+ ...
+ }
+
+ This could also be done as:
+
+
+ listen {
+ ...
+ virtual_server = server_one
+ }
+ client one {
+ ...
+ }
+ client two {
+ ...
+ virtual_server = server_two
+ }
+ server server_one {
+ authorize {
+ ...
+ }
+ ...
+ }
+ server server_two {
+ authorize {
+ ...
+ }
+ ...
+ }
+
+ In this case, the default server for the socket is "server_one", so
+there is no need to set that in the client "one" configuration. The
+"server_two" configuration for client "two" over-rides the default
+setting for the socket.
+
+ Note that the following configuration will NOT work:
+
+ listen {
+ ...
+ virtual_server = server_one
+ }
+ client one {
+ ...
+ }
+ server server_one {
+ authorize {
+ ...
+ }
+ ...
+ }
+ server server_two {
+ client two {
+ ...
+ }
+ authorize {
+ ...
+ }
+ ...
+ }
+
+ In this example, client "two" is hidden inside of the virtual
+server, where the "listen" section cannot find it.
+
+
+7. Outlined examples
+
+ This section outlines a number of examples, with alternatives.
+
+ One server, multiple sockets
+ - multiple "listen" sections in a "server" section
+
+ one server per client
+ - define multiple servers
+ - have a global "listen" section
+ - have multiple global "clients", each with "virtual_server = X"
+
+ two servers, each with their own sockets
+ - define multiple servers
+ - put "client" sections into each "server"
+ - put a "listen" section into each "server"
+
+ Each server can list the same client IP, and the secret
+ can be different
+
+ two sockets, sharing a list of clients, but pointing to different servers
+ - define global "listen" sections
+ - in each, set "virtual_server = X"
+ - in each, set "clients = Y"
+ - define "clients Y" section, containing multiple clients.
+
+ This also means that you can have a third socket, which
+ doesn't share any of these clients.
+
+
+8. How to decide what to do
+
+
+ If you want *completely* separate policies for a socket or a client,
+then create a separate virtual server. Then, map the request to that
+server by setting configuration entries in a "listen" section or in a
+"client" section.
+
+ Start off with the common cases first. If most of the clients
+and/or sockets get a particular policy, make that policy the default.
+Configure it without paying attention to the sockets or clients you
+want to add later, and without adding a second virtual server. Once
+it works, then add the second virtual server.
+
+ If you want to re-use the previously defined sockets with the second
+virtual server, then you will need one or more global "client"
+sections. Those clients will contain a "virtual_server = ..." entry
+that will direct requests from those clients to the appropriate
+virtual server.
diff --git a/src/test/setup/radius-config/freeradius/sites-available/buffered-sql b/src/test/setup/radius-config/freeradius/sites-available/buffered-sql
new file mode 100644
index 0000000..4217d99
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/buffered-sql
@@ -0,0 +1,129 @@
+# -*- text -*-
+######################################################################
+#
+# In 2.0.0, radrelay functionality is integrated into the
+# server core. This virtual server gives an example of
+# using radrelay functionality inside of the server.
+#
+# In this example, the detail file is read, and the data
+# is put into SQL. This configuration is used when a RADIUS
+# server on this machine is receiving accounting packets,
+# and writing them to the detail file.
+#
+# The purpose of this virtual server is to de-couple the storage
+# of long-term accounting data in SQL from "live" information
+# needed by the RADIUS server as it is running.
+#
+# The benefit of this approach is that for a busy server, the
+# overhead of performing SQL queries may be significant. Also,
+# if the SQL databases are large (as is typical for ones storing
+# months of data), the INSERTs and UPDATEs may take a relatively
+# long time. Rather than slowing down the RADIUS server by
+# having it interact with a database, you can just log the
+# packets to a detail file, and then read that file later at a
+# time when the RADIUS server is typically lightly loaded.
+#
+# If you use on virtual server to log to the detail file,
+# and another virtual server (i.e. this one) to read from
+# the detail file, then this process will happen automatically.
+# A sudden spike of RADIUS traffic means that the detail file
+# will grow in size, and the server will be able to handle
+# large volumes of traffic quickly. When the traffic dies down,
+# the server will have time to read the detail file, and insert
+# the data into a long-term SQL database.
+#
+# $Id: bc5abe8e104accca792de61201c741d07e825894 $
+#
+######################################################################
+
+server buffered-sql {
+ listen {
+ type = detail
+
+ # The location where the detail file is located.
+ # This should be on local disk, and NOT on an NFS
+ # mounted location!
+ filename = "${radacctdir}/detail-*"
+
+ #
+ # The server can read accounting packets from the
+ # detail file much more quickly than those packets
+ # can be written to a database. If the database is
+ # overloaded, then bad things can happen.
+ #
+ # The server will keep track of how long it takes to
+ # process an entry from the detail file. It will
+ # then pause between handling entries. This pause
+ # allows databases to "catch up", and gives the
+ # server time to notice that other packets may have
+ # arrived.
+ #
+ # The pause is calculated dynamically, to ensure that
+ # the load due to reading the detail files is limited
+ # to a small percentage of CPU time. The
+ # "load_factor" configuration item is a number
+ # between 1 and 100. The server will try to keep the
+ # percentage of time taken by "detail" file entries
+ # to "load_factor" percentage of the CPU time.
+ #
+ # If the "load_factor" is set to 100, then the server
+ # will read packets as fast as it can, usually
+ # causing databases to go into overload.
+ #
+ load_factor = 10
+
+ #
+ # Set the interval for polling the detail file.
+ # If the detail file doesn't exist, the server will
+ # wake up, and poll for it every N seconds.
+ #
+ # Useful range of values: 1 to 60
+ poll_interval = 1
+
+ #
+ # Set the retry interval for when the home server
+ # does not respond. The current packet will be
+ # sent repeatedly, at this interval, until the
+ # home server responds.
+ #
+ # Useful range of values: 5 to 30
+ retry_interval = 30
+
+ }
+
+ #
+ # 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
+
+ #
+ # Read the 'acct_users' file. This isn't always
+ # necessary, and can be deleted if you do not use it.
+ files
+ }
+
+ #
+ # Accounting. Log the accounting data.
+ #
+ accounting {
+ #
+ # Log traffic to an SQL database.
+ #
+ # See "Accounting queries" in sql.conf
+ # sql
+
+
+ # Cisco VoIP specific bulk accounting
+ # pgsql-voip
+
+ }
+
+ # The requests are not being proxied, so no pre/post-proxy
+ # sections are necessary.
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/check-eap-tls b/src/test/setup/radius-config/freeradius/sites-available/check-eap-tls
new file mode 100644
index 0000000..d84378f
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/check-eap-tls
@@ -0,0 +1,131 @@
+# This virtual server allows EAP-TLS to reject access requests
+# based on some certificate attributes.
+#
+# Value-pairs that are available for checking include:
+#
+# TLS-Client-Cert-Subject
+# TLS-Client-Cert-Issuer
+# TLS-Client-Cert-Common-Name
+# TLS-Client-Cert-Subject-Alt-Name-Email
+#
+# To see a full list of attributes, run the server in debug mode
+# with this virtual server configured, and look at the attributes
+# passed in to this virtual server.
+#
+#
+# This virtual server is also useful when using EAP-TLS as it is only called
+# once, just before the final Accept is about to be returned from eap, whereas
+# the outer authorize section is called multiple times for each challenge /
+# response. For this reason, here may be a good location to put authentication
+# logging, and modules that check for further authorization, especially if they
+# hit external services such as sql or ldap.
+
+server check-eap-tls {
+
+
+# Authorize - this is the only section required.
+#
+# To accept the access request, set Auth-Type = Accept, otherwise
+# set it to Reject.
+
+authorize {
+
+ #
+ # By default, we just accept the request:
+ #
+ update config {
+ Auth-Type := Accept
+ }
+
+
+ #
+ # Check the client certificate matches a string, and reject otherwise
+ #
+
+# if ("%{TLS-Client-Cert-Common-Name}" == "client.example.com") {
+# update config {
+# Auth-Type := Accept
+# }
+# }
+# else {
+# update config {
+# Auth-Type := Reject
+# }
+# update reply {
+# Reply-Message := "Your certificate is not valid."
+# }
+# }
+
+
+ #
+ # Check the client certificate common name against the supplied User-Name
+ #
+# if ("host/%{TLS-Client-Cert-Common-Name}" == "%{User-Name}") {
+# update config {
+# Auth-Type := Accept
+# }
+# }
+# else {
+# update config {
+# Auth-Type := Reject
+# }
+# }
+
+
+ #
+ # This is a convenient place to call LDAP, for example, when using
+ # EAP-TLS, as it will only be called once, after all certificates as
+ # part of the EAP-TLS challenge process have been verified.
+ #
+ # An example could be to use LDAP to check that the connecting host, as
+ # well as presenting a valid certificate, is also in a group based on
+ # the User-Name (assuming this contains the service principal name).
+ # Settings such as the following could be used in the ldap module
+ # configuration:
+ #
+ # basedn = "dc=example, dc=com"
+ # filter = "(servicePrincipalName=%{User-Name})"
+ # base_filter = "(objectClass=computer)"
+ # groupname_attribute = cn
+ # groupmembership_filter = "(&(objectClass=group)(member=%{control:Ldap-UserDn}))"
+
+# ldap
+
+ # Now let's test membership of an LDAP group (the ldap bind user will
+ # need permission to read this group membership):
+
+# if (!(Ldap-Group == "Permitted-Laptops")) {
+# update config {
+# Auth-Type := Reject
+# }
+# }
+
+ # or, to be more specific, you could use the group's full DN:
+ # if (!(Ldap-Group == "CN=Permitted-Laptops,OU=Groups,DC=example,DC=org")) {
+
+
+ #
+ # This may be a better place to call the files modules when using
+ # EAP-TLS, as it will only be called once, after the challenge-response
+ # iteration has completed.
+ #
+
+# files
+
+
+ #
+ # Log all request attributes, plus TLS certificate details, to the
+ # detail auth_log. Again, this is just once per connection request, so
+ # may be preferable than in the outer authorize section. It is
+ # suggested that 'auth_log' also be in the outer post-auth and
+ # Post-Auth REJECT sections to log reply packet details, too.
+ #
+
+ auth_log
+
+}
+
+
+
+}
+
diff --git a/src/test/setup/radius-config/freeradius/sites-available/coa b/src/test/setup/radius-config/freeradius/sites-available/coa
new file mode 100644
index 0000000..66caa31
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/coa
@@ -0,0 +1,49 @@
+# -*- text -*-
+######################################################################
+#
+# Sample virtual server for receiving a CoA or Disconnect-Request packet.
+#
+
+# Listen on the CoA port.
+#
+# This uses the normal set of clients, with the same secret as for
+# authentication and accounting.
+#
+listen {
+ type = coa
+ ipaddr = *
+ port = 3799
+ server = coa
+}
+
+server coa {
+ # When a packet is received, it is processed through the
+ # recv-coa section. This applies to *both* CoA-Request and
+ # Disconnect-Request packets.
+ recv-coa {
+ # CoA && Disconnect packets can be proxied in the same
+ # way as authentication or accounting packets.
+ # Just set Proxy-To-Realm, or Home-Server-Pool, and the
+ # packets will be proxied.
+
+ # Do proxying based on realms here. You don't need
+ # "IPASS" or "ntdomain", as the proxying is based on
+ # the Operator-Name attribute. It contains the realm,
+ # and ONLY the realm (prefixed by a '1')
+ suffix
+
+ # Insert your own policies here.
+ ok
+ }
+
+ # When a packet is sent, it is processed through the
+ # recv-coa section. This applies to *both* CoA-Request and
+ # Disconnect-Request packets.
+ send-coa {
+ # Sample module.
+ ok
+ }
+
+ # You can use pre-proxy and post-proxy sections here, too.
+ # They will be processed for sending && receiving proxy packets.
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/control-socket b/src/test/setup/radius-config/freeradius/sites-available/control-socket
new file mode 100644
index 0000000..c3f813d
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/control-socket
@@ -0,0 +1,73 @@
+# -*- text -*-
+######################################################################
+#
+# Control socket interface.
+#
+# In the future, we will add username/password checking for
+# connections to the control socket. We will also add
+# command authorization, where the commands entered by the
+# administrator are run through a virtual server before
+# they are executed.
+#
+# For now, anyone who has permission to connect to the socket
+# has nearly complete control over the server. Be warned!
+#
+# This functionality is NOT enabled by default.
+#
+# See also the "radmin" program, which is used to communicate
+# with the server over the control socket.
+#
+# $Id: 8d06082d3a8fba31bb1471aef19e28093cee4a9e $
+#
+######################################################################
+listen {
+ #
+ # Listen on the control socket.
+ #
+ type = control
+
+ #
+ # Socket location.
+ #
+ # This file is created with the server's uid and gid.
+ # It's permissions are r/w for that user and group, and
+ # no permissions for "other" users. These permissions form
+ # minimal security, and should not be relied on.
+ #
+ socket = ${run_dir}/${name}.sock
+
+ #
+ # The following two parameters perform authentication and
+ # authorization of connections to the control socket.
+ #
+ # If not set, then ANYONE can connect to the control socket,
+ # and have complete control over the server. This is likely
+ # not what you want.
+ #
+ # One, or both, of "uid" and "gid" should be set. If set, the
+ # corresponding value is checked. Unauthorized users result
+ # in an error message in the log file, and the connection is
+ # closed.
+ #
+
+ #
+ # Name of user that is allowed to connect to the control socket.
+ #
+# uid = radius
+
+ #
+ # Name of group that is allowed to connect to the control socket.
+ #
+# gid = radius
+
+ #
+ # Access mode.
+ #
+ # This can be used to give *some* administrators access to
+ # monitor the system, but not to change it.
+ #
+ # ro = read only access (default)
+ # rw = read/write access.
+ #
+# mode = rw
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/copy-acct-to-home-server b/src/test/setup/radius-config/freeradius/sites-available/copy-acct-to-home-server
new file mode 100644
index 0000000..5f962f8
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/copy-acct-to-home-server
@@ -0,0 +1,169 @@
+# -*- text -*-
+######################################################################
+#
+# In 2.0.0, radrelay functionality is integrated into the
+# server core. This virtual server gives an example of
+# using radrelay functionality inside of the server.
+#
+# In this example, the detail file is read, and the packets
+# are proxied to a home server. You will have to configure
+# realms, home_server_pool, and home_server in proxy.conf
+# for this to work.
+#
+# The purpose of this virtual server is to enable duplication
+# of information across a load-balanced, or fail-over set of
+# servers. For example, if a group of clients lists two
+# home servers (primary, secondary), then RADIUS accounting
+# messages will go only to one server at a time. This file
+# configures a server (primary, secondary) to send copies of
+# the accounting information to each other.
+#
+# That way, each server has the same set of information, and
+# can make the same decision about the user.
+#
+# $Id: 2869287260929f35d1a575b52014de20ce6cf3bb $
+#
+######################################################################
+
+server copy-acct-to-home-server {
+ listen {
+ type = detail
+
+ ######################################################
+ #
+ # !!!! WARNING !!!!
+ #
+ # The detail file reader acts just like a NAS.
+ #
+ # This means that if accounting fails, the packet
+ # is re-tried FOREVER. It is YOUR responsibility
+ # to write an accounting policy that returns "ok"
+ # if the packet was processed properly, "fail" on
+ # a database error, AND "ok" if you want to ignore
+ # the packet (e.g. no Acct-Status-Type).
+ #
+ # Neither the detail file write OR the detail file
+ # reader look at the contents of the packets. They
+ # just either dump the packet verbatim to the file,
+ # or read it verbatim from the file and pass it to
+ # the server.
+ #
+ ######################################################
+
+
+ # The location where the detail file is located.
+ # This should be on local disk, and NOT on an NFS
+ # mounted location!
+ #
+ # On most systems, this should support file globbing
+ # e.g. "${radacctdir}/detail-*:*"
+ # This lets you write many smaller detail files as in
+ # the example in radiusd.conf: ".../detail-%Y%m%d:%H"
+ # Writing many small files is often better than writing
+ # one large file. File globbing also means that with
+ # a common naming scheme for detail files, then you can
+ # have many detail file writers, and only one reader.
+ filename = ${radacctdir}/detail
+
+ #
+ # The server can read accounting packets from the
+ # detail file much more quickly than those packets
+ # can be written to a database. If the database is
+ # overloaded, then bad things can happen.
+ #
+ # The server will keep track of how long it takes to
+ # process an entry from the detail file. It will
+ # then pause between handling entries. This pause
+ # allows databases to "catch up", and gives the
+ # server time to notice that other packets may have
+ # arrived.
+ #
+ # The pause is calculated dynamically, to ensure that
+ # the load due to reading the detail files is limited
+ # to a small percentage of CPU time. The
+ # "load_factor" configuration item is a number
+ # between 1 and 100. The server will try to keep the
+ # percentage of time taken by "detail" file entries
+ # to "load_factor" percentage of the CPU time.
+ #
+ # If the "load_factor" is set to 100, then the server
+ # will read packets as fast as it can, usually
+ # causing databases to go into overload.
+ #
+ load_factor = 10
+ }
+
+ #
+ # Pre-accounting. Decide which accounting type to use.
+ #
+ preacct {
+ preprocess
+
+ # Since we're just proxying, we don't need 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. This isn't always
+ # necessary, and can be deleted if you do not use it.
+ files
+ }
+
+ #
+ # Accounting. Log the accounting data.
+ #
+ accounting {
+ #
+ # Since we're proxying, we don't log anything
+ # locally. Ensure that the accounting section
+ # "succeeds" by forcing an "ok" return.
+ ok
+ }
+
+
+ #
+ # 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 {
+
+ # 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 in radiusd.conf.
+ # 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 in radiusd.conf.
+ # 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
+ }
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/decoupled-accounting b/src/test/setup/radius-config/freeradius/sites-available/decoupled-accounting
new file mode 100644
index 0000000..199258d
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/decoupled-accounting
@@ -0,0 +1,140 @@
+# -*- text -*-
+######################################################################
+#
+# This is a sample configuration for "decoupled" accounting.
+# "Decoupled" accounting is where the accounting packets are
+# NOT written "live" to the back-end database. This method
+# can only be used if you are not interested in "live"
+# accounting. i.e. Where you can tolerate delays that may be
+# a few seconds, before accounting packets get written to
+# the DB.
+#
+# Oddly enough, this method can speed up the processing of
+# accounting packets, as all database activity is serialized.
+#
+# This file is NOT meant to be used as-is. It needs to be
+# edited to match your local configuration.
+#
+# $Id$
+#
+######################################################################
+
+# Define a virtual server to write the accounting packets.
+# Any "listen" section that listens on an accounting port should
+# set "virtual_server = write-detail.example.com
+server write_detail.example.com {
+ accounting {
+ #
+ # Write the "detail" files.
+ #
+ # See raddb/modules/detail.example.com for more info.
+ detail.example.com
+ }
+
+ # That's it!
+}
+
+# Define a virtual server to process the accounting packets.
+server read-detail.example.com {
+ # Read accounting packets from the detail file(s) for
+ # the home server.
+ listen {
+ type = detail
+ filename = "${radacctdir}/detail.example.com/detail-*:*"
+ load_factor = 10
+ }
+
+ # All packets read from the detail file are processed through
+ # the preacct && accounting sections.
+ #
+ # The following text is copied verbatim from sites-available/default.
+ # You should edit it for your own local configuration.
+
+#
+# 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.
+ #
+ # NOTE! You will have to ensure that any accounting packets
+ # NOT handled by the SQL module (e.g. "stop with zero session length"
+ # result in the accounting section still returning "ok".
+ #
+ # Otherwise, the server will think that the accounting packet
+ # was NOT handled properly, and will keep trying to process it
+ # through this virtual server!
+ #
+ # 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 {
+#
+# }
+}
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/default b/src/test/setup/radius-config/freeradius/sites-available/default
new file mode 100644
index 0000000..934f835
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/default
@@ -0,0 +1,844 @@
+######################################################################
+#
+# As of 2.0.0, FreeRADIUS supports virtual hosts using the
+# "server" section, and configuration directives.
+#
+# Virtual hosts should be put into the "sites-available"
+# directory. Soft links should be created in the "sites-enabled"
+# directory to these files. This is done in a normal installation.
+#
+# If you are using 802.1X (EAP) authentication, please see also
+# the "inner-tunnel" virtual server. You will likely have to edit
+# that, too, for authentication to work.
+#
+# $Id: 3278975e054fab504afda5ba8fc999239cb2fb9d $
+#
+######################################################################
+#
+# Read "man radiusd" before editing this file. See the section
+# titled DEBUGGING. It outlines a method where you can quickly
+# obtain the configuration you want, without running into
+# trouble. See also "man unlang", which documents the format
+# of this file.
+#
+# This configuration is designed to work in the widest possible
+# set of circumstances, with the widest possible number of
+# authentication methods. This means that in general, you should
+# need to make very few changes to this file.
+#
+# The best way to configure the server for your local system
+# is to CAREFULLY edit this file. Most attempts to make large
+# edits to this file will BREAK THE SERVER. Any edits should
+# be small, and tested by running the server with "radiusd -X".
+# Once the edits have been verified to work, save a copy of these
+# configuration files somewhere. (e.g. as a "tar" file). Then,
+# make more edits, and test, as above.
+#
+# There are many "commented out" references to modules such
+# as ldap, sql, etc. These references serve as place-holders.
+# If you need the functionality of that module, then configure
+# it in radiusd.conf, and un-comment the references to it in
+# this file. In most cases, those small changes will result
+# in the server being able to connect to the DB, and to
+# authenticate users.
+#
+######################################################################
+
+server default {
+#
+# If you want the server to listen on additional addresses, or on
+# additional ports, you can use multiple "listen" sections.
+#
+# Each section make the server listen for only one type of packet,
+# therefore authentication and accounting have to be configured in
+# different sections.
+#
+# The server ignore all "listen" section if you are using '-i' and '-p'
+# on the command line.
+#
+listen {
+ # Type of packets to listen for.
+ # Allowed values are:
+ # auth listen for authentication packets
+ # acct listen for accounting packets
+ # proxy IP to use for sending proxied packets
+ # detail Read from the detail file. For examples, see
+ # raddb/sites-available/copy-acct-to-home-server
+ # status listen for Status-Server packets. For examples,
+ # see raddb/sites-available/status
+ # coa listen for CoA-Request and Disconnect-Request
+ # packets. For examples, see the file
+ # raddb/sites-available/coa-server
+ #
+ type = auth
+
+ # Note: "type = proxy" lets you control the source IP used for
+ # proxying packets, with some limitations:
+ #
+ # * A proxy listener CANNOT be used in a virtual server section.
+ # * You should probably set "port = 0".
+ # * Any "clients" configuration will be ignored.
+ #
+ # See also proxy.conf, and the "src_ipaddr" configuration entry
+ # in the sample "home_server" section. When you specify the
+ # source IP address for packets sent to a home server, the
+ # proxy listeners are automatically created.
+
+ # IP address on which to listen.
+ # Allowed values are:
+ # dotted quad (1.2.3.4)
+ # hostname (radius.example.com)
+ # wildcard (*)
+ ipaddr = *
+
+ # OR, you can use an IPv6 address, but not both
+ # at the same time.
+# ipv6addr = :: # any. ::1 == localhost
+
+ # Port on which to listen.
+ # Allowed values are:
+ # integer port number (1812)
+ # 0 means "use /etc/services for the proper port"
+ port = 0
+
+ # Some systems support binding to an interface, in addition
+ # to the IP address. This feature isn't strictly necessary,
+ # but for sites with many IP addresses on one interface,
+ # it's useful to say "listen on all addresses for eth0".
+ #
+ # If your system does not support this feature, you will
+ # get an error if you try to use it.
+ #
+# interface = eth0
+
+ # Per-socket lists of clients. This is a very useful feature.
+ #
+ # The name here is a reference to a section elsewhere in
+ # radiusd.conf, or clients.conf. Having the name as
+ # a reference allows multiple sockets to use the same
+ # set of clients.
+ #
+ # If this configuration is used, then the global list of clients
+ # is IGNORED for this "listen" section. Take care configuring
+ # this feature, to ensure you don't accidentally disable a
+ # client you need.
+ #
+ # See clients.conf for the configuration of "per_socket_clients".
+ #
+# clients = per_socket_clients
+
+ #
+ # Connection limiting for sockets with "proto = tcp".
+ #
+ # This section is ignored for other kinds of sockets.
+ #
+ limit {
+ #
+ # Limit the number of simultaneous TCP connections to the socket
+ #
+ # The default is 16.
+ # Setting this to 0 means "no limit"
+ max_connections = 16
+
+ # The per-socket "max_requests" option does not exist.
+
+ #
+ # 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 received over the connection for
+ # this time, the connection will be closed.
+ #
+ # Setting this to 0 means "no timeout".
+ #
+ # We STRONGLY RECOMMEND that you set an idle timeout.
+ #
+ idle_timeout = 30
+ }
+}
+
+#
+# This second "listen" section is for listening on the accounting
+# port, too.
+#
+listen {
+ ipaddr = *
+# ipv6addr = ::
+ port = 0
+ type = acct
+# interface = eth0
+# clients = per_socket_clients
+
+ limit {
+ # The number of packets received can be rate limited via the
+ # "max_pps" configuration item. When it is set, the server
+ # tracks the total number of packets received in the previous
+ # second. If the count is greater than "max_pps", then the
+ # new packet is silently discarded. This helps the server
+ # deal with overload situations.
+ #
+ # The packets/s counter is tracked in a sliding window. This
+ # means that the pps calculation is done for the second
+ # before the current packet was received. NOT for the current
+ # wall-clock second, and NOT for the previous wall-clock second.
+ #
+ # Useful values are 0 (no limit), or 100 to 10000.
+ # Values lower than 100 will likely cause the server to ignore
+ # normal traffic. Few systems are capable of handling more than
+ # 10K packets/s.
+ #
+ # It is most useful for accounting systems. Set it to 50%
+ # more than the normal accounting load, and you can be sure that
+ # the server will never get overloaded
+ #
+# max_pps = 0
+
+ # Only for "proto = tcp". These are ignored for "udp" sockets.
+ #
+# idle_timeout = 0
+# lifetime = 0
+# max_connections = 0
+ }
+}
+
+# Authorization. First preprocess (hints and huntgroups files),
+# then realms, and finally look in the "users" file.
+#
+# Any changes made here should also be made to the "inner-tunnel"
+# virtual server.
+#
+# 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 {
+ #
+ # Take a User-Name, and perform some checks on it, for spaces and other
+ # invalid characters. If the User-Name appears invalid, reject the
+ # request.
+ #
+ # See policy.d/filter for the definition of the filter_username policy.
+ #
+ filter_username
+
+ #
+ # 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.
+ preprocess
+
+ # If you intend to use CUI and you require that the Operator-Name
+ # be set for CUI generation and you want to generate CUI also
+ # for your local clients then uncomment the operator-name
+ # below and set the operator-name for your clients in clients.conf
+# operator-name
+
+ #
+ # If you want to generate CUI for some clients that do not
+ # send proper CUI requests, then uncomment the
+ # cui below and set "add_cui = yes" for these clients in clients.conf
+# cui
+
+ #
+ # 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
+
+ #
+ # The WiMAX specification says that the Calling-Station-Id
+ # is 6 octets of the MAC. This definition conflicts with
+ # RFC 3580, and all common RADIUS practices. Un-commenting
+ # the "wimax" module here means that it will fix the
+ # Calling-Station-Id attribute to the normal format as
+ # specified in RFC 3580 Section 3.21
+# wimax
+
+ #
+ # 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 'smbpasswd' module.
+# smbpasswd
+
+ #
+ # The ldap module reads passwords from the LDAP database.
+ -ldap
+
+ #
+ # Enforce daily limits on time spent logged in.
+# daily
+
+ #
+ 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 appropriate 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
+
+ # 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.
+ #
+ # We do NOT recommend using this. LDAP servers are databases.
+ # They are NOT authentication servers. FreeRADIUS is an
+ # authentication server, and knows what to do with authentication.
+ # LDAP servers do not.
+ #
+# Auth-Type LDAP {
+# ldap
+# }
+
+ #
+ # Allow EAP authentication.
+ eap
+
+ #
+ # The older configurations sent a number of attributes in
+ # Access-Challenge packets, which wasn't strictly correct.
+ # If you want to filter out these attributes, uncomment
+ # the following lines.
+ #
+# Auth-Type eap {
+# eap {
+# handled = 1
+# }
+# if (handled && (Response-Packet-Type == Access-Challenge)) {
+# attr_filter.access_challenge.post-auth
+# handled # override the "updated" code from attr_filter
+# }
+# }
+}
+
+
+#
+# Pre-accounting. Decide which accounting type to use.
+#
+preacct {
+ preprocess
+
+ #
+ # Merge Acct-[Input|Output]-Gigawords and Acct-[Input-Output]-Octets
+ # into a single 64bit counter Acct-[Input|Output]-Octets64.
+ #
+# acct_counters64
+
+ #
+ # Session start times are *implied* in RADIUS.
+ # The NAS never sends a "start time". Instead, it sends
+ # a start packet, *possibly* with an Acct-Delay-Time.
+ # The server is supposed to conclude that the start time
+ # was "Acct-Delay-Time" seconds in the past.
+ #
+ # The code below creates an explicit start time, which can
+ # then be used in other modules. It will be *mostly* correct.
+ # Any errors are due to the 1-second resolution of RADIUS,
+ # and the possibility that the time on the NAS may be off.
+ #
+ # The start time is: NOW - delay - session_length
+ #
+
+# update request {
+# FreeRADIUS-Acct-Session-Start-Time = "%{expr: %l - %{%{Acct-Session-Time}:-0} - %{%{Acct-Delay-Time}:-0}}"
+# }
+
+
+ #
+ # 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 {
+ # Update accounting packet by adding the CUI attribute
+ # recorded from the corresponding Access-Accept
+ # use it only if your NAS boxes do not support CUI themselves
+# cui
+ #
+ # 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
+
+ #
+ # If you receive stop packets with zero session length,
+ # they will NOT be logged in the database. The SQL module
+ # will print a message (only in debugging mode), and will
+ # return "noop".
+ #
+ # You can ignore these packets by uncommenting the following
+ # three lines. Otherwise, the server will not respond to the
+ # accounting request, and the NAS will retransmit.
+ #
+# if (noop) {
+# ok
+# }
+
+ #
+ # Instead of sending the query to the SQL server,
+ # write it into a log file.
+ #
+# sql_log
+
+ # Cisco VoIP specific bulk accounting
+# pgsql-voip
+
+ # For Exec-Program and Exec-Program-Wait
+ exec
+
+ # 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
+
+
+ # Create the CUI value and add the attribute to Access-Accept.
+ # Uncomment the line below if *returning* the CUI.
+# cui
+
+ #
+ # If you want to have a log of authentication replies,
+ # un-comment the following line, and enable the
+ # 'detail reply_log' module.
+# 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 want to modify the user's object
+ # in LDAP after a successful login.
+ #
+# ldap
+
+ # For Exec-Program and Exec-Program-Wait
+ exec
+
+ #
+ # Calculate the various WiMAX keys. In order for this to work,
+ # you will need to define the WiMAX NAI, usually via
+ #
+ # update request {
+ # WiMAX-MN-NAI = "%{User-Name}"
+ # }
+ #
+ # If you want various keys to be calculated, you will need to
+ # update the reply with "template" values. The module will see
+ # this, and replace the template values with the correct ones
+ # taken from the cryptographic calculations. e.g.
+ #
+ # update reply {
+ # WiMAX-FA-RK-Key = 0x00
+ # WiMAX-MSK = "%{EAP-MSK}"
+ # }
+ #
+ # You may want to delete the MS-MPPE-*-Keys from the reply,
+ # as some WiMAX clients behave badly when those attributes
+ # are included. See "raddb/modules/wimax", configuration
+ # entry "delete_mppe_keys" for more information.
+ #
+# wimax
+
+
+ # If there is a client certificate (EAP-TLS, sometimes PEAP
+ # and TTLS), then some attributes are filled out after the
+ # certificate verification has been performed. These fields
+ # MAY be available during the authentication, or they may be
+ # available only in the "post-auth" section.
+ #
+ # The first set of attributes contains information about the
+ # issuing certificate which is being used. The second
+ # contains information about the client certificate (if
+ # available).
+#
+# update reply {
+# Reply-Message += "%{TLS-Cert-Serial}"
+# Reply-Message += "%{TLS-Cert-Expiration}"
+# Reply-Message += "%{TLS-Cert-Subject}"
+# Reply-Message += "%{TLS-Cert-Issuer}"
+# Reply-Message += "%{TLS-Cert-Common-Name}"
+# Reply-Message += "%{TLS-Cert-Subject-Alt-Name-Email}"
+#
+# Reply-Message += "%{TLS-Client-Cert-Serial}"
+# Reply-Message += "%{TLS-Client-Cert-Expiration}"
+# Reply-Message += "%{TLS-Client-Cert-Subject}"
+# Reply-Message += "%{TLS-Client-Cert-Issuer}"
+# Reply-Message += "%{TLS-Client-Cert-Common-Name}"
+# Reply-Message += "%{TLS-Client-Cert-Subject-Alt-Name-Email}"
+# }
+
+ # Insert class attribute (with unique value) into response,
+ # aids matching auth and acct records, and protects against duplicate
+ # Acct-Session-Id. Note: Only works if the NAS has implemented
+ # RFC 2865 behaviour for the class attribute, AND if the NAS
+ # supports long Class attributes. Many older or cheap NASes
+ # only support 16-octet Class attributes.
+# insert_acct_class
+
+ # MacSEC requires the use of EAP-Key-Name. However, we don't
+ # want to send it for all EAP sessions. Therefore, the EAP
+ # modules put required data into the EAP-Session-Id attribute.
+ # This attribute is never put into a request or reply packet.
+ #
+ # Uncomment the next few lines to copy the required data into
+ # the EAP-Key-Name attribute
+# if (reply:EAP-Session-Id) {
+# update reply {
+# EAP-Key-Name := "%{reply:EAP-Session-Id}"
+# }
+# }
+
+ # Remove reply message if the response contains an EAP-Message
+ remove_reply_message_if_eap
+
+ #
+ # 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 {
+ # log failed authentications in SQL, too.
+ -sql
+ attr_filter.access_reject
+
+ # Insert EAP-Failure message if the request was
+ # rejected by policy instead of because of an
+ # authentication failure
+ eap
+
+ # Remove reply message if the response contains an EAP-Message
+ remove_reply_message_if_eap
+ }
+}
+
+#
+# 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 {
+ # Before proxing the request add an Operator-Name attribute identifying
+ # if the operator-name is found for this client.
+ # No need to uncomment this if you have already enabled this in
+ # the authorize section.
+# operator-name
+
+ # The client requests the CUI by sending a CUI attribute
+ # containing one zero byte.
+ # Uncomment the line below if *requesting* the CUI.
+# cui
+
+ # 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
+
+ # 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
+# }
+}
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/dhcp b/src/test/setup/radius-config/freeradius/sites-available/dhcp
new file mode 100644
index 0000000..42760ef
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/dhcp
@@ -0,0 +1,279 @@
+# -*- text -*-
+######################################################################
+#
+# This is a virtual server that handles DHCP.
+#
+# $Id: 170e2b191af7184b519d3594fa99476c857dfda5 $
+#
+######################################################################
+
+#
+# The DHCP functionality goes into a virtual server.
+#
+server dhcp {
+
+# Define a DHCP socket.
+#
+# The default port below is 6700, so you don't break your network.
+# If you want it to do real DHCP, change this to 67, and good luck!
+#
+# You can also bind the DHCP socket to an interface.
+# See below, and raddb/radiusd.conf for examples.
+#
+# This lets you run *one* DHCP server instance and have it listen on
+# multiple interfaces, each with a separate policy.
+#
+# If you have multiple interfaces, it is a good idea to bind the
+# listen section to an interface. You will also need one listen
+# section per interface.
+#
+# FreeBSD does *not* support binding sockets to interfaces. Therefore,
+# if you have multiple interfaces, broadcasts may go out of the wrong
+# one, or even all interfaces. The solution is to use the "setfib" command.
+# If you have a network "10.10.0/24" on LAN1, you will need to do:
+#
+# Pick any IP on the 10.10.0/24 network
+# $ setfib 1 route add default 10.10.0.1
+#
+# Edit /etc/rc.local, and add a line:
+# setfib 1 /path/to/radiusd
+#
+# The kern must be built with the following options:
+# options ROUTETABLES=2
+# or any value larger than 2.
+#
+# The other only solution is to update FreeRADIUS to use BPF sockets.
+#
+listen {
+ # This is a dhcp socket.
+ type = dhcp
+
+ # IP address to listen on. Will usually be the IP of the
+ # interface, or 0.0.0.0
+ ipaddr = 127.0.0.1
+
+ # source IP address for unicast packets sent by the
+ # DHCP server.
+ #
+ # The source IP for unicast packets is chosen from the first
+ # one of the following items which returns a valid IP
+ # address:
+ #
+ # src_ipaddr
+ # ipaddr
+ # reply:DHCP-Server-IP-Address
+ # reply:DHCP-DHCP-Server-Identifier
+ #
+ src_ipaddr = 127.0.0.1
+
+ # The port should be 67 for a production network. Don't set
+ # it to 67 on a production network unless you really know
+ # what you're doing. Even if nothing is configured below, the
+ # server may still NAK legitimate responses from clients.
+ port = 6700
+
+ # Interface name we are listening on. See comments above.
+# interface = lo0
+
+ # The DHCP server defaults to allowing broadcast packets.
+ # Set this to "no" only when the server receives *all* packets
+ # from a relay agent. i.e. when *no* clients are on the same
+ # LAN as the DHCP server.
+ #
+ # It's set to "no" here for testing. It will usually want to
+ # be "yes" in production, unless you are only dealing with
+ # relayed packets.
+ broadcast = no
+
+ # On Linux if you're running the server as non-root, you
+ # will need to do:
+ #
+ # sudo setcap cap_net_admin=ei /path/to/radiusd
+ #
+ # This will allow the server to set ARP table entries
+ # for newly allocated IPs
+}
+
+# Packets received on the socket will be processed through one
+# of the following sections, named after the DHCP packet type.
+# See dictionary.dhcp for the packet types.
+
+# Return packets will be sent to, in preference order:
+# DHCP-Gateway-IP-Address
+# DHCP-Client-IP-Address
+# DHCP-Your-IP-Address
+# At least one of these attributes should be set at the end of each
+# section for a response to be sent.
+
+dhcp DHCP-Discover {
+
+ # Set the type of packet to send in reply.
+ #
+ # The server will look at the DHCP-Message-Type attribute to
+ # determine which type of packet to send in reply. Common
+ # values would be DHCP-Offer, DHCP-Ack or DHCP-NAK. See
+ # dictionary.dhcp for all the possible values.
+ #
+ # DHCP-Do-Not-Respond can be used to tell the server to not
+ # respond.
+ #
+ # In the event that DHCP-Message-Type is not set then the
+ # server will fall back to determining the type of reply
+ # based on the rcode of this section.
+
+ update reply {
+ DHCP-Message-Type = DHCP-Offer
+ }
+
+ # The contents here are invented. Change them!
+ update reply {
+ DHCP-Domain-Name-Server = 127.0.0.1
+ DHCP-Domain-Name-Server = 127.0.0.2
+ DHCP-Subnet-Mask = 255.255.255.0
+ DHCP-Router-Address = 192.0.2.1
+ DHCP-IP-Address-Lease-Time = 86400
+ DHCP-DHCP-Server-Identifier = 192.0.2.1
+ }
+
+ # Do a simple mapping of MAC to assigned IP.
+ #
+ # See below for the definition of the "mac2ip"
+ # module.
+ #
+ #mac2ip
+
+ # If the MAC wasn't found in that list, do something else.
+ # You could call a Perl, Python, or Java script here.
+
+ #if (notfound) {
+ # ...
+ #}
+
+ # Or, allocate IPs from the DHCP pool in SQL. You may need to
+ # set the pool name here if you haven't set it elsewhere.
+# update control {
+# Pool-Name := "local"
+# }
+# dhcp_sqlippool
+
+ # If DHCP-Message-Type is not set, returning "ok" or
+ # "updated" from this section will respond with a DHCP-Offer
+ # message.
+ #
+ # Other rcodes will tell the server to not return any response.
+ ok
+}
+
+dhcp DHCP-Request {
+
+ # Response packet type. See DHCP-Discover section above.
+ update reply {
+ DHCP-Message-Type = DHCP-Ack
+ }
+
+ # The contents here are invented. Change them!
+ update reply {
+ DHCP-Domain-Name-Server = 127.0.0.1
+ DHCP-Domain-Name-Server = 127.0.0.2
+ DHCP-Subnet-Mask = 255.255.255.0
+ DHCP-Router-Address = 192.0.2.1
+ DHCP-IP-Address-Lease-Time = 86400
+ DHCP-DHCP-Server-Identifier = 192.0.2.1
+ }
+
+ # Do a simple mapping of MAC to assigned IP.
+ #
+ # See below for the definition of the "mac2ip"
+ # module.
+ #
+ #mac2ip
+
+ # If the MAC wasn't found in that list, do something else.
+ # You could call a Perl, Python, or Java script here.
+
+ #if (notfound) {
+ # ...
+ #}
+
+ # Or, allocate IPs from the DHCP pool in SQL. You may need to
+ # set the pool name here if you haven't set it elsewhere.
+# update control {
+# Pool-Name := "local"
+# }
+# dhcp_sqlippool
+
+ # If DHCP-Message-Type is not set, returning "ok" or
+ # "updated" from this section will respond with a DHCP-Ack
+ # packet.
+ #
+ # "handled" will not return a packet, all other rcodes will
+ # send back a DHCP-NAK.
+ ok
+}
+
+#
+# Other DHCP packet types
+#
+# There should be a separate section for each DHCP message type.
+# By default this configuration will ignore them all. Any packet type
+# not defined here will be responded to with a DHCP-NAK.
+
+dhcp DHCP-Decline {
+ update reply {
+ DHCP-Message-Type = DHCP-Do-Not-Respond
+ }
+ reject
+}
+
+dhcp DHCP-Inform {
+ update reply {
+ DHCP-Message-Type = DHCP-Do-Not-Respond
+ }
+ reject
+}
+
+dhcp DHCP-Release {
+ update reply {
+ DHCP-Message-Type = DHCP-Do-Not-Respond
+ }
+ reject
+}
+
+
+}
+
+######################################################################
+#
+# This next section is a sample configuration for the "passwd"
+# module, that reads flat-text files. It should go into
+# radiusd.conf, in the "modules" section.
+#
+# The file is in the format <mac>,<ip>
+#
+# 00:01:02:03:04:05,192.0.2.100
+# 01:01:02:03:04:05,192.0.2.101
+# 02:01:02:03:04:05,192.0.2.102
+#
+# This lets you perform simple static IP assignment.
+#
+# There is a preconfigured "mac2ip" module setup in
+# mods-available/mac2ip. To use it do:
+#
+# # cd raddb/
+# # ln -s ../mods-available/mac2ip mods-enabled/mac2ip
+# # mkdir mods-config/passwd
+#
+# Then create the file mods-config/passwd/mac2ip with the above
+# format.
+#
+######################################################################
+
+
+# This is an example only - see mods-available/mac2ip instead; do
+# not uncomment these lines here.
+#
+#passwd mac2ip {
+# filename = ${confdir}/mac2ip
+# format = "*DHCP-Client-Hardware-Address:=DHCP-Your-IP-Address"
+# delimiter = ","
+#}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/dhcp.relay b/src/test/setup/radius-config/freeradius/sites-available/dhcp.relay
new file mode 100644
index 0000000..737cc5d
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/dhcp.relay
@@ -0,0 +1,44 @@
+# -*- text -*-
+######################################################################
+#
+# This is a virtual server that handles DHCP relaying
+#
+# Only one server can listen on a socket, so you cannot
+# do DHCP relaying && run a DHCP server at the same time.
+#
+######################################################################
+
+server dhcp.eth1 {
+ listen {
+ ipaddr = *
+ port = 67
+ type = dhcp
+ interface = eth1
+ }
+
+ # Packets received on the socket will be processed through one
+ # of the following sections, named after the DHCP packet type.
+ # See dictionary.dhcp for the packet types.
+ dhcp DHCP-Discover {
+ update config {
+ # IP Address of the DHCP server
+ DHCP-Relay-To-IP-Address := 192.0.2.2
+ }
+ update request {
+ # IP Address of the DHCP relay (ourselves)
+ DHCP-Gateway-IP-Address := 192.0.2.1
+ }
+ ok
+ }
+
+ dhcp DHCP-Request {
+ update config {
+ # IP Address of the DHCP server
+ DHCP-Relay-To-IP-Address := 192.0.2.2
+ }
+ update request {
+ DHCP-Gateway-IP-Address := 192.0.2.2
+ }
+ ok
+ }
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/dynamic-clients b/src/test/setup/radius-config/freeradius/sites-available/dynamic-clients
new file mode 100644
index 0000000..8f5edde
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/dynamic-clients
@@ -0,0 +1,224 @@
+# -*- text -*-
+######################################################################
+#
+# Sample configuration file for dynamically updating the list
+# of RADIUS clients at run time.
+#
+# Everything is keyed off of a client "network". (e.g. 192.0.2/24)
+# This configuration lets the server know that clients within
+# that network are defined dynamically.
+#
+# When the server receives a packet from an unknown IP address
+# within that network, it tries to find a dynamic definition
+# for that client. If the definition is found, the IP address
+# (and other configuration) is added to the server's internal
+# cache of "known clients", with a configurable lifetime.
+#
+# Further packets from that IP address result in the client
+# definition being found in the cache. Once the lifetime is
+# reached, the client definition is deleted, and any new requests
+# from that client are looked up as above.
+#
+# If the dynamic definition is not found, then the request is
+# treated as if it came from an unknown client. i.e. It is
+# silently discarded.
+#
+# As part of protection from Denial of Service (DoS) attacks,
+# the server will add only one new client per second. This CANNOT
+# be changed, and is NOT configurable.
+#
+# $Id: cdfa6175a9617bcd081b0b69f2c9340c3adaa56e $
+#
+######################################################################
+
+#
+# Define a network where clients may be dynamically defined.
+client dynamic {
+ ipaddr = 192.0.2.0
+
+ #
+ # You MUST specify a netmask!
+ # IPv4 /32 or IPv6 /128 are NOT allowed!
+ netmask = 24
+
+ #
+ # Any other configuration normally found in a "client"
+ # entry can be used here.
+
+ #
+ # A shared secret does NOT have to be defined. It can
+ # be left out.
+
+ #
+ # Define the virtual server used to discover dynamic clients.
+ dynamic_clients = dynamic_clients
+
+ #
+ # The directory where client definitions are stored. This
+ # needs to be used ONLY if the client definitions are stored
+ # in flat-text files. Each file in that directory should be
+ # ONE and only one client definition. The name of the file
+ # should be the IP address of the client.
+ #
+ # If you are storing clients in SQL, this entry should not
+ # be used.
+# directory = ${confdir}/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
+}
+
+#
+# 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 {
+
+ #
+ # Put any modules you want here. SQL, LDAP, "exec",
+ # Perl, etc. The only requirements is that the
+ # attributes MUST go into the control item list.
+ #
+ # The request that is processed through this section
+ # is EMPTY. There are NO attributes. The request is fake,
+ # and is NOT the packet that triggered the lookup of
+ # the dynamic client.
+ #
+ # The ONLY piece of useful information is either
+ #
+ # Packet-Src-IP-Address (IPv4 clients)
+ # Packet-Src-IPv6-Address (IPv6 clients)
+ #
+ # The attributes used to define a dynamic client mirror
+ # the configuration items in the "client" structure.
+ #
+
+ #
+ # Example 1: Hard-code a client IP. This example is
+ # useless, but it documents the attributes
+ # you need.
+ #
+ update control {
+
+ #
+ # Echo the IP address of the client.
+ FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
+
+ # require_message_authenticator
+ FreeRADIUS-Client-Require-MA = no
+
+ # secret
+ FreeRADIUS-Client-Secret = "testing123"
+
+ # shortname
+ FreeRADIUS-Client-Shortname = "%{Packet-Src-IP-Address}"
+
+ # nas_type
+ FreeRADIUS-Client-NAS-Type = "other"
+
+ # virtual_server
+ #
+ # This can ONLY be used if the network client
+ # definition (e.g. "client dynamic" above) has
+ # NO virtual_server defined.
+ #
+ # If the network client definition does have a
+ # virtual_server defined, then that is used,
+ # and there is no need to define this attribute.
+ #
+ FreeRADIUS-Client-Virtual-Server = "something"
+
+ }
+
+ #
+ # Example 2: Read the clients from "clients" files
+ # in a directory.
+ #
+
+ # This requires you to uncomment the
+ # "directory" configuration in the
+ # "client dynamic" configuration above,
+ # and then put one file per IP address in
+ # that directory.
+ #
+ dynamic_clients
+
+ #
+ # Example 3: Look the clients up in SQL.
+ #
+ # This requires the SQL module to be configured, of course.
+ if ("%{sql: SELECT nasname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}") {
+ update control {
+ #
+ # Echo the IP.
+ FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
+
+ #
+ # Do multiple SELECT statements to grab
+ # the various definitions.
+ FreeRADIUS-Client-Shortname = "%{sql: SELECT shortname FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
+
+ FreeRADIUS-Client-Secret = "%{sql: SELECT secret FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
+
+ FreeRADIUS-Client-NAS-Type = "%{sql: SELECT type FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
+
+ FreeRADIUS-Client-Virtual-Server = "%{sql: SELECT server FROM nas WHERE nasname = '%{Packet-Src-IP-Address}'}"
+ }
+
+ }
+
+ # Do an LDAP lookup in the elements OU, check to see if
+ # the Packet-Src-IP-Address object has a "ou"
+ # attribute, if it does continue. Change "ACME.COM" to
+ # the real OU of your organization.
+ #
+ # Assuming the following schema:
+ #
+ # OU=Elements,OU=Radius,DC=ACME,DC=COM
+ #
+ # Elements will hold a record of every NAS in your
+ # Network. Create Group objects based on the IP
+ # Address of the NAS and set the "Location" or "l"
+ # attribute to the NAS Huntgroup the NAS belongs to
+ # allow them to be centrally managed in LDAP.
+ #
+ # e.g. CN=10.1.2.3,OU=Elements,OU=Radius,DC=ACME,DC=COM
+ #
+ # With a "l" value of "CiscoRTR" for a Cisco Router
+ # that has a NAS-IP-Address or Source-IP-Address of
+ # 10.1.2.3.
+ #
+ # And with a "ou" value of the shared secret password
+ # for the NAS element. ie "password"
+ if ("%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?ou?sub?cn=%{Packet-Src-IP-Address}}") {
+ update control {
+ FreeRADIUS-Client-IP-Address = "%{Packet-Src-IP-Address}"
+
+ # Set the Client-Shortname to be the Location
+ # "l" just like in the Huntgroups, but this
+ # time to the shortname.
+
+ FreeRADIUS-Client-Shortname = "%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?l?sub?cn=%{Packet-Src-IP-Address}}"
+
+ # Lookup and set the Shared Secret based on
+ # the "ou" attribute.
+ FreeRADIUS-Client-Secret = "%{ldap:ldap:///OU=Elements,OU=Radius,DC=ACME,DC=COM?ou?sub?cn=%{Packet-Src-IP-Address}}"
+ }
+ }
+
+ #
+ # Tell the caller that the client was defined properly.
+ #
+ # If the authorize section does NOT return "ok", then
+ # the new client is ignored.
+ ok
+ }
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/example b/src/test/setup/radius-config/freeradius/sites-available/example
new file mode 100644
index 0000000..05522ea
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/example
@@ -0,0 +1,122 @@
+######################################################################
+#
+# An example virtual server configuration.
+#
+# $Id: e58e24319d6320a0a0d56fd649d937bf95156739 $
+#
+######################################################################
+
+
+#
+# This client will be available to any "listen" section that
+# are defined outside of a virtual server section. However,
+# when the server receives a packet from this client, the
+# request will be processed through the "example" virtual
+# server, as the "client" section contains a configuration item
+# to that effect.
+#
+# Note that this client will be able to send requests to any
+# port defined in a global "listen" section. It will NOT,
+# however, be able to send requests to a port defined in a
+# "listen" section that is contained in a "server" section.
+#
+# With careful matching of configurations, you should be able
+# to:
+#
+# - Define one authentication port, but process each client
+# through a separate virtual server.
+#
+# - define multiple authentication ports, each with a private
+# list of clients.
+#
+# - define multiple authentication ports, each of which may
+# have the same client listed, but with different shared
+# secrets
+#
+# FYI: We use an address in the 192.0.2.* space for this example,
+# as RFC 3330 says that that /24 range is used for documentation
+# and examples, and should not appear on the net. You shouldn't
+# use it for anything, either.
+#
+client 192.0.2.10 {
+ shortname = example-client
+ secret = testing123
+ virtual_server = example
+}
+
+######################################################################
+#
+# An example virtual server. It starts off with "server name {"
+# The "name" is used to reference this server from a "listen"
+# or "client" section.
+#
+######################################################################
+server example {
+ #
+ # Listen on 192.0.2.1:1812 for Access-Requests
+ #
+ # When the server receives a packet, it is processed
+ # through the "authorize", etc. sections listed here,
+ # NOT the global ones the "default" site.
+ #
+ listen {
+ ipaddr = 192.0.2.1
+ port = 1821
+ type = auth
+ }
+
+ #
+ # This client is listed within the "server" section,
+ # and is therefore known ONLY to the socket defined
+ # in the "listen" section above. If the client IP
+ # sends a request to a different socket, the server
+ # will treat it as an unknown client, and will not
+ # respond.
+ #
+ # In contrast, the client listed at the top of this file
+ # is outside of any "server" section, and is therefore
+ # global in scope. It can send packets to any port
+ # defined in a global "listen" section. It CANNOT send
+ # packets to the listen section defined above, though.
+ #
+ # Note that you don't have to have a "virtual_server = example"
+ # line here, as the client is encapsulated within
+ # the "server" section.
+ #
+ client 192.0.2.9 {
+ shortname = example-client
+ secret = testing123
+ }
+
+ authorize {
+ #
+ # Some example policies. See "man unlang" for more.
+ #
+ if ("%{User-Name}" == "bob") {
+ update control {
+ Cleartext-Password := "bob"
+ }
+ }
+
+ #
+ # And then reject the user. The next line requires
+ # that the "always reject {}" section is defined in
+ # the "modules" section of radiusd.conf.
+ #
+ reject
+ }
+
+ authenticate {
+
+ }
+
+ post-auth {
+
+ Post-Auth-Type Reject {
+ update reply {
+ Reply-Message = "This is only an example."
+ }
+ }
+ }
+
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/inner-tunnel b/src/test/setup/radius-config/freeradius/sites-available/inner-tunnel
new file mode 100644
index 0000000..dc7b7de
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/inner-tunnel
@@ -0,0 +1,408 @@
+# -*- text -*-
+######################################################################
+#
+# This is a virtual server that handles *only* inner tunnel
+# requests for EAP-TTLS and PEAP types.
+#
+# $Id: 11b6c12d845a1e8287888b3f0a0748d810b2c184 $
+#
+######################################################################
+
+server inner-tunnel {
+
+#
+# This next section is here to allow testing of the "inner-tunnel"
+# authentication methods, independently from the "default" server.
+# It is listening on "localhost", so that it can only be used from
+# the same machine.
+#
+# $ radtest USER PASSWORD 127.0.0.1:18120 0 testing123
+#
+# If it works, you have configured the inner tunnel correctly. To check
+# if PEAP will work, use:
+#
+# $ radtest -t mschap USER PASSWORD 127.0.0.1:18120 0 testing123
+#
+# If that works, PEAP should work. If that command doesn't work, then
+#
+# FIX THE INNER TUNNEL CONFIGURATION SO THAT IT WORKS.
+#
+# Do NOT do any PEAP tests. It won't help. Instead, concentrate
+# on fixing the inner tunnel configuration. DO NOTHING ELSE.
+#
+listen {
+ ipaddr = 127.0.0.1
+ port = 18120
+ type = auth
+}
+
+
+# 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 {
+ #
+ # 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
+
+ #
+ # 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 reads passwords from the LDAP database.
+ -ldap
+
+ #
+ # Enforce daily limits on time spent logged in.
+# daily
+
+ 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 appropriate 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
+
+ # 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.
+ #
+ # We do NOT recommend using this. LDAP servers are databases.
+ # They are NOT authentication servers. FreeRADIUS is an
+ # authentication server, and knows what to do with authentication.
+ # LDAP servers do not.
+ #
+# 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 {
+ # If you want privacy to remain, see the
+ # Chargeable-User-Identity attribute from RFC 4372.
+ # If you want to use it just uncomment the line below.
+# cui-inner
+
+ #
+ # If you want to have a log of authentication replies,
+ # un-comment the following line, and enable the
+ # 'detail reply_log' module.
+# 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 {
+ # log failed authentications in SQL, too.
+ -sql
+ 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 still want to use the inner tunnel User-Name then
+ # uncomment the section below, otherwise you may want
+ # to use Chargeable-User-Identity attribute from RFC 4372.
+ # See further on.
+ #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 {
+ # 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
+
+ # 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/src/test/setup/radius-config/freeradius/sites-available/originate-coa b/src/test/setup/radius-config/freeradius/sites-available/originate-coa
new file mode 100644
index 0000000..79e2f1d
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/originate-coa
@@ -0,0 +1,190 @@
+# -*- text -*-
+######################################################################
+#
+# The server can originate Change of Authorization (CoA) or
+# Disconnect request packets. These packets are used to dynamically
+# change the parameters of a users session (bandwidth, etc.), or
+# to forcibly disconnect the user.
+#
+# There are some caveats. Not all NAS vendors support this
+# functionality. Even for the ones that do, it may be difficult to
+# find out what needs to go into a CoA-Request or Disconnect-Request
+# packet. All we can suggest is to read the NAS documentation
+# available from the vendor. That documentation SHOULD describe
+# what information their equipment needs to see in a CoA packet.
+#
+# This information is usually a list of attributes such as:
+#
+# NAS-IP-Address (or NAS-IPv6 address)
+# NAS-Identifier
+# User-Name
+# Acct-Session-Id
+#
+# CoA packets can be originated when a normal Access-Request or
+# Accounting-Request packet is received. Simply update the
+# "coa" list:
+#
+# update coa {
+# User-Name = "%{User-Name}"
+# Acct-Session-Id = "%{Acct-Session-Id}"
+# NAS-IP-Address = "%{NAS-IP-Address}"
+# }
+#
+# And the CoA packet will be sent. You can also send Disconnect
+# packets by using "update disconnect { ...".
+#
+# This "update coa" entry can be placed in any section (authorize,
+# preacct, etc.), EXCEPT for pre-proxy and post-proxy. The CoA
+# packets CANNOT be sent if the original request has been proxied.
+#
+# The CoA functionality works best when the RADIUS server and
+# the NAS receiving CoA packets are on the same network.
+#
+# If "update coa { ... " is used, and then later it becomes necessary
+# to not send a CoA request, the following example can suppress the
+# CoA packet:
+#
+# update control {
+# Send-CoA-Request = No
+# }
+#
+# The default destination of a CoA packet is the NAS (or client)
+# the sent the original Access-Request or Accounting-Request. See
+# raddb/clients.conf for a "coa_server" configuration that ties
+# a client to a specific home server, or to a home server pool.
+#
+# If you need to send the packet to a different destination, update
+# the "coa" list with one of:
+#
+# Packet-Dst-IP-Address = ...
+# Packet-Dst-IPv6-Address = ...
+# Home-Server-Pool = ...
+#
+# That specifies an Ipv4 or IPv6 address, or a home server pool
+# (such as the "coa" pool example below). This use is not
+# recommended, however, It is much better to point the client
+# configuration directly at the CoA server/pool, as outlined
+# earlier.
+#
+# If the CoA port is non-standard, you can also set:
+#
+# Packet-Dst-Port
+#
+# to have the value of the port.
+#
+######################################################################
+
+#
+# When CoA packets are sent to a NAS, the NAS is acting as a
+# server (see RFC 5176). i.e. it has a type (accepts CoA and/or
+# Disconnect packets), an IP address (or IPv6 address), a
+# destination port, and a shared secret.
+#
+# This information *cannot* go into a "client" section. In the future,
+# FreeRADIUS will be able to receive, and to proxy CoA packets.
+# Having the CoA configuration as below means that we can later do
+# load-balancing, fail-over, etc. of CoA servers. If the CoA
+# configuration went into a "client" section, it would be impossible
+# to do proper proxying of CoA requests.
+#
+home_server localhost-coa {
+ type = coa
+
+ #
+ # Note that a home server of type "coa" MUST be a real NAS,
+ # with an ipaddr or ipv6addr. It CANNOT point to a virtual
+ # server.
+ #
+ ipaddr = 127.0.0.1
+ port = 3799
+
+ # This secret SHOULD NOT be the same as the shared
+ # secret in a "client" section.
+ secret = testing1234
+
+ # CoA specific parameters. See raddb/proxy.conf for details.
+ coa {
+ irt = 2
+ mrt = 16
+ mrc = 5
+ mrd = 30
+ }
+}
+
+#
+# CoA servers can be put into pools, just like normal servers.
+#
+home_server_pool coa {
+ type = fail-over
+
+ # Point to the CoA server above.
+ home_server = localhost-coa
+
+ # CoA requests are run through the pre-proxy section.
+ # CoA responses are run through the post-proxy section.
+ virtual_server = originate-coa.example.com
+
+ #
+ # Home server pools of type "coa" cannot (currently) have
+ # a "fallback" configuration.
+ #
+}
+
+#
+# When this virtual server is run, the original request has FINISHED
+# processing. i.e. the reply has already been sent to the NAS.
+# You can access the attributes in the original packet, reply, and
+# control items, but changing them will have NO EFFECT.
+#
+# The CoA packet is in the "proxy-request" attribute list.
+# The CoA reply (if any) is in the "proxy-reply" attribute list.
+#
+server originate-coa.example.com {
+ pre-proxy {
+ update proxy-request {
+ NAS-IP-Address = 127.0.0.1
+ }
+ }
+
+ #
+ # Handle the responses here.
+ #
+ post-proxy {
+ switch "%{proxy-reply:Packet-Type}" {
+ case CoA-ACK {
+ ok
+ }
+
+ case CoA-NAK {
+ # the NAS didn't like the CoA request
+ ok
+ }
+
+ case Disconnect-ACK {
+ ok
+ }
+
+ case Disconnect-NAK {
+ # the NAS didn't like the Disconnect request
+ ok
+ }
+
+ # Invalid packet type. This shouldn't happen.
+ case {
+ fail
+ }
+ }
+
+ #
+ # These methods are run when there is NO response
+ # to the request.
+ #
+ Post-Proxy-Type Fail-CoA {
+ ok
+ }
+
+ Post-Proxy-Type Fail-Disconnect {
+ ok
+ }
+ }
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/proxy-inner-tunnel b/src/test/setup/radius-config/freeradius/sites-available/proxy-inner-tunnel
new file mode 100644
index 0000000..1ce4137
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/proxy-inner-tunnel
@@ -0,0 +1,47 @@
+# -*- text -*-
+######################################################################
+#
+# This is a virtual server that handles *only* inner tunnel
+# requests for EAP-TTLS and PEAP types.
+#
+# $Id$
+#
+######################################################################
+
+server proxy-inner-tunnel {
+
+#
+# This example is very simple. All inner tunnel requests get
+# proxied to another RADIUS server.
+#
+authorize {
+ #
+ # Do other things here, as necessary.
+ #
+ # e.g. run the "realms" module, to decide how to proxy
+ # the inner tunnel request.
+ #
+
+ update control {
+ # You should update this to be one of your realms.
+ Proxy-To-Realm := "example.com"
+ }
+}
+
+authenticate {
+ #
+ # This is necessary so that the inner tunnel EAP-MSCHAPv2
+ # method can be called. That method takes care of turning
+ # EAP-MSCHAPv2 into plain MS-CHAPv2, if necessary.
+ eap
+}
+
+post-proxy {
+ #
+ # This is necessary for LEAP, or if you set:
+ #
+ # proxy_tunneled_request_as_eap = no
+ #
+ eap
+}
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/robust-proxy-accounting b/src/test/setup/radius-config/freeradius/sites-available/robust-proxy-accounting
new file mode 100644
index 0000000..9bf8697
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/robust-proxy-accounting
@@ -0,0 +1,167 @@
+# -*- text -*-
+######################################################################
+#
+# This is a sample configuration for robust proxy accounting.
+# accounting packets are proxied, OR logged locally if all
+# home servers are down. When the home servers come back up,
+# the accounting packets are forwarded.
+#
+# This method enables the server to proxy all packets to the
+# home servers when they're up, AND to avoid writing to the
+# detail file in most situations.
+#
+# In most situations, proxying of accounting messages is done
+# in a "pass-through" fashion. If the home server does not
+# respond, then the proxy server does not respond to the NAS.
+# That means that the NAS must retransmit packets, sometimes
+# forever. This example shows how the proxy server can still
+# respond to the NAS, even if all home servers are down.
+#
+# This configuration could be done MUCH more simply if ALL
+# packets were written to the detail file. But that would
+# involve a lot more disk writes, which may not be a good idea.
+#
+# This file is NOT meant to be used as-is. It needs to be
+# edited to match your local configuration.
+#
+# $Id$
+#
+######################################################################
+
+# (1) Define two home servers.
+home_server home1.example.com {
+ type = acct
+ ipaddr = 192.0.2.10
+ port = 1813
+ secret = testing123
+
+ # Mark this home server alive ONLY when it starts being responsive
+ status_check = request
+ username = "test_user_status_check"
+
+ # Set the response timeout aggressively low.
+ # You MAY have to increase this, depending on tests with
+ # your local installation.
+ response_window = 6
+}
+
+home_server home2.example.com {
+ type = acct
+ ipaddr = 192.0.2.20
+ port = 1813
+ secret = testing123
+
+ # Mark this home server alive ONLY when it starts being responsive
+ status_check = request
+ username = "test_user_status_check"
+
+ # Set the response timeout aggressively low.
+ # You MAY have to increase this, depending on tests with
+ # your local installation.
+ response_window = 6
+}
+
+# (2) Define a virtual server to be used when both of the
+# home servers are down.
+home_server acct_detail.example.com {
+ virtual_server = acct_detail.example.com
+}
+
+# Put all of the servers into a pool.
+home_server_pool acct_pool.example.com {
+ type = load-balance # other types are OK, too.
+
+ home_server = home1.example.com
+ home_server = home2.example.com
+ # add more home_server's here.
+
+ # If all home servers are down, try a home server that
+ # is a local virtual server.
+ fallback = acct_detail.example.com
+
+ # for pre/post-proxy policies
+ virtual_server = home.example.com
+}
+
+# (3) Define a realm for these home servers.
+# It should NOT be used as part of normal proxying decisions!
+realm acct_realm.example.com {
+ acct_pool = acct_pool.example.com
+}
+
+# (4) Define a detail file writer.
+# See raddb/modules/detail.example.com
+
+# (5) Define the virtual server to write the packets to the detail file
+# This will be called when ALL home servers are down, because of the
+# "fallback" configuration in the home server pool.
+server acct_detail.example.com {
+ accounting {
+ detail.example.com
+ }
+}
+
+# (6) Define a virtual server to handle pre/post-proxy re-writing
+server home.example.com {
+ pre-proxy {
+ # Insert pre-proxy rules here
+ }
+
+ post-proxy {
+ # Insert post-proxy rules here
+
+ # This will be called when the CURRENT packet failed
+ # to be proxied. This may happen when one home server
+ # suddenly goes down, even though another home server
+ # may be alive.
+ #
+ # i.e. the current request has run out of time, so it
+ # cannot fail over to another (possibly) alive server.
+ #
+ # We want to respond to the NAS, so that it can stop
+ # re-sending the packet. We write the packet to the
+ # "detail" file, where it will be read, and sent to
+ # another home server.
+ #
+ Post-Proxy-Type Fail {
+ detail.example.com
+ }
+ }
+
+
+ # Read accounting packets from the detail file(s) for
+ # the home server.
+ #
+ # Note that you can have only ONE "listen" section reading
+ # detail files from a particular directory. That is why the
+ # destination host name is used as part of the directory name
+ # below. Having two "listen" sections reading detail files
+ # from the same directory WILL cause problems. The packets
+ # may be read by one, the other, or both "listen" sections.
+ listen {
+ type = detail
+ filename = "${radacctdir}/detail.example.com/detail-*:*"
+ load_factor = 10
+ }
+
+ # All packets read from the detail file are proxied back to
+ # the home servers.
+ #
+ # The normal pre/post-proxy rules are applied to them, too.
+ #
+ # If the home servers are STILL down, then the server stops
+ # reading the detail file, and queues the packets for a later
+ # retransmission. The Post-Proxy-Type "Fail" handler is NOT
+ # called.
+ #
+ # When the home servers come back up, the packets are forwarded,
+ # and the detail file processed as normal.
+ accounting {
+ # You may want accounting policies here...
+
+ update control {
+ Proxy-To-Realm := "acct_realm.example.com"
+ }
+ }
+
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/soh b/src/test/setup/radius-config/freeradius/sites-available/soh
new file mode 100644
index 0000000..9196e5b
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/soh
@@ -0,0 +1,34 @@
+# This is a simple server for the MS SoH requests generated by the
+# peap module - see "eap.conf" for more info
+
+# Requests are ONLY passed through the authorize section, and cannot
+# current be proxied (in any event, the radius attributes used are
+# internal).
+
+server soh-server {
+ authorize {
+ if (SoH-Supported == no) {
+ # client NAKed our request for SoH - not supported, or turned off
+ update config {
+ Auth-Type = Accept
+ }
+ }
+ else {
+ # client replied; check something - this is a local policy issue!
+ if (SoH-MS-Windows-Health-Status =~ /antivirus (warn|error) /) {
+ update config {
+ Auth-Type = Reject
+ }
+ update reply {
+ Reply-Message = "You must have antivirus enabled & installed!"
+ }
+ }
+ else {
+ update config {
+ Auth-Type = Accept
+ }
+ }
+ }
+ }
+}
+
diff --git a/src/test/setup/radius-config/freeradius/sites-available/status b/src/test/setup/radius-config/freeradius/sites-available/status
new file mode 100644
index 0000000..5432203
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/status
@@ -0,0 +1,127 @@
+# -*- text -*-
+######################################################################
+#
+# A virtual server to handle ONLY Status-Server packets.
+#
+# Server statistics can be queried with a properly formatted
+# Status-Server request. See dictionary.freeradius for comments.
+#
+# If radiusd.conf has "status_server = yes", then any client
+# will be able to send a Status-Server packet to any port
+# (listen section type "auth", "acct", or "status"), and the
+# server will respond.
+#
+# If radiusd.conf has "status_server = no", then the server will
+# ignore Status-Server packets to "auth" and "acct" ports. It
+# will respond only if the Status-Server packet is sent to a
+# "status" port.
+#
+# The server statistics are available ONLY on socket of type
+# "status". Queries for statistics sent to any other port
+# are ignored.
+#
+# Similarly, a socket of type "status" will not process
+# authentication or accounting packets. This is for security.
+#
+# $Id: e7d4346310b837d56bffe4c991b4e5680742ebc0 $
+#
+######################################################################
+
+server status {
+ listen {
+ # ONLY Status-Server is allowed to this port.
+ # ALL other packets are ignored.
+ type = status
+
+ ipaddr = 127.0.0.1
+ port = 18121
+ }
+
+ #
+ # We recommend that you list ONLY management clients here.
+ # i.e. NOT your NASes or Access Points, and for an ISP,
+ # DEFINITELY not any RADIUS servers that are proxying packets
+ # to you.
+ #
+ # If you do NOT list a client here, then any client that is
+ # globally defined (i.e. all of them) will be able to query
+ # these statistics.
+ #
+ # Do you really want your partners seeing the internal details
+ # of what your RADIUS server is doing?
+ #
+ client admin {
+ ipaddr = 127.0.0.1
+ secret = adminsecret
+ }
+
+ #
+ # Simple authorize section. The "Autz-Type Status-Server"
+ # section will work here, too. See "raddb/sites-available/default".
+ authorize {
+ ok
+
+ # respond to the Status-Server request.
+ Autz-Type Status-Server {
+ ok
+ }
+ }
+}
+
+# Statistics can be queried via a number of methods:
+#
+# All packets received/sent by the server (1 = auth, 2 = acct)
+# FreeRADIUS-Statistics-Type = 3
+#
+# All packets proxied by the server (4 = proxy-auth, 8 = proxy-acct)
+# FreeRADIUS-Statistics-Type = 12
+#
+# All packets sent && received:
+# FreeRADIUS-Statistics-Type = 15
+#
+# Internal server statistics:
+# FreeRADIUS-Statistics-Type = 16
+#
+# All packets for a particular client (globally defined)
+# FreeRADIUS-Statistics-Type = 35
+# FreeRADIUS-Stats-Client-IP-Address = 192.0.2.1
+#
+# All packets for a client attached to a "listen" ip/port
+# FreeRADIUS-Statistics-Type = 35
+# FreeRADIUS-Stats-Client-IP-Address = 192.0.2.1
+# FreeRADIUS-Stats-Server-IP-Address = 127.0.0.1
+# FreeRADIUS-Stats-Server-Port = 1812
+#
+# All packets for a "listen" IP/port
+# FreeRADIUS-Statistics-Type = 67
+# FreeRADIUS-Stats-Server-IP-Address = 127.0.0.1
+# FreeRADIUS-Stats-Server-Port = 1812
+#
+# All packets for a home server IP / port
+# FreeRADIUS-Statistics-Type = 131
+# FreeRADIUS-Stats-Server-IP-Address = 192.0.2.2
+# FreeRADIUS-Stats-Server-Port = 1812
+
+#
+# You can also get exponentially weighted moving averages of
+# response times (in usec) of home servers. Just set the config
+# item "historic_average_window" in a home_server section.
+#
+# By default it is zero (don't calculate it). Useful values
+# are between 100, and 10,000. The server will calculate and
+# remember the moving average for this window, and for 10 times
+# that window.
+#
+
+#
+# Some of this could have been simplified. e.g. the proxy-auth and
+# proxy-acct bits aren't completely necessary. But using them permits
+# the server to be queried for ALL inbound && outbound packets at once.
+# This gives a good snapshot of what the server is doing.
+#
+# Due to internal limitations, the statistics might not be exactly up
+# to date. Do not expect all of the numbers to add up perfectly.
+# The Status-Server packets are also counted in the total requests &&
+# responses. The responses are counted only AFTER the response has
+# been sent.
+#
diff --git a/src/test/setup/radius-config/freeradius/sites-available/tls b/src/test/setup/radius-config/freeradius/sites-available/tls
new file mode 100644
index 0000000..0874951
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/tls
@@ -0,0 +1,506 @@
+######################################################################
+#
+# Initial implementation of RADIUS over TLS (radsec)
+#
+######################################################################
+
+listen {
+ ipaddr = *
+ port = 2083
+
+ #
+ # TCP and TLS sockets can accept Access-Request and
+ # Accounting-Request on the same socket.
+ #
+ # auth = only Access-Request
+ # acct = only Accounting-Request
+ # auth+acct = both
+ #
+ type = auth+acct
+
+ # For now, only TCP transport is allowed.
+ proto = tcp
+
+ # Send packets to the default virtual server
+ virtual_server = default
+
+ clients = radsec
+
+ #
+ # Connection limiting for sockets with "proto = tcp".
+ #
+ limit {
+ #
+ # Limit the number of simultaneous TCP connections to the socket
+ #
+ # The default is 16.
+ # Setting this to 0 means "no limit"
+ max_connections = 16
+
+ # The per-socket "max_requests" option does not exist.
+
+ #
+ # 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 received over the connection for
+ # this time, the connection will be closed.
+ #
+ # Setting this to 0 means "no timeout".
+ #
+ # We STRONGLY RECOMMEND that you set an idle timeout.
+ #
+ idle_timeout = 30
+ }
+
+ # This is *exactly* the same configuration as used by the EAP-TLS
+ # module. It's OK for testing, but for production use it's a good
+ # idea to use different server certificates for EAP and for RADIUS
+ # transport.
+ #
+ # If you want only one TLS configuration for multiple sockets,
+ # then we suggest putting "tls { ...}" into radiusd.conf.
+ # The subsection below can then be changed into a reference:
+ #
+ # tls = ${tls}
+ #
+ # Which means "the tls sub-section is not here, but instead is in
+ # the top-level section called 'tls'".
+ #
+ # If you have multiple tls configurations, you can put them into
+ # sub-sections of a top-level "tls" section. There's no need to
+ # call them all "tls". You can then use:
+ #
+ # tls = ${tls.site1}
+ #
+ # to refer to the "site1" sub-section of the "tls" section.
+ #
+ tls {
+ private_key_password = whatever
+ private_key_file = ${certdir}/server.pem
+
+ # If Private key & Certificate are located in
+ # the same file, then private_key_file &
+ # certificate_file must contain the same file
+ # name.
+ #
+ # If ca_file (below) is not used, then the
+ # certificate_file below MUST include not
+ # only the server certificate, but ALSO all
+ # of the CA certificates used to sign the
+ # server certificate.
+ certificate_file = ${certdir}/server.pem
+
+ # Trusted Root CA list
+ #
+ # ALL of the CA's in this list will be trusted
+ # to issue client certificates for authentication.
+ #
+ # In general, you should use self-signed
+ # certificates for 802.1x (EAP) authentication.
+ # In that case, this CA file should contain
+ # *one* CA certificate.
+ #
+ # This parameter is used only for EAP-TLS,
+ # when you issue client certificates. If you do
+ # not use client certificates, and you do not want
+ # to permit EAP-TLS authentication, then delete
+ # this configuration item.
+ ca_file = ${cadir}/ca.pem
+
+ #
+ # For DH cipher suites to work, you have to
+ # run OpenSSL to create the DH file first:
+ #
+ # openssl dhparam -out certs/dh 1024
+ #
+ dh_file = ${certdir}/dh
+
+ #
+ # If your system doesn't have /dev/urandom,
+ # you will need to create this file, and
+ # periodically change its contents.
+ #
+ # For security reasons, FreeRADIUS doesn't
+ # write to files in its configuration
+ # directory.
+ #
+# random_file = ${certdir}/random
+
+ #
+ # The default fragment size is 1K.
+ # However, it's possible to send much more data than
+ # that over a TCP connection. The upper limit is 64K.
+ # Setting the fragment size to more than 1K means that
+ # there are fewer round trips when setting up a TLS
+ # connection. But only if the certificates are large.
+ #
+ fragment_size = 8192
+
+ # include_length is a flag which is
+ # by default set to yes If set to
+ # yes, Total Length of the message is
+ # included in EVERY packet we send.
+ # If set to no, Total Length of the
+ # message is included ONLY in the
+ # First packet of a fragment series.
+ #
+ # include_length = yes
+
+ # Check the Certificate Revocation List
+ #
+ # 1) Copy CA certificates and CRLs to same directory.
+ # 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
+ # 'c_rehash' is OpenSSL's command.
+ # 3) uncomment the line below.
+ # 5) Restart radiusd
+ # check_crl = yes
+ ca_path = ${cadir}
+
+ #
+ # If check_cert_issuer is set, the value will
+ # be checked against the DN of the issuer in
+ # the client certificate. If the values do not
+ # match, the certificate verification will fail,
+ # rejecting the user.
+ #
+ # In 2.1.10 and later, this check can be done
+ # more generally by checking the value of the
+ # TLS-Client-Cert-Issuer attribute. This check
+ # can be done via any mechanism you choose.
+ #
+ # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
+
+ #
+ # If check_cert_cn is set, the value will
+ # be xlat'ed and checked against the CN
+ # in the client certificate. If the values
+ # do not match, the certificate verification
+ # will fail rejecting the user.
+ #
+ # This check is done only if the previous
+ # "check_cert_issuer" is not set, or if
+ # the check succeeds.
+ #
+ # In 2.1.10 and later, this check can be done
+ # more generally by checking the value of the
+ # TLS-Client-Cert-CN attribute. This check
+ # can be done via any mechanism you choose.
+ #
+ # check_cert_cn = %{User-Name}
+ #
+ # Set this option to specify the allowed
+ # TLS cipher suites. The format is listed
+ # in "man 1 ciphers".
+ cipher_list = "DEFAULT"
+
+ #
+
+ # This configuration entry should be deleted
+ # once the server is running in a normal
+ # configuration. It is here ONLY to make
+ # initial deployments easier.
+ #
+ #
+ # This is enabled in eap.conf, so we don't need it here.
+ #
+# make_cert_command = "${certdir}/bootstrap"
+
+ #
+ # Session resumption / fast reauthentication
+ # cache.
+ #
+ # The cache contains the following information:
+ #
+ # session Id - unique identifier, managed by SSL
+ # User-Name - from the Access-Accept
+ # Stripped-User-Name - from the Access-Request
+ # Cached-Session-Policy - from the Access-Accept
+ #
+ # The "Cached-Session-Policy" is the name of a
+ # policy which should be applied to the cached
+ # session. This policy can be used to assign
+ # VLANs, IP addresses, etc. It serves as a useful
+ # way to re-apply the policy from the original
+ # Access-Accept to the subsequent Access-Accept
+ # for the cached session.
+ #
+ # On session resumption, these attributes are
+ # copied from the cache, and placed into the
+ # reply list.
+ #
+ # You probably also want "use_tunneled_reply = yes"
+ # when using fast session resumption.
+ #
+ cache {
+ #
+ # Enable it. The default is "no".
+ # Deleting the entire "cache" subsection
+ # Also disables caching.
+ #
+ # You can disallow resumption for a
+ # particular user by adding the following
+ # attribute to the control item list:
+ #
+ # Allow-Session-Resumption = No
+ #
+ # If "enable = no" below, you CANNOT
+ # enable resumption for just one user
+ # by setting the above attribute to "yes".
+ #
+ enable = no
+
+ #
+ # Lifetime of the cached entries, in hours.
+ # The sessions will be deleted after this
+ # time.
+ #
+ lifetime = 24 # hours
+
+ #
+ # The maximum number of entries in the
+ # cache. Set to "0" for "infinite".
+ #
+ # This could be set to the number of users
+ # who are logged in... which can be a LOT.
+ #
+ max_entries = 255
+
+ #
+ # Internal "name" of the session cache.
+ # Used to distinguish which TLS context
+ # sessions belong to.
+ #
+ # The server will generate a random value
+ # if unset. This will change across server
+ # restart so you MUST set the "name" if you
+ # want to persist sessions (see below).
+ #
+ # If you use IPv6, change the "ipaddr" below
+ # to "ipv6addr"
+ #
+ #name = "TLS ${..ipaddr} ${..port} ${..proto}"
+
+ #
+ # Simple directory-based storage of sessions.
+ # Two files per session will be written, the SSL
+ # state and the cached VPs. This will persist session
+ # across server restarts.
+ #
+ # The server will need write perms, and the directory
+ # should be secured from anyone else. You might want
+ # a script to remove old files from here periodically:
+ #
+ # find ${logdir}/tlscache -mtime +2 -exec rm -f {} \;
+ #
+ # This feature REQUIRES "name" option be set above.
+ #
+ #persist_dir = "${logdir}/tlscache"
+ }
+
+ #
+ # Require a client certificate.
+ #
+ require_client_cert = yes
+
+ #
+ # As of version 2.1.10, client certificates can be
+ # validated via an external command. This allows
+ # dynamic CRLs or OCSP to be used.
+ #
+ # This configuration is commented out in the
+ # default configuration. Uncomment it, and configure
+ # the correct paths below to enable it.
+ #
+ verify {
+ # A temporary directory where the client
+ # certificates are stored. This directory
+ # MUST be owned by the UID of the server,
+ # and MUST not be accessible by any other
+ # users. When the server starts, it will do
+ # "chmod go-rwx" on the directory, for
+ # security reasons. The directory MUST
+ # exist when the server starts.
+ #
+ # You should also delete all of the files
+ # in the directory when the server starts.
+ # tmpdir = /tmp/radiusd
+
+ # The command used to verify the client cert.
+ # We recommend using the OpenSSL command-line
+ # tool.
+ #
+ # The ${..ca_path} text is a reference to
+ # the ca_path variable defined above.
+ #
+ # The %{TLS-Client-Cert-Filename} is the name
+ # of the temporary file containing the cert
+ # in PEM format. This file is automatically
+ # deleted by the server when the command
+ # returns.
+ # client = "/path/to/openssl verify -CApath ${..ca_path} %{TLS-Client-Cert-Filename}"
+ }
+ }
+}
+
+clients radsec {
+ client 127.0.0.1 {
+ ipaddr = 127.0.0.1
+
+ #
+ # Ensure that this client is TLS *only*.
+ #
+ proto = tls
+
+ #
+ # TCP clients can have any shared secret.
+ #
+ # TLS clients MUST have the shared secret
+ # set to "radsec". Or, for "proto = tls",
+ # you can omit the secret, and it will
+ # automatically be set to "radsec".
+ #
+ secret = radsec
+
+ #
+ # You can also use a "limit" section here.
+ # See raddb/clients.conf for examples.
+ #
+ # Note that BOTH limits are applied. You
+ # should therefore set the "listen" limits
+ # higher than the ones for each individual
+ # client.
+ #
+ }
+}
+
+home_server tls {
+ ipaddr = 127.0.0.1
+ port = 2083
+ type = auth
+ secret = testing123
+ proto = tcp
+ status_check = none
+
+ tls {
+ private_key_password = whatever
+ private_key_file = ${certdir}/client.pem
+
+ # If Private key & Certificate are located in
+ # the same file, then private_key_file &
+ # certificate_file must contain the same file
+ # name.
+ #
+ # If ca_file (below) is not used, then the
+ # certificate_file below MUST include not
+ # only the server certificate, but ALSO all
+ # of the CA certificates used to sign the
+ # server certificate.
+ certificate_file = ${certdir}/client.pem
+
+ # Trusted Root CA list
+ #
+ # ALL of the CA's in this list will be trusted
+ # to issue client certificates for authentication.
+ #
+ # In general, you should use self-signed
+ # certificates for 802.1x (EAP) authentication.
+ # In that case, this CA file should contain
+ # *one* CA certificate.
+ #
+ # This parameter is used only for EAP-TLS,
+ # when you issue client certificates. If you do
+ # not use client certificates, and you do not want
+ # to permit EAP-TLS authentication, then delete
+ # this configuration item.
+ ca_file = ${cadir}/ca.pem
+
+ #
+ # For DH cipher suites to work, you have to
+ # run OpenSSL to create the DH file first:
+ #
+ # openssl dhparam -out certs/dh 1024
+ #
+ dh_file = ${certdir}/dh
+ random_file = ${certdir}/random
+
+ #
+ # The default fragment size is 1K.
+ # However, TLS can send 64K of data at once.
+ # It can be useful to set it higher.
+ #
+ fragment_size = 8192
+
+ # include_length is a flag which is
+ # by default set to yes If set to
+ # yes, Total Length of the message is
+ # included in EVERY packet we send.
+ # If set to no, Total Length of the
+ # message is included ONLY in the
+ # First packet of a fragment series.
+ #
+ # include_length = yes
+
+ # Check the Certificate Revocation List
+ #
+ # 1) Copy CA certificates and CRLs to same directory.
+ # 2) Execute 'c_rehash <CA certs&CRLs Directory>'.
+ # 'c_rehash' is OpenSSL's command.
+ # 3) uncomment the line below.
+ # 5) Restart radiusd
+ # check_crl = yes
+ ca_path = ${cadir}
+
+ #
+ # If check_cert_issuer is set, the value will
+ # be checked against the DN of the issuer in
+ # the client certificate. If the values do not
+ # match, the certificate verification will fail,
+ # rejecting the user.
+ #
+ # In 2.1.10 and later, this check can be done
+ # more generally by checking the value of the
+ # TLS-Client-Cert-Issuer attribute. This check
+ # can be done via any mechanism you choose.
+ #
+ # check_cert_issuer = "/C=GB/ST=Berkshire/L=Newbury/O=My Company Ltd"
+
+ #
+ # If check_cert_cn is set, the value will
+ # be xlat'ed and checked against the CN
+ # in the client certificate. If the values
+ # do not match, the certificate verification
+ # will fail rejecting the user.
+ #
+ # This check is done only if the previous
+ # "check_cert_issuer" is not set, or if
+ # the check succeeds.
+ #
+ # In 2.1.10 and later, this check can be done
+ # more generally by checking the value of the
+ # TLS-Client-Cert-CN attribute. This check
+ # can be done via any mechanism you choose.
+ #
+ # check_cert_cn = %{User-Name}
+ #
+ # Set this option to specify the allowed
+ # TLS cipher suites. The format is listed
+ # in "man 1 ciphers".
+ cipher_list = "DEFAULT"
+ }
+
+}
+
+home_server_pool tls {
+ type = fail-over
+ home_server = tls
+}
+
+realm tls {
+ auth_pool = tls
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/virtual.example.com b/src/test/setup/radius-config/freeradius/sites-available/virtual.example.com
new file mode 100644
index 0000000..b78a520
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/virtual.example.com
@@ -0,0 +1,26 @@
+# -*- text -*-
+######################################################################
+#
+# Sample virtual server for internally proxied requests.
+#
+# See the "realm virtual.example.com" example in "proxy.conf".
+#
+# $Id: 211daab3af0161aefa4990b137ba2739257f8326 $
+#
+######################################################################
+
+#
+# Sample contents: just do everything that the default configuration does.
+#
+# You WILL want to edit this to your local needs. We suggest copying
+# the "default" file here, and then editing it. That way, any
+# changes to the "default" file will not affect this virtual server,
+# and vice-versa.
+#
+# When this virtual server receives the request, the original
+# attributes can be accessed as "outer.request", "outer.control", etc.
+# See "man unlang" for more details.
+#
+server virtual.example.com {
+$INCLUDE ${confdir}/sites-available/default
+}
diff --git a/src/test/setup/radius-config/freeradius/sites-available/vmps b/src/test/setup/radius-config/freeradius/sites-available/vmps
new file mode 100644
index 0000000..64d5e93
--- /dev/null
+++ b/src/test/setup/radius-config/freeradius/sites-available/vmps
@@ -0,0 +1,98 @@
+# -*- text -*-
+######################################################################
+#
+# As of version 2.0.0, the server also supports the VMPS
+# protocol.
+#
+# $Id: 8703902cafb5cc2b869dc42da9f554da313825ad $
+#
+######################################################################
+
+server vmps {
+ listen {
+ # VMPS sockets only support IPv4 addresses.
+ ipaddr = *
+
+ # Port on which to listen.
+ # Allowed values are:
+ # integer port number
+ # 1589 is the default VMPS port.
+ port = 1589
+
+ # Type of packets to listen for. Here, it is VMPS.
+ type = vmps
+
+ # Some systems support binding to an interface, in addition
+ # to the IP address. This feature isn't strictly necessary,
+ # but for sites with many IP addresses on one interface,
+ # it's useful to say "listen on all addresses for
+ # eth0".
+ #
+ # If your system does not support this feature, you will
+ # get an error if you try to use it.
+ #
+ # interface = eth0
+ }
+
+ # If you have switches that are allowed to send VMPS, but NOT
+ # RADIUS packets, then list them here as "client" sections.
+ #
+ # Note that for compatibility with RADIUS, you still have to
+ # list a "secret" for each client, though that secret will not
+ # be used for anything.
+
+
+ # And the REAL contents. This section is just like the
+ # "post-auth" section of radiusd.conf. In fact, it calls the
+ # "post-auth" component of the modules that are listed here.
+ # But it's called "vmps" to highlight that it's for VMPS.
+ #
+ vmps {
+ #
+ # Some requests may not have a MAC address. Try to
+ # create one using other attributes.
+ if (!VMPS-Mac) {
+ if (VMPS-Ethernet-Frame =~ /0x.{12}(..)(..)(..)(..)(..)(..).*/) {
+ update request {
+ VMPS-Mac = "%{1}:%{2}:%{3}:%{4}:%{5}:%{6}"
+ }
+ }
+ else {
+ update request {
+ VMPS-Mac = "%{VMPS-Cookie}"
+ }
+ }
+ }
+
+ # Do a simple mapping of MAC to VLAN.
+ #
+ # See radiusd.conf for the definition of the "mac2vlan"
+ # module.
+ #
+ #mac2vlan
+
+ # required VMPS reply attributes
+ update reply {
+ VMPS-Packet-Type = VMPS-Join-Response
+ VMPS-Cookie = "%{VMPS-Mac}"
+
+ VMPS-VLAN-Name = "please_use_real_vlan_here"
+
+ #
+ # If you have VLAN's in a database, you can select
+ # the VLAN name based on the MAC address.
+ #
+ #VMPS-VLAN-Name = "%{sql:select ... where mac='%{VMPS-Mac}'}"
+ }
+
+ # correct reply packet type for reconfirmation requests
+ #
+ if (VMPS-Packet-Type == VMPS-Reconfirm-Request){
+ update reply {
+ VMPS-Packet-Type := VMPS-Reconfirm-Response
+ }
+ }
+ }
+
+ # Proxying of VMPS requests is NOT supported.
+}