openvpn Connection Timeout (not sure where) tunnel bytes 0

[ritzt3ch]

not sure exactly where it fails but I tried 2 different methods (taking all 5 files needed) But that didnt work then i consolidated all the crt/ca/key/tls-auth files into <ca> </ca> etc etc


this setup has been working for 4 years and when i finally saw openvpn on the app market i was like OOHHHHH YEA

tunnelblick works / windows / etc etc

heres my snapshot for the .ovpn (under the hood do you see anything wrong?) (its 2 versions in 1 i just tried the other way to contain it all)

client
dev tun
proto udp
remote vpn.remote.net 1194
resolv-retry infinite
nobind
persist-key
persist-tun
;ca vpn-user-ca.crt
;cert vpn-user-client.crt
;key vpn-user-client.key
;tls-auth vpn-user-ta.key 1
comp-lzo
verb 4
explicit-exit-notify
auth-user-pass


<ca>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
-----END PRIVATE KEY-----
</key>
<tls-auth>
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----
</tls-auth>






Heres the output as it just sits there

2013-03-30 22:21:35 ----- OpenVPN Start -----
2013-03-30 22:21:35 LZO-ASYM init swap=0 asym=0
2013-03-30 22:21:35 EVENT: RESOLVE
2013-03-30 22:21:36 EVENT: WAIT
2013-03-30 22:21:36 Connecting to vpn.remote.net:1194 (64.11.22.44) via UDPv4
2013-03-30 22:21:36 EVENT: CONNECTING
2013-03-30 22:21:36 Tunnel Options:V4,dev-type tun,link-mtu 1542,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client
2013-03-30 22:21:36 Peer Info:
IV_VER=1.0
IV_PLAT=ios
IV_NCP=1
IV_LZO=1


2013-03-30 22:21:36 VERIFY OK: depth=1
cert. version : 3
serial number : A4:64:BB:4D:C5:6A:2D:6B
issuer name :
subject name :
issued on : 2008-04-14 23:42:58
expires on : 2018-04-12 23:42:58
signed using : RSA+SHA1
RSA key size : 2048 bits

2013-03-30 22:22:05 EVENT: CONNECTION_TIMEOUT [ERR]
2013-03-30 22:22:05 EVENT: DISCONNECTED
2013-03-30 22:22:05 Raw stats on disconnect:
BYTES_IN : 5130
BYTES_OUT : 23520
PACKETS_IN : 39
PACKETS_OUT : 54
CONNECTION_TIMEOUT : 1
2013-03-30 22:22:05 Performance stats on disconnect:
CPU usage (microseconds): 746747
Network bytes per CPU second: 38366
Tunnel bytes per CPU second: 0
2013-03-30 22:22:05 ----- OpenVPN Stop -----
2013-03-30 22:22:05 EVENT: DISCONNECT_PENDING

[ritzt3ch]

Hmmmmm must be a bug cause i was able to get it to work with android with that (but not openvpn android client) but called openvpn for android

https://play.google.com/store/apps/deta ... GVudnBuIl0.


Unless theres something that checks and fails. I even tried installing the certs but no go

[ritzt3ch]

Veeeeeery weird so i found sort of the issue and not sure what stops ill have to run a tcpdump/packet capture on the andriod somehow to see where it fails.

But where it was just stuck on connection timeout (i was all weekend in AZ with no internet except for my Verizon LTE tether to my galaxy s3) other issue maybe openvpn has a more latency timeout on the IOS

im now home and the OPENVPN connection still fails but went farther . it authenticated and finally started the SSL handshake and Sesion active and pulling routes but where it now fails is here.

Client exception in transport_recv: proccess_server_push_error : Problem accepting server-pushed parameter: option_error: more than one instance of option 'ping'

[ritzt3ch]

might open another thread but this is really now option issues.

the server has it showing when the options come through. (ive used 4 differnt openvpn client types ) android / mac (tunnel blick) verisoity) / windows all with no issues is there an extra option i can use to not stop at because theres w ping options from the server


17 [route] [172.27.0.0] [255.255.0.0]
18 [dhcp-option] [DOMAIN] [.site]
19 [dhcp-option] [DNS] [10.42.160.5]
20 [dhcp-option] [DNS] [10.42.168.5]
21 [ping] [10]
22 [ping-restart] [60]
23 [route-gateway] [172.27.8.1]
24 [topology] [subnet]
25 [ping] [10]
26 [ping-restart] [60]
27 [ifconfig] [172.27.8.134] [255.255.254.0]




Client exception in transport_recv: proccess_server_push_error : Problem accepting server-pushed parameter: option_error: more than one instance of option 'ping'

[shadoweyez]

Did you ever get this to work?

I'm having almost the exact same problem with my iPad2, and the server config I'm using works with windows, linux and mac/tunnel-blick clients.

client config:
remote <server> 443
client
push "redirect-gateway"
remote-cert-tls server
comp-lzo
verb 4
dev tun0
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
float
;ca vpn-user-ca.crt
;cert vpn-user-client.crt
;key vpn-user-client.key

[ritzt3ch]

they said to submit a bug tkt for this.... but I don't have an elevated account this

[shadoweyez]

Ritz;

I have a similar problem, and I regenerated all keys (the private CA, server keys, client keys, and DH params) and instead of using 4096 bit keys, I used 1024 bit keys, and OpenVPN connect on my Ipad with the DD-WRT server worked FLAWLESSLY. I did not change ANY settings on either the client or the server, just new keys, and it worked.

This is also a config that works on my linux laptop (using 'real' openvpn) and I would assume windows though i have not tried it yet.

Given this config (less the key size issue) only does NOT work when connecting openVPN on iOS to DD-WRT, the bug seems to be an application level issue with openVPN on iOS, or possibly a bug in the DD-WRT server.

I noticed you were using 2048-bit keys. For thoroughness/testing sake, trying using 1024-bit keys on your config and see if it works.
*** For security sake - I would NOT recommend 1024-bit keys anymore on a production system. They can be brute-forced within a reasonable timeframe in this day and age. ***

This seems to represent a bug in iOS openVPN, one which I would like to have corrected.

[ritzt3ch]

Yea unfortunately i cant go to my server config at all as its about 10k employees but i did find out theres a new release about to hit apple store within the next week or so so i hope they ironed out this bug .


But not sure if you having the problem as more then one option as its quite strict.

21 [ping] [10]
22 [ping-restart] [60]
23 [route-gateway] [172.27.8.1]
24 [topology] [subnet]
25 [ping] [10]
26 [ping-restart] [60]
27 [ifconfig] [172.27.8.134] [255.255.254.0]




Client exception in transport_recv: proccess_server_push_error : Problem accepting server-pushed parameter: option_error: more than one instance of option 'ping'

[xsited]

I am using OpenVPN 1.0.1 build 88 (iOS) and have a similar configuration and behavior as ritzt3ch only not working with mention version on ipad2.

Attaching to this thread while working on the issue in case there is an update.

Thx

[jamesyonan]

There is an issue with OpenVPN Connect 1.0.0 and 1.0.1 on iOS where if duplicate options are pushed by the server, you may get an error such as this:

Client exception in transport_recv: proccess_server_push_error : Problem accepting server-pushed parameter: option_error: more than one instance of option 'ping'

The upcoming 1.0.2 build should fix this. If you have an Android device, you can test it now using the newly released OpenVPN Connect 1.1.12 for Android which fixes the issue of crashing when duplicate options are present.

James