OpenVPN UDP don't work with iPhone?

I've a strange situation.

LEDE with OpenVPN, standard config, working fine with a Mac OS X client. Using UDP.

However doesn't work with an iPhone.

At the client I can see Server poll timeout, trying next remote entry... in just 5 seconds. At the server:
UDPv4 READ [14] from [AF_INET]37.10.134.28:62013: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0

TCP works on both, the Mac OS X and the iPhone, using the same port.

With OpenWRT all was working fine, so this happened since upgraded to LEDE (stable). I mean the iPhone was working fine with UDP OpenVPN on OpenWRT. In fact, still works with another router that has OpenWRT (Chaos Chalmer, 15.05), os is not a problem of UDP port being filtered by the ISP/cell provider or anything similar.

Anyone got the same problem?

I have a working OpenVPN setup on my TL-WR1043NDv2 with factory LEDE firewall rules plus OpenVPN opened inbound traffic. I haven't any problems connecting with various clients (win7, iphone, etc).

I recently wrote a howto on lede wiki, so my setup looks like this

Can you post your openvpn config files (client and server) as well your firewall rules ?

Regards.

P.S. Change your post title as "UTP" could be misleading.

Sorry, misstype, now corrected ...

I will review with detail again this afternoon your howto, but it seems the same I've. As said, it works in Mac OS X, and it worked with OpenWRT and is still working in another router with OpenWRT, so it is strange.

I see only one difference, in the server, I don't do this:
openvpn --genkey --secret /etc/easy-rsa/keys/ta.key

Neither for the clients:
openssl rsa -in /etc/easy-rsa/keys/myuser.key -des3 -out /etc/easy-rsa/keys/myuser.3des.key

I guess is some security increase and is not a "must", but as said, will check again step by step this afternoon/evening.

Thanks a lot!

I've done this again from scratch. I'm not using TA, so I just use the .key resulting from build-key-pkcs12 myuser, as I've done always.

It works with the Mac client, but not iPhone.

However, doing the same with OpenWRT works fine in both, Mac client and iPhone (iOS 10.2.1).

If I change to TCP, it works in iPhone as well.

Just in case, I've tried with both routers, both MT7821 based.

In all the cases is the same Mac and iPhone client, so definitively is not related to those, or to the configuration file in the server or client or the cellular network.

At the client I can see:

2017-03-20 11:40:43 EVENT: RESOLVE
2017-03-20 11:40:43 Contacting x.x.x.x:1194 via UDP
2017-03-20 11:40:43 EVENT: WAIT
2017-03-20 11:40:43 SetTunnelSocket returned 1
2017-03-20 11:40:43 Connecting to [x.x]:1194 (x.x.x.x) via UDPv4
2017-03-20 11:40:44 NET Internet:ReachableViaWWAN/WR t------
2017-03-20 11:40:53 Server poll timeout, trying next remote entry...
2017-03-20 11:40:53 EVENT: RECONNECTING
2017-03-20 11:40:53 EVENT: RESOLVE

...

At the server I see:

Mon Mar 20 00:30:24 2017 us=189722 MULTI: multi_create_instance called
Mon Mar 20 00:30:24 2017 us=190417 37.10.134.28:62203 Re-using SSL/TLS context
Mon Mar 20 00:30:24 2017 us=190585 37.10.134.28:62203 LZO compression initializing
Mon Mar 20 00:30:24 2017 us=191639 37.10.134.28:62203 Control Channel MTU parms [ L:1622 D:1212 EF:38 EB:0 ET:0 EL:3 ]
Mon Mar 20 00:30:24 2017 us=191941 37.10.134.28:62203 Data Channel MTU parms [ L:1622 D:1450 EF:122 EB:406 ET:0 EL:3 ]
Mon Mar 20 00:30:24 2017 us=192131 37.10.134.28:62203 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Mon Mar 20 00:30:24 2017 us=192272 37.10.134.28:62203 calc_options_string_link_mtu: link-mtu 1622 -> 1542
Mon Mar 20 00:30:24 2017 us=192520 37.10.134.28:62203 crypto_adjust_frame_parameters: Adjusting frame parameters for crypto by 40 bytes
Mon Mar 20 00:30:24 2017 us=192661 37.10.134.28:62203 calc_options_string_link_mtu: link-mtu 1622 -> 1542
Mon Mar 20 00:30:24 2017 us=192864 37.10.134.28:62203 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server'
Mon Mar 20 00:30:24 2017 us=193007 37.10.134.28:62203 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-client'
Mon Mar 20 00:30:24 2017 us=193304 37.10.134.28:62203 UDPv4 READ [14] from [AF_INET]37.10.134.28:62203: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Mon Mar 20 00:30:24 2017 us=193507 37.10.134.28:62203 TLS: Initial packet from [AF_INET]37.10.134.28:62203, sid=b02969a2 20a639ab
Mon Mar 20 00:30:24 2017 us=193765 37.10.134.28:62203 UDPv4 WRITE [26] to [AF_INET]37.10.134.28:62203: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Mon Mar 20 00:30:24 2017 us=968397 37.10.134.28:62203 UDPv4 READ [14] from [AF_INET]37.10.134.28:62203: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Mon Mar 20 00:30:24 2017 us=968989 37.10.134.28:62203 UDPv4 WRITE [22] to [AF_INET]37.10.134.28:62203: P_ACK_V1 kid=0 [ 0 ]
Mon Mar 20 00:30:26 2017 us=8488 37.10.134.28:62203 UDPv4 READ [14] from [AF_INET]37.10.134.28:62203: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 [ ] pid=0 DATA len=0
Mon Mar 20 00:30:26 2017 us=8996 37.10.134.28:62203 UDPv4 WRITE [26] to [AF_INET]37.10.134.28:62203: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] pid=0 DATA len=0
Mon Mar 20 00:30:26 2017 us=968397 37.10.134.28:62203 NOTE: --mute triggered...

Did you ever find a solution here? I have the same problem, only it is both iOS 11 and Android having same problem.

No, only solution seems to be using TCP.

I've confirmed that seems to be some cellular networks blocking UDP, which sounds strange to me, but happens the same in some hotels when using he WiFi ...

I don't think it's cellular companies blocking, as I can tether and OSX has no problem. Really strange. I'll use TCP for the time being.