On Wed, 10 May 2017 08:31:12 +0100 Jonathon Fernyhough <[email protected]> wrote:
> Hi Jean-Yves, Hi Jo, > On 09/05/17 23:32, Bzzzz wrote: > > 1- I solved the LAN being unreachable apart the endpoint and the > > internet being completely unreachable with an iptables rule: > > iptables -t nat -I POSTROUTING -s 10.11.12.0/24 -o eth0 -j > > MASQUERADE is this right? (if not, why?) > > I don't think this is Wireguard specific. That rule essentially allows > that machine to act as a NAT gateway, the same as for e.g. an OpenVPN > server. Fine, in fact I was using this for OpenVPN but WG is much faster. > > 2- When I want to ssh any LAN machine, wireshark only sees 4 packets: > > client announce > > server ACK > > client key negociation > > server key negociation > > and that's all. > > Is it a limitation (non-TCP packets) or is there another reason > > for ssh not working as expected? (connecting to any machine http srv > > works perfectly) > > SSH over a Wireguard interface works as expected for me. You might have > some luck seeing what's going on with `ssh -v` (and increasing the > verbosity with further `v`s, e.g. `ssh -vvvv`). No, I even tried 'ssh -vvvvvvvvvvvvvvvvvv' just in case, but I do not see anything special; last lines before being stuck 30" and closed by server, are: … debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup [email protected] debug1: kex: server->client aes128-ctr [email protected] none debug2: mac_setup: setup [email protected] debug1: kex: client->server aes128-ctr [email protected] none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY Connection closed by 192.168.1.50 I use publickey ssh only. A LAN ssh (working, of course) continues: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup [email protected] debug1: kex: server->client aes128-ctr [email protected] none debug2: mac_setup: setup [email protected] debug1: kex: client->server aes128-ctr [email protected] none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: RSA <redacted> debug3: load_hostkeys: loading entries for host "mybigserver" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:1 debug3: load_hostkeys: loaded 1 keys debug3: load_hostkeys: loading entries for host "192.168.1.50" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:2 debug3: load_hostkeys: loaded 1 keys debug1: Host 'mybigserver' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 … I double-checked the the only difference between a LAN ssh and a VPN ssh is the VPN one stucks just after the "expecting SSH2_MSG_KEX_ECDH_REPLY" line without an obvious reason :/ Note that it is also the case with any other LAN machine when the VPN is in use. Don't worry if I don't answer, I'm out for sleep a few hours. Thanks & regards, Jean-Yves _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
