WireGuard Profile for an IPsec Gateway: What to Ask For Instead

Handshake timeouts with a silent gateway usually mean two protocols that never meet. A WireGuard peer speaks Noise while an IPsec gateway waits for IKE. Correct address and port do not change that.

Reusing the endpoint in a profile does not bridge the two. The next step is a request to whoever runs the gateway.

Request One: The Protocol Version

IPsec names a family rather than a single workflow. IKEv2 and IKEv1 differ in their exchanges, their authentication options and their behaviour across a network change. A gateway that terminates only IKEv1 will behave quite differently from one that offers IKEv2. The client configuration differs with it.

Ask which version the service terminates and whether it runs a standards-based implementation or a vendor variant with its own client. Operating system menus often hide that answer behind a single label. The label is not the protocol.

Request Two: The Client Authentication Method

Authentication is where most of the real work sits. The service may expect a machine certificate with a particular extended key usage, a user certificate, an EAP method over IKEv2, or a pre-shared key bound to an identity. Which one applies decides what the client needs.

A WireGuard private key is none of those things. It is a Curve25519 key used in one specific handshake. No conversion turns it into a certificate or an EAP credential. A tool that claims otherwise is renaming the file or generating something unrelated.

The IKEv2 specification in RFC 7296 describes what an implementation of that version must support. It is a reference for a vague operator answer, not a client configuration guide.

Request Three: The Trusted Identity and the Destinations

Ask for the gateway identity as the client must see it, plus the trust anchor that validates it. Then ask which private ranges and resolvers the service pushes. Those two answers decide what the tunnel actually carries.

Without them a working connection can still fail the task. A tunnel up with no pushed resolver leaves internal names unanswered. A missing traffic selector leaves the destination outside the tunnel even though the handshake succeeded.

A probe of the endpoint answers a different question than the client error does. A reachable port with no association points at authentication, while an unreachable port points at the path.

# what does the endpoint offer on its IPsec ports?
sudo nmap -sU -p 500,4500 198.51.100.44

# strongSwan: what did the IKE exchange negotiate?
sudo swanctl --list-sas
sudo swanctl --list-conns

Run that probe before changing anything in the client. If the ports answer and the association still fails, the problem is credentials or policy. If they do not answer at all, no profile edit will help.

When Both Protocols Have to Coexist

Administering both networks is a legitimate reason to keep both protocols. The usual design terminates WireGuard and IPsec on separate interfaces or separate gateways. Approved traffic is then routed between them.

That design introduces a trust and authorization boundary, and it should be written down as one. Which peers may cross, in which direction, and under whose policy is a routing and firewall decision. Neither protocol supplies it.

What it is not is a transparent conversion. Traffic arriving over WireGuard is re-originated into the IPsec tunnel, and every policy in between applies to it.

Settle the server's protocol and authentication requirements first. Then use the client and enrollment path the operator supports, and keep private keys out of web converters while that happens.