*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* <http://www.linuxspace.org>
*--*
*Best regards.*
*Alex Berber*
*+9 72 54 285 952 3*
*www.linuxspace.org* <http://www.linuxspace.org/>