I have encountered what I think is a bug in wireguard-go which causes a SIGSEGV like:
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x1006ce478] goroutine 150 [running]: golang.zx2c4.com/wireguard/tun/netstack.(*netTun).Write(0x140004501e0, {0x14000192000, 0x58, 0x100000000000000?}, 0x3?) /Users/spike/go/pkg/mod/github.com/coder/wireguard-go/tun/netstack@v0.0.0-20220614153727-d82b4ba8619f/tun.go:192 +0x108 golang.zx2c4.com/wireguard/device.(*Peer).RoutineSequentialReceiver(0x14000558000) /Users/spike/go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20220703234212-c31a7b1ab478/device/receive.go:476 +0x4a0 created by golang.zx2c4.com/wireguard/device.(*Peer).Start /Users/spike/go/pkg/mod/golang.zx2c4.com/wireguard@v0.0.0-20220703234212-c31a7b1ab478/device/peer.go:199 +0x2c8 I believe this happens when I call `Close()` on the Device with this Peer. Closing the device triggers gVisor to Attach a nil NetworkDispatcher to the tun, which the Peer goroutine attempts to dereference via Write. This is a race condition that depends on whether any packets are queued up at the time: if the queues are empty, we are fine. I'm able to work around this issue by calling RemoveAllPeers() prior to Close() on the device, but presumably it wasn't the intention to make Close() on its own dangerous in this way. I'm happy to offer a patch if you're interested. -- Spike Curtis Principal Engineer coder.com