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.
+}