Score:0

Terminal issues with SSH via VPN

hn flag

I try to access a Linux Ubuntu server via SSH from a Linux Ubuntu client machine.

When the client and the server are in the same network everything works fine, when I try to access the server remotely via VPN - openVPN, full screen applications like mc- midnight commander do not show properly, meaning that I only see the top right corner character of the presented screen, and apparently keyboard interaction doesn't work.

Also the cat command issued against a simple text file hangs the terminal without showing any output.

Strangely enough accessing the same server via VPN from my android phone using an Android OpenVPN client and an Android SSH client everything works fine.

On my Ubuntu client machine the TERM environment variable is set to "xterm-256color", on my Android phone it is set to "linux". Trying to set it to "linux" on my Ubuntu client before starting the SSH session works, meaning that within the SSH session I see that the terminal is actually set to "linux", but has no effect.

On the Ubuntu client I also tried connecting via Putty, but the result is the same.

Any clue on the reason why this happens?

Thanks in advance!

ec flag
**Welcome to the Ask Ubuntu community.** Can you please add to your description the Ubuntu releases (and whether they're desktop or server) of both the client and server? Thanks
Mario Bezzi avatar
hn flag
Apologize for not providing them in the first place. The server machine runs Ubuntu Server 22.04, the client machine runs Ubuntu Desktop 22.04. Thanks!
Score:0
hn flag

Well, I eventually found the solution for this reading the OpenVPN manual, located here:

https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/

The issue was apparently related to Path MTU discovery not working properly.

"Both --fragment and --mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.

The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage. If --fragment and --mssfix are used together, --mssfix will take its default max parameter from the --fragment max option.

Therefore, one could lower the maximum UDP packet size to 1300 (a good first try for solving MTU-related connection problems) with the following options:

--tun-mtu 1500 --fragment 1300 --mssfix "

adding those two option both on the server and the client side resolved the problem for me.

I hope this helps.

I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.