Ok, so I prepared a RW connection on Ipfire 2.27.172, dowloaded the files .ovpn, .key, .p12 to my laptop running Ubuntu 22.04, and tested the connection with:
sudo openvpn --client --config /etc/openvpn/client/desktopclient.ovpn
The result messages ended with Initialization Sequence Completed.
I was able to ping my remote hosts, but wasn’t able to load the html pages from them, i.e. the empty screen kept waiting forever to load the page.
What am I missing …?
Thanks for reading,
-GianLuca
Probably you have a problem of Maximum Transmission Unit, or MTU. To make a long story short, between the server and the client, the maximum size of the packet might change traversing networks, therefore the payload of the packets (TCP or UDP) entering to a different network with smaller MTU, gets broken up in more packets, obviously this is after encryption. The post-reassembly decryption is therefore subjected to an important bottle neck, which can translate to a slower loading web site, buffering of videos etc.
The problem is solved by preventing the post-encryption fragmentation, allowing fragmenting the content before encryption, at the source. This means that the server and the client need to have an MTU as small as the smallest one in the networks between the two ends of the tunnel.
What you have to do is progressively lowering the MTU server side until you find the maximum size that will prevent fragmentation post encryption.
You can use the ping command to obtain this information. In alternative OpenVPN comes with its own way to calculate it, described in the wiki.
There are two possible settings you can change, either the MTU in the main web page,
or in the advanced page of the web user interface (wui), there is a checkbox to activate mssfix and type in the fragment box the value that the test will suggest.
The difference between the two is 40 bytes (MSS being equal to MTU - 40 bytes). This is a bit confusing in the documentation. The way I understand it is that the value suggested by mtu-test is in fact the MSS, not the MTU.
If for example the tests suggests a value for the MTU of 1253, that value should be put in the fragment box below mssfix checkbox (activated). Or you can add 40, and put 1293 to MTU in the main page of the wui. One or the other.
EDIT: mssfix is available only with UDP, if you use TCP packets, you should modify the MTU and leave mssfix unchecked.
3 Likes
thanks for your kind reply, cfusco.
Pretty technical, I’ll have to do some homework…
I modified my post to include snap shoots of the WUI at the relevant places.
thanks, but it doesn’t work.
Changed to 1400 and /or TLS channel protection on/off, it’ always the same.
I suspect a routing problem.
Did you test the MTU, or you just put 1400?
Do this test:
- connect the client to your server;
- open a console on the client;
- on windows:
ping -n 1 -l 1400 -f www.google.com
OR
on MacOS:
ping -D -v -s 1400 -c 1 www.google.com
OR
on linux
ping -M do -s 1400 -c 1 www.google.com
if 1400 is not correct (which is what I suspect), it will give you :
PING www.google.com (172.217.16.132): 1400 data bytes
ping: sendto: Message too long
The page below may be helpful:
2 Likes
this is what I get from a host on my LAN:
gian@Think-GLS:~$ ping -M do -s 1400 -c 1 www.google.com
PING www.google.com (142.250.180.132) 1400(1428) bytes of data.
76 bytes from mil04s43-in-f4.1e100.net (142.250.180.132): icmp_seq=1 ttl=117 (truncated)
— www.google.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.842/3.842/3.842/0.000 ms
gian@Think-GLS:~$ ping -M do -s 1500 -c 1 www.google.com
PING www.google.com (142.250.184.100) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500
— www.google.com ping statistics —
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
MTU 1400 should work. After restarting the server with MTU of 1400, still you can’t load any web page? What about the WUI of IPFire?
Did you fill out the DNS for the OVPN?
It is located under “advanced server opions”.
- In my case this made it work for me.
Regards,
Bernard
1 Like