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.
Why does my server log have MULTI errors? They look like this: MULTI: bad source address from client [LAN_IP], packet dropped. Also, "What is iroute?"
An OpenVPN server has an internal routing table, as controlled by iroute.
[11:56] <vpnHelper> krzee: "iroute" is does not bypass or alter the kernel's routing table, it allows openvpn to know it should handle the routing when the kernel points to it but the network is not one that openvpn knows about. This is only needed when connecting a LAN which is behind a client, and therefor belongs in a ccd entry.
This is so the OpenVPN server can have clients with LANs (foreign subnets) behind it, otherwise it wouldn't know what LAN is behind what client. MULTI errors happen when packets come from a foreign subnet that is not in the internal routing table. The OpenVPN server doesn't know what it's supposed to do with those packets, so it gives the MULTI error.
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 with default topology (default is net30, if you change to topology subnet this is not true). 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. 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?
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 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.
a example config would look like this:
Networks: <pre>Whole Network: 192.168.0.0/16 VPN Employees: 192.168.110.0/24 VPN Admins: 192.168.111.0/24 VPN Extern Users: 192.168.120.0/24 Server-Networks: 192.168.100.16/28,
Setup-Script (really simplyfied) <pre>#!/bin/bash
- 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 192.168.111.0/24 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i tun0 -s 192.168.110.0/24 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i tun0 -s 192.168.110.0/24 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i tun0 -s 192.168.120.0/24 -d 192.168.0.0/16 -j ACCEPT iptables -A FORWARD -i tun0 -s 192.168.120.0/24 -d 192.168.0.0/16 -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</pre>
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?
This is a problem with the reverse path filter; it is a check to see if, for a packet arriving on an interface, a packet sent to the original packet's source address would be sent out on that interface; if not, the arriving packet is dropped. it can be considered an attempt at detecting packets with spoofed source addresses.
Fix this with: <pre>echo 1 > /proc/sys/net/ipv4/conf/br0/rp_filter</pre>
- Note: This may be a red herring. It seemed to help user belZe in ##openvpn on freenode, but upon fresh install, it doesn't help anymore. I'm leaving it up incase it does help someone.