OpenVPN TCP in 2.4.5-p1 not working
-
@chipbr said in OpenVPN TCP in 2.4.5-p1 not working:
Sir, could you please explain why? I have more than 10 openvpn site-to-site using TCP, all with netgate sg1000. What is the reason not to use it?
- The OpenVPN protocol is designed to run over UDP.
- UDP is faster / less overhead
- It's not a good idea to wrap TCP packets in TCP packets. You can run in situations with compounded loss, which means OpenVPN is retransmitting lost TCP packets at the VPN layer while lost TCP packets inside the tunnel (say your client loading a HTTPS website) is also retransmitting at the same time.
TCP should be your second choice for OpenVPN if you can't do UDP for some reason.
-Rico
-
I agree, unless there is a specific reason to run tcp for your openvpn, it is better to use udp.
That being said, there are some valid reason(s) why you might need/want to run it on tcp as well. The reason I do, is that not all locations allow for UDP 1194 outbound.. But its pretty much a given that tcp 443 will be allowed out, even if you have to auth to a proxy.. You can still get your vpn connection.
So I run standard 1194 udp, as well as a tcp 443 instance.. If udp 1194 doesn't work, then try the 443 tcp one.
-
I totally see the reason for TCP 443 RAS, like sneaking out the hotels wifi with any but the common ports blocked.
But for site to site VPNs? Bad idea.... maybe if you need to establish a connection between the US and China or something like this. ;-)-Rico
-
I'm one of those cases. I run a network behind a network at a college, pfsense is the firewall I use to get out of my network. And my college IT department won't open UDP for me, even though I know it is the better choice.
To johnpoz, I think this might have only been a site to site issue, not client to site like you show on your phone. Not positive, but possible. In my case, I'm also on a non-standard port, it was already open and I "snuck" this into service when we were all sent to work from home. I did seek permission and never got that permission, but I never got denied either. I spoke to several people about this VPN and they had several chances to tell me to turn it off, even earlier this week. So that turns it into permission by omission.
-
@Greg_E said in OpenVPN TCP in 2.4.5-p1 not working:
So that turns it into permission by omission.
Which is always the funnest kind - you didn't tell me I couldn't do that ;)
-
There are UDP ports you can use to try and evade some filters (53, 123, 5060, 500, 4500) TCP should only be used as a last resort if all other access is blocked.
-
Completely agree but almost always those UDPs are blocked when your behind a proxy.. Which was my case back when had to go to the office every day ;)
You know it was kind of under that - hey you didn't actually say I couldn't connect to my home vpn, Im going thru the proxy and you didn't block the destination IP ;) sort of permission things that @Greg_E mentioned ;)
-
Maybe so but this error only affects when pfSense itself is acting as a TCP client to a remote OpenVPN TCP server. And if your firewall is behind something that dumb, you probably have bigger problems.
-
^ concur ;)
-
@Rico said in OpenVPN TCP in 2.4.5-p1 not working:
@chipbr said in OpenVPN TCP in 2.4.5-p1 not working:
Sir, could you please explain why? I have more than 10 openvpn site-to-site using TCP, all with netgate sg1000. What is the reason not to use it?
- The OpenVPN protocol is designed to run over UDP.
- UDP is faster / less overhead
- It's not a good idea to wrap TCP packets in TCP packets. You can run in situations with compounded loss, which means OpenVPN is retransmitting lost TCP packets at the VPN layer while lost TCP packets inside the tunnel (say your client loading a HTTPS website) is also retransmitting at the same time.
TCP should be your second choice for OpenVPN if you can't do UDP for some reason.
-Rico
Thank you for your answer. I understand your point and agree, UDP is faster.
However, in my case, all my offices/branches use thin client terminals, which connect to our main server via MS RDP.Of course, packet loss happens sometimes, and when running on UDP, the thin clients hangs or disconnect. This does not happen when using TCP: they just freeze for 1-3 seconds then resume working as usual
-
I guess finding a bug is sometimes a good thing. I was using TCP for years. After switching to UDP, it does indeed seem faster. I wonder if this isn't as uncommon as you might think. I'm pretty sure that I followed a tutorial years back and the protocol was 'TCP'. I would also like to suggest that if someone is tries switching from TCP to UDP, don't forget to also change your firewall rule protocol as well! It's easy to overlook when you are trying to figure things out in a hurry.
