Project

General

Profile

Virtual IP » History » Version 16

Tobias Brunner, 10.11.2015 09:54
Note on pool order added

1 6 Martin Willi
h1. Virtual IP
2 1 Martin Willi
3 11 Tobias Brunner
{{>toc}}
4 1 Martin Willi
5 10 Tobias Brunner
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.
6 1 Martin Willi
7 6 Martin Willi
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_.
8 6 Martin Willi
9 11 Tobias Brunner
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.
10 1 Martin Willi
11 7 Tobias Brunner
12 11 Tobias Brunner
h2. Initiator Configuration
13 1 Martin Willi
14 6 Martin Willi
The client needs an additional parameter called _leftsourceip_.
15 6 Martin Willi
16 7 Tobias Brunner
<pre>
17 1 Martin Willi
    leftsourceip=%config
18 11 Tobias Brunner
</pre> 
19 11 Tobias Brunner
20 1 Martin Willi
_%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:
21 1 Martin Willi
<pre>
22 1 Martin Willi
    leftsourceip=10.3.0.5
23 1 Martin Willi
</pre>
24 11 Tobias Brunner
25 1 Martin Willi
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.
26 1 Martin Willi
27 15 Noel Kuntze
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.
28 15 Noel Kuntze
29 14 Tobias Brunner
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.
30 14 Tobias Brunner
31 14 Tobias Brunner
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_.
32 14 Tobias Brunner
33 11 Tobias Brunner
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.
34 11 Tobias Brunner
The main use case is for dualstack hosts to request a virtual IP of each address family:
35 11 Tobias Brunner
36 11 Tobias Brunner
<pre>
37 6 Martin Willi
    leftsourceip=%config4,%config6
38 11 Tobias Brunner
</pre> This is also illustrated in the {{tc(ikev2/ip-two-pools-v4v6)}} test scenario.
39 1 Martin Willi
40 11 Tobias Brunner
h3. DNS servers
41 3 Martin Willi
42 11 Tobias Brunner
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 [[resolveplugin|resolve plugin]] which writes them to _/etc/resolv.conf_, or an other file specified with the _--with-resolve-conf_ configure directive.
43 11 Tobias Brunner
44 12 Tobias Brunner
h3. Implementation
45 12 Tobias Brunner
46 12 Tobias Brunner
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 [[Autoconf|./configured]] with _--with-routing-table_). The source routes force the use of the virtual IP when sending packets to the subnets in _rightsubnet_.
47 12 Tobias Brunner
48 11 Tobias Brunner
49 11 Tobias Brunner
h2. Responder Configuration
50 11 Tobias Brunner
51 1 Martin Willi
The responder configuration uses the _rightsourceip_ option:
52 1 Martin Willi
<pre>
53 6 Martin Willi
    rightsourceip=10.3.0.6
54 5 Martin Willi
</pre>
55 11 Tobias Brunner
56 1 Martin Willi
This will serve the IP _10.3.0.6_ to the client, even if the initiator requested another address. Additionally, the responder may define:
57 1 Martin Willi
<pre>
58 1 Martin Willi
    rightsourceip=%config
59 1 Martin Willi
</pre>
60 11 Tobias Brunner
61 1 Martin Willi
to let the client choose an address. This is not recommended if you do not trust the client completely.
62 5 Martin Willi
63 11 Tobias Brunner
You may define an address pool in CIDR notation, e.g.
64 1 Martin Willi
<pre>
65 6 Martin Willi
    rightsourceip=10.3.0.0/24
66 11 Tobias Brunner
</pre> to serve addresses from that pool.
67 11 Tobias Brunner
68 11 Tobias Brunner
You may also use an external pool implemented as a plugin where you can specify a pool name to select addresses from. The definition
69 1 Martin Willi
<pre>
70 1 Martin Willi
    rightsourceip=%poolname
71 11 Tobias Brunner
</pre> 
72 11 Tobias Brunner
73 11 Tobias Brunner
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. Since [[5.0.1]] multiple connections (i.e. [[ConnSection|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).
74 11 Tobias Brunner
75 11 Tobias Brunner
Multiple pools can be listed in _rightsourceip_ since [[5.0.1]], e.g.
76 11 Tobias Brunner
<pre>
77 11 Tobias Brunner
    rightsourceip=10.3.0.0/28,fec3::/120
78 6 Martin Willi
</pre>
79 1 Martin Willi
80 11 Tobias Brunner
As used in the {{tc(ikev2/ip-two-pools-v4v6)}} test scenario.
81 1 Martin Willi
82 11 Tobias Brunner
h3. DNS servers
83 1 Martin Willi
84 11 Tobias Brunner
DNS servers and other attributes can be assigned by plugins (e.g. the [[AttrPlugin|attr plugin]]) or since [[5.0.1]] directly in [[ipsec.conf]] by use of the _rightdns_ option.
85 11 Tobias Brunner
86 11 Tobias Brunner
h3. Database backend
87 11 Tobias Brunner
88 11 Tobias Brunner
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]].
89 11 Tobias Brunner
90 11 Tobias Brunner
h3. DHCP backend
91 11 Tobias Brunner
92 1 Martin Willi
With the [[DHCPPlugin|dhcp plugin]] the responder can request virtual IP addresses for clients from a DHCP server using broadcasts, or a designated server.
93 1 Martin Willi
94 1 Martin Willi
DNS/WINS server information is additionally served to clients if the DHCP server provides such information.
95 7 Tobias Brunner
96 11 Tobias Brunner
The plugin is used in [[ipsec.conf]] configurations by setting
97 7 Tobias Brunner
<pre>
98 8 Tobias Brunner
    rightsourceip=%dhcp
99 1 Martin Willi
</pre>
100 8 Tobias Brunner
101 11 Tobias Brunner
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.
102 11 Tobias Brunner
103 13 Tobias Brunner
h3. RADIUS backend
104 13 Tobias Brunner
105 13 Tobias Brunner
Since [[5.0.3]] the [[EAPRAdius|RADIUS plugin]] can provide virtual IP addresses assigned to RADIUS clients via the Framed-IP-Address attribute.
106 13 Tobias Brunner
107 13 Tobias Brunner
The plugin is used in [[ipsec.conf]] configurations by setting
108 13 Tobias Brunner
<pre>
109 13 Tobias Brunner
    rightsourceip=%radius
110 13 Tobias Brunner
</pre>
111 11 Tobias Brunner
112 16 Tobias Brunner
h3. Multiple pools, different backends
113 16 Tobias Brunner
114 16 Tobias Brunner
If multiple pools are defined from different backends, for instance
115 16 Tobias Brunner
116 16 Tobias Brunner
<pre>
117 16 Tobias Brunner
    rightsourceip=%radius,10.0.1.0/24
118 16 Tobias Brunner
</pre>
119 16 Tobias Brunner
120 16 Tobias Brunner
the order in which they are queried for virtual IPs depends on the [[PluginLoad|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.
121 16 Tobias Brunner
122 11 Tobias Brunner
h2. Versions before 5.0.0
123 11 Tobias Brunner
124 11 Tobias Brunner
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).
125 11 Tobias Brunner
126 11 Tobias Brunner
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":http://www.strongswan.org/uml/testresults4/ikev1/virtual-ip/).
127 11 Tobias Brunner
128 11 Tobias Brunner
The IKEv2 daemon charon supports address pools since version [[4.2.1]], the IKEv1 daemon pluto gained support for this in [[4.4.0]].