VPN server

From securityrouter.org, an OpenBSD-based firewall
Jump to: navigation, search

The VPN server allows external users and computers to authenticate in order to gain specific network access privileges. The VPN server supports both the PPTP and L2TP protocol.


Users may be added locally with username and password, or they may be authenticated remotely using RADIUS. Locally added users have precedence over RADIUS users in case conflicts occur.

Passwords are stored in clear-text, obfuscated with base64 (unsecured, only designed to prevent "shoulder-surfing" attacks when viewing router configurations). Saving the passwords in clear-text is unfortunately necessary because of the way that the MSCHAP authentication works.

IP addresses

Users should not be filtered/restricted by IP address in the firewall, groups should be used (see Groups below). The address pool (default: is dynamic. However if an address is sent in the RADIUS reply it will be used (but it's not recommended).

Address pool

The VPN server doesn't proxy ARP for users by default, therefore it relies on routing. By default it is not possible to use the same address pool as any locally connected network, the address pool should be unique. So if the VPN server appliance is not the default gateway for a local network resource, additional routes may be needed (for the address pool) on the network.

Proxy ARP

If you want to add vpn users to your local network. You need to per-allocate a sub-portion of your subnet to the vpn-server. This in combination with the proxy-arp will cause the firewall to claim all IP-addresses in the subnet (

interface em1 {
    group "lan"
vpn-server {
    authentication "lan" {
        user "test" {
            password "test"


In case you don't want to use the VPN server as default gateway, you may configure the VPN server to announce custom static routes.

vpn-server {


A group (authentication) stores a set of users which shares a common access policy configured in the firewall using interface groups. If per-user policies are required, you could add each user to a separate group.

By default, the group "lan" is used. In which case the users (in that group) shares the same firewall rules as your "lan" interface group.

Each group adds a tun interfaces, these interfaces are configured as members of different interface groups (called after the authentication group) and should never be referred to by interface name (tun0, tun1..) as they may change name without prior notice.

If the group is configured as a RADIUS source, RADIUS authenticated users may be assigned to this group using the Filter-Id AVP. If no Filter-Id is sent by the RADIUS server. The RADIUS group configured as radius default will be used. Further if a Filter-Id is sent but it doesn't match a group the user will not be authenticated regardless if the password was correct.

Search domain

The VPN server support DNS suffix delegation (search-domain) via stateless DHCP. A DNS suffix allows for resources and servers to be accessed by its host name (eg. DC01 instead of DC01.MYDOMAIN.LOCAL) a network configuration that is commonly used in Microsoft Windows™ networks.

vpn-server {
   search-domain dc01.mydomain.local


Noticed in Apple iOS 6.1 and 7.0 (possible other), if you enable the "Send All Traffic" on a VPN connection, it doesn't ask for a search domain. In order to still send all traffic, you should disable the "Send All Traffic" feature and add as an VPN route.


To configure RADIUS authentication you must first enable RADIUS globally for the vpn-server, and then choose which group(s) should be allowed to handle external users. Multiple (backup) servers may be added. The accounting directive is optional.

RADIUS uses port 1812, and accounting the same server and secret, but port 1813.

vpn-server {
   authentication "lan" {
      radius default
   authentication "sales" {
   radius {
      secret "my secret"

In order to separate users into different groups a "Filter-Id" AVP may be sent containing the group name (eg. "sales"). If no Filter-Id AVP is sent the user will be associated with the group configured as radius default. This is probably the most common case when activating RADIUS without doing any explicit user configuration on the RADIUS server. If a Filter-Id is sent, but doesn't match a radius configured group. The user will not be authenticated.

Microsoft Active Directory

In order to use a Active Directory (AD) as a user source you must install the Network Policy Server (do not confuse RADIUS with LDAP). Configure a RADIUS client (for the appliance IP) and enable "Dial-in" access per user, either configure "Allow Access" or "Control access through NPS Network Policy". If configured through a "NPS Network Policy" a Filter-Id (group membership) may be sent for a group of users according to the user directory layout (eg. OU=management, warehouse, sales).

This guide is for Windows Server 2008, additional resources on how to activate RADIUS may be useful as well.

  1. Install the NPS service included in the "Network Policy and Access Services" package (usually through the "Add Role" methodology).
  2. Open the "Network Policy Server" (under "Administrative Tools"), add a "RADIUS Client" with a shared secret.
  3. Open the "Active Directory Users and Computers" tool, change the user property "Dial-in" to "Allow Access".

These three steps will get you started. However if you want to separate users into different groups. You should instead of "Allow Access" use the "Control access through NPS Network Policy" option and continue the configuration.

  1. Create a "Network policy" (only changes from the default are noted), with the condition "User Groups" (a User group eg. "DOMAIN\Sales"), click through until you're asked to configure "Standard RADIUS Attribute", add an attribute called "Filter-Id". It should be added as a string (eg. "sales") representing the "User Group" previously configured.
  2. The order of Network policies are of importance, so move this policy to a appropriate position (at the top) as they are evaluated top-down.

A group must now be added to the VPN server called "sales", with RADIUS activated. Don't forget to add firewall rules.


As an alternative to Active Directory on the Windows platform, TekRADIUS allows simple user management and grouping tool. Not much configuration is needed (except for the RADIUS client configuration), so a screenshot should be enough to get started.

Halon Security doesn't endorse any specific RADIUS server, these are just one of many tools available.

Common errors

Connecting to wrong address when having aliases

If you have aliases (multiple addresses) on your WAN interface, and connect to one of the aliases, you'll notice an error along the lines of

...router/NAT issue?

because connections from the router to the client will be issued from the primary unless specified. This problem is solved by either connecting to the router's primary (non-alias) address, or by specifying one of the aliases as the VPN server's listen address.