The mechanics of provisioning forward secrecy within OpenVPN are nontrivial.
OpenVPN doesn't use any ciphers itself. Rather, it replies on the available OpenSSL (or, less commonly, PolarSSL) suites. OpenVPN defaults to certain ciphers unless it is told explicitly to use others (and only if those others are supported by the OpenSSL framework on the machine it calls home - as well as client-side, of course). IPsec can use just about any cipher out there, but it's hideously complex to implement (we now have strong evidence this complexity was intentionally encouraged by NSA "plants" during the lengthy standards review process).
Unfortunately, Yonan has touted "perfect forward secrecy" as an intrinsic attribute of OpenVPN itself and that's not perhaps a clearcut statement. Yes, default is for (control channel) session re-keying every hour... but defaults also enable massive overlap of earlier keys during this process. Indeed, in many real-world implementations the "overlap" period is longer than the rekey duration itself! That's not PFS, obviously. It's... something rather odd.
Then there's TLS session management itself which - as numerous cryptography researchers have repeatedly reminded the rest of us - can and will break all attempts at PFS if not adjusted in production settings. If there's a "VPN service" that has done so, they've managed to keep that expertise very, very secret - which suggests otherwise.
In the OpenVPN security model, there's also the intial TLS session created to "bootstrap" the control channel instantiation itself... and that early session relies on the "shared keys" which are part of the default configuration of the package. Those keys (both public and private), and their corresponding certificates, are so badly mismanaged by so many "VPN companies" as to be almost a form of satire. Unfortunately, those keys are the essential core of the integrity of the initial TLS "bootstrap" session itself - if the asymmetric handshake underlying that early session is implemented inaccurately due to sloppy production engineering decisions (or just total misunderstandings of public key/asymmetric cryptographic primitives on the part of nearly every "VPN company" selling service), then the roll-forward control-channel TLS session is functionally plaintext - whatever cipher suites are used.
Think of it this way: if I call you on the phone and start talking to you, but we agree to hang up every 20 minutes and call each other on entirely new phone lines... this should help keep us secure, right? Well, if someone's eavesdropping on that original call, they can just listen for the numbers we're going to use for the next 20 minutes, then listen in on that call, then roll to the next call, and so on. Thus does "perfect" forward secrecy break.
With a broken bootstrap session, then all the ephemeral whiz-bangery of future key cycling is useless: the whole thing is broken.
Which, in turn requires good selection of nonces, IVs, HMAC methodology, and other routine crypto engineering issues to ensure that initial bootstrap isn't weak. OpenVPN does none of this right by default - it can do it, but it need proper setup. Which includes compiling with custom flags, and manual editing of source to ensure correct integration with current OpenSSL libraries.
None of this is rocket science - but how many "VPN companies" out there bragging about "100% protection" have the slightest idea how to do this, and not screw it up when trying? Use one hand to count, you'll have most all fingers left when done.
Also, regarding discussions of DHE/ECDHE, they're not hard to find when it comes to serious network security providers: viewtopic.php?f=32&t=3443