Greetings! *** Bruno Clermont [2016-10-19 19:25]: >handshake.go:290: Invalid server's random number with $PEER >I did my homework, even spent some time trying to figure why looking at the code. But that function is quite cryptic to me. So, what this error mean? What cause this? How to fix? http://www.govpn.info/Handshake.html Second message, that is sent from server to client, contains randomly generated RS (Random number of Server), that is sent enciphered to the client. Client have to decrypt it and send back to the server in third encrypted message -- confirming that second message was deciphered successfully and that he really received it from the server exactly during that session. Server checks that received RS equals to the saved in Handshake.rServer one. Actually I have never seen this part failing. In theory that means that your handshake packet was tampered, man-in-the-middle changed their contents. But in practice I can not assume what is going wrong (if no traffic is really tampered). Do you have equal GoVPN versions (6.0 on both sides)? Are you using amd64, 64-bit platform? If you run tcpdump and listen for the traffic on GoVPN's port, is there really only three packets are passed between (C->S, S->C, C->S)? Be sure that all your configuration on the client and server side is equal! For example if you enable "-encless" mode just on one side -- nothing will works, if you enable -noise/-cpr/etc options -- nothing will works too. You have to use symmetrically equal configuration options on both sides. GoVPN has very simple protocol without any options and configuration agreement/coordination (this is an additional possible attack vector). If everything is ok there (try to setup all configuration from the ground, from very beginning), then personally I will add debugging print-s in the code to see are encryption keys, nonces and deciphered information is the same on both sides and when it becomes different. >Bonus question: could it be very hard to add support for tun interface instead of tap? "instead of" -- no, "in addition to" -- seems to be yes :-) I have never worked with TUN interfaces, but seems that working with them is the same as with TAP ones. Just slightly another structures. So should be relatively easy. I added TUN support to the TODO list, but currently can give no time expectations when it will be done (to much work now :-(). -- Happy hacking