strongSwan

h1. Virtual IP

IKEv1 and IKEv2 both know the concept of _virtual IPs_. This means that the initiator (or even the responder) 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_.

h2. IKEv1

The feature set is similar to that in IKEv2, but not all features are supported. If the virtual IP is not assigned by the responder with _rightsourceip_ you may need to use the _rightsubnetwithin_ directive (see "this example":http://www.strongswan.org/uml/testresults/ikev1/virtual-ip/).

h2. IKEv2

strongSwan currently implements one scenario with configuration payloads, where an IP address is assigned to the initiator. The opposite is possible by the protocol, but is an uncommon setup and therefore not supported.

h3. Initiator Configuration

The client needs an additional parameter called _leftsourceip_.

<pre>

    leftsourceip=%config

</pre>

_%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:

<pre>

    leftsourceip=10.3.0.5

</pre>

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 client can't request other attributes, but it may process the DNS attributes. Received DNS servers are written to the beginning of _/etc/resolv.conf_, or an other file specified with the _--with-resolve-conf_ configure directive.

You should not include the _leftsubnet_ option, as the subnet may not match your received virtual IP. Without the _leftsubnet_ option, the subnet is narrowed to your assigned virtual IP automatically.

h3. Responder Configuration

The responder configuration uses the _rightsourceip_ option:

<pre>

    rightsourceip=10.3.0.6

</pre>

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

<pre>

    rightsourceip=%config

</pre>

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

The IKEv2 daemon charon supports address pools since version 4.2.1; the IKEv1 daemon pluto added support in 4.4.0. You may define an address pool in CIDR notation, e.g.

<pre>

    rightsourceip=10.3.0.0/24

</pre>

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

<pre>

    rightsourceip=%poolname

</pre>

queries registered plugins for an IP from a pool named _poolname_. This can also be the name of another connection in [[IpsecConf|ipsec.conf]] which defines a pool in CIDR notation with _rightsourceip_, as a pool with that connection's name is created implicitly.

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

With the [[DHCPPlugin|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

<pre>

    rightsourceip=%dhcp

</pre>

The [[FARPPlugin|farp plugin]] might also be of use when using the [[DHCPPlugin|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.