Configuration Profile Selection Rules for prol2tpd

The ProL2TP L2TP daemon, prol2tpd, uses a concept of “configuration profiles”.

Configuration profiles are used in two ways.

Firstly, they allow the operator to map incoming tunnel and session setup requests to the appropriate configuration to use for that connection.

Secondly, they provide a flexible way to manage common sets of configuration parameters which can be used by multiple tunnel or session instances.

In this section we delve into configuration profiles more deeply to explore how they can be deployed.

Overview

ProL2TP has several profile types:-

• Peer profile
• Tunnel profile
• Session profile
• Pseudowire profile

An L2TP server needs to derive connection-specific configuration parameters when an L2TP tunnel or session setup request is received from a peer. ProL2TP does this by looking up one or more profiles using parameters of the received L2TP SCCRQ or ICRQ setup request.

There is a hierarchical relationship between the profile types: peer profiles reference a tunnel profile, tunnel profiles reference a session profile, and session profiles reference a pseudowire profile.

Selecting tunnel configuration using peer profiles

On receipt of a tunnel setup request message (SCCRQ), ProL2TP looks up the appropriate tunnel configuration to use based on parameters contained in the request’s Attribute-Value Pair (AVP) list.

The mapping between SCCRQ AVPs and tunnel configuration is managed using prol2tpd peer profiles. The peer profile contains one or more configuration parameters which could match SCCRQ AVPs, and names a tunnel profile to use when the parameters are matched.

peer profile "mypeer" {
    tunnel_profile_name "oxford"
}

There are three parameters which can be used to match incoming tunnel setup requests:

• profile name
• IP address and netmask
• L2TPv3 router id

If no peer profile match is found, the peer’s tunnel setup request is rejected.

Selection by hostname

An L2TP tunnel setup request (SCCRQ) contains a Hostname AVP which identifies the peer. It is usually derived from the client’s system name, although some L2TP clients allow an operator to set a custom value.

To have a peer profile match clients by its advertised hostname, the peer profile must be given the same name. For example, to match host oxford-l2tp-03

peer profile "oxford-l2tp-03" {
    tunnel_profile_name "oxford"
}

For this to work, the L2TP server administrator must know the hostname which is advertised by the L2TP peer in its setup request. This can easily be discovered by capturing L2TP request packets from the peer using a tool like Wireshark which understands L2TP packet contents. Look for the Hostname AVP in the SCCRQ message from the peer.

Selection by peer IP address

It is sometimes useful to lookup peer profiles using the peer’s IP address. To do so, configure peer_ipaddr and netmask parameters of the peer profile. If netmask is not specified, only one IP address will match the peer profile.

peer profile "mypeer" {
    peer_ipaddr 10.1.2.3
    tunnel_profile_name "oxford"
}

peer profile "mypeers" {
    peer_ipaddr 10.1.2.0
    netmask 255.255.255.0
    tunnel_profile_name "oxford2"
}

Selection by Router ID (L2TPv3 only)

L2TPv3 introduces a RouterID AVP in L2TP tunnel setup request messages. This is a 32-bit binary value which is configurable at the client. To match a peer profile using a router_id value, specify it in the peer profile.

peer profile "mypeer" {
    router_id 15742
    tunnel_profile_name "oxford"
}

If the router_id being used by the L2TP client isn’t already known, it might be possible to discover it by capturing the peer’s L2TP SCCRQ using a network capture tool. Look for the RouterID AVP.

Selection algorithm

More than one of the selection parameters may be set in a single peer profile, allowing the profile to be matched using any of the selection criteria described above. But if a request arrives that can match several different peer profiles, which profile is chosen?

The selection is done by a simple ordered sequence:-

1. If the peer’s host_name matches one of the peer profiles, use it.

2. Otherwise, if it is an L2TPv3 request, look for a peer profile which matches the supplied router_id parameter.

3. Otherwise check for a peer profile which matches any IP address parameters. Choose the profile with the best match of IP address, i.e. the one with the longest netmask.

Selecting session configuration using session profiles

In environments with many L2TP sessions, it may be necessary to call out unique session profiles per session. In order to do so, an identifier is needed in the session setup request (ICRQ) sent by the peer.

In L2TPv2 setups, the protocol designers did not allow for this. Typical setups use common parameters for all sessions in the tunnel, and use RADIUS to derive user-specific parameters via PPP. The session profile to use is given by session_profile_name in the tunnel profile.

In L2TPv3, a new remote_end_id parameter was added to the ICRQ message. This is a variable length byte array, set by a local administrator to identify each session. ProL2TP allows its value to be set as an ASCII string value or as a hexadecimal array, e.g.

session profile "mysession1" {
    remote_end_id hex:0123456789abcdef
}
session profile "mysession2" {
    remote_end_id "sid42"
}

When a session setup message is received from an L2TP peer, ProL2TP checks whether it contains a remote_end_id parameter. If so, it tries to find a session profile with a matching remote_end_id value and uses that profile if found, overriding any session profile setting of the tunnel.

If no session profile match is found, the peer’s session setup request is rejected.

Configuration Inheritance

For outbound tunnel setup requests (when used as an L2TP client), the profiles to be used are explicitly specified in the configuration.

tunnel "one" {
    tunnel_profile_name "oxford"
    session "one" {
        session_profile_name "ox1"
    }
}

Sometimes it is useful to share common parameters using profiles that are shared by more than one tunnel or session instance while overriding values set in profiles with locally set values.

tunnel profile "oxford" {
    host_name "mytunnel"
        proto_version 3
        hide_avps true
        secret "aue03inc26"
}
tunnel "one" {
    tunnel_profile_name "oxford"
        host_name "mysupertunnel"
        session "building1" {
            cookie_len 4
            session_profile_name "ox1"
        }
    session "building2" {
        l2spec_type none
        session_profile_name "ox1"
    }
}
tunnel "two" {
    tunnel_profile_name "oxford"
        session "building1" {
            cookie_len 4
            session_profile_name "ox1"
        }
}

In the example above, tunnels one and two share configuration from the profile oxford. Tunnel one overrides the host_name parameter, while tunnel two inherits host_name from the profile. All the sessions inherit from the named profile ox1.