I'm encountering a problem where ssh to a remote server hangs with the message SSH2_MSG_KEXINIT sent. I have already explored the MTU options with no luck.
Case 1 (fails)
This happens when I ssh from my Linux PC through an openWRT router running the openVPN client. I have the router set to forward from the LAN 44.20.11.0/24 to the VPN tun0. I can successfully ping the remote ssh server from my PC, so I don't think forwarding is the problem.
This openVPN PC client version is 2.5.2 mips-openwrt-linux-gnu. The server-side openWRT openVPN version is openvpn-2.3.8-16.26.1.x86_64.
Here is the ssh client's output for the failed case:
ssh -vvvv [email protected]
OpenSSH_8.8p1, OpenSSL 1.1.1m 14 Dec 2021
debug1: Reading configuration data /home/myuser/.ssh/config
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: /usr/etc/ssh/ssh_config line 24: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 26: Applying options for *
debug2: resolve_canonicalize: hostname 10.84.96.200 is address
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/myuser/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/myuser/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to 10.84.96.200 [10.84.96.200] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/myuser/.ssh/id_rsa type 0
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa type 2
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/myuser/.ssh/id_ed25519 type -1
debug1: identity file /home/myuser/.ssh/id_ed25519-cert type -1
debug1: identity file /home/myuser/.ssh/id_ed25519_sk type -1
debug1: identity file /home/myuser/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/myuser/.ssh/id_xmss type -1
debug1: identity file /home/myuser/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: compat_banner: match: OpenSSH_7.6 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.84.96.200:22 as 'myuser'
debug3: record_hostkey: found key type ECDSA in file /home/myuser/.ssh/known_hosts:828
debug3: record_hostkey: found key type RSA in file /home/myuser/.ssh/known_hosts:2050
debug3: record_hostkey: found key type DSA in file /home/myuser/.ssh/known_hosts:2051
debug3: record_hostkey: found key type ED25519 in file /home/myuser/.ssh/known_hosts:2052
debug3: load_hostkeys_file: loaded 4 keys from 10.84.96.200
debug1: load_hostkeys: fopen /home/myuser/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type [email protected], using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent```
Here is the PC's route for this scenario (Case 1, failure):
default via 44.20.6.1 dev br0
10.0.0.0/8 via 44.20.11.11 dev enp1s0
44.20.6.0/24 dev br0 proto kernel scope link src 44.20.6.2
44.20.11.0/24 dev enp1s0 proto kernel scope link src 44.20.11.187
Case 2 (works)
When I run the openVPN client directly on the Linux PC, I can successfully ssh to the remote ssh server. This makes me think the problem lies in the openWRT/openVPN router.
This openvpn client version is 2.5.5 x86_64-suse-linux-gnu
Here is the Linux PC's route when bypassing the openWRT router and running the openVPN client directly on the PC:
default via 44.20.6.1 dev br0
44.20.6.0/24 dev br0 proto kernel scope link src 44.20.6.2
44.20.11.0/24 dev enp1s0 proto kernel scope link src 44.20.11.187
I only have one instance of the openVPN client running at any given time.
I've read all the threads suggesting changing the MTU. I've tried setting it to 1492, 1000, and 576 on the client side's network devices, with no luck. The server-side openVPN server's MTU is set to 1492.
Both the Linux PC and openWRT/openVPN VPN clients use the same client config (relevant portions included):
client
dev tun
keepalive 10 300
reneg-sec 0
auth-user-pass
script-security 3
pull
persist-key
persist-tun
ns-cert-type server
comp-lzo
verb 6
mute 20
auth SHA512
cipher AES-256-CBC
My observations:
Because this works when running the VPN client directly on the Linux PC, I do not believe this is an openVPN client or server misconfiguration. I suspect the problem lies in between, in the openWRT/openVPN router. When ssh'ing directly from the openWRT router, the connection also hangs.
mtr 10.84.96.200 shows no packet loss.
I suspect the problem could be one of these things:
- I didn't change MTU on the correct network devices
- MTU should be a value other than
1492,1000or576 - There is a firewall setting on the openWRT router that's breaking this
- Something in openWRT makes this fail
The openWRT device is a gl.inet Slate travel router. I can access the logs from both the client and server openVPNs, but I can't change the server side openVPN. I can access and change the server-side ssh server.
Here is a diagram to hopefully explain more clearly:
