SSH stuck

SSH stuck

[Bzzzz]

Debian jessie + backports - arch amd64
Kernel 4.9.18-1~bpo8+1
wireguard-dkms  0.0.20170421-wg1~zesty
wireguard-tools 0.0.20170421-wg1~zesty
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Hi list,

Setup:
LAN: 192.168.1.0/24
VPN: 10.11.12.0/24 (SRV: =E2=80=A61, CLI: =E2=80=A62)
(Client: AllowedIPs=3D0.0.0.0/0)

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?)

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)

Jean-Yves

Re: SSH stuck

[Jonathon Fernyhough]

[-- Attachment #1.1: Type: text/plain, Size: 1015 bytes --]

Hi Jean-Yves,

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.

> 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`).



Jonathon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: SSH stuck

[Bzzzz]

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

Re: SSH stuck

[Jason A. Donenfeld]

Lower the MTU of the WireGuard interface.

Re: SSH stuck

[Bzzzz]

On Wed, 10 May 2017 10:13:29 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> Lower the MTU of the WireGuard interface.

Thanks, Jason, just lowering 2bytes from 1420 to 1418 is enough
to get ssh operational :)
If you have time for that, please feel free to explain me why.

JY

Re: SSH stuck

[Bzzzz]

On Wed, 10 May 2017 10:13:29 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> Lower the MTU of the WireGuard interface.

Correction: 4 bytes: from 1420 to 1416; done by a PostUp.

I've also seen something that wasn't much expected:
manually changing the MTU from 1418 to 1416 on the server, 
while VPN was on, also changed the IP address of the WG I/F:
	inet addr:0.0.5.136	!(?)

JY

Re: SSH stuck

[Jason A. Donenfeld]

On Wed, May 10, 2017 at 8:05 PM, Bzzzz <lazyvirus@gmx.com> wrote:
> Correction: 4 bytes: from 1420 to 1416; done by a PostUp.

In the next snapshot, if your primary ethernet device has a
non-standard MTU, wg-quick will try to figure it out automatically and
adjust. However, if your end router (adsl modem, for example) is doing
something odd, you'll have to make this adjustment for yourself. Thus,
the next version of wg-quick will have also an MTU= directive.
Hopefully the snapshot will be out somewhat soon.

> I've also seen something that wasn't much expected:
> manually changing the MTU from 1418 to 1416 on the server,
> while VPN was on, also changed the IP address of the WG I/F:
>         inet addr:0.0.5.136     !(?)

That's totally bizarre. I'm guessing you just entered the wrong
command at some point. That's not wireguard-related code, anyhow.

>>> 1416 & 0xff
136
>>> 1416 >> 8
5

Re: SSH stuck

[Bzzzz]

On Wed, 10 May 2017 21:00:33 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> On Wed, May 10, 2017 at 8:05 PM, Bzzzz <lazyvirus@gmx.com> wrote:
> > Correction: 4 bytes: from 1420 to 1416; done by a PostUp.
> 
> In the next snapshot, if your primary ethernet device has a
> non-standard MTU, wg-quick will try to figure it out automatically and
> adjust. However, if your end router (adsl modem, for example) is doing
> something odd, you'll have to make this adjustment for yourself. Thus,
> the next version of wg-quick will have also an MTU= directive.
> Hopefully the snapshot will be out somewhat soon.

OK, it's noted.

> > I've also seen something that wasn't much expected:
> > manually changing the MTU from 1418 to 1416 on the server,
> > while VPN was on, also changed the IP address of the WG I/F:
> >         inet addr:0.0.5.136     !(?)
> 
> That's totally bizarre. I'm guessing you just entered the wrong
> command at some point. That's not wireguard-related code, anyhow.
> 
> >>> 1416 & 0xff
> 136
> >>> 1416 >> 8
> 5

You're right, seems tied to the 4.9 kernel &| the ifconfig program
as it does the same weird thing to my eth0 I/F :/ 

JY

Re: SSH stuck

[Jason A. Donenfeld]

On Wed, May 10, 2017 at 9:57 PM, Bzzzz <lazyvirus@gmx.com> wrote:
> You're right, seems tied to the 4.9 kernel &| the ifconfig program
> as it does the same weird thing to my eth0 I/F :/

$ ip link set mtu 1416 dev wg0

Re: SSH stuck

[Bzzzz]

On Wed, 10 May 2017 23:55:14 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> On Wed, May 10, 2017 at 9:57 PM, Bzzzz <lazyvirus@gmx.com> wrote:
> > You're right, seems tied to the 4.9 kernel &| the ifconfig program
> > as it does the same weird thing to my eth0 I/F :/
> 
> $ ip link set mtu 1416 dev wg0

Thanks.

JY