deadshadow

network privacy model

tl;dr

incoming traffic enters an offshore gre tunnel endpoint. the endpoint forwards traffic to our nginx server without preserving the original public source ip as application-visible data. nginx receives only the internal tunnel address (10.10.10.x) as $remote_addr, then rewrites x-forwarded-for to 0.0.0.0 before synapse. a privileged administrator with direct access to the routing device could theoretically enable packet capture and observe encrypted flow metadata including source ips, but could not read message contents without breaking tls. this model is an application-layer guarantee, not a claim of global network anonymity.


routing architecture

incoming traffic first reaches an offshore gre tunnel endpoint operating in a jurisdiction outside our primary hosting location. that endpoint encapsulates and forwards traffic through the gre tunnel to our final server, without preserving the original public source ip as any application-layer or header data.

by the time a request reaches our nginx instance, the only visible address is an internal tunnel address such as 10.10.10.40. this is what nginx logs as $remote_addr — not the client's real ip.

nginx then explicitly sets x-forwarded-for: 0.0.0.0 before proxying to synapse, so even the tunnel address does not reach the matrix application layer.

client
real public ip: x.x.x.x
↓ tls connection
offshore gre endpoint
sees: x.x.x.x
forwards via gre — source ip not preserved
↓ gre tunnel
nginx ($remote_addr)
sees: 10.10.10.40
sets x-forwarded-for: 0.0.0.0
↓ localhost
synapse (application layer)
x-forwarded-for: 0.0.0.0
real ip: never present

observability
theoretically observable — transport layer only, requires deliberate packet capture
  • source and destination ip addresses at the gre endpoint
  • ports, timing, packet sizes, and flow direction
  • tls sni field in the unencrypted handshake, where present
  • traffic volume patterns that may suggest client or federation activity
not observable — protected by tls regardless of packet capture
  • plaintext message contents
  • matrix event bodies and payloads inside tls connections
  • user credentials and session tokens
  • mapping of encrypted flows to specific user identities without external correlation data

scope and limits

this is an application-layer guarantee. our production matrix homeserver cannot log users' real public source ip addresses because those addresses do not reach the application layer at all.

it is not a claim of global network anonymity. at the transport layer, an administrator with direct access to the routing device could theoretically enable packet capture and observe encrypted flow metadata. that metadata would not include message contents.

we will never voluntarily share any data in our possession with any government, law enforcement agency, intelligence service, or third party. we do not retain ip logs. there is no user data to hand over at the application layer because we do not collect it.

if you require network-layer anonymity beyond this model, we recommend tor or a self-hosted vpn — specifically amnezia vpn, a self-hostable solution with advanced obfuscation protocols designed to resist deep packet inspection and network-level censorship.