From: Bzzzz <lazyvirus@gmx.com>
To: wireguard@lists.zx2c4.com
Subject: Re: SSH stuck
Date: Wed, 10 May 2017 10:10:13 +0200 [thread overview]
Message-ID: <20170510101013.715986f0@msi.defcon1> (raw)
In-Reply-To: <196a1f14-d30b-3926-561c-baf3c8c73c58@york.ac.uk>
On Wed, 10 May 2017 08:31:12 +0100
Jonathon Fernyhough <jonathon.fernyhough@york.ac.uk> 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?)
>=20
> 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)
>=20
> 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:
=E2=80=A6
debug2: kex_parse_kexinit: first_kex_follows 0=20
debug2: kex_parse_kexinit: reserved 0=20
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com 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=20
debug2: kex_parse_kexinit: reserved 0=20
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com 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 "/r=
oot/.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
=E2=80=A6
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
next prev parent reply other threads:[~2017-05-10 7:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-09 22:32 Bzzzz
2017-05-10 7:31 ` Jonathon Fernyhough
2017-05-10 8:10 ` Bzzzz [this message]
2017-05-10 8:13 ` Jason A. Donenfeld
2017-05-10 8:35 ` Bzzzz
2017-05-10 18:05 ` Bzzzz
2017-05-10 19:00 ` Jason A. Donenfeld
2017-05-10 19:57 ` Bzzzz
2017-05-10 21:55 ` Jason A. Donenfeld
2017-05-10 22:08 ` Bzzzz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170510101013.715986f0@msi.defcon1 \
--to=lazyvirus@gmx.com \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).