Special settings for connection from China?

kitschen

Dear all

My OpenVPN server is located in Europe. Client connections from Europe work.

Now I have clients connecting from China and I get in my server log:
Fri Jul 18 09:38:57 2014 59.57.xxx.xxx:2176 TLS: Initial packet from [AF_INET]59.57.xxx.xxx:2176, sid=4179487a 8789acf0
Fri Jul 18 09:39:57 2014 59.57.xxx.xxx:2176 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

I have seen the FAQ http://openvpn.net/index.php/open-source/faq/79-client/253-tls-error-tls-key-negotiation-failed-to-occur-within-60-seconds-check-your-network-connectivity.html which basically says:
1. is there a server firewall?
2. is there a badly configured NAT gateway?
3. does the client have the correct "remote" directive
4. has the client a firewall which must be open

In my case I believe
- as I see the machine trying to connect in the server logs, this basically excludes the first 3 reasons (right?). If there was a firewall or a basic misconfigration, no message at all would reach the OpenVPN server (right?)
- as it is working from europe, this basically excludes all above reasons (right ?)

This brings me to conclude, that some firewall mechanism may be active from China (or on the server, but targeted at China only). Have you experienced similar connection problems from China?

Can you recommend how to analyze this problem?

Regards Philipp

kitschen

Here is the repeating part of the log.

Fri Jul 18 10:41:12 2014 MULTI: multi_create_instance called
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Re-using SSL/TLS context
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 LZO compression initialized
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Control Channel MTU parms [ L:1562 D:138 EF:38 EB:0 ET:0 EL:0 ]
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Local Options hash (VER=V4): 'e11a9f86'
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 Expected Remote Options hash (VER=V4): '0c7fabe0'
Fri Jul 18 10:41:12 2014 59.57.xxx.xxx:2218 TLS: Initial packet from [AF_INET]59.57.xxx.xxx:2218, sid=67d08100 4f858f30
Fri Jul 18 10:42:12 2014 59.57.xxx.xxx:2218 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Fri Jul 18 10:42:12 2014 59.57.xxx.xxx:2218 TLS Error: TLS handshake failed
Fri Jul 18 10:42:12 2014 59.57.xxx.xxx:2218 SIGUSR1[soft,tls-error] received, client-instance restarting

I also get some

Fri Jul 18 10:36:37 2014 read UDPv4 [ECONNREFUSED]: Connection refused (code=111)
Fri Jul 18 10:36:39 2014 read UDPv4 [ECONNREFUSED|ECONNREFUSED]: Connection refused (code=111)
Fri Jul 18 10:37:23 2014 read UDPv4 [EHOSTUNREACH|EHOSTUNREACH]: No route to host (code=113)

Server config:

port 1193
proto udp
dev tun
ca h2-keys/ca.crt
cert h2-keys/server.crt
key h2-keys/server.key # This file should be kept secret
dh h2-keys/dh.pem
server 10.24.0.0 255.255.0.0
ifconfig-pool-linear
ifconfig-pool-persist h2-ipp.txt
keepalive 10 120
cipher AES-128-CBC # AES
comp-lzo
user daemon
group daemon
persist-key
persist-tun
status h2-openvpn-status.log
log-append /var/log/h2-openvpn.log
verb 3
management localhost 7506
fragment 1300
mssfix

Client config

log-append /var/log/openvpn.log
client
dev tun
proto udp
remote myserver.mycompany.com 1193
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client.crt
key /etc/openvpn/keys/client.key
remote-cert-tls server
cipher AES-128-CBC
comp-lzo
verb 3
script-security 2
up /etc/openvpn/up.sh
down /etc/openvpn/down.sh
fragment 1300

Server version: 2.1.0
Client version: 2.1.3

kitschen

Sure - I know about the great firewall.

I expected OpenVPN (encrypted) to be immune against this.
Is there a current status on how OpenVPN works from China?

My connection should be really short and need only to download a file of a few bytes to confirm that a connection has taken place.

Regards