This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
vpn-server [2023/09/12 18:29] – [OpenVPN Server Notes] -append "and Troubleshooting" hogwild | vpn-server [2023/09/12 19:51] – [TLS renegotiation time] -captialize subhead hogwild | ||
---|---|---|---|
Line 136: | Line 136: | ||
- | ==== TLS Control | + | ==== TLS Control |
(tls-auth/ | (tls-auth/ | ||
Line 179: | Line 179: | ||
In Static Key encryption mode, the HMAC key is included in the key file. In TLS mode, the HMAC key is dynamically generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC, it will drop the packet. HMAC usually adds 16 or 20 bytes per packet. | In Static Key encryption mode, the HMAC key is included in the key file. In TLS mode, the HMAC key is dynamically generated and shared between peers via the TLS control channel. If OpenVPN receives a packet with a bad HMAC, it will drop the packet. HMAC usually adds 16 or 20 bytes per packet. | ||
- | For basic HMAC information, | + | For basic HMAC information, |
- | [[https:// | + | |
==== VPN Subnet/ | ==== VPN Subnet/ | ||
Line 195: | Line 195: | ||
===== Advanced Tab ===== | ===== Advanced Tab ===== | ||
- | \\ | + | |
- | {{: | + | \\ {{: |
- | \\ | + | |
==== Poll Interval ==== | ==== Poll Interval ==== | ||
Line 250: | Line 251: | ||
- | ==== TLS renegotiation time ==== | + | ==== TLS Renegotiation Time ==== |
This specifies how many seconds (//n//) will pass before OpenVPN renegotiates the data channel key (Default=3600). When using dual-factor authentication, | This specifies how many seconds (//n//) will pass before OpenVPN renegotiates the data channel key (Default=3600). When using dual-factor authentication, | ||
This option can be used on both client and server. Whichever host uses the lower value will trigger the renegotiation. It's a common mistake to set this parameter to a higher value on either the client or server, while the other end is still using the default value. In this case, renegotiation will still occur once every 3600 seconds. The solution is to increase// –reneg-sec// | This option can be used on both client and server. Whichever host uses the lower value will trigger the renegotiation. It's a common mistake to set this parameter to a higher value on either the client or server, while the other end is still using the default value. In this case, renegotiation will still occur once every 3600 seconds. The solution is to increase// –reneg-sec// | ||
+ | |||
==== Manage Client-Specific Options ==== | ==== Manage Client-Specific Options ==== | ||
Line 382: | Line 384: | ||
- | ==== A warning | + | ==== A Warning |
A common mistake when setting up a new Certificate Authority is to place all CA files on the OpenVPN server.%% **Avoid doing this**. %%A CA requires a private key to sign the certificates used by clients and servers. If you lose control of the CA private key, you can no longer trust certificates from that CA. Anyone with access to the CA private key can sign new certificates without your knowledge, and clients using those certificates can then connect to your OpenVPN server without modifying anything on the VPN Server. Whenever possible, place your CA files on an //offline// storage medium, only to be activated when you need to get a new certificate for a client or server. | A common mistake when setting up a new Certificate Authority is to place all CA files on the OpenVPN server.%% **Avoid doing this**. %%A CA requires a private key to sign the certificates used by clients and servers. If you lose control of the CA private key, you can no longer trust certificates from that CA. Anyone with access to the CA private key can sign new certificates without your knowledge, and clients using those certificates can then connect to your OpenVPN server without modifying anything on the VPN Server. Whenever possible, place your CA files on an //offline// storage medium, only to be activated when you need to get a new certificate for a client or server. | ||
Line 401: | Line 403: | ||
- | ==== Adding | + | ==== Adding |
Within the CA, you can also revoke certificates as needed. Using your preferred CA management tool, you should be able to generate a Certificate Revocation List (CRL file). Adding this to the OpenVPN server should cause all client certificates to be checked against this revocation list. Clients which have their certificates listed in the CRL will not be able to connect. This is a common way to disable access to a VPN service on a per-user level. | Within the CA, you can also revoke certificates as needed. Using your preferred CA management tool, you should be able to generate a Certificate Revocation List (CRL file). Adding this to the OpenVPN server should cause all client certificates to be checked against this revocation list. Clients which have their certificates listed in the CRL will not be able to connect. This is a common way to disable access to a VPN service on a per-user level. | ||
Line 415: | Line 417: | ||
</ | </ | ||
+ | \\ | ||
- | ===== Routing notes ===== | ||
- | If you want to access particular network resources on other IP addresses via the VPN tunnel, you need to add network routes. A network route tells your operating system where it needs to send the network traffic when you want to access certain resources. An operating system can handle multiple routes via multiple gateways at the same time. So if you have a server on 192.168.1.10 behind your VPN server and you want to access this server via the VPN, you need to tell OpenVPN to configure a route for either a specific host or a network range to go via the tunnel. | + | ==== Routing Notes ==== |
- | So to configure this, you need to add one line in the server configuration and restart server and client. | + | If you want to access particular network resources fromk other IP addresses through the VPN tunnel, you need to add network routes. A route tells your system where it needs to send network traffic in order to access certain resources. An operating system can handle multiple routes via multiple gateways at the same time. So if you have a server on 192.168.1.10 behind your VPN server and you want to access this server via the VPN, you need to tell OpenVPN to configure a route for either a specific host or a network range to go via the tunnel. |
+ | |||
+ | \\ | ||
+ | |||
+ | To configure this, you need to add a line in the server configuration and restart | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 426: | Line 434: | ||
</ | </ | ||
- | When the client now connects, the server tells the VPN client that it should route all traffic for IP addresses in the 192.168.1.XXX scope via the VPN connection. | + | \\ |
- | This is a very basic setup. And when we now start on the routing part, the VPN setup is mostly done. All you need now is to add the needed routes you need, just like you would do for normal TCP/IP routing. | + | Now, when the client connects, the server tells the VPN client that it should route all traffic |
- | **BEWARE**: Remember that you also need to consider what is called " | + | This is an example of a very basic setup. And when we now start on the routing part, the VPN setup is mostly done. All you need now is to add the needed routes |
- | For a more detailed example using routing, see the%% %%Using routing%% %%section in the ' | + | Remember that you also need to consider " |
- | ==== Routing everything over the VPN ==== | + | For a more detailed example of using routing, see the%% %%Using routing%% %%section in the ' |
- | It is possible to route absolutely all network traffic over the VPN. The configuration in OpenVPN is fairly simple. But you will need to investigate how to configure NAT on your VPN server for the virtual tun adapter. | ||
- | You can either push such a "route everything over VPN" via the server, or you can add it explicitly in the client configuration. Do not use both at the same time. | + | ==== Routing all Traffic over the VPN ==== |
+ | |||
+ | It is possible to route all network traffic over the VPN. The OpenVPN configuration for this is fairly simple. However, you'' | ||
+ | |||
+ | You can either push a "route everything over VPN" | ||
+ | |||
+ | \\ | ||
Server push: | Server push: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
push " | push " | ||
</ | </ | ||
+ | |||
+ | \\ | ||
Client configuration alternative: | Client configuration alternative: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 452: | Line 471: | ||
</ | </ | ||
- | ==== What about IPv6? ==== | + | \\ |
- | OpenVPN v2.3 and later supports | + | |
+ | ==== About IPv6 ==== | ||
+ | |||
+ | OpenVPN v2.3 and later support | ||
+ | |||
+ | \\ | ||
For example, adding this will configure the IPv6 addresses for server and clients: | For example, adding this will configure the IPv6 addresses for server and clients: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
server-ipv6 2001: | server-ipv6 2001: | ||
</ | </ | ||
+ | |||
+ | \\ | ||
You can use the // | You can use the // | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 468: | Line 498: | ||
</ | </ | ||
- | ===== OpenVPN Server Notes ===== | + | \\ |
- | There are a few more things which may need to be configured, but those are mostly outside of OpenVPN. The most common issues are related to adjusting your operating system to allow forwarding of packets and configuring the firewall properly. | + | \\ |
- | Configuring a Linux-based firewall can be quite different from configuring one based on other Unix based operating systems. In addition, several Linux distributions have their own tools to manage iptables. Therefore, it is better to read the specific manuals for firewall configuration on your operating system. | ||