skip to content

When a WireGuard gateway replaces IPsec remote access for 50 engineers, what does the protocol leave you to build, and when would you decline?

level: principalimportance: should knowfreq 18%

answer

  1. a key per device, not a user
  2. addresses are static configuration
  3. revocation is deleting a row
  4. no algorithm to choose
  5. who runs the key inventory

basics

~20 s

WireGuard authenticates device keys, not users, and pushes no configuration, so enrolment, key-to-person mapping, revocation, addressing and client settings are yours. Decline, or keep IPsec beside it, where policy demands certificate or EAP login or mandated algorithms.

solid answer

~50 s

WireGuard gives you a small, fixed protocol: a one-round-trip handshake, ChaCha20-Poly1305 with nothing negotiated, roaming, and a gateway that stays silent toward anyone without a configured key. What it deliberately leaves out is everything an IKEv2 remote-access stack bundles. Identity is a device's static public key, so issuing keys, mapping them to people and removing them when people leave is your system. Revocation means deleting the peer from the gateway. There is no user login or second factor in the protocol: the private key file is the credential. Addresses are static allowed-IPs entries, and routes and resolvers live in each client's configuration instead of being pushed the way an IKEv2 configuration payload pushes them. For 50 engineers, configuration generated from one inventory is enough. I would decline, or run both, where policy demands per-user certificate or EAP authentication, or an approved algorithm set WireGuard cannot offer.

go deeper

for a junior

Recall that WireGuard knows devices by public keys only: no usernames, no pushed settings, and removing a key is how access is taken away.

for a middle

List what IKEv2 remote access bundled that WireGuard does not: user authentication, address and resolver push, revocation through certificates, and algorithm choice.

for a senior

Design the key lifecycle: generation on the device, an inventory tied to people, generated gateway tables, static-key rotation and an offboarding step.

for a principal

Own the decision: the protocol's simplicity moves risk into the inventory you run, so decline or run both where policy, staffing or devices cannot carry that.

## What the protocol gives you As the WireGuard paper defines it, WireGuard is deliberately narrow: - a **one-round-trip handshake** between peers that already hold each other's static Curve25519 public keys; - **one fixed suite** with no negotiation, so nothing can be mismatched or downgraded; - **cryptokey routing**: each peer's allowed IPs pick its packets outbound and authenticate their source inbound; - **roaming**, because a peer's endpoint is learned from its latest authenticated packet; - **silence** toward anyone who cannot authenticate, plus a cookie mechanism for handshake floods; - sessions that rekey about every two minutes, which gives forward secrecy. The paper is explicit that key distribution is *the wrong layer* for the protocol to address. That decision shapes the whole migration. ## What it leaves to you An IPsec remote-access deployment negotiated by IKEv2 (RFC 7296) carries a lot of machinery that WireGuard does not have. The table names the IKEv2 side in one phrase only: | Concern | IKEv2 remote access | WireGuard | What you build | |---|---|---|---| | Who is connecting | certificates or EAP methods | a device's static public key | a key-to-person inventory | | Enrolment | a certificate issued by a CA | a public key copied out of band | an enrolment flow; keys generated on the device | | Revocation | certificate revocation or expiry | delete the peer's row | an offboarding step that edits the gateway | | User login, second factor | possible through EAP | none in the protocol | gate the enrolment, and re-enrol periodically | | Client address | configuration payload (`INTERNAL_IP4_ADDRESS`) | a static `/32` in allowed IPs | an address allocation list | | Resolvers and routes | configuration payload (`INTERNAL_IP4_DNS`) | client-side configuration | generated client configuration files | | Algorithms | negotiated proposals | fixed | a plan for a fleet-wide update | ## A key lifecycle for 50 engineers 1. **Generate the key pair on the laptop.** Only the public key leaves the device. One key pair per device, never shared; the paper warns against peers sharing private keys. 2. **Register** the public key with the engineer's name, the device and an allocated `/32` from `10.66.0.0/24` in one inventory. 3. **Render** the gateway's peer table and each laptop's configuration from that inventory, with an overlap check on allowed IPs. 4. **Rotate static keys on a schedule.** Session keys change roughly every `Rekey-After-Time` (120 s), but static identity keys never change on their own. 5. **Offboard** by removing the row. No new handshake can complete, and the current session cannot outlive `Reject-After-Time` (180 s). At 50 engineers this fits in a small script and a reviewed change. At several thousand it becomes a real control plane, and that is the point to reconsider build versus buy. ## Optional extras and their price - **The pre-shared key.** The `psk2` part of the handshake can mix in a per-pair 256-bit symmetric key. The paper's motive is traffic recorded today being decrypted later if Curve25519 falls. It doubles the secrets per laptop that the inventory must distribute and rotate. - **The persistent keepalive.** It is needed only if the office must reach idle laptops behind translators. It costs battery and the tunnel's silence. ## When I would decline, or run both - **A mandated algorithm set.** If policy names specific algorithms, WireGuard cannot comply, because its suite is fixed. - **Per-user authentication in the protocol.** If an audit needs each tunnel tied to a user's certificate or an EAP login at connect time, WireGuard authenticates only a device key. You would have to rebuild that assurance around enrolment. - **No capacity to run the inventory.** The protocol stays simple only while someone owns key issuance and revocation. Without an owner, keys of departed staff linger. - **Endpoints that cannot run WireGuard.** Devices limited to IKEv2 keep the existing gateway. Running both for a while is normal: move engineers whose devices and roles fit, and leave the rest on IPsec until the inventory has proven itself. ## The trade in one line You swap a protocol that negotiates and pushes everything for one that does almost nothing at connect time. Its correctness then depends on the configuration you generate for it.

  • How does offboarding an engineer work on a WireGuard gateway, and how quickly does access end?
    Remove the laptop's public key and its allowed-IPs row from the gateway. From then on no handshake can complete for that key, and the session already running cannot be used past `Reject-After-Time` (180 s) per the WireGuard paper. Disabling the engineer's directory account does nothing by itself, because the protocol never asks who the user is.
  • Would you configure WireGuard's optional pre-shared key for every laptop?
    Only if the data must stay confidential for years. The pre-shared key protects against traffic recorded now being decrypted if Curve25519 is broken later, which is the paper's motive. It adds one more secret per laptop to distribute and rotate. With an automated inventory that cost is small; with manual key handling it doubles the error surface.

saying these in an interview costs you the question

  • WireGuard authenticates the engineer, so disabling their account cuts off the tunnel.
  • A WireGuard gateway assigns each client an address dynamically when it connects.
  • WireGuard sessions rekey every two minutes, so static keys never need rotating.
  • WireGuard can be configured to use AES-GCM to meet an approved-algorithm policy.
  • Several WireGuard laptops can share one key pair to make enrolment simpler.