IPsec connection names¶
IPsec tunnels follow a consistent naming pattern when forming connection namesused in the strongSwan configuration. These names are printed in the IPsecstatus and can also be found in the IPsec configuration file(/var/etc/ipsec/swanctl.conf), the IPsec log, and the output of variousswanctl commands.
Non-mobile tunnels all use an IKE connection named conX where X is thephase 1 IKE ID.
Phase 2 child definitions use slightly different names based on the tunnelsettings:
For normal IKEv2 tunnels without Split Connections enabled all phase 2entries are combined into a single child definition. In this case theconnections are named conX where X is the phase 1 IKE ID and this isidentical to the name of the IKE portion of the connection.
For IKEv1 tunnels and for IKEv2 tunnels with Split Connections enabled eachphase 2 entry is defined as a separate child. In this case the child definitionsare named conX_Y where X is the phase 1 IKE ID and Y is the phase 2reqid.
Note
The phase 1 IKE ID and phase 2 reqid are printed in the IPsec tunnel list andon the page when editing those entries.
To see a list of current connections, run the following command from the shell:
# swanctl --list-conns
The output of that command lists the IKE connection name first (e.g. con1)with no indentation. Child definitions are listed at the end of a tunnel entryand are indented.
Manually connect IPsec from the shell¶
Connections can be manually initiated and terminated from the shell using theswanctl command.
Tip
When initiating a tunnel in this way, swanctl will output only therelevant logs to the terminal. This is much easier than attempting to followthe log file contents in other ways.
The connection name for a tunnel must be used in this case, such as con1 orcon2_1.
Note
To locate the correct con identifier, see IPsec connection names.
The following command will attempt to initiate the IKE portion of a tunnel(phase 1):
# swanctl --initiate --ike conX
The following command will attempt to initiate the child SA portion of a tunnel(phase 2) as well as IKE if it is not already connected:
# swanctl --initiate --child conX
Terminating a tunnel uses similar syntax.
Terminate IKE connection (also terminates all child connections):
# swanctl --terminate --ike conX
Terminate a child connection:
# swanctl --terminate --child conX
Tunnel does not establish¶
First check the service status at Status > Services. If the IPsec service isstopped, check if there is at least one configured and enabled IPsec tunnel(IPsec Tunnels Tab).
If the service is running, check the firewall logs at Status > System Logs,Firewall tab. Look for entries that indicate that the connection is beingblocked. If the tunnel is not establishing, check for UDP entries for ports500 and 4500. Rules are normally added automatically for IPsec(IPsec and firewall rules), but that feature can be disabled or theremay be edge cases where the firewall cannot identify the remote IPsec gateway.Add rules to pass traffic if needed.
The single most common cause of failed IPsec tunnel connections is aconfiguration mismatch. Often it is something small, such as a DH group setdifferently, or perhaps a subnet mask of /24 on one side and /32 on the other inthe phase 2 networks. Some routers (Linksys, for one) also like to hide certainoptions behind “Advanced” buttons or make assumptions. A lot of trial and errormay be involved, and a lot of log reading, but ensuring that both sides matchprecisely will help the most.
Depending on the Internet connections on either end of the tunnel, it is alsopossible that a router involved on one side or the other does not properlyhandle IPsec traffic. This is a larger concern with mobile clients and networkswhere NAT is involved outside of the actual IPsec endpoints. The problems aregenerally with the ESP protocol and problems with it being blocked or mishandledalong the way. NAT Traversal (NAT-T) encapsulates ESP in UDP port 4500traffic to work around these issues. Typically this situation is detectedautomatically but in some edge cases it can help to force NAT traversal forIKEv1 tunnels.
“Random” tunnel disconnects/DPD failures on low-end routers¶
If IPsec tunnels are dropped on low-end hardware that is pushing the limits ofits CPU, DPD on the tunnel may need disabled. Such failures tend to correlatewith times of high bandwidth usage. This happens when the CPU on a low-powersystem is tied up with sending IPsec traffic or is otherwise occupied. Due tothe CPU overload it may not take the time to respond to DPD requests or see aresponse to a request of its own. As a consequence, the tunnel will fail a DPDcheck and be disconnected. This is a clear sign that the hardware is beingdriven beyond its capacity. If this happens, consider replacing the firewallwith a more powerful model.
Tunnels establish and work but fail to renegotiate¶
In some cases a tunnel will function properly but once the phase 1 or phase 2lifetime expires the tunnel will fail to renegotiate properly. This can manifestit*elf in a few different ways, each with a different resolution.
DPD is unsupported and one side drops while the other remains¶
Consider this scenario, which DPD is designed to prevent, but can happen inplaces where DPD is unsupported:
A tunnel is established from Site A to Site B, from traffic initiated at SiteA.
Site B expires the phase 1 or phase 2 before Site A
Site A will believe the tunnel is up and continue to send traffic as thoughthe tunnel is working properly.
Only when the Site A phase 1 or phase 2 lifetime expires will it renegotiateas expected.
In this scenario, the likely things resolutions are:
Check to make sure all of the settings match on both sides, especially thephase 1 DH Group and phase 2 PFS values.
Enable DPD, or Site B must send traffic to Site A which will cause the entiretunnel to renegotiate. The easiest way to make this happen is to enable a keepalive mechanism on both sides of the tunnel.
Enable the periodic check keep alive method on one end(Configuring IPsec Keep Alive)
Tunnel establishes when initiating but not when responding¶
If a tunnel will establish sometimes, but not always, generally there is asettings mismatch. The tunnel may still establish because if the settingspresented by one side are more secure the other may accept them, but not theother way around.
Lifetime mismatches do not cause a failure in phase 1 or phase 2.
To track down these failures, configure the logs as shown inTroubleshooting IPsec Logs and attempt to initiate the tunnel from each side, thencheck the logs.
Tunnel establishes at start but not when disconnected¶
An IPsec tunnel can be disconnected for a variety of reasons. For example,connectivity being interrupted to the far side, the remote being down or offlinefor an extended time, or even a manual or policy action on the far side.
Note
This is not the same scenario as a rekey or reauthentication event, whichwill rebuild the appropriate parts of the tunnel and remain active.
A tunnel mode IPsec instance will connect at start and when it disconnects, willconnect again on demand. This happens due to trap policies which triggerinitiation when traffic attempts to use the tunnel. A tunnel mode IPsecconnection can be reconnected without manual intervention by the automatic pingkeep alive function on a phase 2 entry.
VTI mode IPsec cannot support trap policies so it is not capable of using thistactic. As such, a VTI tunnel may need help to stay up and running at all times.
There are a two workarounds that may help in this case:
- Keep Alive - Periodic Check:
The IPsec phase 2 Keep Alive option toperform a periodic IPsec status check is ideally suited to this case. Whenenabled, if a given phase 2 is down it will trigger an initiation directly.
This works with VTI because it does not rely on trap policies.
Note
This feature is new in pfSense® Plus software version 22.01 and CE 2.6.0.
- Child SA Actions:
Another tactic to keep a tunnel up is to set it to initiate immediately atstart and automatically reconnect if it gets disconnected. This should only beset on one side of a tunnel.
- Child SA Start Action:
Set the start action to Initiate at start. This will trigger a tunnelinitiation when the IPsec daemon starts, such as at boot time.
Note
This does not trigger when the IPsec configuration is changed andreloaded, only when the daemon loads the configuration the first time atstartup.
- Child SA Close Action:
Set the close action to Restart/Reconnect which will attempt toimmediately reconnect the child SA if it gets disconnected.
Depending on the reason the tunnel was disconnected, this may or may not behelpful. For example, if the reason the tunnel disconnected was a local cause,these events may not trigger. The periodic check keep alive method is muchmore reliable, but only available on current versions of pfSense software.
Tunnel stops attempting connections after timeout¶
If the remote end of an IPsec tunnel is down when the tunnel attempts toinitiate at start, but fails, it may eventually times out and stop trying toconnect.
The solution here is similar to the previous scenario above, which is to enablekeep alive options for the tunnel which will trigger a fresh initiationperiodically if the tunnel is down.
