I was just looking at the .ovpn config files and I see that the only difference between tcp and udp is one line in the config (proto tcp or proto udp)
It would be really cool to have a toggle switch in the GUI so you could switch all profiles to tcp or udp, saving space on the device too rather than uploading two types of profiles and letting you choose between UDP for speed or TCP for restrictive networks.
Could this be a feature in next firmware?
This setting needs to match the setting on your VPN router.
what is the advantage of using udp or tcp for the same server? or, why you want to shift between udp or tcp?
This can be done using the switch but I think you need to write a script. Not difficult in fact, unless you really think this is useful.
With UDP, packets are sent to recipient with no verification that the packets are received. This lack of error correction makes it faster so it is more suitable for live streaming and gaming than TCP.
However, TCP is still necessary and having the option to switch to it is desirable because some networks with more restrictive firewalls are not compatible with UDP but would still work under TCP.
To have one set of profiles and toggle between optimising for speed / optimising for reliability would be great.
Nice idea but not really do-able - ovpn files often differ by more than TCP/UDP, for example all mine use a different port both the two protocols.
You may have a TCP with one port and a UDP with another, but the choice of the port is a separate issue to the choice of protocol, and TCP or UDP can be routed over any port. This may just be how your provider has set-up the config files.
Switching the single line of proto tcp / proto udp would switch from routing TCP to UDP (the port would remain the same as contained in the .ovpn file). Personally regardless of choice of protocol, I would always route over port 443.
This provides nice summary of protocols, it would be a switch between (Regular VPN vs Stronger VPN).
TCP vs UDP
Long story short: TCP is heavier and slower than UDP. UDP is a preferred choice for speed, TCP is preferred when Internet connection is unstable.
TCP provides highly reliable, ordered, and checked for error delivery of information between applications. TCP is a connection based protocol which means that TCP first establishes a connection between two devices and only then sends data. Additionally, TCP performs flow control, error detection and correction to ensure that all packets are delivered. All data transferred via TCP is guaranteed to be delivered in the same order it was sent. TCP is heavier, its header size is 20 bytes while UDP is only 8 bytes. All of the above causes network overhead and makes TCP much slower. TCP is an excellent choice on unreliable networks, however, since TCP will check for lost packets and automatically resend them.
UDP is a more efficient protocol since it doesn’t establish a direct channel between two devices, it provides a connectionless datagram service that emphasizes reduced latency over reliability. UDP only sends information, but does not care if it ever reaches the intended destination or gets lost in the process, avoiding the overhead of error processing at the network interface level. Since UDP does not take time to establish connection, never checks for errors and does not track the packets, time-sensitive applications (gaming, streaming, VoIP) often use UDP because dropping packets is preferable to waiting for delayed packets. Sounds bad, right? Not really since the packets are virtually never lost in real life unless the Internet connection is unreliable.
Here is some info about ports:
Common applications/processes often use specifically reserved port numbers for receiving service requests from clients:
HTTPS (TLS/SSL) – 443 TCP/UDP // HTTP – 80 UDP/TCP // OpenVPN – 1194 TCP/UDP // PPTP – 1723 TCP/UDP // L2TP – 1701 UDP // SSTP – 443 TCP // Cisco IPsec – 1293 TCP/UDP, 500 TCP/UDP // IKEv2 (Internet Key Exchange) – 500 TCP/UDP
Since default configurations for specific processes are well known, network admins can easily block certain ports to restrict a particular traffic. For instance, when 1194 port is blocked, OpenVPN doesn’t work unless VPN software can forward OpenVPN traffic via a port that is open.
So in order to bypass restrictive firewalls that block ports (college and corporate networks, for instance), VPN providers offer port forwarding typically to 443, 80, 53, 22 ports:
PORT FORWARDING TO PORT 443
Forwarding VPN traffic to port 443 is the best way to bypass firewall restrictions since port 443 is used for encrypted TLS/SSL traffic by default. In other words, web browsers establish secure HTTPS connections using port 443. So as long as access to https:// websites is not restricted, port 443 is open. Additionally, since port 443 is used for encrypted communication, VPN traffic sent over 443 will sort of “blend in” with the rest (deep packet inspection can still detect it, of course).
I think we can compare this to when we used to have to go over to the TV physically to change channel, rather than use the remote - how many want to go back to that?
Anyway, I suppose you could edit the ovpn file and just make one. Then use the switch to insert the port and server. However, the space saving is neglible.
Glitch
For me I have around 100 profiles uploading with various countries, and I have to go and switch between one profile at home and one profile in a coffee shop for example.
From a usability perspective, I think switching protocol should not require switching profile. A protocol switch (enabling a toggle between performance and wider network support would be a great feature).
Appreciate some may have different opinions.
>>> switching protocol should not require switching profile
But the profile has the port and protocol in it.
>>> 100 profiles,… and I have to go and switch between one profile at home and one profile in a coffee shop for example.
Where is the difficulty in changing it via a browser? And why would you need tcp in the coffee shop and udp at home?
I am not saying the idea is a bad one but the complexity and work involved seems to out-weigh any benefit.
I would use UDP at home with less restrictive firewall and better speeds but TCP on any public network as VPN with UDP protocol often runs into challenges on these networks such as at my office. I wouldn’t want too much complexity, but Alfie did suggest it may be simple.