Differences

This shows you the differences between two versions of the page.

--- install_24_4_strongswan [2026/01/11 14:42] – [Configure Swanctl] system
+++ install_24_4_strongswan [2026/01/12 06:08] (current) – [Create PKI] system
@@ Line 6: / Line 6: @@
   * The following instructions should work well on any of the recent versions of StrongSwan
+-----------
 ===== Install StrongSwan  =====
   * As stated on the StrongSwan Primer wiki page, StrongSwan has gone through an aggressive redesign and you should take care when installing it not to install the older legacy version.
@@ Line 54: / Line 55: @@
 ------
 ===== Create PKI  =====
-  * Next we will creaate the PKI.
+  * Next we will create the PKI.
   * We need to install a helper package that is part of StrongSwan first.
 <code bash>
@@ Line 61: / Line 62: @@
   * We issue the following commands.
 <code bash>
-mkdir -p ~/pki/{cacerts,certs,private}
+mkdir -p ~/pki/{ca,certs,private}
 chmod 700 ~/pki
 cd ~/pki
@@ Line 81: / Line 82: @@
 </code>
+<WRAP center round tip 100%>
+  * StrongSwan has some very good documentation on managing certificates
+  * https://docs.strongswan.org/docs/latest/pki/pkiQuickstart.html
+</WRAP>
 --------
@@ Line 89: / Line 95: @@
   * This setup relies strong on convention where **swanctl** expect certain items to be located under certain folders.
   * We also have the **swanctl.conf** config file which we will cover in this section.
+---------
 ==== Config File ====
   * The config file has a JSON like structure.
@@ Line 136: / Line 144: @@
 }
 </code>
+------------
+==== Cert and Key Files ====
+  * As we stated there are some pre-installed sub folders under the **/etc/swanctl** folder.
+  * The following should be used to contain the CA, server cert and server key files.
+  * Copy the **ca.crt** file to **/etc/swanctl/x509ca**.
+  * Copy the **server.key** file to **/etc/swanctl/private**.
+  * Copy the **server.crt** file to **/etc/swanctl/x509**.
+----------
+===== Xfrm Interface Prep =====
+  * When a client connects establishes a connection to the StrongSwan server, it is referred to as a Security Association (SA).
+  * We can use the swanctl command to see if there are any existing SAs.
+<code bash>
+sudo swanctl --list-sa
+xfrm-gw: #11, ESTABLISHED, IKEv2, 8c4f8f2882625d72_i* f423c783942a5006_r
+  local  'cloud.radiusdesk.com' @ 164.160.89.129[4500]
+  remote 'carol@strongswan.org' @ 197.64.146.11[4500] [10.3.1.0]
+  AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
+  established 679s ago, rekeying in 2626s
+  xfrm-gw: #7, reqid 1, INSTALLED, TUNNEL-in-UDP, ESP:AES_CBC-128/HMAC_SHA1_96/MODP_2048
+    installed 1372s ago, rekeying in 2128s, expires in 2588s
+    in  c9f9936f (-|0x00000064),   2645 bytes,    29 packets,   139s ago
+    out c33bfaa6 (-|0x00000064),  22938 bytes,    38 packets,   139s ago
+    local  0.0.0.0/0
+    remote 0.0.0.0/0
+</code>
+  * We implement a route based IPsec VPN (The other option is policy based).
+  * Route based IPsec specify a **if_id_in** and **if_id_out**.
+  * This is used to tag traffic inside a SA.
+  * With Wireguard, you can have multiple instances running on different ports.
+  * With StrongSwan there is one instance, but you can have multiple connections defined in the config file each using a unique **if_id_in** and **if_id_out**.
+  * The **if_id_in** and **if_if_out** in tern have to terminate into a **xfrm** interface.
+  * We will create a startup script that prepare this interface for us **BEFORE** we start StrongSwan.
+  * Create the file **/usr/local/sbin/xfrm-up.sh** with the following contents.
+  * We assume eth0 is the interface name where the server gets it Internet from. Please adapt if your server is different.
+<code bash>
+#!/bin/sh
+set -e
+#
+IFACE=xfrm0
+IF_ID=100
+ADDR=10.3.0.1/32
+SUBNET=10.3.0.0/24
+# Create XFRM interface
+ip link show "$IFACE" >/dev/null 2>&1 || \
+ip link add "$IFACE" type xfrm if_id "$IF_ID"
+# Assign IP
+ip addr show "$IFACE" | grep -q "$ADDR" || \
+ip addr add "$ADDR" dev "$IFACE"
+# Bring interface up
+ip link set "$IFACE" up
+# Route for remote side
+ip route show "$SUBNET" | grep -q "$IFACE" || \
+ip route add "$SUBNET" dev "$IFACE"
+# ---- NAT via nftables ----
+# Create table if missing
+nft list table ip nat >/dev/null 2>&1 || \
+nft add table ip nat
+# Create postrouting chain if missing
+nft list chain ip nat postrouting >/dev/null 2>&1 || \
+nft add chain ip nat postrouting { type nat hook postrouting priority 100\; }
+# Add SNAT/MASQUERADE rule (idempotent)
+nft list chain ip nat postrouting | grep -q "$IFACE" || \
+nft add rule ip nat postrouting oifname "$IFACE" masquerade
+nft add rule ip nat postrouting oifname "eth0" masquerade
+</code>
+  * Create a startup script called **/etc/systemd/system/xfrm0.service** which calls the script above.
+<code bash>
+[Unit]
+Description=XFRM Interface xfrm0
+Before=strongswan.service
+Wants=network-online.target
+After=network-online.target
+[Service]
+Type=oneshot
+ExecStart=/usr/local/sbin/xfrm-up.sh
+RemainAfterExit=yes
+[Install]
+WantedBy=multi-user.target
+</code>
+  * Enable the startup script and start it up
+<code bash>
+systemctl enable xfrm0
+systemctl start xfrm0
+</code>
+  * Everything is now prepared on the server side.
+  * We can now configure clients in APdesk and MESHdesk to route certain traffic through the IPsec tunnel.
+  * These are covered in a dedicated Wiki page.