ANSWERED [SOLVED] P2P slow over UDP and fast over TCP?

[Jojonintendo 1]

Hello community,

 

I'm trying AirVPN since yesterday and I must say I really like it. I use it on linux, Windows and Android, and it works pretty good (although my Android gets disconnected often for no reason, but I might open another thread for that).

 

However, I just noticed that my torrents are working much faster when I use the TCP 443 config for OpenVPN, over the UDP one. This worries me a little, because UDP is recommended and is supposed to work better. I do get better pings with UDP, and general surfing and gaming works well, but the torrent speed just skyrockets with TCP.

 

I have a forwarded port, which is working as per AirVPN checking, I have disabled UPnP and uTP on the client (Transmission).

 

Are there some tests I can run to understand what happens? Does this happen to anyone? I've been reading the forum pretty much all day, and I'm a little lost.

 

Thanks for your time!

 

Edit: I forgot to add that websites that test speed always show good results, with UDP and TCP, only P2P traffic seems affected.

[Jojonintendo 1]

Hi again,

 

After some testing I also noticed that when I use a UDP connection, some websites won't load (aliexpress or my bank for example). General traffic and P2P works, but really slow, and pings are very good. With TCP everything loads as it should, and P2P is very fast. Could it be a signal that the MTU size is wrong? I only use configs generated by AirVPN.

 

Thanks again for your time.

[go558a83nk 364]

Hi again,

 

After some testing I also noticed that when I use a UDP connection, some websites won't load (aliexpress or my bank for example). General traffic and P2P works, but really slow, and pings are very good. With TCP everything loads as it should, and P2P is very fast. Could it be a signal that the MTU size is wrong? I only use configs generated by AirVPN.

 

Thanks again for your time.

 

I don't know why some websites won't load.  First I've heard of that sort of thing depending on what protocol is used.  But, if UDP is slow then perhaps your ISP is treating it very unfavorably.

[Jojonintendo 1]

Maybe my ISP is slowing down my UDP traffic, but then I don't understand how I can have amazing P2P speed when outside of the VPN.

 

Also, I don't know if it's related, but when I use UDP I get a ton of these:

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1275 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

[go558a83nk 364]

Maybe my ISP is slowing down my UDP traffic, but then I don't understand how I can have amazing P2P speed when outside of the VPN.

 

Also, I don't know if it's related, but when I use UDP I get a ton of these:

Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #1275 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

 

Yeah, looks like the network your packets are traversing is treating UDP badly or it is an MTU problem as you said earlier.  Try adding 'mssfix 1200' to your UDP config and reconnect to see if that makes a difference. 

 

Unless you turn on "utp" or whatever it's called in your torrent client, bittorrent usually uses TCP. 

[Jojonintendo 1]

Yeah, looks like the network your packets are traversing is treating UDP badly or it is an MTU problem as you said earlier.  Try adding 'mssfix 1200' to your UDP config and reconnect to see if that makes a difference. 

 

Unless you turn on "utp" or whatever it's called in your torrent client, bittorrent usually uses TCP.

 

I definitely notice an improvement in speed when I use MTU 1200. Even the websites I previously had trouble with just load great.

Now I have two more questions:

 

1) If P2P use TCP, then why is UDP recommended for a VPN? Isn't it counterproductive?

 

2) How can I find the best MTU value for my connection?

[go558a83nk 364]

 

Yeah, looks like the network your packets are traversing is treating UDP badly or it is an MTU problem as you said earlier.  Try adding 'mssfix 1200' to your UDP config and reconnect to see if that makes a difference. 

 

Unless you turn on "utp" or whatever it's called in your torrent client, bittorrent usually uses TCP.

 

I definitely notice an improvement in speed when I use MTU 1200. Even the websites I previously had trouble with just load great.

Now I have two more questions:

 

1) If P2P use TCP, then why is UDP recommended for a VPN? Isn't it counterproductive?

 

2) How can I find the best MTU value for my connection?

 

UDP packets are sent/received easier in a loaded network.

 

mssfix and MTU aren't the same thing.  Read up on it.  Adjusting MTU has to be done on both server and client to have an effect.  Adjusting mssfix on the client is the way to go to help with MTU problems.  Default mssfix for openvpn is 1450.  You might start with just 1442 and work your way lower to find what works best.

[OpenSourcerer 1441]

Why is it that if something is not working fingers get pointed at them first, without hesitation? ISP throttles me. The server lags. Air staff/community is wrong. Bla, blabla. Why?..

 

Anyway, in 80% of cases issues arise out of your own setup. It's you, and you only: Your software, your computer, your network.

 

Also, the difference between TCP and UDP is, in short, that UDP is a connectionless protocol. Spoken figuratively, it values spontaneity rather than planning. While UDP's greeting line would be "Hi, i'm UDP, here's a packet, and another one, and another one!", TCP would say "Hey there, I'm TCP!", while waiting for an answer back. "Here's a packet", would it say, "did you receive it?" You instantly see that this constant politeness of TCP willing to know if packets arrived safe and sound will inevitably take more time.

 

OpenVPN works best in UDP because UDP wouldn't give a damn about whether packets arrived or not. The only checks performed are those by OpenVPN. Class dismissed.

 

Also, I don't know if it's related, but when I use UDP I get a ton of these:

 

Yes, it's one of OpenVPN's security checks failing because on your computer or network there is a device receiving UDP packets and resending them. This is sometimes done for QoS - Quality of Service, I linked something about it from Cisco. On some routers from TP-Link, ASUS, etc. there's a setting for this.
Some antivirus softwares can also cause this when they are configured to scan network traffic. I have Avast! and AVG in mind, offering some "protection" from UDP flooding.

 

1) If P2P use TCP, then why is UDP recommended for a VPN? Isn't it counterproductive?

 

Know that OpenVPN creates a tunnel encapsulating all your other traffic (that's why all the connections on your computer are routed through it) and this tunnel can be established using either TCP or UDP. The protocols inside the tunnel have nothing to do with it.

 

2) How can I find the best MTU value for my connection?

 

As Mr. go558a83nk wrote, MTU != mssfix. The one defines how big a packet may be in total (networking-wide term) while the other defines how big a packet inside the OpenVPN tunnel may be (OpenVPN term).
If the default of 1450 bytes does not work, try 1400, if not, 1350, if yes, 1375, if no, 1370, like this.
There's also the recommendation to use mssfix with fragment, though not sure what that might lead to.
 

[Jojonintendo 1]

Thank you very much, both of you, for your detailed explanations.

 

First of all, I am really not a "blame-everyone" type of person, I perfectly know that my knowledge is limited and I didn't want to sound rude by any means. I thought the problem might come from my ISP because lately they just gave me many problems with the router, etc.

 

I like your explanation about TCP and UDP, very clear and easy to remember

 

As for QoS, this is my setup: ISP router (Livebox) > TP-Link router (via wifi 5GHz) > cable to my PC. The TP-Link router is just a bridge with no configuration, and the Livebox gives almost no options to set. I don't see any QoS option, so I think I won't be able to change it. I don't use any antivirus, but I do have an iptables firewall set-up and working. I am pretty sure my iptables doesn't do anything inside the tunnel though.

 

My question about a UDP tunnel encapsulating a TCP connection might not have been well asked. What I would like to know is if I use a UDP tunnel, will I lose the reliability of the TCP that is inside? This is what I don't really understand. If I use a TCP tunnel, will the reliability checks happen twice?

 

As for the MTU and mssfix, I think I understand how it works now, thanks again for your time. I will do some tests to see what works best for me.

[OpenSourcerer 1441]

Oh, and of course, UDP is more vulnerable when transmitted over WLAN. Are you able to replace the WLAN connection to the ISP router with a cable for testing?

[Jojonintendo 1]

I have just done some testing, here are the results. As pointed out by go558a83nk, an mssfix value of 1442 is perfect: problematic websites like aliexpress load perfectly fine, and P2P doesn't seem affected. Also, I don't get any warning from OpenVPN.

 

I also fixed my iptables settings, somehow it was limiting my P2P ports. I though the firewall was bypassed by the VPN, I guess I have much more to learn about this

 

Anyway, the issue is now solved, thank you very much for your help and patience!

 

Edit: I have just seen your reply. The ISP router is very far from my PC, but the mssfix 1442 did the trick anyway. It's amazing what a small number difference can do!

[OpenSourcerer 1441]

Glad to read that. Enjoy.

[gh7qnrsx 1]

Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186216 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186218 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186217 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186219 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186220 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:12 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186221 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186938 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186939 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186940 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186941 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186942 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186943 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Sat May 27 09:48:14 2017 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #186944 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

Same problem here!

When using udp i get this error while torrenting + slow speeds. tcp works fine but speeds are ~ 50% slower!

[Jojonintendo 1]

Try what I did on my end, with mssfix. It works wonders for me.

[gh7qnrsx 1]

Try what I did on my end, with mssfix. It works wonders for me.

 

I've tried mssfix from 500-1200-1442 up to 3000 it didn't solved my problem.

[OpenSourcerer 1441]

That TCP does not work in the same way as it worked for Mr. jojonintendo should be the ultimate proof that your issue is not the same. Similar, but not the same. Open up your own threads for your own issues, include your logs, dxdiag/inxi output and whatever else you can give us.

 

Actually, do this right now.

 

I found your post, I'm sorry for sending you back and forth, but you did the right thing. Keep your issue there, please.