Now Available: Open WireGuard Endpoints and Lambda Async Invocation - Proxylity Blog
Now Available: Open WireGuard Endpoints and Lambda Async Invocation
By Lee Harding | June 3, 2026 | 7 min read
Two new capabilities are available in UDP Gateway today. The first allows WireGuard Listeners to accept<br>connections from any client without pre-registration — the same model HTTPS uses for websites. The second<br>allows Lambda destinations to be invoked asynchronously, firing a packet into a long-running workflow<br>without the Gateway waiting for a response. Together they open up a class of public-facing, event-driven<br>WireGuard services that previously required significant custom infrastructure to build.
WireGuard Open Endpoints
WireGuard Listeners have always required every connecting client to be pre-registered: you list each<br>peer's public key in your CloudFormation template, and the Listener rejects any handshake from an<br>unknown key. That model fits private services with a managed set of devices. But it<br>creates a problem for anything that needs to be accessible by a large or unknown set of clients.
Consider a mobile app that generates a WireGuard keypair on first launch. Or a fleet of devices<br>provisioned on demand where central key management is operationally impractical. Or any public-facing<br>service where clients you've never seen before need to connect. With the previous model, every one of<br>those clients required an out-of-band registration step and a CloudFormation update before it could<br>complete a handshake. That's not a model that scales to public services.
The new AllowUnknownPeers property removes that restriction. Set it to true<br>on a WireGuard Listener and the Gateway will complete the handshake with any valid WireGuard client,<br>regardless of whether its public key is listed. The connection is still fully encrypted — WireGuard's<br>cryptographic properties don't change. The difference is simply that the Listener no longer requires<br>the key to be known in advance.
The analogy to HTTPS is intentional. When you visit a website over HTTPS, the server doesn't need to<br>know who you are before establishing an encrypted connection. The TLS handshake completes, the channel<br>is encrypted, and authentication (if it happens at all) is a separate concern at the application layer.<br>Open WireGuard endpoints work the same way: the transport is encrypted, and identity can be handled<br>by your Lambda or Step Functions destination however your application requires.
Adding a shared credential gate
Fully open enrollment — accepting literally any WireGuard client — is appropriate for some services.<br>For others, you want the encryption and the open handshake, but you also want to prevent connections<br>from clients that weren't issued credentials. The UnknownPeerPreSharedKey property<br>provides a lightweight gate for exactly this case.
When UnknownPeerPreSharedKey is set, unknown peers must include that PSK in their<br>WireGuard configuration or the handshake fails. It's not per-device authentication — every client<br>uses the same secret — but it meaningfully restricts access to clients that were issued the PSK.<br>Think of it like a shared API key for transport-layer access: not strong identity, but a real<br>barrier against arbitrary connections from clients who were never given credentials.
Distributing the PSK to clients is your application's responsibility. Store it in AWS Secrets Manager<br>and reference it from your CloudFormation stack on the infrastructure side; provision it to devices<br>during manufacturing or enrollment on the client side.
WireGuardListener:<br>Type: Custom::ProxylityUdpGatewayListener<br>Properties:<br>ServiceToken: !FindInMap [ProxylityConfig, !Ref "AWS::Region", ServiceToken]<br>ApiKey: !FindInMap [ProxylityConfig, Account, ApiKey]<br>Protocols:<br>- wg<br>AllowUnknownPeers: true<br>UnknownPeerPreSharedKey: !Sub "{{resolve:secretsmanager:${WireGuardPSK}:SecretString}}"<br>Destinations:<br>- Name: packet-handler<br>DestinationArn: !GetAtt HandlerLambda.Arn<br>Role:<br>Arn: !GetAtt ProxylityRole.Arn
Named peers (listed in the Peers array) are unaffected by AllowUnknownPeers<br>and UnknownPeerPreSharedKey. They use their own per-peer SharedSecret as<br>before. The two models can coexist on a single Listener: a fixed set of known devices with per-device<br>PSKs, and an open slot for dynamic clients behind a shared credential.
Lambda Async Invocation
Lambda destinations in UDP Gateway have always used synchronous RequestResponse invocation:<br>the Gateway delivers a batch of packets, waits for the function to complete, and uses the function's<br>return value to send reply packets back to clients. That model is the default to align with how<br>UDP request/response patterns work.
But synchronous invocation becomes limiting for workloads where a function's job is to kick off<br>processing that outlives a single invocation. Lambda durable functions address exactly this: using<br>a checkpoint-and-replay mechanism, a durable function can execute for up to one year,...