Project

General

Profile

Virtual IP » History » Version 16

« Previous - Version 16/24 (diff) - Next » - Current version
Tobias Brunner, 10.11.2015 09:54
Note on pool order added


Virtual IP

IKEv1 and IKEv2 both know the concept of virtual IPs. This means that the initiator requests an additional IP address from the peer to use as inner IPsec tunnel address.

In IKEv1, virtual IPs are exchanged using the mode config extension. IKEv2 has full support for virtual IPs in the core standard using configuration payloads.

strongSwan currently implements one scenario with configuration payloads, where an IP address is assigned to the initiator (since 5.0.1 multiple addresses can be assigned from multiple pools). The opposite is possible by the protocol, but is an uncommon setup and therefore not supported.

Initiator Configuration

The client needs an additional parameter called leftsourceip.

    leftsourceip=%config

%config means to request an address from the responder and is an alias for the IKEv1 specific %modecfg. But you may specify an address explicitly by setting:

    leftsourceip=10.3.0.5

This will include 10.3.0.5 into the configuration payload request. However, the responder may return a different address, or may not return one at all.

The leftsubnet option defaults to the value %dynamic. If leftsourceip respectively rightsourceip is used, this value gets dynamically replaced by the received or assigned virtual IP.

The leftsubnet option should not be included when requesting a virtual IP, as the subnet may not match the received address. Without the leftsubnet option, the subnet is narrowed to the assigned virtual IP automatically.

To use a static virtual IP (i.e. without exchanging configuration payloads) it may simply be added to any local interface (even lo) and referenced in leftsubnet.

Since 5.0.1 a client may request multiple IP addresses by listing a comma-separated combination of %config4, %config6 or fixed IP addresses in leftsourceip. Configuring %config (or one of its aliases) will request an address of the tunnel address family.
The main use case is for dualstack hosts to request a virtual IP of each address family:

    leftsourceip=%config4,%config6
This is also illustrated in the ikev2/ip-two-pools-v4v6 test scenario.

DNS servers

Before 5.0.1 the client couldn't explicitly request other attributes, but it may still have processed the DNS attribute. With current releases DNS servers may explicitly be requested with the leftdns option. Received DNS servers are handled, for instance, by the resolve plugin which writes them to /etc/resolv.conf, or an other file specified with the --with-resolve-conf configure directive.

Implementation

On Linux, the virtual IP addresses will be installed on the outbound interface by default (may be changed, since 5.0.1, with the charon.install_virtual_ip_on option) and source routes will be installed in the routing table configured with charon.routing_table in strongswan.conf (or ./configured with --with-routing-table). The source routes force the use of the virtual IP when sending packets to the subnets in rightsubnet.

Responder Configuration

The responder configuration uses the rightsourceip option:

    rightsourceip=10.3.0.6

This will serve the IP 10.3.0.6 to the client, even if the initiator requested another address. Additionally, the responder may define:

    rightsourceip=%config

to let the client choose an address. This is not recommended if you do not trust the client completely.

You may define an address pool in CIDR notation, e.g.

    rightsourceip=10.3.0.0/24
to serve addresses from that pool.

You may also use an external pool implemented as a plugin where you can specify a pool name to select addresses from. The definition

    rightsourceip=%poolname

queries registered plugins for an IP from a pool named poolname. This can also be the name of another connection in ipsec.conf which defines a pool in CIDR notation with rightsourceip, as a pool with that connection's name is created implicitly. Since 5.0.1 multiple connections (i.e. conn sections) can share the same pool implicitly if they use the same definition in rightsourceip (previously each connection would use it's own copy and the same virtual IP may have been handed out to different clients).

Multiple pools can be listed in rightsourceip since 5.0.1, e.g.

    rightsourceip=10.3.0.0/28,fec3::/120

As used in the ikev2/ip-two-pools-v4v6 test scenario.

DNS servers

DNS servers and other attributes can be assigned by plugins (e.g. the attr plugin) or since 5.0.1 directly in ipsec.conf by use of the rightdns option.

Database backend

The ipsec pool utility allows to easily manage IP address pools and other attributes, like DNS servers, stored in an SQL database using the attr-sql plugin.

DHCP backend

With the dhcp plugin the responder can request virtual IP addresses for clients from a DHCP server using broadcasts, or a designated server.

DNS/WINS server information is additionally served to clients if the DHCP server provides such information.

The plugin is used in ipsec.conf configurations by setting

    rightsourceip=%dhcp

The farp plugin might also be of use when using the dhcp plugin. It allows the responder to fake ARP responses for virtual IP addresses handed out to clients. This lets a road-warrior act as a client on the local LAN of the responder.

RADIUS backend

Since 5.0.3 the RADIUS plugin can provide virtual IP addresses assigned to RADIUS clients via the Framed-IP-Address attribute.

The plugin is used in ipsec.conf configurations by setting

    rightsourceip=%radius

Multiple pools, different backends

If multiple pools are defined from different backends, for instance

    rightsourceip=%radius,10.0.1.0/24

the order in which they are queried for virtual IPs depends on the plugin load order (in-memory pools are provided by the stroke plugin). The order in rightsourceip is irrelevant, unless, multiple in-memory pools are defined.

Versions before 5.0.0

The description above covers the features of the charon daemon, which handled only IKEv2 connections in earlier releases. The pluto daemon that handled IKEv1 connections provided a similar feature set but not everything was supported (for instance, the dhcp and farp plugins).

The pluto daemon did not request virtual IP addresses from the responder if they were explicitly configured with leftsourceip. In that case, that is, if the virtual IP was not assigned by the responder with rightsourceip one may had to use the rightsubnetwithin directive (refer to this example).

The IKEv2 daemon charon supports address pools since version 4.2.1, the IKEv1 daemon pluto gained support for this in 4.4.0.