content:en_us:7_ug_openvpn
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
content:en_us:7_ug_openvpn [2020/03/25 08:16] 84.9.57.48 |
content:en_us:7_ug_openvpn [2020/04/16 09:34] 84.9.57.48 |
||
|---|---|---|---|
| Line 60: | Line 60: | ||
| Depending on your network configuration, you may need to specify the WINS settings in VPN client configuration. | Depending on your network configuration, you may need to specify the WINS settings in VPN client configuration. | ||
| + | ==== Additional Settings ==== | ||
| + | {{7_openvpn_app_additional_settings.png}} | ||
| + | |||
| + | === Enable NAT === | ||
| + | The Windows firewall often blocks connections (e.g.pings, file shares etc) from outside its own LAN. OpenVPN connections by default appear from 10.8.0.0/24 and will often be blocked but not always (e.g TightVNC creates a global exception in the firewall, not just one for the local LAN). You can adjust the Windows firewall on every machine, or you can enable this rule. With this rule enabled, all OpenVPN connections will appear to come from the ClearOS LAN IP. The advantage of this is that it is easy to set up. The disadvantage is that a LAN machine cannot identify where the connection is coming from. | ||
| + | <note>This setting only affects ClearOS when it is in Gateway mode. When in Standalone mode, connections are NAT'd anyway.</note> | ||
| + | <note>If you previously created a Custom Firewall rule:<code>$IPTABLES -t nat -I POSTROUTING -s your_openvpn_subnet -j MASQUERADE</code>it can now be removed in favour of this option.</note> | ||
| + | === Force All traffic through VPN === | ||
| + | By default OpenVPN allows split tunnelling, so, on the client, only traffic for the ClearOS LAN goes through the tunnel. The rest goes directly to the internet. If this is enabled, all traffic except DHCP (to get a lease from the local DHCP server/router) gets forced through the tunnel. This will slow down browsing on the client but allow you to control internet access with tools like Gateway Management. | ||
| + | === Allow Client to Client traffic === | ||
| + | By default, one OpenVPN client cannot talk to another. Enabling this allows them to connect to each other. This can help, for example, if you are remote to ClearOS and trying to give another remote user help by VNC or RDP. On the flip side, it is a bit less secure. | ||
| + | === Force DNS through VPN === | ||
| + | If you use the same domain name internally and externally, Windows can have problems resolving internal FQDN entries. This is because it fires off DNS lookups simultaneously to all its DNS servers and takes the first response. This will normally be the external DNS servers. Also, if your external DNS server resolves a wildcard to your external IP, all LAN resources will appear as your WAN IP which is not much use. It all depends on the type of reply your external DNS server gives for an unknown resource. Enabling this forces all DNS lookups to ClearOS. This will slow down external lookups if the setting is enabled as they all have to go via the VPN. | ||
| + | <note>There is no point in enabling this if you enable "Force All traffic through VPN" but it won't harm.</note> | ||
| ==== App Policies ==== | ==== App Policies ==== | ||
| Line 73: | Line 87: | ||
| <note warning>With automatic login, the connection is authenticated only by the certificates and at the moment there is no certificate revocation method available.</note> | <note warning>With automatic login, the connection is authenticated only by the certificates and at the moment there is no certificate revocation method available.</note> | ||
| - | |||
| - | === Routing all traffic through OpenVPN === | ||
| - | |||
| - | Add a line: | ||
| - | <code> | ||
| - | push "redirect-gateway def1" | ||
| - | </code> | ||
| - | or | ||
| - | <code> | ||
| - | push "redirect-gateway def1 bypass-dhcp" | ||
| - | </code> | ||
| - | to /etc/openvpn/clients.conf then restart OpenVPN. The second form can get round an issue of the client PC renewing its local LAN DCHP lease. | ||
| === Windows 10 DNS resolution always resolves to an external IP === | === Windows 10 DNS resolution always resolves to an external IP === | ||
| Line 90: | Line 92: | ||
| Windows 10 introduced a horrible feature in its DNS resolution. It queries all DNS resolvers simultaneously and takes the first answer it gets. Invariably this will be from the external DNS servers rather than through the LAN. If you need the names to resolve to a LAN IP you have three choices: | Windows 10 introduced a horrible feature in its DNS resolution. It queries all DNS resolvers simultaneously and takes the first answer it gets. Invariably this will be from the external DNS servers rather than through the LAN. If you need the names to resolve to a LAN IP you have three choices: | ||
| - | 1 - Use the method above to tunnel all traffic trough the VPN\\ | + | 1 - Enable "Force All traffic through VPN" (drastic)\\ |
| - | 2 - Edit the Windows hosts file so all LAN IP's resolve through it\\ | + | 2 - Enable "Force DNS through VPN" (not so drastic)\\ |
| - | 3 - add the line | + | 3 - Edit the Windows hosts file so all LAN IP's resolve through it. |
| - | <code>push "block-outside-dns"</code> | + | |
| - | to /etc/openvpn/clients.conf then restart OpenVPN. This will force **all** DNS traffic through the VPN. | + | |
| === Adding additional subnets to go through the tunnel === | === Adding additional subnets to go through the tunnel === | ||
| - | OpenVPN will normally only give you access to your standard LAN's. If there are other subnets you want access to as well (VLAN's, remote LAN's etc), add the additional subnets to the EXTRALANS parameter in /etc/clearos/network.conf in CIDR form, space separated, then restart OpenVPN. e.g.: | + | OpenVPN will normally only give you access to your standard LAN's. If there are other subnets you want access to as well (HotLAN, DMZ, VLAN's, remote LAN's etc), add the additional subnets to the EXTRALANS parameter in /etc/clearos/network.conf in CIDR form, space separated, then restart OpenVPN. e.g.: |
| <code> | <code> | ||
| EXTRALANS="192.168.25.0/23 172.20.0/24" | EXTRALANS="192.168.25.0/23 172.20.0/24" | ||
| Line 106: | Line 106: | ||
| By default, OpenVPN is configured to use the 10.8.0.0/24 subnet. Each user uses 4 IP's and the server uses 4. I am also not sure if the .252-.255 block is available. This means that the maximum number of users is 62 or 63. If you want to increase this, you need to expand the subnet. It is specified by the "server" line in /etc/openvpn/clients.conf (and /etc/openvpn/clients-tcp.conf). The first parameter **must** be the subnet base address and the second is the subnet mask. If the first parameter is not the base address, OpenVPN will fail to start. Care must be taken with expanding it so you don't overlap with the subnet in /etc/openvpn/clients-tcp.conf. Examples are:<code>server 10.8.0.0 255.255.254.0 # allows 126 or 127 addresses | By default, OpenVPN is configured to use the 10.8.0.0/24 subnet. Each user uses 4 IP's and the server uses 4. I am also not sure if the .252-.255 block is available. This means that the maximum number of users is 62 or 63. If you want to increase this, you need to expand the subnet. It is specified by the "server" line in /etc/openvpn/clients.conf (and /etc/openvpn/clients-tcp.conf). The first parameter **must** be the subnet base address and the second is the subnet mask. If the first parameter is not the base address, OpenVPN will fail to start. Care must be taken with expanding it so you don't overlap with the subnet in /etc/openvpn/clients-tcp.conf. Examples are:<code>server 10.8.0.0 255.255.254.0 # allows 126 or 127 addresses | ||
| server 10.8.0.0 255.255.252.0 # allows 254 or 255 addresses | server 10.8.0.0 255.255.252.0 # allows 254 or 255 addresses | ||
| - | server 10.8.0.0 255.255.248.0 # allows 510 or 511 addresses | ||
| server 10.8.0.0 255.255.248.0 # allows 510 or 511 addresses | server 10.8.0.0 255.255.248.0 # allows 510 or 511 addresses | ||
| server 10.8.0.0 255.255.240.0 # Be careful. You now overlap with /etc/openvpn/clients-tcp.conf so you need to move the subnet there as well</code> | server 10.8.0.0 255.255.240.0 # Be careful. You now overlap with /etc/openvpn/clients-tcp.conf so you need to move the subnet there as well</code> | ||
| Line 127: | Line 126: | ||
| ===== Revoking Certificates ===== | ===== Revoking Certificates ===== | ||
| Currently this is a manual process. Start by initialising the file /etc/pki/CA/crlnumber:<code>echo 1000 > /etc/pki/CA/crlnumber</code> | Currently this is a manual process. Start by initialising the file /etc/pki/CA/crlnumber:<code>echo 1000 > /etc/pki/CA/crlnumber</code> | ||
| - | Create a file in /etc/cron.monthly. I used /etc/cron.monthly/openssl_crl. In it put:<code>openssl ca -gencrl -crldays 45 -config /usr/clearos/apps/certificate_manager/deploy/openssl.cnf \ | + | Create a file in /etc/cron.monthly. I used /etc/cron.monthly/openssl_crl. In it put:<code>openssl ca -gencrl -crldays 45 -config /usr/clearos/apps/certificate_manager/deploy/openssl.cnf -out /etc/pki/CA/crl/crl.pem > /dev/null 2>&1</code>And make the file executable:<code>chmod 0744 /etc/cron.monthly/openssl_crl</code>Then execute the file:<code>/etc/cron.monthly/openssl_crl</code>You should now find you have a file /etc/pki/CA/crl/crl.pem. |
| - | -out /etc/pki/CA/crl/crl.pem \ | + | |
| - | -keyfile /etc/pki/CA/private/ca-key.pem \ | + | |
| - | -cert /etc/pki/CA/ca-cert.pem > /dev/null 2>&1</code>And make the file executable:<code>chmod 0744 /etc/cron.monthly/openssl_crl</code>Then execute the file:<code>/etc/cron.monthly/openssl_crl</code>You should now find you have a file /etc/pki/CA/crl/crl.pem. | + | |
| To revoke a certificate, find the file name in /etc/pki/CA. It should be in the form client-{username}-cert.pem and revoke it and regenerate the crl.pem with:<code>openssl ca -config /usr/clearos/apps/certificate_manager/deploy/openssl.cnf -revoke /etc/pki/CA/client-{username}-cert.pem | To revoke a certificate, find the file name in /etc/pki/CA. It should be in the form client-{username}-cert.pem and revoke it and regenerate the crl.pem with:<code>openssl ca -config /usr/clearos/apps/certificate_manager/deploy/openssl.cnf -revoke /etc/pki/CA/client-{username}-cert.pem | ||
| Line 407: | Line 403: | ||
| <note tip> | <note tip> | ||
| - | If it shows as 'Connected' but authentication fails, you've used an incorrect password. Just reenter the correct password and it should connect correctly.\\ | + | If it shows as 'Connected' but authentication fails, you've used an incorrect password. Just re-enter the correct password and it should connect correctly.\\ |
| If it shows as 'Connected' at this point, you'll know your configuration file was assembled correctly.\\ | If it shows as 'Connected' at this point, you'll know your configuration file was assembled correctly.\\ | ||
| If it doesn't connect, you'll receive an error. You should then recheck your configuration file for errors. | If it doesn't connect, you'll receive an error. You should then recheck your configuration file for errors. | ||
| Line 442: | Line 438: | ||
| <note info>This section is only relevant to OpenVPN in Gateway mode. In standalone mode all OpenVPN packets will appear to come from the ClearOS IP and not the OpenVPN subnet</note> | <note info>This section is only relevant to OpenVPN in Gateway mode. In standalone mode all OpenVPN packets will appear to come from the ClearOS IP and not the OpenVPN subnet</note> | ||
| - | Sometimew you will find you cannot ping a Windows device or connect to it through the tunnel. If this is the case, please check the Windows firewall. In many cases it is set by default to only allow in traffic from the local subnet and the OpenVPN subnet (default 10.8.0.0/24) does not count as local. As an example, in the Windows firewall, look at the "File and Printer Sharing (Echo Request - ICMPv4-In)" rule and its "Scope" tab. You will see it only allows the "Remote IP address" to be "Local subnet" by default. You may need to modify those rules or create a blanket rule to also allow all traffic from the OpenVPN subnet. | + | Sometimes you will find you cannot ping a Windows device or connect to it through the tunnel. If this is the case, please check the Windows firewall. In many cases it is set by default to only allow in traffic from the local subnet and the OpenVPN subnet (default 10.8.0.0/24) does not count as local. As an example, in the Windows firewall, look at the "File and Printer Sharing (Echo Request - ICMPv4-In)" rule and its "Scope" tab. You will see it only allows the "Remote IP address" to be "Local subnet" by default. You may need to modify those rules or create a blanket rule to also allow all traffic from the OpenVPN subnet. |
| It may also be possible to change the settings via Group Policies - see under Local Computer Policy > Computer Configuration > Administrative Templates > Network > Network Connections > Windows Defender Firewall > Standard Profile or Domain Profile depending on your environment. | It may also be possible to change the settings via Group Policies - see under Local Computer Policy > Computer Configuration > Administrative Templates > Network > Network Connections > Windows Defender Firewall > Standard Profile or Domain Profile depending on your environment. | ||
| - | Alternatively you can use the following Custom Firewall rule: | + | Alternatively you can enable the Additional Setting "Enable NAT". See above. |
| - | <code>$IPTABLES -t nat -I POSTROUTING -s your_openvpn_subnet -j MASQUERADE</code>Again, you get the OpenVPN subnet from /etc/openvpn/clients.conf.\\ | + | |
| - | This is easier to implement. The disadvantage of using this rule is that all connections to the Windows machine will appear to come from the ClearOS server and so you will not be able to log which machine is connecting. | + | |
| - | + | ||
| - | As a default example, you will have a line in your /etc/openvpn/clients.conf which reads:<code>server 10.8.0.0 255.255.255.0</code>In that case the firewall rule to add is:<code>$IPTABLES -t nat -I POSTROUTING -s 10.8.0.0/255.255.255.0 -j MASQUERADE</code>or:<code>$IPTABLES -t nat -I POSTROUTING -s 10.8.0.0/24 -j MASQUERADE</code>The two rules are equivalent. Obviously, if you have changed your subnet in /etc/openvpn/clients.conf, you will need to adjust your firewall rule. | + | |
| - | + | ||
| - | <note info>You normally do not need the a rule for the tcp subnet in /etc/openvpn/clients-tcp.conf as the tcp connection is not used. It won't, however, harm anything if you do add one.</note> | + | |
| ===== Multi-WAN Environments ===== | ===== Multi-WAN Environments ===== | ||
| Line 463: | Line 453: | ||
| ===== DNS ===== | ===== DNS ===== | ||
| - | If you are having issues with DNS on your OpenVPN connection, it can be that you are using an external DNS server to resolve internal hosts or an internal which doesn't resolve external hosts. If you use the ClearOS gateway to resolve the DNS from its cache, you can [[content:en_us:kb_o_splitting_dns_cache_to_use_specific_dns_server_for_domains|split the resolution of external and internal domains using this guide]]. | + | If you are having issues with DNS on your OpenVPN connection, it can be that you are using an external DNS server to resolve internal hosts or an internal DNS server which doesn't resolve external hosts. If you use the ClearOS gateway to resolve the DNS from its cache, you can [[content:en_us:kb_o_splitting_dns_cache_to_use_specific_dns_server_for_domains|split the resolution of external and internal domains using this guide]]. |
| ===== VPN connects but no traffic passes ===== | ===== VPN connects but no traffic passes ===== | ||
content/en_us/7_ug_openvpn.txt · Last modified: 2021/03/31 10:14 by 84.9.57.48