{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiagq26pmuerdocobs7vgb5z53mroyk2ay3cr5nkoq7eo4hx52zpqq",
    "uri": "at://did:plc:haakkg7y3xdghcdmprxeexso/app.bsky.feed.post/3mm6445zd2te2"
  },
  "path": "/t/mullvad-exit-ips-as-a-fingerprinting-vector/37910#post_18",
  "publishedAt": "2026-05-18T23:26:09.000Z",
  "site": "https://discuss.privacyguides.net",
  "tags": [
    "by design"
  ],
  "textContent": "obscuracarl:\n\n> WireGuard is by design a “Connection-less Protocol”, there’s no concept of a connection\n\nNot true at all. This is a misunderstanding of how Peer association works.\n\nobscuracarl:\n\n> the exit IP were randomized each time you “connect” to the server\n\nOur WireGuard client changes keys & peer every 45m. Yet to hear complaints from testers about broken streams etc. We’ll see.\n\nobscuracarl:\n\n> connections that are on non-roaming protocols (basically everything except QUIC) would be disrupted\n\nSome L4 load balancers are clever. They pin clients (destination) only on source tuple (of the LB) to backends. That is, as long as the client connects to the same LB (same IP & port), it’ll have an unbroken stream to backend that served it.\n\nobscuracarl:\n\n> this person keeps reconnecting from a different IP, they must be using Mullvad\n\nDisingenuous when public VPN provider exit IP ranges are not secret and/or published openly.\n\njonah:\n\n> Really nothing to do with what I said\n\nProbably. I assumed you wrote precisely whatever you want said.",
  "title": "Mullvad exit IPs as a fingerprinting vector"
}