From Secure Computing Wiki
Revision as of 08:58, 25 March 2009 by Ecrist (talk | contribs)
Jump to navigation Jump to search


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.

I see this in my logs and it seems to be the reason my OpenVPN doesn't work: Tue 07/01/08 11:19 AM: Cannot load certificate file cert.crt: error:02001002:system library:fopen:No such file or directory: error:20074002:BIO routines:FILE_CTRL:system lib: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib

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. 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?

Please look at this OpenVPN-Users mailing list post. There is an issue with the easy-rsa "revoke-full" script. (July 07, 2008 2.1_rc7)

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

If you setup a configuration like the one used in, 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.

a example config would look like this:


Whole Network:
VPN Employees:
VPN Admins:
VPN Extern Users:

Setup-Script (really simplyfied)

# set default policys to drop
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

# access policys for traffic from vpn to the local network
iptables -A FORWARD -i tun0 -s -d -j ACCEPT
iptables -A FORWARD -i tun0 -s -d -j ACCEPT
iptables -A FORWARD -i tun0 -s -d -j ACCEPT
iptables -A FORWARD -i tun0 -s -d -j ACCEPT
iptables -A FORWARD -i tun0 -s -d -j ACCEPT

# simplified, if you are paranoid (what you should be) just let through the traffic from tun0 to eth0 in reverse.
# a better solution would be to do stateful filtering here, 
# but i haven't found a quick way to do stateful filtering over more than one interfaces
# traffic replied 
iptables -A FORWARD -i eth0 -j ACCEPT

# simplified, in real environments just enabled wanted services 
# traffic to/from openvpn server
iptables -A INPUT tun0 -j ACCEPT
iptables -A OUTPUT tun0 -j ACCEPT

# simplified, in real environments just enabled wanted services 
# traffic to/from local network
iptables -A INPUT eth0 -j ACCEPT
iptables -A OUTPUT eth0 -j ACCEPT

traffic can now go from tun0->eth0 and back without problems :)

(Mario dot Steinhoff at catapullt dot de, OpenVPN 2.0.9 on debian etch, Oct 7, 2008)

I'm getting the following error: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology

This error means that you're connecting to an OpenVPN server running 2.1 with the --topology option, from a client, probably 2.0.9 or earlier, which does not support that option.

I seem to be having problems with ARP requests reaching the VPN from my server's LAN. How do I fix this?

echo 1 > /proc/sys/net/ipv4/conf/br0/rp_filter