baobo5625
I have a issue with my OPENVPN servers setup.
I have several servers across in China (Set A) and severals in the U.S. (Set B)
Set A servers and Set B servers are interconnected using openvpn. (They all have server/client ends)
it runs good at the beginning, but after several days (about 6~7 days, the connection is alive all the time in the period), they are not be able to connect each other due to TLS handshake failure.
The strangest is the following two points:
1. The servers within Set A/B are able to connect to each other, but not able to cross the boarder.
2. When I change the server side local binding port, they are able to make connection right away.
ping and traceroute results are good
I made the tcpdump inspection. I saw the tcl packet was sent from the server side, but the client side was not able to receive it. (didn't see the packet coming in on the client side through tcpdump)
Btw, one of the server ser are running inside Citrix Xenserver and in the same ip subnet, but I made the tcpdump on the xenserver as well, same result.
Anyone can help?
baobo5625
forgot to mention that they all running under Centos 6.2
gigiskhan
Hi Baobo,
I face exactly the same situation.
I have several openvpn Clients in China and 3 servers in Europe.
Since mi November, I could see that from time to time, the client had problems reaching my servers.
When I Bind my servers to a different UDP port, It works for a few days / hours but then.
The client can send tcl Packet, but never receive it from the server.
It seems that the great firewall is restricting the use of OpenVPN from China.
If anyone finds a solution,I would be very glad to know about it.
I have asked my Embassy (France) to know if there would be a solution to allow VPN connection by declaring my VPN server to the Chinese authorities, but till now did not get any answer.
Please someone help us.
Gigiskhan
senseless
Recently started having the same issue myself about a month ago.
It seems to be automated on their part. There is probably some identifying piece of information in the SSL connection that allows them to determine if it's a normal SSL HTTPS connection or an OpenVPN connection.
I ran OpenVPN with TCP only on 443 for a long time with no problems. Around november all clients from china are no longer able to download new profiles or connect to the servers (I'm using Access Server). I had UDP connections disabled, I enabled them and they were live for about 48 hours before being banned. I tried changing ports once more, and again it took about 48 hours for it to become blocked.
These are not the standard DNS blocks that they have employed in the past. Before they would obfuscate a banned URL (lets say facebook) so facebook's URL would resolve to a bad ip. But if you connect directly to the face book ip the page still loaded fine. With this they are not changing the DNS but just outright blocking the connection to that ip on that port. They don't block connectivity to the IP completely, just to the OpenVPN ports.
Definitely something new, and automated. Perhaps someone more advanced with packet inspection than me can go through and compare
SSL packets to OpenVPN packets to see how they're able to detect the difference. They might not even be looking at the packets, they could just be logging all SSL connections to test them later, but that wouldn't explain the UDP problems.
Interestingly, L2TP connections still work fine.
