Something is killing my OpenVPN Connection

I've always used OpenVPN-AS, never had any issues. Perhaps the PRC is interfering with Port 1194 that is for standard installations? Try changing it to 443 (TLS), no one would dare block that…

PPTP is dangerous! Unstable, unencrypted (weak)… Beware!

If you're just using it for web browsing, an SSH tunnel might be easier to set up. Just connect to ssh with the -D flag, and set your web browser to use the local port as a socks proxy.

@ComplexMind -

Thanks for the heads up on OpenVPN-AS. I wish I had gone with this initially. I have configured it to use PAM as login - does it still require keys for the client? I generated keys for regular openVPN but they don't seem to work (I get the login / pass) but cannot proceed further.

I tried to download the ovpn file from the web interface and that gave me a : Options error: Unrecognized option or missing parameter(s) in config.conf:25: key-direction (2.0.9)

@hybinet

Thanks for the recommendation. Yes, that works fine for web browsing- but it doesn't allow HULU streaming.

Still would like to get OpenVPN working if possible. I feel like I'm close!!!!

I've had similar problems, try playing with the fragment and/or mssfix options to see if your hitting MTU / fragmentation issues.

I've never run OpenVPN but I'd say Complex Mind's suggestion makes sense, try running the server on port 443 the HTTPS port. Maybe pay for the second IP in case you need 443 for a real HTTPS server on your main IP.

Thanks guys. I tried 443. Was a tad better but same problem - VPN became unusable within minutes. Strange that PPTP works perfectly but openVPN does not.

@thebai:

Thanks guys. I tried 443. Was a tad better but same problem - VPN became unusable within minutes. Strange that PPTP works perfectly but openVPN does not.
Well, they're two totally different ways of tunneling, not to mention distinct software, so while they can share some failure modes, I'm sure there are plenty that aren't common.

I'd agree with a prior suggestion to try the mssfix or fragment options to try to protect against MTU issues along the path. And for testing, I'd start by being aggressive (like keep packet sizes below 512 or something) only worrying about larger sizes for performance once things seem stable.

You could also try switching the OpenVPN connection to use TCP rather than UDP, as it may be more resilient to the particular path being used and/or friendlier to devices in the middle that may not like seeing a UDP stream. (And it's possible those devices are treating GRE tunnel traffic differently)

I guess if nothing else works, bump up debugging in the OpenVPN configuration on both ends and see if it notes anything interesting. If it seems to be missing traffic, you could also run a tcpdump on the relevant interfaces to see if you can deduce if the problem is on the sending or receiving end (the latter probably pointing to an issue in the middle).

It might also be worth testing from a different client if to date you've only tried the single client on your Mac, just in case it's something about how the client ties into the networking subsystem on your Mac. I use Tunnelblick myself, so that might be worth giving a shot if the Mac is the only client platform you have access to.

It certainly should be solvable - I know I'm using OpenVPN connections to Linodes without any major issues.

– David

Thanks for the help everyone. I have good news to report.

I played with MTU settings as advised - namely tun-mtu, fragment, and mssfix. I used mtu-test on the client and determined that the MTU size is 997.

Using this, I tried the settings (using UDP)

tun-mtu 1500

fragment 1000

mssfix

and I'm happy to report that the connection is stable, and fairly fast. Not as fast as the PPTP VPN, but not bad (about 2/3 the speed by unscientific and subjective measures)

lowering tun-mtu or using TCP had a direct impact on the speed, and using the combination of fragment and tun-mtu seems to have yielded the desired results.

I will keep playing around with the settings to see if I can improve the speed, and report back in the event anyone else runs into this problem.

update:

keeping tun-mtu at 1500 (changing this affects speed), and continuing with my tweak of fragment size:

fragment 1200 (caused the same problems - likely because it exceeds the recommended mtu-test MTU suze)

fragment 900 works really well. So far, no dropped connections.

I did notice that on the load of a long page (say a flickr gallery with a lot of thumbnails, it gets slower at the end).

But overall, very happy with the improvement, thanks to the valuable advice from everyone here.

@thebai:

and I'm happy to report that the connection is stable, and fairly fast. Not as fast as the PPTP VPN, but not bad (about 2/3 the speed by unscientific and subjective measures)
First, glad you were able to get stability.

It may or may not make a difference, but if comparing performance with PPTP, you should check if your particular setup is encrypting the data tunnel - as encryption does add some overhead. If not, then OpenVPN may suffer by comparison as is it encrypting by default. Alternatively, independent of PPTP, if it's not critical to you, you could try disabling encryption with OpenVPN (cipher none) and see if that gives any additional performance boost.

– David

Considering where he is, I'd say encryption is quite desired…

Try setting MTU to 576. See if that helps. :-)

![](http://www.it.ubc.ca/__shared/assets/tr … up4308.gif">http://www.it.ubc.ca/_shared/assets/trumpetwinsock3setup4308.gif" />

@hoopycat: did you mean tun-mtu or link-mtu? I found that if I set them too low, the connection speed decreases.

I was mostly joking; back in the dialup days, an MTU of 576 was often used to improve interactive response, since large packets would tie up the serial link for a noticeably long time. In your situation, go with whatever works, since something in the middle has failed if the default mechanisms aren't working.

(Why 576? Per RFC 791 section 3.2:
> Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled.
)

Hi guys,

i'm jumping pretty late in the conversation but I'm setting up an openvpn connection between my OsX here in China and a server back in europe.

I've got a very similar situation, an I'm wondering if someone could enlighten me on what's possible to control by the great Chinese Firewall and what's not.

I've been using ssh tunnel for a long time without problem. Youtube would work with much difficulties but overall it was enough for me.

This recently stopped working, I now can't connect to anything and get the following traces in my term:

channel 2: open failed: administratively prohibited: open failed

…

it goes on with the channel number increasing limitlessly it seems…

To me that's clearly an limit from the CFW. It used to work weel, it doesn't at all anymore.

Any idea how they could do that?

Since this won't work anymore (I haven't tried form any other location yet though), I've setup an openvpn tunnel.

First attempt after fresh default install was very successful, I could access everything - except youtube and few others, haven't really understood why.

Since that first day, I can establish the tunnel but it won't get me any connection. Name resolution works but i can't trace route, I simply can't connect to anything except the openvpn server machine itself.

It also really look like a blockade from a CFW, isn't it?

I'm gonna try to play with the MTU as indicated in your posts.

But same question again, how can they block such a connection?

I was on regular TCP 1194, tried on udp 65000 without success.

Would Ipsec kind of tunneling work better?

cheers

TCP + OpenVPN == bad. You get two levels of congestion management fighting against each other, two levels of delivery reliability fighting each other, etc. OpenVPN works best over UDP, since that lets the tunneled protocol (usually TCP) worry about congestion management and reliability.

@Complex Mind:

I've always used OpenVPN-AS, never had any issues.
I just tried installing OpenVPN-AS on Ubuntu 8.04 on my linode, but it can't configure iptables and therefore fails to start. What is your configuration?

When I installed OpenVPN-as on Ubuntu 8.04 on my linode, I didn't run into any iptables issues. Then again, I don't think I have any iptables rules either.