> For the complete documentation index, see [llms.txt](https://docs.sendman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sendman.com/admin-portal/settings/network-connections/ipsec.md). # IPsec Connect a local network to Sendman with an IKEv2 IPsec tunnel Sendman supports **route-based IKEv2 IPsec tunnels** with pre-shared key (PSK) authentication. This guide uses the example address plan from [Network Connections](/admin-portal/settings/network-connections.md#address-plan): | Purpose | Example | | ----------------------------- | ------------------ | | Sendman tunnel address | `169.254.100.5/30` | | Your gateway's tunnel address | `169.254.100.6/30` | | Your local network | `10.20.0.0/24` | | Your gateway's public address | `203.0.113.20` | {% hint style="info" %} IKEv1, L2TP, transport mode, certificate or EAP authentication and address assignment by IKE are not supported. {% endhint %} ## Choose how the tunnel is set up | Connection setup | Requirements | | -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Sendman dials your gateway** (recommended) | Your gateway has a public IPv4 address that is reachable on UDP 500 and 4500. Nothing has to be opened towards Sendman. | | **Your gateway dials Sendman** | Your gateway initiates the tunnel to Sendman's public address on UDP 500 and 4500. Sendman recognises your gateway by its IKE identity and the pre-shared key alone, so use a long random key. | ## Create the connection in the portal 1. Go to **Settings → Network Connections**, click **Add connection** and choose **IPsec**. 2. **General:** enter a **Name**, e.g. `Headquarters`. 3. **Tunnel:** * **Tunnel address:** Sendman's tunnel address, e.g. `169.254.100.5/30` * **Connection setup:** see above * **Remote gateway address:** your gateway's public IPv4 address, e.g. `203.0.113.20` (only if Sendman dials your gateway) * **Pre-shared key (PSK):** a long random key, different for every connection. If your gateway dials Sendman, it must have at least 20 characters. * **Local IKE identity:** Sendman's identity, e.g. `sendman.contoso.com` * **Remote IKE identity:** your gateway's identity, e.g. `vpn.contoso.com`. Every connection needs a different remote identity. * **IKE proposals:** default `aes256-sha256-modp2048` * **ESP proposals:** default `aes256-sha256` * **MTU:** we recommend `1400` for IPsec. 4. **Routing:** * **Customer subnets:** your local networks that shall reach Sendman, comma-separated, e.g. `10.20.0.0/24` 5. Save the connection. The IKE identities are names that identify the two ends; they do not have to exist in DNS. Configure them as FQDN identities on your gateway. ## Configure your gateway On your gateway, *local* and *remote* are the other way round: | Setting on your gateway | Value | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | VPN type | Route-based (interface-based) IPsec, tunnel mode | | IKE version | IKEv2 | | Authentication | Pre-shared key, identical to the PSK in the portal | | Local IKE identity | Sendman's **Remote IKE identity**, e.g. `vpn.contoso.com` (FQDN) | | Remote IKE identity | Sendman's **Local IKE identity**, e.g. `sendman.contoso.com` (FQDN) | | Remote gateway | Sendman dials your gateway: accept the peer by its IKE identity (dynamic peer). Your gateway dials Sendman: the **IKE endpoint** shown in the connection details. | | IKE (phase 1) | AES-256-CBC, SHA-256, DH group 14 (MODP 2048) | | ESP (phase 2) | AES-256-CBC, HMAC-SHA-256, no PFS (matching the default `aes256-sha256`) | | Traffic selectors / proxy IDs | `0.0.0.0/0` on both sides | | NAT traversal | Enabled | | Dead peer detection | Enabled | | Tunnel interface address | `169.254.100.6/30`, if your gateway requires a numbered tunnel interface | | Route to Sendman | `169.254.100.5/32` via the IPsec tunnel interface | | MTU | `1400` | {% hint style="info" %} If your security policy requires perfect forward secrecy (PFS) for ESP, change the **ESP proposals** in the portal, e.g. to `aes256-sha256-modp2048`, and configure the same group on your gateway. {% endhint %} In addition: * Allow your clients to reach `169.254.100.5` on TCP 25, 465 and 587 as needed, and permit the replies. * Do not apply NAT to traffic from your local network to Sendman. * The traffic selectors `0.0.0.0/0` do not create a default route. Only route Sendman's tunnel address through the tunnel. ## Enable and test 1. In **Settings → Network Connections**, tick the connection under **Sendman ingress** and click **Save selection**. 2. Add your local network, e.g. `10.20.0.0`–`10.20.0.255`, to the [IP Allow List](/admin-portal/sendman/ip-allow-list.md). 3. Check on your gateway that the IKE and IPsec security associations are established. If the first attempt failed because of a configuration error, initiate the tunnel again after correcting it. 4. From a client in your local network, send a test message to `169.254.100.5` on port 587 or 25, and check [Logs](/admin-portal/insights/logs.md) for the client's local address. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.sendman.com/admin-portal/settings/network-connections/ipsec.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.