OpenVPN TCP in 2.4.5-p1 not working
-
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 -
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.
-
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.
-
Fix: https://redmine.pfsense.org/issues/10650
-
@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.
-
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.
-
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 Alright, persistence paid off, got it patched. Thanks for the info on the patch.
-
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.
-
Well this bug crept into 2.4.5-p1 and we had no update since.
-Rico
-
@KOM you can also try https://redmine.pfsense.org/issues/10311#note-3 to improve openvpn speed
-
@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?
-
@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
-
@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.
-
@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.
-
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.
-
@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?
-
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.
-
@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.
