OpenVPN TCP only, no UDP

Normally OpenVPN should run with the UDP protocol, but for me it doesn’t work, I can connect with the configured Roadwarrior without errors in the log, but I have no access to the Internet via VPN and I get no contact to the internal network. As an example, after connecting to the VPN server I try to access the Ipfire, login is still requested, but that’s it, more does not come. If I switch to the TCP protocol everything works fine.
What could be the reason for this?

Hi,

this can happen if you are behind some really crappy networks of hotels and such, where anything besides TCP ports 80 and 443 is blocked. While such setups are diminishing, they still appear rather frequently, I found.

TCP over TCP is far from optimal, but especially if there is no alternative such as internet via cellular network available, running OpenVPN on TCP port 443 guarantees maximum “interoperability”.

Thanks, and best regards,
Peter Müller

But I’m at home and have a bomb good connection, even the smartphone, the Roadwarrior is good in business with LTE and 4 bars, but still it does not work.
It is in no case due to poor data throughput.
Any other ideas what it could be?

Hi,

to ensure I understood your issue correctly: OpenVPN with UDP works fine to you, unless you are at home - behind your IPFire machine where the OpenVPN service is running, I imagine?

@ummeegge: Do you have an idea?

Thanks, and best regards,
Peter Müller

No sir, UDP doesn’t work at all and the only connection I establish is from my smartphone over LTE network which is configured as Roadwarrior, my Ipfire is at home behind a modem.
And the connection only works with TCP protocol, if I switch to UDP I can connect with no errors in the log but no data goes through.

Hi,

I am getting the feeling this is caused by an MTU issue. To verify that:

  • What MTU is configured on the OpenVPN CGI page?
  • What MTU does your internet connection feature?
  • Can you at the very least ping through the OpenVPN connection when it is using UDP (that should always work, since ICMP packets are unlikely to cause MTU trouble)?

Thanks, and best regards,
Peter Müller

Hi all,
have heard of problems that some SPIs do cut stateless connections which UDP is. May ISP limitations can come there also to play… The logs can may also give a hint of what is going wrong.

Best,

Erik

Standard MTU 1400

[root@XXXXX ~]# ifconfig red0
red0: flags=67<UP,BROADCAST,RUNNING> mtu 1500
inet 84.118.155.105 netmask 255.255.248.0 broadcast 84.118.159.255
ether 70:85:c2:ca:70:9c txqueuelen 1000 (Ethernet)
RX packets 25995546 bytes 34478044533 (32.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 12967105 bytes 4205427022 (3.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 16 memory 0xa1300000-a1320000

correct? or need other command?

log witch connection with UDP Protocol and MTU 1500, it looks the same with standard MTU1400

Blockquote
May 1 22:29:23 openvpnserver[25162]: DEPRECATED OPTION: ncp-disable. Disabling cipher negotiation is a deprecated debug feature that will be removed in OpenVPN 2.6
May 1 22:29:23 openvpnserver[25162]: WARNING: --topology net30 support for server configs with IPv4 pools will be removed in a future release. Please migrate to --topology subnet as soon as possible.
May 1 22:29:23 openvpnserver[25162]: DEPRECATED OPTION: --cipher set to ‘AES-256-CBC’ but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add ‘AES-256-CBC’ to --data-ciphers or change --cipher ‘AES-256-CBC’ to --data-ciphers-fallback ‘AES-256-CBC’ to silence this warning.
May 1 22:29:23 openvpnserver[25162]: OpenVPN 2.5.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Dec 19 2021
May 1 22:29:23 openvpnserver[25162]: library versions: OpenSSL 1.1.1n 15 Mar 2022, LZO 2.09
May 1 22:29:23 openvpnserver[25163]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
May 1 22:29:23 openvpnserver[25163]: Diffie-Hellman initialized with 3072 bit key
May 1 22:29:23 openvpnserver[25163]: CRL: loaded 1 CRLs from file /var/ipfire/ovpn/crls/cacrl.pem
May 1 22:29:23 openvpnserver[25163]: Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 22:29:23 openvpnserver[25163]: Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 22:29:23 openvpnserver[25163]: ROUTE_GATEWAY XXX.XXX.XXX.XXX/255.255.248.0 IFACE=red0 HWADDR=XX:XX:XX:XX:XX:XX
May 1 22:29:23 openvpnserver[25163]: TUN/TAP device tun0 opened
May 1 22:29:23 openvpnserver[25163]: /sbin/ip link set dev tun0 up mtu 1500
May 1 22:29:23 openvpnserver[25163]: /sbin/ip link set dev tun0 up
May 1 22:29:23 openvpnserver[25163]: /sbin/ip addr add dev tun0 local 10.104.150.1 peer 10.104.150.2
May 1 22:29:23 openvpnserver[25163]: /sbin/ip route add 10.104.150.0/24 via 10.104.150.2
May 1 22:29:23 openvpnserver[25163]: /sbin/ip route add 10.104.150.0/24 via 10.104.150.2
May 1 22:29:23 openvpnserver[25163]: ERROR: Linux route add command failed: external program exited with error status: 2
May 1 22:29:23 openvpnserver[25163]: Could not determine IPv4/IPv6 protocol. Using AF_INET
May 1 22:29:23 openvpnserver[25163]: Socket Buffers: R=[212992->212992] S=[212992->212992]
May 1 22:29:23 openvpnserver[25163]: UDPv4 link local (bound): [AF_INET][undef]:1194
May 1 22:29:23 openvpnserver[25163]: UDPv4 link remote: [AF_UNSPEC]
May 1 22:29:23 openvpnserver[25163]: GID set to nobody
May 1 22:29:23 openvpnserver[25163]: UID set to nobody
May 1 22:29:23 openvpnserver[25163]: MULTI: multi_init called, r=256 v=256
May 1 22:29:23 openvpnserver[25163]: IFCONFIG POOL IPv4: base=10.104.150.4 size=62
May 1 22:29:23 openvpnserver[25163]: IFCONFIG POOL LIST
May 1 22:29:23 openvpnserver[25163]: Initialization Sequence Completed
May 1 23:06:43 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 Outgoing Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 23:06:43 openvpnserver[25163]: XXXXXXX.XXX.XXX:8698 Incoming Control Channel Authentication: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 23:06:43 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 TLS: Initial packet from [AF_INET]XXX.XXX.XXX.XXX:8698, sid=33f5c90b 705dd5c8
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 VERIFY SCRIPT OK: depth=1, C=DE, ST=XX, L=XXXXXXXXXXXXX, O=VPN at Home, OU=XXXXXXXXXXX, CN=VPN at Home CA
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 VERIFY OK: depth=1, C=DE, ST=XXX, L=XXXXXXXXXX, O=VPN at Home, OU=XXXXXXXXXX, CN=VPN at Home CA
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 VERIFY SCRIPT OK: depth=0, C=DE, ST=XXX, O=VPN at Home, CN=oneplus
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 VERIFY OK: depth=0, C=DE, ST=XXX, O=VPN at Home, CN=oneplus
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_VER=2.6_master
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_PLAT=android
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_TCPNL=1
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_CIPHERS=AES-256-CBC
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_PROTO=22
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_LZO_STUB=1
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_COMP_STUB=1
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_COMP_STUBv2=1
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_GUI_VER=de.blinkt.openvpn_0.7.34
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 peer info: IV_SSO=openurl,webauth,crtext
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 WARNING: ‘auth’ is used inconsistently, local=‘auth SHA512’, remote=‘auth SHA2-512’
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 [oneplus] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:8698
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 MULTI_sva: pool returned IPv4=10.104.150.6, IPv6=(Not enabled)
May 1 23:06:44 openvpnserver[25163]: onepllus/XXX.XXX.XXX.XXX:8698 OPTIONS IMPORT: reading client specific options from: /var/ipfire/ovpn/ccd/oneplus
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_55d5b95594a3da3e3da8d25ad2c1420d.tmp
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 MULTI: Learn: 10.104.150.6 → oneplus/XXX.XXX.XXX.XXX:8698
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 MULTI: primary virtual IP for oneplus/XXX.XXX.XXX.XXX:8698: 10.104.150.6
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 Outgoing Data Channel: Cipher ‘AES-256-CBC’ initialized with 256 bit key
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 Outgoing Data Channel: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 Incoming Data Channel: Cipher ‘AES-256-CBC’ initialized with 256 bit key
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 Incoming Data Channel: Using 512 bit message hash ‘SHA512’ for HMAC authentication
May 1 23:06:44 openvpnserver[25163]: oneplus/XXX.XXX.XXX.XXX:8698 SENT CONTROL [oneplus]: ‘PUSH_REPLY,route 10.104.150.1,topology net30,ping 10,ping-restart 60,redirect-gateway,route 192.168.1.0 255.255.255.0,ifconfig 10.104.150.6 10.104.150.5,peer-id 0,cipher AES-256-CBC’ (status=1)

I changed the MTU for the test on 1500, but is the same with Standard MTU 1400.
I don’t see any errors that take me further, there is a connection, but no data goes through, with UDP protocol.

Are you using a Windows client ? If so, may you can find in here → OpenVPN / Thread: [Openvpn-users] UDP throughput issue with openVPN UDP tunnel and e.g. here → Solving OpenVPN Poor Throughput and Packet Loss - Ivan Vari some possible explanations/solutions.

Best,

Erik

No, my Roadwarrior is my smartphone with android. I use the APP “OpenVPN for Android” from F-Droid store.

What you mean? Should I try to lower the MTU as in the link disciption, or rise the MTU?

I never changed such as things like txqueuelen and month/years ago my settings worked like a charme with standard configuration.

Is there something i can test or do to see anything specific whats going wrong?
As Example i get massiv Firewall logs from HOSTILE and CTINVALID, since they are active, I get over 4000 messages in log every day and the second most IP entry is my own. I dont know if thats all ok, I assume that has something to do with the Tor Realy.

I have also installed two “managed switches”, once before the ipfire (red) to modem and once after in my Network (green), could I have done something wrong there?
I have to work with two VLANs to connect the modem to the Ipfire (VLAN1) and at the same time serve my network on the back channel(VLAN2),with 2 cabels, off course.

Did you checked a traceroute e.g.–> https://apkpure.com/traceroute/com.appsteka.traceroute from your Phone to IPFire, Client behind IPFire and WAN wide since you have redirect-gateway active ? Did you have also another Roadwarrior client to check the VPN connection via UDP ? A tcpdump/tshark from IPFire side while connected can may also deliver some more infos.
This message
May 1 23:06:44 openvpnserver[25163]: XXX.XXX.XXX.XXX:8698 WARNING: ‘auth’ is used inconsistently, local=‘auth SHA512’, remote=‘auth SHA2-512’
looks also a little strange to me…

Best,

Erik

Hi,
just saw this:

not sure, but could be a reason…
You may check the routes set after the connection is established
could You please compare Your logs from udp with tcp.

Cheers, Stephan

I have changed absolutely nothing at all in the configuration, neither at the OpenVPN server nor at the Android, but the access to my network works now with TCP as well as with UDP again. I have attached the traceroute.I think you meant that the roadwarrior should access the network from outside the network, i.e. from the road, everything else would make no sense. I have not activated “redirect-gateway active”, do I need that? I currently have only one roadwarrior set up.



Except for one, maybe you can help me there. I have attached the traceroute to the specific client (192.168.1.13), it is a Windows 10 PC that shares a folder on the network and is accessible within that network, just not over the VPN connection (UDP and TCP). Do I need to change anything in Windows there? If so, please what exactly?

As said openVPN connection is now also possible with UDP, no idea why. Thanks for the help anyway!

Only the one client still makes problems. Any ideas?

The Redirect Gareway option is described on the following Wiki page

Yes thanks i see, my roadwarrior has access to the green network except one client, the windows machine, as I mentioned above.
This redirect gateway was a problem earlier, because if you set it to the client and to the server something don’t work anymore, so I decided to set the option on the client. So I was wrong, i only set the option not on server, but on client and I didn’t remember.

This “Windows 10 PC” must allow communication with the OpenVPN client IP address.

And how will I do this? I only find the advanced share options and they are turn on.


My google results are all VPN instructions only

On a “Windows 10 PC” is there only Widows Defender, or another firewall or antivirus+firewall?

Is the “Windows 10 PC” working in a domain or standalone?

Standalone and windows defender firewall, but I have no idea at all how to configure defender, I always just allow access for programs once the request comes and that’s it.

A little hint :
Press the “Windows key” +R
Type wf.msc and then press Enter.

Edit:
You should look for “Windows Defender Firewall with Advanced Security” configuration pages for file sharing.

For examples:

Edit2:
The windows 10 firewall event preview can also be useful.

Regards