Thomas Eizinger

@jamilbk Let me know if you think this should go in the changelog.

> Furthermore, I believe that we should address multiple resource opening a single gateway connection soon. I'll look into how difficult that would be. Currently, I don't think we have...

So the proptests just found a "bug": Sending multiple DNS queries to a resolver through the tunnel drops all later ones because they get discarded during the throttling of connection...

> > Should we buffer more than 1 packet here per intent? Should we make that specific to UDP & ICMP and only buffer the first one for TCP? >...

> > So the proptests just found a "bug": Sending multiple DNS queries to a resolver through the tunnel drops all later ones because they get discarded during the throttling...

> This doesn't solve though all cases of multiple resources trying to open a connection at the same time, it only improves conditions for multiple packets for the same resource....

That is odd, it works as expected for me on Linux: ``` ❯ ping ifconfig.net -c 1 PING ifconfig.net (fd00:2021:1111:8000::) 56 data bytes 64 bytes from ifconfig.net (fd00:2021:1111:8000::): icmp_seq=1 ttl=57...

> Notice in the log above that the packet is flushed before the WireGuard handshake completes. Yeah that is because this log is kind of hacked in due to `boringtun`...

> It's the ol' `ERR_NETWORK_CHANGED` event unique to Chrome. Apparently this happens when chrome detects a TCP reset. I was unable to reproduce in Chromium, weird!

> I am curious if the packets or their replies are being mangled somehow that would prevent the macOS kernel from routing them back properly. It works once the tunnel...