Introduction to strongSwan » History » Version 38

Noel Kuntze, 10.01.2019 15:02
Certificate requirements and Notes regarding certificates

1 2 Tobias Brunner
{{title(Introduction to strongSwan)}}
2 2 Tobias Brunner
3 1 Tobias Brunner
h1. Introduction to strongSwan
4 1 Tobias Brunner
5 1 Tobias Brunner
6 1 Tobias Brunner
7 1 Tobias Brunner
This document is intended to give an introduction to strongSwan for new users (or existing users with catching-up to do).
8 1 Tobias Brunner
9 1 Tobias Brunner
h2. Prerequisites
10 1 Tobias Brunner
11 1 Tobias Brunner
It is assumed that the reader of this document...
12 1 Tobias Brunner
* understands the principles of networking, from setting IP addresses and DNS servers to basic firewalling
13 1 Tobias Brunner
* grasps the basic concepts of authentication based on public-key cryptography and a public-key infrastructure (PKI)
14 1 Tobias Brunner
* knows how to install binary software packages or how to compile source code following instructions
15 1 Tobias Brunner
* is adept on the console
16 1 Tobias Brunner
17 1 Tobias Brunner
If you don't have such knowledge, there exist many ready-to-use appliances that provide remote IPsec access.
18 1 Tobias Brunner
19 1 Tobias Brunner
h2. Securing a Network
20 1 Tobias Brunner
21 1 Tobias Brunner
strongSwan is a complete IPsec solution providing encryption and authentication to servers and clients.
22 1 Tobias Brunner
It can be used to secure communications with remote networks, so that connecting remotely is the same as
23 1 Tobias Brunner
connecting locally.
24 1 Tobias Brunner
25 1 Tobias Brunner
26 21 Tobias Brunner
27 1 Tobias Brunner
28 1 Tobias Brunner
* *Gateway*: The gateway is usually your firewall, but this can be any host within your network.
29 1 Tobias Brunner
Often the gateway is also able to serve a small network with DHCP and DNS.
30 1 Tobias Brunner
In the image above the hosts *moon* and *sun* serve as gateways for the internal hosts *alice* and *bob*,
31 1 Tobias Brunner
32 1 Tobias Brunner
* *Remote access / Roadwarrior clients*: Usually, roadwarriors are laptops and other mobile devices
33 1 Tobias Brunner
connecting from remote to your network using the gateway. In the image above *carol* represents a
34 1 Tobias Brunner
roadwarrior who wants to access either of the two networks behind the two gateways.
35 1 Tobias Brunner
* *Remote hosts / Host-to-Host*: This can be a remote web server or a backup system. This is illustrated
36 1 Tobias Brunner
in the image by host *winnetou* and either of the gateways. The connection between the two hosts can
37 1 Tobias Brunner
usually be initiated by either one of them.
38 1 Tobias Brunner
* *Remote sites / Site-to-Site*: Hosts in two or more subnets at different locations should be able to access
39 1 Tobias Brunner
each other. Again referring to the image above, the two subnets @ and @ behind
40 1 Tobias Brunner
gateways *moon* and *sun*, respectively, might be connected, so that the hosts *alice* and *bob* may securely
41 1 Tobias Brunner
communicate with one another.
42 1 Tobias Brunner
43 1 Tobias Brunner
On our website you'll find dozens of [[ConfigurationExamples|complete configuration examples]] covering these and similar situations.
44 1 Tobias Brunner
45 1 Tobias Brunner
h2. IKE and IPsec Basics
46 1 Tobias Brunner
47 1 Tobias Brunner
*strongSwan is basically a keying daemon*, which uses the "Internet Key Exchange": protocols (IKEv1 and IKEv2)
48 1 Tobias Brunner
to establish _security associations_ (SA) between two peers. IKE provides strong authentication of both peers and derives
49 1 Tobias Brunner
unique cryptographic session keys.  Such an IKE session is often denoted *IKE_SA* in our documentation.
50 37 Tobias Brunner
Besides authentication and key material IKE also provides the means to exchange configuration information (e.g. [[virtualIP|virtual
51 37 Tobias Brunner
IP addresses]]) and to negotiate IPsec SAs, which are often called *CHILD_SAs*.  IPsec SAs define which network traffic is
52 37 Tobias Brunner
to be secured and how it has to be encrypted and authenticated.
53 1 Tobias Brunner
54 23 Noel Kuntze
A CHILD_SA consists of two components:
55 29 Noel Kuntze
# The actual IPsec SAs (there are two, one in each direction) describing the algorithms and keys used to encrypt and authenticate the traffic
56 37 Tobias Brunner
# The policies (there are at least two) that define which network traffic shall use such an SA
57 1 Tobias Brunner
58 1 Tobias Brunner
The policies work both ways, that is, only traffic matching an inbound policy will be allowed after decryption. Policies are derived from the
59 1 Tobias Brunner
traffic selectors (TS) negotiated via IKE when establishing a CHILD_SA.
60 37 Tobias Brunner
Unprotected traffic that the kernel receives and for which there is a matching inbound IPsec policy will be dropped. This is a security feature.
61 23 Noel Kuntze
62 23 Noel Kuntze
The actual *IPsec traffic is not handled by strongSwan* but instead by the network and IPsec stack of the operating
63 1 Tobias Brunner
system kernel.
64 1 Tobias Brunner
65 37 Tobias Brunner
*strongSwan installs the negotiated IPsec SAs and SPs into the kernel by using a platform dependent kernel API.*
66 37 Tobias Brunner
67 1 Tobias Brunner
The mentioned distinction between policies and SAs often leads to *misconceptions*.  For instance, referring to the image
68 1 Tobias Brunner
above, if host moon has a site-to-site tunnel to host sun (connecting the two networks and,
69 1 Tobias Brunner
and host carol has a roadwarrior connection to host sun (from which carol received a virtual IP address of,
70 1 Tobias Brunner
then carol wont be able to automatically communicate with alice, even if forwarding is enabled on sun.  This is because
71 1 Tobias Brunner
there is no IPsec policy allowing traffic between carol ( and alice ( An additional SA between moon
72 1 Tobias Brunner
and sun, connecting the virtual subnet with would be a possible solution to this issue.
73 24 Noel Kuntze
74 24 Noel Kuntze
Generally, IPsec processing and routing are two different topics. IPsec is often just bumped into the stack (policy based)
75 24 Noel Kuntze
and the original routing decision for the unprotected packet also applies to the protected packet.
76 24 Noel Kuntze
This is the reason charon, by default, installs specific routes to the remote part of the TS (in newer versions of charon (>5.5.0),
77 24 Noel Kuntze
routes aren't installed for transport mode CHILD_SAs).
78 37 Tobias Brunner
An exception to this is route based IPsec, which uses interfaces to control what packets are going to be processed
79 37 Tobias Brunner
by each tunnel to a unique participant. Route based IPsec is less flexible than policy based IPsec.
80 24 Noel Kuntze
81 1 Tobias Brunner
[[IPsecDocumentation|More information about IPsec and IKE]] can be found on our wiki.
82 1 Tobias Brunner
83 1 Tobias Brunner
h2. Authentication Basics
84 1 Tobias Brunner
85 1 Tobias Brunner
To ensure that the peer with which an IKE_SA is established is really who it claims to be it has to be authenticated.
86 1 Tobias Brunner
87 1 Tobias Brunner
strongSwan provides several methods to do this:
88 1 Tobias Brunner
89 37 Tobias Brunner
* *Public Key Authentication*: This uses *RSA, ECDSA or EdDSA X.509 certificates* to verify the authenticity of the peer.
90 37 Tobias Brunner
** Certificates can be self-signed (in which case they have to be installed on all peers), or signed by a common
91 1 Tobias Brunner
Certificate Authority (CA). The latter simplifies deployment and configuration a lot as the gateway only
92 1 Tobias Brunner
needs the CA certificate to authenticate all peers that provide a valid certificate signed by that CA.
93 1 Tobias Brunner
** "Certificate Revocation Lists": (CRLs) or the "Online Certificate Status Protocol": (OCSP) may be
94 1 Tobias Brunner
used to verify the validity of certificates.
95 1 Tobias Brunner
** To securely store private keys [[SmartCards|smart cards]] may be used via the [[PKCS11Plugin|PKCS#11 plugin]].
96 1 Tobias Brunner
** In order to prevent "man-in-the-middle attacks": the identity claimed by the peer has to be confirmed by
97 1 Tobias Brunner
the certificate, either by the _subject_ or a _subjectAltName_ extension.
98 1 Tobias Brunner
* *Pre-Shared-Key (PSK)*: A pre-shared-key is an easy to deploy option but it *requires strong secrets* to be secure.
99 1 Tobias Brunner
** If the PSK is known to many users (which is often the case with IKEv1 XAuth with PSK) any user who knows
100 1 Tobias Brunner
the secret could impersonate the gateway. Therefore this method is *not recommended* for large scale
101 1 Tobias Brunner
102 1 Tobias Brunner
* *Extensible Authentication Protocol (EAP)*: This covers several possible authentication methods, some are
103 1 Tobias Brunner
based on username/password authentication (EAP-MD5, EAP-MSCHAPv2, EAP-GTC) or on certificates (EAP-TLS),
104 1 Tobias Brunner
some can even tunnel other EAP methods (EAP-TTLS, EAP-PEAP).
105 1 Tobias Brunner
** The actual authentication of users may be delegated to a RADIUS server with the [[EAPRAdius|eap-radius plugin]].
106 1 Tobias Brunner
** EAP authentication can only be used with IKEv2 and for some methods with IKEv1 using the [[XAuthEap|xauth-eap plugin]].
107 10 Noel Kuntze
* *eXtended Authentication (XAuth)*: XAuth provides a flexible authentication framework within IKEv1. It is mainly
108 1 Tobias Brunner
used for username/password based authentication. Also, it is generally used as a second authentication method
109 1 Tobias Brunner
after a mutual authentication with either certificates or PSK. With _IKEv1 hybrid authentication_ is is, however,
110 1 Tobias Brunner
possible to authenticate the gateway with a certificate and use only XAuth to authenticate the client.
111 1 Tobias Brunner
112 1 Tobias Brunner
With IKEv2 it is possible to use multiple authentication rounds, for instance, to first authenticate the "machines" with
113 1 Tobias Brunner
certificates and then the "user" with an username/password-based authentication scheme (e.g EAP-MSCHAPv2).  It is also
114 1 Tobias Brunner
possible to use asymmetric authentication, for instance, by authenticating the gateway with a certificate and the client
115 37 Tobias Brunner
with a username/password-based EAP method (in the first authentication round). Please be aware that not all IKEv2
116 37 Tobias Brunner
implementations support this extension ("RFC 4739":
117 1 Tobias Brunner
118 1 Tobias Brunner
Again, our website provides dozens of [[ConfigurationExamples|configuration examples]] covering these and other authentication options.
119 1 Tobias Brunner
120 1 Tobias Brunner
h2. Configuration Files
121 1 Tobias Brunner
122 32 Andreas Steffen
The recommended way of configuring strongSwan is via the powerful [[vici]] interface and the [[swanctl]] command line tool. The [[swanctl.conf]] configuration file used by [[swanctl]] is stored together with certificates and corresponding private keys in the [[SwanctlDirectory|swanctl directory]]. Global strongSwan settings as well as plugin-specific configurations are defined in [[strongswanConf|strongswan.conf]].
123 1 Tobias Brunner
124 37 Tobias Brunner
Alternatively, the legacy [[Ipsecstroke|ipsec stroke]] interface and its [[IpsecConf|ipsec.conf]] and [[IpsecSecrets|ipsec.secrets]] configuration files may be used.
125 1 Tobias Brunner
126 1 Tobias Brunner
h3. Other Configuration Sources
127 1 Tobias Brunner
128 1 Tobias Brunner
The configuration may also be loaded from [[SQL|an SQL database]] or provided by custom plugins like the one used with the [[NetworkManager|NetworkManager plugin]].
129 1 Tobias Brunner
130 1 Tobias Brunner
h2. Installation
131 1 Tobias Brunner
132 1 Tobias Brunner
The [[InstallationDocumentation|installation of strongSwan]] is covered in a separate part of the wiki.
133 1 Tobias Brunner
134 1 Tobias Brunner
Using binary packages provided by your distribution is generally recommended as it makes maintenance easier.
135 1 Tobias Brunner
Unfortunately, this means that you are often not able to use the most recent version.
136 1 Tobias Brunner
137 1 Tobias Brunner
h2. Invocation and Maintenance
138 1 Tobias Brunner
139 37 Tobias Brunner
strongSwan is usually managed with the [[swanctl]] command, while the IKE daemon [[charon-systemd|charon]] is controlled by @systemd@ on modern distros.
140 37 Tobias Brunner
With legacy installations, strongSwan is controlled by the [[IpsecCommand|ipsec command]], where @ipsec start@ will start the [[IpsecStarter|starter daemon]] which in turn
141 1 Tobias Brunner
starts and configures the keying daemon [[charon]].
142 1 Tobias Brunner
143 37 Tobias Brunner
Connections and CHILD_SAs defined in [[swanctl.conf]] (or in [[ConnSection|conn sections in ipsec.conf]]) can be started on three different occasions:
144 1 Tobias Brunner
145 37 Tobias Brunner
* *On traffic*: If _start_action=trap/auto=route_ is used, IPsec trap policies for the configured traffic (_local|remote_ts/left|rightsubnet_)
146 37 Tobias Brunner
will be installed and traffic matching these policies will trigger acquire events that cause the daemon to establish the required IKE/IPsec SAs.
147 16 Tobias Brunner
This is also used for passthrough/drop IPsec policies, to let specific traffic bypass other policies/SAs, or drop it completely.
148 37 Tobias Brunner
* *On startup*: CHILD_SAs configured with _start_action=start_ (or _auto=start_) will automatically be established when the daemon is started. 
149 37 Tobias Brunner
They are not automatically restarted when they go down for some reason. You need to specify other configuration settings 
150 37 Tobias Brunner
(_dpd_action/dpdaction_ and/or _close_action/closeaction_) to restart them automatically, but even then, the setup is not bullet-proof
151 37 Tobias Brunner
and will potentially leak packets. You are encouraged to use trap policies and read the [[SecurityRecommendations|SecurityRecommendations]] to take care of any problems.
152 37 Tobias Brunner
* *Manually*: A connection that uses no _start_action_ (or _auto=add_ in ipsec.conf) has to be established manually with @swanctl --initiate@ (or @ipsec up@) or by a peer/roadwarrior.
153 37 Tobias Brunner
Depending on the configuration, it is also possible to use @swanctl --install@ (or @ipsec route@) to install policies manually for such connections, like _start_action=trap/auto=route_ would do it on startup.
154 1 Tobias Brunner
155 37 Tobias Brunner
After an SA has been established @swanctl --terminate@ (or @ipsec down@) may be used to tear down the IKE_SA or individual CHILD_SAs.
156 1 Tobias Brunner
157 37 Tobias Brunner
Whenever the [[swanctl.conf]] file or credentials the [[SwanctlDirectory|swanctl directory]] are changed they may be reloaded with the different @--load*@ commands (with [[ipsec.conf]] the @ipsec update@ or @ipsec reload@ commands may be used to reload the config). Already established
158 37 Tobias Brunner
connections are not affected by these commands (unless _start_action=start_ is used), if that is required the SAs or even the daemon must be restarted.
159 1 Tobias Brunner
160 37 Tobias Brunner
For legacy configs, if [[ipsec.secrets]] or the files in [[IpsecDirectory|ipsec.d]] have been changed the [[IpsecCommand#Reread-Commands|ipsec reread...]] commands may be used to reload these files.
161 37 Tobias Brunner
End-entity certificates placed in [[IpsecDirectoryCerts|ipsec.d/certs]] are not loaded automatically, instead they are loaded whenever referenced
162 37 Tobias Brunner
with _left|rightcert_ in a [[ConnSection|conn section]]. Using the [[IpsecCommand#Purge-Commands|ipsec purge...]] commands may be required in order for the new files to be used (not required when using [[swanctl]] to load credentials).
163 1 Tobias Brunner
164 37 Tobias Brunner
Using the different @swanctl --list*@ ([[Ipseccommand#List-Commands|ipsec list...]]) commands will provide information about loaded or cached certificates, supported algorithms and loaded plugins.
165 1 Tobias Brunner
166 12 Noel Kuntze
h2. Logging and Monitoring
167 1 Tobias Brunner
168 1 Tobias Brunner
If you run into problems, increasing the log level might help you understand what exactly went wrong. The different
169 37 Tobias Brunner
[[Loggerconfiguration|logging options]] are described on our wiki and the [[strongswan.conf]] man page (recommended log settings for
170 37 Tobias Brunner
debugging problems may be found on [[HelpRequests]]).
171 1 Tobias Brunner
172 1 Tobias Brunner
Whenever you encounter a log message similar to @"received ... error notify"@, where @...@ is, for instance,
173 1 Tobias Brunner
@NO_PROPOSAL_CHOSEN@ or @TS_UNACCEPTABLE@, you should consult the logs of the *remote peer* so as to find out why
174 1 Tobias Brunner
it generated that error notify in the first place.
175 1 Tobias Brunner
176 37 Tobias Brunner
Starting the daemon with @ipsec start --nofork@) prevents it from forking and will log directly to the console (in case
177 1 Tobias Brunner
loggers are configured in [[strongswan.conf]] make sure one of them logs to _stderr_ or _stdout_).
178 1 Tobias Brunner
179 37 Tobias Brunner
The [[swanctl]] @--list*@ commands (or [[IpsecCommand|ipsec]] @status@ and @statusall@) will provide information about the established and configured connections.
180 1 Tobias Brunner
181 37 Tobias Brunner
On Linux, the _iproute2_ package provides the @ip xfrm state@ and @ip xfrm policy@ commands to request detailed
182 1 Tobias Brunner
information about the IPsec SAs and policies installed in the kernel.  Adding the @-s@ option will display extensive
183 1 Tobias Brunner
statistical information like the number of transmitted or invalid packages. On other platforms the _setkey_ command
184 1 Tobias Brunner
from the _ipsec-tools_ package provides similar information.
185 1 Tobias Brunner
186 1 Tobias Brunner
_tcpdump_ and _wireshark_ are also often useful to debug problems.
187 1 Tobias Brunner
188 1 Tobias Brunner
When testing a connection with _ping_ make sure to select a source IP address (with the @-I@ option) that is included in the
189 1 Tobias Brunner
local traffic selector (also see [[IntroductionToStrongswan#Site-to-Site-Configurations|Site-to-Site Configurations]] below).
190 1 Tobias Brunner
191 1 Tobias Brunner
h2. PKI
192 1 Tobias Brunner
193 1 Tobias Brunner
To use certificate based authentication you'll need to create either self-signed certificates or setup a whole public-key
194 1 Tobias Brunner
infrastructure (PKI), consisting of a Certificate Authority (CA), optional intermediate CAs and end-entity certificates plus
195 1 Tobias Brunner
certificate revocation lists (CRL) or other methods like OCSP to verify the validity of certificates.
196 1 Tobias Brunner
197 1 Tobias Brunner
One of the easiest ways to generate certificates is to use the [[IPsecPki|ipsec pki]] utility. Since setting up a whole PKI can be quite
198 1 Tobias Brunner
complex, we only [[SimpleCA|provide instructions]] to get you started.
199 1 Tobias Brunner
200 1 Tobias Brunner
OpenSSL is also a widespread alternative to generate certificates, as are several GUI based [[CAmanagementGUIs|CA management utilities]].
201 1 Tobias Brunner
Commercial CA management tools like Microsoft's are also often used for large scale CAs.
202 1 Tobias Brunner
203 38 Noel Kuntze
h3. Certificate requirements
204 38 Noel Kuntze
205 38 Noel Kuntze
# *The generated leaf (end) certificates need to authenticate the corresponding peer's IKE ID for authentication to succeed.*
206 38 Noel Kuntze
# *To authenticate against another instance of strongSwan using a or several certificates (if attribute certificates are used), the certificate must authenticate the ID that the host sends (so Alice tries to authenticate against Bob as Alice (herself), so Alice's certificate has to have at least a SAN field with the correct type (FQDN) and value "Alice" or the _DN_ (not _CN_!) has to be "Alice"*. In other words, you can use the _complete DN_ or _any_ of the _SAN fields' values_ (assuming the type is correct. See [[IntroductionTostrongSwan#Notes-regarding-certificates|Notes regarding certificates]] for details) as an ID.
207 38 Noel Kuntze
# Additionally, the certificate has to be trusted by Bob by, for example, it being known beforehand as valid to Bob or the certificate being authenticated/issued by a certificate authority *that Bob trusts*.
208 38 Noel Kuntze
# For authentication to succeed, the other peer has to possess the complete chain of the certificate (from root certificate (the root CA) to the leaf certificate (the host's certificate) *with all intermediate certificates* (all intermediate CAs). This is done by sending any intermediate certificates to the remote host.
209 38 Noel Kuntze
210 38 Noel Kuntze
h3. Notes regarding certificates
211 38 Noel Kuntze
212 38 Noel Kuntze
Because a foreign root certificate is not automatically trusted, a certificate's root certificate is _not_ sent to another host. That other host already has to have that root certificate available in the first place for authentication to succeed.
213 38 Noel Kuntze
214 38 Noel Kuntze
A local certificate is only sent to another host if at least one of the following is true:
215 38 Noel Kuntze
# You set leftsendcert=always in the conn that is used
216 38 Noel Kuntze
# The remote peer requested a certificate issued by a trusted CA by sending a CERTREQ payload to the local peer that indicates one of the CAs in the path from the local host's certificate to its root certificate.
217 34 Noel Kuntze
218 16 Tobias Brunner
h2. Routing
219 16 Tobias Brunner
220 16 Tobias Brunner
On Linux, strongSwan installs routes into routing table 220 by default and hence requires the kernel to support policy
221 16 Tobias Brunner
based routing.
222 16 Tobias Brunner
223 16 Tobias Brunner
You can make the daemon install the routes into any table you like, or you can disable it completely.
224 16 Tobias Brunner
For those purposes, the _charon.install_routes_, _charon.routing_table_ and _charon.routing_table_prio_ settings
225 17 Noel Kuntze
in [[strongswan.conf]] may be used. When a tunnel is established between two subnets, charon tries to find local IPs in the tunneled
226 17 Noel Kuntze
local subnets. Such an IP must be configurd with _scope global_ to be viable for the lookup. If a valid IP is found, charon will install
227 17 Noel Kuntze
a route pointing to the remote subnet where the source IP is set to the found IP. This results in routes like the following:
228 17 Noel Kuntze
229 19 Noel Kuntze via src
230 17 Noel Kuntze
231 17 Noel Kuntze
In that example, the local IP would be The remote subnet would be
232 17 Noel Kuntze
This is done so packets to the remote subnet are sent with the correct source IP, so the IPsec policies match and traffic
233 17 Noel Kuntze
from the local machine to the remote subnet will be secured with IPsec.
234 16 Tobias Brunner
235 16 Tobias Brunner
To avoid conflicts with these routes (especially if [[VirtualIP|virtual IPs]] are used), the _kernel-netlink_ plugin manually parses the
236 16 Tobias Brunner
host's routing tables to determine a suitable source address when sending IKE packets.  On hosts with a (very) high number
237 16 Tobias Brunner
of routes this is quite inefficient. In that case, setting _charon.plugins.kernel-netlink.fwmark_ in [[strongswan.conf]] is
238 16 Tobias Brunner
recommended as it will allow using a more efficient source address lookup.
239 16 Tobias Brunner
240 16 Tobias Brunner
In order to detect connectivity changes strongSwan parses the events that the kernel sends when a route is installed or
241 16 Tobias Brunner
deleted and hence could cause high CPU load when you run it on a system that receives a lot of routes via dynamic
242 16 Tobias Brunner
routing, for example. You can disable it using the _charon.process_route_ setting in [[strongswan.conf]].
243 16 Tobias Brunner
244 20 Tobias Brunner
If IPv6 is used then make sure to [[IPv6NDP|bypass NDP(Neighbor Discovery Protocol) traffic]] if necessary.
245 20 Tobias Brunner
246 16 Tobias Brunner
It is possible that you encounter MSS/MTU problems when tunneling traffic. Please refer to [[ForwardingAndSplitTunneling#MTUMSS-issues|Forwarding and Split-Tunneling]]
247 16 Tobias Brunner
for details.
248 1 Tobias Brunner
249 1 Tobias Brunner
h2. Remote Access Configurations
250 1 Tobias Brunner
251 1 Tobias Brunner
In this section we present example configurations for common remote access use cases.  In these so called _roadwarrior_
252 1 Tobias Brunner
scenarios mobile clients will be able to connect to a remote network.
253 1 Tobias Brunner
254 1 Tobias Brunner
Because these clients most likely connect from unknown IP addresses the gateway will use _right=%any_ to literally accept
255 1 Tobias Brunner
connections from anywhere.  To simplify [[ForwardingAndSplitTunneling|routing traffic back]] to the clients and because roadwarriors are often located
256 1 Tobias Brunner
behind one or more NAT devices, the use of [[VirtualIP|virtual IP addresses]] is necessary.
257 1 Tobias Brunner
258 1 Tobias Brunner
The virtual IPs can either be from a distinct subnet or actually from the subnet behind the gateway (by use of the
259 1 Tobias Brunner
[[farpplugin|farp]] and optionally the [[dhcpplugin|dhcp]] plugins).
260 1 Tobias Brunner
261 1 Tobias Brunner
Whether roadwarriors will send all traffic to the gateway or use [[ForwardingAndSplitTunneling|split-tunneling]], that is, only send traffic for specific
262 1 Tobias Brunner
destinations through the tunnel, is also something to consider.  It is explained more detailed in [[ForwardingAndSplitTunneling|Forwarding and]]
263 1 Tobias Brunner
264 1 Tobias Brunner
265 1 Tobias Brunner
The above page also explains how traffic is [[ForwardingAndSplitTunneling|forwarded]] to hosts behind the gateway.
266 1 Tobias Brunner
267 6 Tobias Brunner
h3. IKEv2 (Windows 7/8, Linux, Android 4+, Mac OS X, iOS 8+)
268 1 Tobias Brunner
269 1 Tobias Brunner
The gateway configurations shown in the [[Windows7|Windows 7 section]] of the wiki may be used for all IKEv2 clients. In both use
270 1 Tobias Brunner
cases presented there the gateway is authenticated with a certificate, while the clients will either authenticate themselves
271 1 Tobias Brunner
with certificates, or use username and password. Both configurations may be implemented on a gateway to leave it to the
272 1 Tobias Brunner
clients to select an authentication method.
273 1 Tobias Brunner
274 3 Tobias Brunner
With the [[EAPRadius|eap-radius plugin]] the user authentication may be delegated to a RADIUS server (e.g. an existing Active Directory DC).
275 3 Tobias Brunner
276 1 Tobias Brunner
Both the [[AndroidVPNClient|strongSwan VPN Client for Android 4 and newer]] and the [[NetworkManager|strongSwan NetworkManager plugin]] may be
277 1 Tobias Brunner
used with either of these configs.
278 1 Tobias Brunner
279 3 Tobias Brunner
For Linux roadwarriors that don't want or can't use the NetworkManager plugin [[IKEv2ClientConfig|this client config may be used]]. 
280 3 Tobias Brunner
Alternatively, the [[charon-cmd]] command line IKE client provides a simple means to establish roadwarrior connections since version:5.1.0.
281 1 Tobias Brunner
282 3 Tobias Brunner
[[MacOSX#Native-application|Our app for Mac OS X]] supports IKEv2 and simple EAP authentication.
283 1 Tobias Brunner
284 7 Tobias Brunner
With [[AppleIKEv2Profile|iOS 8 and Mac OS X 10.10]] (Yosemite) Apple introduced support for IKEv2 in their clients. A GUI to configure such connections
285 7 Tobias Brunner
is currently not provided, so it's necessary to write (or generate) [[AppleIKEv2Profile|custom configuration profiles]].
286 5 Tobias Brunner
287 1 Tobias Brunner
h3. IKEv1 (iOS, Mac OS X, Android, Windows)
288 1 Tobias Brunner
289 1 Tobias Brunner
The configuration presented on the [[iOS_(Apple)|iOS and Mac OS X page]] should work for all IKEv1 clients that support XAuth.
290 1 Tobias Brunner
291 1 Tobias Brunner
For Windows hosts before Windows 7 it is recommended to use a third-party IPsec client like "Shrew": instead of the
292 1 Tobias Brunner
built-in IKEv1/L2TP client.
293 1 Tobias Brunner
294 1 Tobias Brunner
Instead of generating a private key and certificate pair for each client you may also use the same key/certificate pair for
295 1 Tobias Brunner
all clients. The actual client authentication will then be based on XAuth (this is similar to hybrid authentication, but also works
296 1 Tobias Brunner
for clients that don't support it, or implement it incorrectly, like some iOS versions did). Even though the private key/certificate
297 1 Tobias Brunner
pair is "public", this still ensures proper authentication of the gateway, but might simplify deployment to clients.
298 1 Tobias Brunner
299 1 Tobias Brunner
XAuth with PSK may also be used (see #218) but is not recommended for larger deployments.
300 1 Tobias Brunner
301 1 Tobias Brunner
The XAuth credentials provided by the clients may be verified against the same RADIUS server used for IKEv2 clients with
302 1 Tobias Brunner
the help of the [[XAuthEAP|xauth-eap plugin]].
303 1 Tobias Brunner
304 1 Tobias Brunner
h2. Site-to-Site Configurations
305 1 Tobias Brunner
306 30 Noel Kuntze
For site-to-site connections you may refer to the [[UsableExamples|configuration examples]]. Out test suites for all features can be found [[ConfigurationExamples|here]].
307 1 Tobias Brunner
308 1 Tobias Brunner
The most important difference compared to the remote access case is that the initiator will not request a [[VirtualIP|virtual IP address]]
309 1 Tobias Brunner
but instead use _leftsubnet_ to tunnel traffic from one or more local subnets.  For IKEv2 multiple subnets (in CIDR notation) can
310 1 Tobias Brunner
be added to _left|rightsubnet_, separated by commas. If IKEv1 is used a separate [[ConnSection|conn section]] has to be added for each
311 1 Tobias Brunner
combination of left and right subnet as only the first subnet in _left|rightsubnet_ will be used (using either _conn %default_ or the
312 1 Tobias Brunner
_also_ keyword can reduce each of these configs to a few lines).
313 1 Tobias Brunner
314 1 Tobias Brunner
One thing that often confuses users new to IPsec is that testing a net-to-net scenario from either of the gateways often requires
315 1 Tobias Brunner
one to select the source address used specifically (e.g. with @ping -I@) because the external IP of either gateway might not be
316 1 Tobias Brunner
included in the tunneled subnets. If that is something you require either add the external IPs to the list of subnets in _left|rightsubnet_
317 1 Tobias Brunner
or add a specific host-to-host config.
318 1 Tobias Brunner
319 1 Tobias Brunner
h2. Host-to-Host Configurations
320 1 Tobias Brunner
321 1 Tobias Brunner
Host-to-host connections are very easy to setup. You basically have to configure _right_ to the hostname or IP address of the peer
322 1 Tobias Brunner
and configure the desired authentication, neither leftsubnet nor rightsubnet have to be set explicitly.
323 1 Tobias Brunner
324 21 Tobias Brunner
Again, [[ConfigurationExamples|our test suite]] provides several examples.