Ssh over vpn fails

Rocky Linux General
1

This is crazy, I can connect to the vpn server. I can ping all the host machines behind the firewall. I can connect to the Windows machines, but I can’t ssh to Linux machines. What’s wrong with this vpnc?

2

Hi,

Does the VPN servers firewall allow ssh connections out to the lan devices?

Do the Firewalls on the linux machines, allow ssh connections for the vpn server/network?

Thanks Tom.

3

Yes, the Linux machines allow ssh connections. Currently I’ve to remote to a Windows machine then putty to the linux

4

Additional info…
I put back the previously working hd into my PC. It’s running Federa 33. Same hw, just different distro. The ssh works over the vpn with the Fedora. I’ve compared routing on the vpn. It looks exactly the same as the Rocky linux. That’s the Enigma!!

5

Hi,

Can you ping the linux devices?

Thanks Tom.

6

Yes, I can ping all the devices behind the firewall. As I’ve said earlier. Everything seems to go through just fine except for ssh. Nothing has changed on the remote site. It works fine with Fedora 33. Rocky works except for ssh.

7

Hi,

This one may be a hard one to solve, being as the vpnc rpm isn’t provided by rocky or epel. Could be a missing dependency.

Are you getting an error message when trying to ssh?

Thanks Tom.

8

I did say it’s a engima. No error…nothing…It’s like port 22 is being blocked. By what…I have no idea.

9

Hi,

Please provide verbose logging from a failed ssh session:

ssh -v user@ip.lin.ux.pc

Thanks Tom.

10

I’ve posted the log earlier. Now it’s missing from the post. I’m posting it again…

[kyiu@rocky ~]$ ssh -v root@192.168.43.5
OpenSSH_8.0p1, OpenSSL 1.1.1g FIPS 21 Apr 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 192.168.43.5 [192.168.43.5] port 22.
debug1: Connection established.
debug1: identity file /home/kyiu/.ssh/id_rsa type 0
debug1: identity file /home/kyiu/.ssh/id_rsa-cert type -1
debug1: identity file /home/kyiu/.ssh/id_dsa type -1
debug1: identity file /home/kyiu/.ssh/id_dsa-cert type -1
debug1: identity file /home/kyiu/.ssh/id_ecdsa type -1
debug1: identity file /home/kyiu/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/kyiu/.ssh/id_ed25519 type -1
debug1: identity file /home/kyiu/.ssh/id_ed25519-cert type -1
debug1: identity file /home/kyiu/.ssh/id_xmss type -1
debug1: identity file /home/kyiu/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to 192.168.43.5:22 as ‘root’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
Connection closed by 192.168.43.5 port 22
[kyiu@rocky ~]$

11

Hi,

It looks likes vpnc client may be causing issues, All I can suggest is try the work arounds mentioned here:

Thanks Tom.

12

Fascinating!

sudo ip li set mtu 1200 dev tun0 works.  

Is there a way to add the vpnc configuration file?
1 Like
13

Hi,

https://askbot.fedoraproject.org/en/question/7797/cisco-vpn-vpnc-mtu-size/

Thanks Tom.

1 Like
14

I’ve found the magic. I’ve created a script in /etc/NetworkManager/dispatcher.d/pre-up.d/mtu.sh

#!/bin/bash
if [ “$DEVICE_IFACE” = “tun0” ] ; then
ifconfig tun0 mtu 1200
fi;

make it executable chmod +x /etc/NetworkManager/dispatcher.d/pre-up.d/mtu.sh
It’ll automatically set the mtu to 1200 when the connection is made to the remote.

2 Likes
15

In the case of multiple tunX interface VPN’s or a prior one leaves a tun0 and the next vpn increments I’d suggest a slight modification.

#!/bin/bash
if [[ “${DEVICE_IFACE}” =~ “tun”[0-9] ]] ; then
ifconfig ${DEVICE_IFACE} mtu 1200
fi;
1 Like
16

Also 1200 is pretty extreme for an MTU reduction. I believe you can instead use an MTU of 1372 to optimize the payload size per packet, as long as the servers tunnel interfaces MSS was not configured to a lower value.

Cisco has an IPsec calculator you can use to determine the exact overhead: IPsec Overhead Calculator

1 Like
17

Thank you for your advice. for sure I’ll give it a try.

18

MTU 1372 almost not work. I’ve tweak it down to 1320. It seems to work better

1 Like