Difference between revisions of "OpenVPN/FAQ"

m(/* I've got the duplicate-cn parameter enabled, and have copied the config/ directory to another machine, but that other machine is unable to connect to the server (the first one connects successfully)

If you setup a configuration like the one used in http://openvpn.net/howto.html#policy, but with default iptables rules for INPUT/FORDWARD/OUTPUT (that should be the case in a production environment anyway :)) set to DROP, traffic won't be forwarded correctly.

+

There has also need to be a FORWARD-ACCEPT rule on your interface that belongs to the local network so the taffic sent from tun->eth can also get back from eth->tun.

I've got the duplicate-cn parameter enabled, and have copied the config/ directory to another machine, but that other machine is unable to connect to the server (the first one connects successfully). Am I correct in my understanding that the duplicate-cn parameter allows for this?

Yes, that is the correct understanding. However, note the answer: Client machine has ZoneAlarm on both computers, and only one of them was exhibiting this problem. Shutting down ZoneAlarm resulted in OpenVPN functioning correctly immediately.
Please note that using duplicate-cn is not recommended, and only exists for testing purposes; instead of using it you should just create more certificates.

There is a file, client.csr, generated by easy-rsa with the build-key command that is not referred to in the howto. What is this file for and what do I do with it?

This is a "certificate signing request." Easy-RSA self-signs your certificates with a local Certificate Authority (CA), so in typical cases you don't need this file. However, if you use an external CA, you can take the .csr and hand it to the CA, and they will hand you back the signed .crt certificate. This can usually be done over a cleartext channel, but care must be taken to ensure that the CSR does not change en route. You may confirm fingerprints by calling the CA's administrator or contacting them directly somehow.

The howto says to use client-config-dir and ifconfig-push if you want to restrict your users to specific IP on the VPN, but it's a major security flaw: once the server pushes you an IP you can manually change it with ifconfig. How can I be sure that the client is using the pushed IP?

If you are using a TUN interface, changing your IP with ifconfig removes your ability to ping the VPN server. While using TAP, users can change their IP and still keep the connection to the VPN server. This behavior has been tested and confirmed. Choose your VPN setup accordingly.

This means that OpenVPN can't read the file it's looking for (in this case, cert.crt). This is most often because you specified only a relative path to the certificate or keyfile instead of an absolute path in your configuration files. Make sure the complete paths to the keys and certificates are defined.

If I'm generating a client key set and don't know the hostname, can I leave this value blank when using easy-rsa?

No. This doesn't necessarily have to be your hostname, but it must be a unique identifier for that key set. It will be used to identify the machine that owns that key set when it logs onto the VPN, and comes in handy for client-config-dir setups.

How do I route public IPs to my VPN clients without using NATD?

It is easier if you have two subnets assigned by your upstream provider. You would set one subnet that your openvpn can use for listening. The other subnet would need to be routed to your server and your server would be acting as the router. inet.net.forwarding should be enabled on FreeBSD (/proc/sys/net/ipv4/ip_forward should be 1 on Linux) and then OpenVPN should use its own routing tables. Just set the configuration like it is an internal.

I installed OpenVPN 2.0.9 on an XP machine this morning (Freshly installed as of last night). When I tried to run OpenVPN.exe it crashes immedietally with "The application failed to initialize properly (0xc000007b).". I tried upgrading to 2.1_rc7, I've rebooted uninstalled/reinstalled several times... No Joy.

"Embassy Security Center" was the culprit.

Why do i get an 'unable to get certificate crl' when running revoke-full?

Traffic forwarding doesn't work when using client specific access rules

If you setup a configuration like the one used in http://openvpn.net/howto.html#policy, but with default iptables rules for INPUT/FORDWARD/OUTPUT (that should be the case in a production environment anyway :)) set to DROP, traffic won't be forwarded correctly.
There has also need to be a FORWARD-ACCEPT rule on your interface that belongs to the local network so the taffic sent from tun->eth can also get back from eth->tun.