Arch Linux
Contents
UDP is referred to as a ‘stateless protocol’ as it performs no such error correction, simply receiving packets with no or retries. This makes it much faster, but less reliable.
OpenVPN over TCP vs. UDP
OpenVPN can run over either the TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) transports. Choosing which one to use is a highly technical issue, and one that most VPN providers (quite understandably) keep hidden ‘behind the scenes’.
Some VPN providers, however, prefer to let customers choose which connection protocol they prefer. The reason for this is that while both offer distinct advantages and disadvantages in each other, choosing which is ‘best is’ difficult, as it depends what the internet is being used for, and what matters to individuals most – speed or reliability.
The Difference
TCP vs UDP, OpenVPN vs TCP, UDP vs OpenVPN. What is the difference, exactly?
TCP is, in general, the most commonly used connection protocol on the internet, as it offers error correction –>(and is therefore known as a ‘stateful protocol’). Whenever a computer sends a network packet using TCP, it waits for confirmation that the packet has arrived before resending the packet (if no confirmation is received), or sending the next packet (if confirmation is received).
This means there is ‘guaranteed delivery’ of all data, making the protocol very reliable, but there is a considerable overhead as packets are sent, confirmed, re-sent etc., making it quite slow.
UDP is referred to as a ‘stateless protocol’ as it performs no such error correction, simply receiving packets with no or retries. This makes it much faster, but less reliable.
Which one to use?
Which one you use, therefore, depends on whether reliability or speed is your primary concern, and, in general, UDP is better for streaming VoIP, and playing games online.
However, how much TCP actually slows a connection down in practice can be very dependent on other network factors, with distance being the most important. The further away you are from your VPN server geographically, the further TCP packets have to travel to and fro, and therefore the slower your connection will be. If the server is relatively close-by, then you may not see much of a speed loss, while benefiting from a more reliable connection.
That said, probably the best general advice is to use the faster UDP protocol unless you experience connection problems, which is the strategy adopted by most VPN providers by default.
Defeat censorship with OpenVPN on TCP Port 443
When you connect to a secure website your connection is protected by SSL encryption. You can tell that a website is secure because its URL (web address) begins with https: and a closed lock icon should appear to the left of your browser’s URL bar. Traditionally it was mainly banks and online shops etc. that used SSL, but with growing public concern about internet security, it is increasingly common to see SSL encryption deployed on all kinds of websites.
SSL is the cornerstone of security on the internet, and any attempt to block it effectively breaks the internet (which hasn’t stopped places such as Iran trying!). SSL runs over TCP port 443.
The interesting thing for OpenVPN (which is based on the OpenSSL libraries) is that configured to run on TCP port 443, OpenVPN traffic looks identical to regular SSL connections. This makes running OpenVPN over TCP port 443 ideal for evading censorship as:
- It is very difficult that OpenVPN is being used rather than regular SSL
- It is almost impossible to block without breaking the internet.
Some custom VPN clients allow you to select TCP port 443, or it can often be configured manually (ask your VPN provider for settings.)
Written by: Douglas Crawford
Has worked for almost six years as senior staff writer and resident tech and VPN industry expert at ProPrivacy.com. Widely quoted on issues relating cybersecurity and digital privacy in the UK national press (The Independent & Daily Mail Online) and international technology publications such as Ars Technica.
Arch Linux
How to debug the following reconnection issue?
I have configured the openvpn client to connect to PIA VPN according to their manual https://www.privateinternetaccess.com/h … e-terminal.
It connects just fine but once my WLAN is interrupted (with a weather radar, happens approx daily) it can not reconnect.
systemctl restart openvpn-client@us_east works with no problem but the automatic reconnect fails. Please see the log below.
I have written to PIA support but have had not reply other than the above manual for more than a week now.
What can I do to debug this?
Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: carrier acquired Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: rebinding lease of 192.168.178.33 Feb 01 12:51:41 arch-box dhcpcd[572]: wlan0: probing address 192.168.178.33/24 Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: leased 192.168.178.33 for 864000 seconds Feb 01 12:51:46 arch-box avahi-daemon[565]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.178.33. Feb 01 12:51:46 arch-box avahi-daemon[565]: New relevant interface wlan0.IPv4 for mDNS. Feb 01 12:51:46 arch-box avahi-daemon[565]: Registering new address record for 192.168.178.33 on wlan0.IPv4. Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: adding route to 192.168.178.0/24 Feb 01 12:51:46 arch-box dhcpcd[572]: wlan0: adding default route via 192.168.178.1 Feb 01 12:54:31 arch-box openvpn[37920]: [newjersey428] Inactivity timeout (--ping-restart), restarting Feb 01 12:54:31 arch-box openvpn[37920]: SIGUSR1[soft,ping-restart] received, process restarting Feb 01 12:54:36 arch-box openvpn[37920]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.102:1198 Feb 01 12:54:36 arch-box openvpn[37920]: UDP link local: (not bound) Feb 01 12:54:36 arch-box openvpn[37920]: UDP link remote: [AF_INET]102.165.16.102:1198 Feb 01 12:55:37 arch-box openvpn[37920]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 01 12:55:37 arch-box openvpn[37920]: SIGUSR1[soft,ping-restart] received, process restarting Feb 01 12:55:42 arch-box openvpn[37920]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.122:1198 Feb 01 12:55:42 arch-box openvpn[37920]: UDP link local: (not bound) Feb 01 12:55:42 arch-box openvpn[37920]: UDP link remote: [AF_INET]102.165.16.122:1198etc. goes forever, every five minutes a different IP.
Actual log with startup sequence and the software versions. The connection is established @Feb 18 03:58:52 but then drops @Feb 18 06:10:27 to never come up again. So maybe there is no information in this log to pin the culprit at all. So where else could I look?
Feb 18 03:58:37 arch-box openvpn[609]: DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --ciph> Feb 18 03:58:37 arch-box openvpn[609]: WARNING: file '/etc/openvpn/login' is group or others accessible Feb 18 03:58:37 arch-box openvpn[609]: OpenVPN 2.5.5 [git:makepkg/869f194c23ae93c4+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Dec 15 > Feb 18 03:58:37 arch-box openvpn[609]: library versions: OpenSSL 1.1.1m 14 Dec 2021, LZO 2.10 Feb 18 03:58:37 arch-box systemd[1]: Started OpenVPN tunnel for us_east. ░░ Subject: A start job for unit openvpn-client@us_east.service has finished successfully ░░ Defined-By: systemd ░░ Support: [url]https://lists.freedesktop.org/mailman/listinfo/systemd-devel[/url] ░░ ░░ A start job for unit openvpn-client@us_east.service has finished successfully. ░░ ░░ The job identifier is 89. Feb 18 03:58:37 arch-box openvpn[609]: CRL: loaded 1 CRLs from file -----BEGIN X509 CRL----- . Feb 18 03:58:37 arch-box openvpn[609]: -----END X509 CRL----- Feb 18 03:58:37 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:37 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:37 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol Feb 18 03:58:37 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting Feb 18 03:58:42 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:42 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:42 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol Feb 18 03:58:42 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting Feb 18 03:58:47 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:47 arch-box openvpn[609]: RESOLVE: Cannot resolve host address: us-newjersey.privacy.network:1198 (Temporary failure in name resolution) Feb 18 03:58:47 arch-box openvpn[609]: Could not determine IPv4/IPv6 protocol Feb 18 03:58:47 arch-box openvpn[609]: SIGUSR1[soft,init_instance] received, process restarting Feb 18 03:58:52 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.194:1198 Feb 18 03:58:52 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 03:58:52 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.194:1198 Feb 18 06:10:27 arch-box openvpn[609]: [newjersey431] Inactivity timeout (--ping-restart), restarting Feb 18 06:10:27 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:10:32 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.194:1198 Feb 18 06:10:32 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:10:32 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.194:1198 Feb 18 06:11:32 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 18 06:11:32 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:11:37 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]191.96.185.72:1198 Feb 18 06:11:37 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:11:37 arch-box openvpn[609]: UDP link remote: [AF_INET]191.96.185.72:1198 Feb 18 06:12:38 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 18 06:12:38 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:12:43 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.219:1198 Feb 18 06:12:43 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:12:43 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.219:1198 Feb 18 06:13:43 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 18 06:13:43 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:13:48 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.99:1198 Feb 18 06:13:48 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:13:48 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.99:1198 Feb 18 06:14:48 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 18 06:14:48 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:14:53 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.195:1198 Feb 18 06:14:53 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:14:53 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.195:1198 Feb 18 06:15:54 arch-box openvpn[609]: [UNDEF] Inactivity timeout (--ping-restart), restarting Feb 18 06:15:54 arch-box openvpn[609]: SIGUSR1[soft,ping-restart] received, process restarting Feb 18 06:15:59 arch-box openvpn[609]: TCP/UDP: Preserving recently used remote address: [AF_INET]102.165.16.90:1198 Feb 18 06:15:59 arch-box openvpn[609]: UDP link local: (not bound) Feb 18 06:15:59 arch-box openvpn[609]: UDP link remote: [AF_INET]102.165.16.90:1198Last edited by kivot (2022-02-21 08:12:53)