fix(gateway): reply with cookie when rate limit is hit

[thomaseizinger]

WireGuard implements a rate-limit mechanism when the number of handshake initiations increases a certain limit. This is important because handshakes involve asymmetric cryptography and are cryptographically expensive. To prevent DoS attacks where other peers repeatedly ask for new handshakes, the rate limiter implements a cookie mechanism where - when under load - the remote peer needs to include a given cookie in new handshakes. This cookie is tied to the peer's IP address to prevent it from being reused by other peers.

Up until now, we have not been passing the sender's IP address to boringtun and therefore, the only option when the rate limit was hit was to error with UnderLoad.

By passing the source IP of the packet, boringtun can engage in the cookie-reply mechanism and therefore avoid the UnderLoad error.

Resolves: #9643

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
firezone	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 24, 2025 9:37am

[Copilot]

Pull Request Overview

This pull request modifies the rate-limiting mechanism in the handshake process by incorporating the sender’s IP address, enabling the cookie reply mechanism during heavy load instead of an UnderLoad error.

• Import std::net::IpAddr to use IP address types.
• Update decapsulate to accept a new IP parameter and pass it to decapsulate_at.

Comments suppressed due to low confidence (3)

rust/connlib/snownet/src/node.rs:2108

• Consider adding a doc comment for the new 'src' parameter to explain that it represents the sender's IP used for the cookie reply mechanism.

        src: IpAddr,

rust/connlib/snownet/src/node.rs:2108

• [nitpick] Consider renaming the parameter 'src' to 'source_ip' for improved clarity regarding its purpose.

        src: IpAddr,

rust/connlib/snownet/src/node.rs:2119

• [nitpick] A brief comment explaining the reason for passing Some(src) (i.e., to enable the cookie reply mechanism instead of erroring on UnderLoad) could improve code clarity.

            .decapsulate_at(Some(src), packet, ip_packet.buf(), now)

[jamilbk]

Nicely done. Does this still work for multiple clients behind a NAT that share the same source IP?

[thomaseizinger]

Nicely done. Does this still work for multiple clients behind a NAT that share the same source IP?

We are following the WireGuard paper here, I'd assume they considered that case in the design.

I think it should work because each tunnel has its own state.