Log InVirtual servers provide a powerful way to define unique policies for different traffic sources. When policy rules for each traffic source are defined in their own separate configuration file, it’s a lot simpler to define them, understand them, and debug them.
Virtual servers are unique to FreeRADIUS. Other RADIUS servers typically have one global policy, with sub-policies defined in a series of nested if/else statements. Unfortunately, the logic expressed in the if/else statements quickly becomes difficult to understand and maintain for all but the simplest scenarios. As the needs of the network infrastructure evolves over time, the logic statements grow in complexity and become error prone and difficult to debug. Changes to one piece may result in unexpected side effects.
Many enterprises need to support clients requests from Wi-Fi, wired ethernet, VPN, and FTP. Corporate network policies might have different requirements for each source, and assign different replies for each source. Do you really want changes to the FTP policy to take down your WiFi? If not, then virtual servers are the answer.
Let’s consider an example scenario, which shows how useful virtual servers are.
A company with limited VPN licenses might have rules such as:
- Only salespeople and C-suite executives are allowed to use the VPN during business hours;
- Outside of business hours, other employees may sign in through the VPN but for no more than one hour at a time;
- Salespeople and C-suite executives have no time restrictions outside of office hours.
For network access Wi-Fi:
- No time limits on network access for any employees;
- CEO and salespeople are assigned more bandwidth than other employees.
This relatively simple scenario turns into a dense and complex series of logic statements when there is only a single global configuration file. However, it is easily handled with the FreeRADIUS virtual server capability.
In FreeRADIUS, a separate “virtual server” configuration file can be created for each traffic source (VPN or WiFi). The policy rules for each traffic source can typically be expressed with only a few lines of code. The key is noticing that the WiFi rules don’t mention VPN, and the VPN rules don’t mention WiFi. So why would those rules be placed into the same policy?
Instead, the rules should be placed into different policies. Separating the policies in this way makes it clear and unambiguous which rules apply in which scenario. If and when the rules change in the future, it becomes trivial to update the policies, without risking breaking the logic for other parts of the system.
The virtual servers allow the WiFi policies to be applied only to WiFi, and the VPN policies to be applied only to the VPN. When you want to debug packets coming from the WiFi system, the debug output will contain only references to WiFi policies. There will not be any if / then / else confusion of “oops, this packet doesn’t look like VPN access, so we won’t run the VPN rules”. Instead, the policies are separated, and “siloed” into their respective areas of operation.
Virtual servers can be created which apply to specific clients, such as VPN concentrator versus WiFI Access Points. Virtual servers can also be tied to different server IP addresses or ports. This degree of granularity allows system administrators tremendous flexibility in customizing the behaviour of the server. All of the devices think that they are talking to “the RADIUS server”. But in reality, there isn’t one “RADIUS server”, there are many. In fact, there is really one RADIUS server for each policy!
Another benefit with this approach is that all of the “virtual” RADIUS servers share access to databases such as SQL, LDAP, Active Directory, etc. There is no need to set up and configure a RADIUS server for each scenario, each of which has only minor differences from the others. Instead, you can set up one RADIUS server, and then with that configuration, create multiple “virtual” servers, one for each kind of RADIUS client.
There is additional documentation on configuring virtual servers, as well as some example configurations on the FreeRADIUS site that we maintain.
Who should use FreeRADIUS virtual servers?
The primary use case for virtual servers is to provide specific policies for different kinds of RADIUS clients. Generally speaking, organizations that support a variety of clients (DSL, 802.1x, VPN, FTP etc) and a range of user roles with different network permissions will find this feature most useful.
Large corporate enterprises and educational institutions are the most common users of virtual servers. ISPs on the other hand, do not generally have the same kind of variety of traffic sources and user roles. User roles for ISPs generally focus on aspects such data limits and bandwidth, not on different kinds of access policies. Because the policies used by ISP tend to be simpler, they are less likely to leverage the benefits of virtual servers.
Need help with virtual servers?
Look no further. We’re the team that developed it. We’re the team that has created and maintained FreeRADIUS for the last 20 years. Our specialty is designing and deploying complex RADIUS infrastructure. If you want the world experts on FreeRADIUS to help you with your project, see our support page to get pricing information.
