Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

VPN speed low , ok after reboot #3801

Open
Majaxx opened this issue Feb 16, 2025 · 13 comments
Open

VPN speed low , ok after reboot #3801

Majaxx opened this issue Feb 16, 2025 · 13 comments
Labels
help wanted

Comments

@Majaxx
Copy link

Majaxx commented Feb 16, 2025 •
edited
Loading

Expected Behavior
The flow rate drops on remote access (example of service: home assistant, emby, nextcloud)

Current Behavior
I have to restart the router to get a correct flow rate from the remote access
I use GloryTun TCP, I tried to use openvpn tcp but the ports remain blocked
I want to use another VPN but none of the others work

I think my problem is similar :
#2418
Spécifications
OpenMPTCProuter version: v0.61-6.6 r0
OpenMPTCProuter VPS version: 0.10.31 6.6.36
OpenMPTCProuter VPS provider: PulseHeberg
Country: FR
OpenMPTCProuter platform: Proxmox
@Ysurac
Copy link
Owner

Ysurac commented Feb 16, 2025

It's why Glorytun TCP is not the default anymore.
To debug with others VPN, check https://github.com/Ysurac/openmptcprouter/wiki/Port-forwarding#debug

@darkman1983
Copy link

But there is no alternative, if you need like stable pings, all the other VPN's fail at that.

@Ysurac
Copy link
Owner

Ysurac commented Feb 16, 2025

I have quite stable ICMP ping with OpenVPN TCP.
Don't forget that ICMP ping doesn't mean connection latency as TCP is using a Proxy.

@darkman1983
Copy link

darkman1983 commented Feb 16, 2025 •
edited
Loading

But OpenVPN isn't multipath, so pretty useless...

Don't forget that ICMP ping doesn't mean connection latency as TCP is using a Proxy.

But the applications don't know this and eventually taking actions because of the ping.
Using VPN, that doesn't aggregate, isn't the usecase of MPTCP and probaly not the usecase of users, using this software.
I need aggregated upload speed and with open ports, the VPN matters, as using UDP over proxy adds a shitload of overhead / latency issues. :-D

@Ysurac
Copy link
Owner

Ysurac commented Feb 17, 2025

OpenVPN is patched to support MPTCP. All available VPNs/Proxy support multipath.
UDP with Shadowsocks doesn't aggregate but with *Ray it can aggregate as UDP over TCP.

@darkman1983
Copy link

OpenVPN is patched to support MPTCP. All available VPNs/Proxy support multipath. UDP with Shadowsocks doesn't aggregate but with *Ray it can aggregate as UDP over TCP.

Do you mean "OpenVPN Bonding"? That one never worked for me. And the normal OpenVPN over TCP has bad latency.

@Ysurac
Copy link
Owner

Ysurac commented Feb 17, 2025

No, I mean "OpenVPN TCP", the default VPN on latest releases.

With latest snapshots, using OpenVPN TCP as VPN and on 2 FTTH + 1 4G:

root@OpenMPTCProuter:~# ping -c 4 9.9.9.9
PING 9.9.9.9 (9.9.9.9) 56(84) bytes of data.
64 bytes from 9.9.9.9: icmp_seq=1 ttl=58 time=18.9 ms
64 bytes from 9.9.9.9: icmp_seq=2 ttl=58 time=18.3 ms
64 bytes from 9.9.9.9: icmp_seq=3 ttl=58 time=19.0 ms
64 bytes from 9.9.9.9: icmp_seq=4 ttl=58 time=22.7 ms

--- 9.9.9.9 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 18.253/19.703/22.674/1.738 ms

Not so bad. It's less good with 2 4G modems...

@darkman1983
Copy link

darkman1983 commented Feb 17, 2025 •
edited
Loading

Not all have and use FTTH; this example is probably more of an exception. I use cable and DSL, and my ping times are significantly worse with OpenVPN. FTTH is the best option, but you can't assume that applies to everyone.

PING google.com (216.58.206.78) 56(84) bytes of data.
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=1 ttl=116 time=136 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=2 ttl=116 time=34.3 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=3 ttl=116 time=23.7 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=4 ttl=116 time=52.6 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=5 ttl=116 time=20.2 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=6 ttl=116 time=36.0 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=7 ttl=116 time=36.4 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=8 ttl=116 time=21.3 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=9 ttl=116 time=32.9 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=10 ttl=116 time=61.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=11 ttl=116 time=20.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=12 ttl=116 time=23.6 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=13 ttl=116 time=93.5 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=14 ttl=116 time=87.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=15 ttl=116 time=46.0 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=16 ttl=116 time=23.6 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=17 ttl=116 time=90.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=18 ttl=116 time=91.3 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=19 ttl=116 time=51.3 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=20 ttl=116 time=37.2 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=21 ttl=116 time=33.5 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=22 ttl=116 time=63.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=23 ttl=116 time=83.8 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=24 ttl=116 time=81.5 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=25 ttl=116 time=78.9 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=26 ttl=116 time=29.5 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=27 ttl=116 time=24.9 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=28 ttl=116 time=22.3 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=29 ttl=116 time=26.9 ms
64 bytes from tzfraa-aa-in-f14.1e100.net (216.58.206.78): icmp_seq=30 ttl=116 time=22.9 ms
--- google.com ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29045ms
rtt min/avg/max/mdev = 20.237/49.635/136.370/29.759 ms

Glorytun TCP - More stable pingtimes:

PING google.com (142.251.39.110) 56(84) bytes of data.
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=1 ttl=117 time=27.0 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=2 ttl=117 time=29.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=3 ttl=117 time=28.1 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=4 ttl=117 time=30.3 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=5 ttl=117 time=28.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=6 ttl=117 time=28.3 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=7 ttl=117 time=25.4 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=8 ttl=117 time=28.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=9 ttl=117 time=27.1 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=10 ttl=117 time=29.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=11 ttl=117 time=29.5 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=12 ttl=117 time=30.2 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=13 ttl=117 time=28.8 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=14 ttl=117 time=28.2 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=15 ttl=117 time=74.6 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=16 ttl=117 time=27.9 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=17 ttl=117 time=30.1 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=18 ttl=117 time=24.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=19 ttl=117 time=27.4 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=20 ttl=117 time=30.2 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=21 ttl=117 time=28.7 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=22 ttl=117 time=27.6 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=23 ttl=117 time=30.3 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=24 ttl=117 time=29.2 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=25 ttl=117 time=28.5 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=26 ttl=117 time=27.4 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=27 ttl=117 time=29.2 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=28 ttl=117 time=30.0 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=29 ttl=117 time=40.1 ms
64 bytes from ams15s48-in-f14.1e100.net (142.251.39.110): icmp_seq=30 ttl=117 time=29.8 ms
--- google.com ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29265ms
rtt min/avg/max/mdev = 24.698/30.499/74.552/8.547 ms

@Ysurac
Copy link
Owner

Ysurac commented Feb 17, 2025

It was an example to say that OpenVPN doesn't always have a bad latency, you can't assume that applies to everyone, and has I said it's not as good with 2 4g modems...

@Majaxx
Copy link
Author

Majaxx commented Feb 17, 2025 •
edited
Loading

Hello
when i lose 4G :
netstat -an | grep 65001
tcp 0 0 192.168.1.230:29824 VPS:65001 ESTABLISHED

after placing the order

root@OpenMPTCProuter:~# netstat -an | grep 65001
tcp 0 0 192.168.1.230:26872 IP_VPS:65001 ESTABLISHED
tcp 0 0 192.168.2.230:60993 IP_VPS:65001 ESTABLISHED

@Majaxx
Copy link
Author

Majaxx commented Feb 17, 2025 •
edited
Loading

Testing and fixing , add crontab

#!/bin/bash

# Adresse IP locale à vérifier
IP="192.168.2.230"
# Fichier de log
LOG_FILE="/var/log/glorytun_check.log"
# Date et heure
DATE=$(date '+%Y-%m-%d %H:%M:%S')

# Vérifier si une connexion ESTABLISHED existe pour l'IP
RESULT=$(netstat -an | grep "$IP" | grep ESTABLISHED)

if [ -n "$RESULT" ]; then
    echo "$DATE - La connexion pour $IP est ESTABLISHED." | tee -a "$LOG_FILE"
else
    echo "$DATE - Aucune connexion ESTABLISHED trouvée pour $IP. Redémarrage du service glorytun..." | tee -a "$LOG_FILE"
    /etc/init.d/glorytun restart
    echo "$DATE - Service glorytun redémarré." | tee -a "$LOG_FILE"
fi

@darkman1983
Copy link

It was an example to say that OpenVPN doesn't always have a bad latency, you can't assume that applies to everyone, and has I said it's not as good with 2 4g modems...

OpenVPN does not foward ports, i dunno whats the problem, but when i switch from Glorytun TCP to OpenVPN, ports no more forwarded. So it's unusable, i restarted VPS + Router several times, makes no difference.

@Ysurac
Copy link
Owner

Ysurac commented Feb 19, 2025

Not related to this issue, open a new one with results of https://github.com/Ysurac/openmptcprouter/wiki/Port-forwarding#debug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@darkman1983 @Majaxx @Ysurac