Healthy Session
Local tracer: enroll, publish, fail over
healthy
A real DAMM device was initialized locally, enrolled against the control plane, assigned 10.44.0.10,
published through a healthy gateway, and then switched to a secondary front door using the signed catalog. This is the clearest single-path proof of the current product model.
Devicetracer-laptop
GatewayBerlin Edge 1 · gw-eu-1
Access Tierstandard
Exit PolicyDE
Annotated flow
- Init: the client generated its WireGuard keypair locally and kept the private key on-device.
- Enroll: the control plane chose a healthy gateway and egress pool, issued
10.44.0.10, and returned peer material.
- Publish: the operator report saw
2 recovery endpoints for the session.
- Fail over: the client switched from
vpn.example.com:51820 to vpn2.example.com:51820 using the signed catalog.
Healthy Session
Host smoke: hub2 ↔ finml
ok
This is a real cross-host WireGuard smoke between two machines we control. It proves that the kernel interfaces came up, the handshake completed on both sides, and bidirectional tunnel ping succeeded.
Left Hostuprootiny@149.102.137.139
Right Hostuprootiny@5.189.145.105
Tunnel10.231.0.1 ↔ 10.231.0.2
Avg RTT1.469 ms / 1.587 ms
Annotated flow
- Bring-up: both hosts created
damm-smoke interfaces and bound UDP port 51871.
- Handshake: each side recorded a recent handshake and transferred bytes in both directions.
- Ping: tunnel ping from left to right averaged
1.469 ms; right to left averaged 1.587 ms.
- Meaning: this is direct packet-level proof that the current host fleet can sustain WireGuard tunnels today.
WireGuard and ping excerpts
interface: damm-smoke
public key: yuISJWlRlgKSlZfW/6So7pdShXIhBOHioTdruRc7s2A=
private key: (hidden)
listening port: 51871
peer: F4cLZVOjbMf+OEkwKO3sLRA2yAtoHKQvrljqjwhBcDY=
endpoint: 5.189.145.105:51871
allowed ips: 10.231.0.2/32
latest handshake: 2 seconds ago
transfer: 180 B received, 272 B sent
persistent keepalive: every 15 seconds
PING 10.231.0.2 (10.231.0.2) 56(84) bytes of data.
64 bytes from 10.231.0.2: icmp_seq=1 ttl=64 time=1.84 ms
64 bytes from 10.231.0.2: icmp_seq=2 ttl=64 time=1.10 ms
--- 10.231.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.097/1.469/1.842/0.372 ms
Healthy Session
Host smoke: hub2 ↔ hyle
ok
This is a real cross-host WireGuard smoke between two machines we control. It proves that the kernel interfaces came up, the handshake completed on both sides, and bidirectional tunnel ping succeeded.
Left Hostuprootiny@149.102.137.139
Right Hostuprootiny@173.212.203.211
Tunnel10.231.0.1 ↔ 10.231.0.2
Avg RTT1.364 ms / 1.954 ms
Annotated flow
- Bring-up: both hosts created
damm-smoke interfaces and bound UDP port 51871.
- Handshake: each side recorded a recent handshake and transferred bytes in both directions.
- Ping: tunnel ping from left to right averaged
1.364 ms; right to left averaged 1.954 ms.
- Meaning: this is direct packet-level proof that the current host fleet can sustain WireGuard tunnels today.
WireGuard and ping excerpts
interface: damm-smoke
public key: miF8uFD4loG+2vlJjOPT2PpoxA06mIk5gAMfHrp80hs=
private key: (hidden)
listening port: 51871
peer: d4FK66Fz2RH4EjzNXoSgYwIN/kWf+oC8aNLSeIwbexI=
endpoint: 173.212.203.211:51871
allowed ips: 10.231.0.2/32
latest handshake: 2 seconds ago
transfer: 180 B received, 272 B sent
persistent keepalive: every 15 seconds
PING 10.231.0.2 (10.231.0.2) 56(84) bytes of data.
64 bytes from 10.231.0.2: icmp_seq=1 ttl=64 time=1.56 ms
64 bytes from 10.231.0.2: icmp_seq=2 ttl=64 time=1.17 ms
--- 10.231.0.2 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.168/1.364/1.560/0.196 ms
Healthy Session
Host workload: hub2 ↔ hyle
ok
This is a real application workload over the WireGuard tunnel rather than just handshake or ICMP. Both hosts served an 8 MiB HTTP payload across the tunnel, fetched it from the opposite side, and verified the file hash after transfer.
Payload8 MiB
App Port18080
Left download5.69 MiB/s
Right download15.82 MiB/s
Annotated flow
- Bring-up: the tunnel came up on the same controlled hosts as the point-to-point smoke.
- Serve: each side bound a local HTTP server on its tunnel address.
- Transfer: the opposite side fetched the 8 MiB payload over the tunnel, not over the public IP.
- Verify: SHA-256 matched after transfer in both directions, proving the tunnel carried real application traffic intact.