3 FreeRADIUS 2.0 supports virtual servers. This is probably the
4 single largest change that is NOT backwards compatible with 1.x.
6 The virtual servers do NOT have to be set up with the
7 "sites-available" and "sites-enabled" directories. You can still have
8 one "radiusd.conf" file, and put the server configuration there:
22 The power of virtual servers lies in their ability to separate
23 policies. A policy can be placed into a virtual server, where it is
24 guaranteed to affect only the requests that are passed through that
25 virtual server. In 1.x, the policies were global, and it sometimes
26 took much effort to write a policy so that it only applied in certain
30 2. What do we mean by "virtual server"?
33 A virtual server is a (nearly complete) RADIUS server, just like a
34 configuration for FreeRADIUS 1.x. However, FreeRADIUS can now run
35 multiple virtual servers at the same time. The virtual servers can
36 even proxy requests to each other!
38 The simplest way to create a virtual server is to take the all of
39 the request processing sections from radius.conf, ("authorize" ,
40 "authenticate", etc.) and wrap them in a "server {}" block, as above.
42 You can create another virtual server by:
44 1) defining a new "server foo {...}" section in radiusd.conf
45 2) Putting the normal "authorize", etc. sections inside of it
46 3) Adding a "listen" section *inside* of the "server" section.
60 Cleartext-Password := "bob"
71 With that text added to "radiusd.conf", run the server in debugging
72 mode (radiusd -X), and in another terminal window, type:
74 $ radtest bob bob localhost:2000 0 testing123
76 You should see the server return an Access-Accept.
79 3. Capabilities and limitations
82 The only sub-sections that can appear in a virtual server section
96 All other configuration parameters (modules, etc.) are global.
98 Inside of a virtual server, the authorize, etc. sections have their
99 normal meaning, and can contain anything that an authorize section
100 could contain in 1.x.
102 When a "listen" section is inside of a virtual server definition, it
103 means that all requests sent to that IP/port will be processed through
104 the virtual server. There cannot be two "listen" sections with the
105 same IP address and port number.
107 When a "client" section is inside of a virtual server definition, it
108 means that that client is known only to the "listen" sections that are
109 also inside of that virtual server. Not only is this client
110 definition available only to this virtual server, but the details of
111 the client configuration is also available only to this virtual
114 i.e. Two virtual servers can listen on different IP address and
115 ports, but both can have a client with IP address 127.0.0.1. The
116 shared secret for that client can be different for each virtual
120 4. More complex "listen" capabilities
122 The "listen" sections have a few additional configuration items that
123 were not in 1.x, and were not mentioned above. These configuration
124 items enable almost any mapping of IP / port to clients to virtual
127 The configuration items are:
129 virtual_server = <name>
131 If set, all requests sent to this IP / port are processed
132 through the named virtual server.
134 This directive can be used only for "listen" sections
135 that are global. i.e. It CANNOT be used if the
136 "listen" section is inside of a virtual server.
140 If set, the "listen" section looks for a "clients" section:
146 It looks inside of that named "clients" section for
147 "client" subsections, at least one of which must
148 exist. Each client in that section is added to the
149 list of known clients for this IP / port. No other
152 If it is set, it over-rides the list of clients (if
153 any) in the same virtual server. Note that the
154 clients are NOT additive!
156 If it is not set, then the clients from the current
157 virtual server (if any) are used. If there are no
158 clients in this virtual server, then the global
161 i.e. The most specific directive is used:
162 * configuration in this "listen" section
163 * clients in the same virtual server
166 The directives are also *exclusive*, not *additive*.
167 If you have one client in a virtual server, and
168 another client referenced from a "listen" section,
169 then that "listen" section will ONLY use the second
170 client. It will NOT use both clients.
173 5. More complex "client" capabilities
175 The "client" sections have a few additional configuration items that
176 were not in 1.x, and were not mentioned above. These configuration
177 items enable almost any mapping of IP / port to clients to virtual
180 The configuration items are:
182 virtual_server = <name>
184 If set, all requests from this client are processed
185 through the named virtual server.
187 This directive can be used only for "client" sections
188 that are global. i.e. It CANNOT be used if the
189 "client" section is inside of a virtual server.
191 If the "listen" section has a "server" entry, and a matching
192 client is found ALSO with a "server" entry, then the clients server is
193 used for that request.
199 Listening on one socket, and mapping requests from two clients to
200 two different servers.
207 virtual_server = server_one
211 virtual_server = server_two
226 This could also be done as:
231 virtual_server = server_one
238 virtual_server = server_two
253 In this case, the default server for the socket is "server_one", so
254 there is no need to set that in the client "one" configuration. The
255 "server_two" configuration for client "two" over-rides the default
256 setting for the socket.
258 Note that the following configuration will NOT work:
262 virtual_server = server_one
283 In this example, client "two" is hidden inside of the virtual
284 server, where the "listen" section cannot find it.
289 This section outlines a number of examples, with alternatives.
291 One server, multiple sockets
292 - multiple "listen" sections in a "server" section
294 one server per client
295 - define multiple servers
296 - have a global "listen" section
297 - have multiple global "clients", each with "virtual_server = X"
299 two servers, each with their own sockets
300 - define multiple servers
301 - put "client" sections into each "server"
302 - put a "listen" section into each "server"
304 Each server can list the same client IP, and the secret
307 two sockets, sharing a list of clients, but pointing to different servers
308 - define global "listen" sections
309 - in each, set "virtual_server = X"
310 - in each, set "clients = Y"
311 - define "clients Y" section, containing multiple clients.
313 This also means that you can have a third socket, which
314 doesn't share any of these clients.
317 8. How to decide what to do
320 If you want *completely* separate policies for a socket or a client,
321 then create a separate virtual server. Then, map the request to that
322 server by setting configuration entries in a "listen" section or in a
325 Start off with the common cases first. If most of the clients
326 and/or sockets get a particular policy, make that policy the default.
327 Configure it without paying attention to the sockets or clients you
328 want to add later, and without adding a second virtual server. Once
329 it works, then add the second virtual server.
331 If you want to re-use the previously defined sockets with the second
332 virtual server, then you will need one or more global "client"
333 sections. Those clients will contain a "virtual_server = ..." entry
334 that will direct requests from those clients to the appropriate