We determined the fastest way out of this problem was simple: run the MQ traffic over a different WireGuard interface. This is actually something we implemented quite a while ago, with "Secure GRPC", where we would run gRPC connections over a WireGuard tunnel. We took it out because it was implemented poorly (by me) but fundamentally the idea made sense. Not only can this tunnel handle MQ traffic, but in the future, it could handle many other parts of the traffic flow as well (API, gRPC, even UI). Think of it like an "overlay network" for Netmaker, a catchall method of encryption to secure client-server communication. Comms networks get generated with random names to avoid collisions between servers, so you'll notice a random name in the netmaker networks if you install 0.11. You'll also notice a new feature, which we rely on for the comms network: "Point-to-Site Networks". The name is subject to change if you can think of a better one 🙂 We also considered "Hub and Spoke" and "Concentrator" but those didnt seem appropriate. Basically, it's a many-to-one relationship, and each peer will only ever have one node (unless it's the hub). If you have experience creating WireGuard VPN's, you've probably created this type of network before. How this works in comms is, every node recieves the server as a peer, and the server adds all the peers. That's it. It does not act as a relay. We realized this could be a useful feature for other networks, so we generalized it, and you can create "point to site" networks if, for instance, you're setting up remote access to a particular machine, but you dont want all the other machines to be able to talk with each other.