Received an error while attempting to accept a connection:clientConfirmationCode and server copy not equal about shapeshifter-dispatcher

[blanu]

For the benefit of others reading these issue comments on github, I do not think that this analysis of the widespread use of NAT by cloud server providers is accurate. It is possible to get a cloud provider where the local IP and the public IP are the same. There are many instances of this application running on production servers on many cloud providers. In particular, we have tested extensively with Digital Ocean and we haven't had any problems, so I can say for sure that it should work fine on Digital Ocean without any special configuration.

We will certainly take note of your feature request to develop a version of the Shadow transport that works behind NAT. I think this should be possible to enable in the future by simply providing an option to give two IPs to the transport: one that it should bind to locally and the public IP to use in the cryptographic protocol exchange. I don't think this seems too difficult, so we'll get working on this straight away and update this issue when the feature is available. Thanks so much for the helpful feedback!

[otonoton]

I should mention this is all using the latest HEAD commit of 5a0a004883c31e7e673e75fa323f3f5edc61c5bf. I tried going back to the current tagged release of v3.0.1 but it would not build for me, it seemed to need a change in shapeshifter-ipc that was made in its 3.0.2 version but trying to change that version in go.mod still wouldn't build due to other issues, and with the latest commit in this repo it seems the ipc package isn't even used anymore so I'm quite confused. Admittedly I'm not a go programmer so I'm not familiar with all these details.

[CryptoSax]

Your commands to run dispatcher, your configs, and the commands you used to generate them all look fine. The issue is that 443 is a dedicated port for https traffic and the telnet client isn't going to know how to send a properly constructed request to initiate a https handshake. Bindaddr and ServerAddress are both needed because proxies always need two addresses. The ServerAddress in the config is the destination address to the server. The bind address is the listening address on the client. Additionally, I made some changes to the README to reflect some of the missing information you mentioned. Thank you for bringing that to our attention! Let us know if there's anything else you can help with.

[blanu]

You cannot use 0.0.0.0 for the server address. Part of the cryptographic handshake is verifying that the server and client have the same address for the server. Using 0.0.0.0 on the server configuration and a different IP for the server on the client confirmation will cause the cryptographic handshake to fail, giving the "clientConfirmationCode and server copy not equal" that you see. If the public IP of the server and the bind address IP of the server do not match, you will be unable to run the Shadow transport. However, this is usually not a problem for Cloud VMs as it would mean that the Cloud VM was behind NAT. You generally cannot run any kind of server behind NAT and you certainly can not run the Shadow transport behind NAT due to the feature of IP address verification.

My recommendation would be to try setting the IP address for the server to the same IP on both the client and the server (the public IP of the server) and see if that works.

[otonoton]

In my experience servers work just fine behind NAT when used with proper port forwarding. Not being able to support this means shutting out most of the largest cloud providers because they assign private IPs to the local interfaces, and public IP's are configured outside of the VM instance through loud balancers, NAT gateways and the like. Off the top of my head, Amazon, IBM, Rackspace, AliYun, DigitalOcean and probably many others, all use some type of NAT. Please consider supporting this as it is a non-starter for me and many others without dedicated server colocation.