Are there any known security vulnerabilities with OpenVPN?
Not to our knowledge (as of 2004.12.08). The current OpenVPN security model matured by version 1.1.0, which was released in 4/2002. Since that time, there have been no confirmed reports on the OpenVPN lists or other security-related forums claiming any security vulnerabilities due to bugs in the software.
Having said that, there is always the potential for security vulnerabilities to be introduced by incorrect configurations. One such vulnerability is discussed here.
While OpenVPN has not as yet been subjected to a comprehensive security review, so far the security model has stood up well to analysis. In 9/2003, cryptography expert Peter Gutmann looked at the field of open source VPNs with a critical eye, and OpenVPN was singled out for some positive remarks.
OpenVPN's security model can be summarized as such: Use the IPSec ESP protocol for tunnel packet security, but then drop IKE in favor of SSL/TLS for session authentication. This allows for a lightweight, portable VPN implementation that draws on IPSec's strengths, without introducing the complexity of IKE.
See the article OpenVPN and the SSL VPN Revolution (PDF), by Charlie Hosner, for a more in-depth look at OpenVPN from a security perspective.
While it's impossible to assure with certainty that no weaknesses exist, OpenVPN has multiple levels of security to protect against a single flaw causing a catastrophic security breach. For example, by using --user nobody --group nobody you can ensure that even if some kind of remote buffer overflow exploit were discovered, the exploit would be unable to elevate its privilege to root. Another example is using SSL/TLS security with --tls-auth. Using --tls-auth ensures that even if a remote buffer overflow is discovered and exploited in the SSL/TLS authentication code in the OpenSSL library, it could not be used to attack an OpenVPN session that is protected with a --tls-authpassword. In addition, if you use SSL/TLS authentication, you have the benefit of "perfect forward secrecy".