heh, similar question to @mikebridge. I've been using remoting on Azure with WebApps (not ASE) since the end of September. Occasionally messages were not received back from the VM, but VM always got them. In general, WebApp restart seemed to be the way to address it. Recently it's been happening more frequently. Not sure if it has anything to do with an upgrade to 4.7.2 and/or latest Akka+dependencies. I do use VNET. When I start WebApps first and then the windows service on the VM - everything is fine. It can last for days. Basically it seems to pair webapp -> VM and keeps it like that. However, when I restart the WebApp I see "connection was reset by peer" on the VM and then when WebApp is started and the message is sent then I see the debug text in the VM's service: attempt to associate WebApp -> VM, which seems to pass, then it receives the message, processes it and tries to reply. And this fails because at this moment VM's service tries to pair back to the WebApp and I get a warning that remote is not accessible and it is gated etc. etc. What's interesting is that it doesn't happen in the happy path start-up order, but does if WebApp is restarted (at least). BTW, happy path works well in the scale-out scenario too. Is there a way to configure VM's service to not try to pair back on connection resets? :) I understand that's against the peer-to-peer nature of Akka where both endpoints should be reachable... However, ASE is not an option and given that it already works half-way... maybe there's some tweak? :) Or is this trully the case (as per docs) for a custom low-level Akka I/O approach? @Horusiath, @Aaronontheweb what do you guys think?