OpenVPN TCP in 2.4.5-p1 not working

mzac · Jun 10, 2020, 12:59 PM

Hi, just upgraded to 2.4.5p1 last night and I have one OpenVPN session using TCP that is no longer working. I am getting this error in the logs. Any ideas? I don't have anything special configured.

Options error: --proto tcp is ambiguous in this context. Please specify --proto tcp-server or --proto tcp-client

gkovachev · Jun 10, 2020, 1:26 PM

Same here, I have pfSense as OpenVPN server and another pfSense as client. After upgrading the client to 2.4.5-p1 it stopped connecting to 2.4.5 server. If you change connection from TCP to UDP on both sides VPN starts to work again.

jimp · Jun 10, 2020, 1:28 PM

It was probably the change for this bug: https://redmine.pfsense.org/issues/10368

You could revert that change using the system patches package to see if that helps.

viktor_g · Jun 10, 2020, 1:56 PM

Fix: https://redmine.pfsense.org/issues/10650

mzac · Jun 10, 2020, 2:30 PM

@jimp Thanks I switched to UDP for now and got it up and running but once the patch is in I'll try and revert back to TCP.

SipriusPT · Jun 30, 2020, 2:06 PM

Thanks all for the help sharing this info!

I have several OpenVPN servers using only TCP, and had this issue, only with the site-to-site VPN from a pfsense 2.4.5-RELEASE-p1 server to a 2.4.5-RELEASE-p1 client, being the pfsense client the last one being updated.

Greg_E · Aug 13, 2020, 1:24 AM

So I just updated a client in my home lab, and got locked out of the vpn to work. I'm trying to follow the fix, but obviously I'm not getting something. I'm assuming I need to edit /src/etc/inc/openvpn.inc to add/change the lines in the fix, but I can't find the /src folder when I SSH into my firewall. I have disabled the default admin account, so I'm logged in as a user I created who should have admin permissions.

Could someone step me through the process from either the HTTP interface or through an SSH connection?

Or do I need to have a keyboard/monitor attached to the computer this is running on?

{EDIT} Found my way into /etc/inc and found the openvpn.inc file, just need to figure out where to put the lines from the fix. I'm using vi and not real familiar with it, so no line numbers.

Greg_E · Aug 13, 2020, 1:43 AM

@Greg_E Alright, persistence paid off, got it patched. Thanks for the info on the patch.

KOM · Aug 13, 2020, 1:10 PM

I just ran into this last night while debugging a throughput issue. I had been using UDP all along, but I could only get 10Mbps out of it. Having read that some ISPs throttle UDP, I tried switching to TCP only to find I could no longer connect. Really unfortunate that this major bug gets reported and months later nothing has changed, and the user is expected to hack around trying to fix it.

Rico · Aug 13, 2020, 1:15 PM

Well this bug crept into 2.4.5-p1 and we had no update since.

-Rico

viktor_g · Aug 13, 2020, 1:22 PM

@KOM you can also try https://redmine.pfsense.org/issues/10311#note-3 to improve openvpn speed

KOM · Aug 13, 2020, 1:32 PM

@viktor_g Thanks. I'm running pfSense on both ends, router to router. Would this fix need to be applied to the server end, or both?

viktor_g · Aug 13, 2020, 1:44 PM

@KOM said in OpenVPN TCP in 2.4.5-p1 not working:

@viktor_g Thanks. I'm running pfSense on both ends, router to router. Would this fix need to be applied to the server end, or both?

it's better to check both ways

jimp · Aug 13, 2020, 1:52 PM

@KOM said in OpenVPN TCP in 2.4.5-p1 not working:

I just ran into this last night while debugging a throughput issue. I had been using UDP all along, but I could only get 10Mbps out of it. Having read that some ISPs throttle UDP, I tried switching to TCP only to find I could no longer connect. Really unfortunate that this major bug gets reported and months later nothing has changed, and the user is expected to hack around trying to fix it.

It was fixed in the repository the same day it was reported. You can apply a single patch with the System Patches package to get the fix. It's not exactly "hacking around". It's not worth making a whole new release for a small bug like this, and almost nobody should be using TCP with OpenVPN anyhow.

KOM · Aug 13, 2020, 2:15 PM

@viktor_g Hmmm, I don't seem to have a loader.conf.local, only loader.conf. And the references to hw.em.rxd etc, is the em specific for the EM-1000 series of NICs? Should it be replaced with hw.vmx.rxd if you're using VMX NICs under VMware?

@jimp First you would have to stumble upon this forum thread, or an entry in Redmine if you even had an inkling this was a bug as opposed to a user config error. Then you have to install the System Patches package which should be something that nobody already has installed. Then you go to that bug in Redmine and you see that there are two patches listed from the same day with different IDs, and you're not sure which one to use. Not exactly simple or intuitive.

Greg_E · Aug 13, 2020, 11:31 PM

I had help pointing me here.

Going to have to read up on the system patches module, didn't know it existed and didn't figure it out while trying to fix my problem, so thanks for the tip.

chipbr · Aug 14, 2020, 11:43 AM

@KOM said in OpenVPN TCP in 2.4.5-p1 not working:

It's not worth making a whole new release for a small bug like this, and almost nobody should be using TCP with OpenVPN anyhow.

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?

johnpoz · Aug 14, 2020, 12:00 PM

I am running 2.4.5p1, and have openvpn running on tcp..

I just validated, and don't see any issues with it.

I didn't install any patches.. Was this only a problem if you were running tcp on both ipv4 and ipv6? Mine has always been called tcp on ipv4 only.

Rico · Aug 14, 2020, 12:39 PM

@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

johnpoz · Aug 14, 2020, 12:46 PM

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.