Hello,

now server and client are up.

SERVER:
root@calvin:~/govpn# ./govpn-server -bind 172.25.60.62:1194 -mtu 1472
2015/05/13 14:24:24.291786 identify.go:133: Adding key 28c3d9d4f4a6fbf27686212a7e220003
2015/05/13 14:24:24.292009 main.go:120: GoVPN version 3.2 built with go1.2.1
2015/05/13 14:24:24.292046 main.go:121: Max MTU on TAP interface: 1432
2015/05/13 14:24:24.292074 main.go:130: Server started

2015/05/13 14:27:27.731480 main.go:225: Peer handshake finished 28c3d9d4f4a6fbf27686212a7e220003:172.25.60.63:59918
2015/05/13 14:27:27.736285 main.go:181: Registered interface  with peer 28c3d9d4f4a6fbf27686212a7e220003:172.25.60.63:59918

CLIENT:
root@farengeit:~/govpn# ./govpn-client -key key.txt -id 28c3d9d4f4a6fbf27686212a7e220003 -iface tap10 -remote 172.25.60.62:1194 -mtu 1472
2015/05/13 14:27:27.782777 main.go:104: GoVPN version 3.2 built with go1.2.1
2015/05/13 14:27:27.783612 main.go:105: Max MTU on TAP interface: 1432
2015/05/13 14:27:27.783878 main.go:118: Starting handshake
2015/05/13 14:27:27.810347 main.go:163: Handshake completed

But there is no traffic go trough the tunnel at all. 
Server: 172.16.0.1
Client: 172.16.0.2

You can see on attached screenshot that both interface are up.

Ping FROM client TO server:
root@farengeit:~# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1) 56(84) bytes of data.
From 172.16.0.2 icmp_seq=1 Destination Host Unreachable
From 172.16.0.2 icmp_seq=2 Destination Host Unreachable
From 172.16.0.2 icmp_seq=3 Destination Host Unreachable

Routing table on client is OK:
root@farengeit:~# ip route show
default via 172.25.60.254 dev eth0
172.16.0.0/24 dev tap10  proto kernel  scope link  src 172.16.0.2
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.42.1
172.25.60.0/24 dev eth0  proto kernel  scope link  src 172.25.60.63

root@farengeit:~# ip route get 172.16.0.1
172.16.0.1 dev tap10  src 172.16.0.2
    cache

Tcpdump from client:
root@farengeit:~# tcpdump -i tap10 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap10, link-type EN10MB (Ethernet), capture size 65535 bytes
17:53:12.533350 ARP, Request who-has 172.16.0.1 tell 172.16.0.2, length 28
17:53:13.529803 ARP, Request who-has 172.16.0.1 tell 172.16.0.2, length 28
17:53:14.529830 ARP, Request who-has 172.16.0.1 tell 172.16.0.2, length 28

Tcp dump on server show no traffic at all: 
root@calvin:~# tcpdump -i tap10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap10, link-type EN10MB (Ethernet), capture size 65535 bytes

Looks like no traffic can go trough the tunnel. 
Firewall are disabled on both VMs of course. 



On Wed, May 13, 2015 at 5:09 PM, <stargrave@stargrave.org> wrote:
Greetings,

*** Alan Holt <berber.it@gmail.com> [2015-05-13 16:51]:
>But in example you do generate in on the *server*:
>
>*server% ./utils/newclient.sh Alice
>Place verifier to peers/6d4ac605ce8dc37c2f0bf21cb542a713/verifier
>
>And this is what I did.

You did everything fine. And documentation is correct too:

* You generate peers-subdirectory for client, and client's identity. But
  this directory currently does not contain "verifier"
* You must send your client its identity, it generates verifier and
  sends it back to server
* Server saves received verifier (because only client must know his
  password) in its corresponding peers directory

Thanks again for your feedback!

--
Happy hacking, Sergey Matveev



--
בברכה, 
אלכס ברבר
+9 72 54 285 952 3
www.linuxspace.org
--
Best regards.
Alex Berber
+9 72 54 285 952 3
www.linuxspace.org