Site Tools


vpn-server

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
vpn-server [2023/09/12 18:30] – [OpenVPN Server Notes] -delete obsolete section hogwildvpn-server [2024/04/11 00:50] (current) – [Adding Certificate Revocation Lists] -formatting hogwild
Line 136: Line 136:
  
  
-==== TLS Control channel security ====+==== TLS Control Channel Security ====
  
 (tls-auth/tls-crypt) (tls-auth/tls-crypt)
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, see: +For basic HMAC information, see: [[https://www.tutorialspoint.com/cryptography/message_authentication.htm|https://www.tutorialspoint.com/cryptography/message_authentication.htm]] 
-[[https://www.tutorialspoint.com/cryptography/message_authentication.htm|https://www.tutorialspoint.com/cryptography/message_authentication.htm]]+
  
 ==== VPN Subnet/Netmask ==== ==== VPN Subnet/Netmask ====
Line 195: Line 195:
  
 ===== Advanced Tab ===== ===== Advanced Tab =====
- \\ + 
-{{:openvpn_server_configuration-advanced_tab-3.jpg?743}} + \\  {{:openvpn_server_configuration-advanced_tab-3.jpg?743}}  \\  \\ 
- \\+ 
 ==== Poll Interval ==== ==== Poll Interval ====
  
Line 231: Line 232:
  
 (Ref. OpenVPN "--data-ciphers") (Ref. OpenVPN "--data-ciphers")
 +
 + \\
  
  
Line 250: Line 253:
  
  
-==== 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, the default value may cause the end user to be asked to reauthorize once per hour. This specifies how many seconds (//n//) will pass before OpenVPN renegotiates the data channel key (Default=3600). When using dual-factor authentication, the default value may cause the end user to be asked to reauthorize once per hour.
  
 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// on both client and server, or set it to "0" (disabled) on one side of the connection, and to your preferred value on the other side. 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// on both client and server, or set it to "0" (disabled) on one side of the connection, and to your preferred value on the other side.
 +
  
 ==== Manage Client-Specific Options ==== ==== Manage Client-Specific Options ====
Line 382: Line 386:
  
  
-==== A warning about certificates ====+==== A Warning about Certificates ====
  
 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 405:
  
  
-==== Adding certificate revocation lists ====+==== Adding Certificate Revocation Lists ====
  
 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 419:
 </code> </code>
  
 + \\
  
-===== 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. 
  
-So to configure this, you need to add one line in the server configuration and restart server and client.+==== OpenVPN Server Won't Start When EasyRSA3 used ==== 
 + 
 +In some cases when you've generated server certificate/keys using EasyRSA 3, the server may not start. This can be happen when the server certificate requires a password but there was no way to provide it. In such cases, you should regenerate the certificate/key using the the EasyRSA "nopass" option. Doing this should allow the OpenVPN Server to start properly. 
 + 
 + 
 +==== Routing Notes ==== 
 + 
 +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 line in the server configuration and restart OpenVPN server and OpenVPN client. 
 + 
 + \\
  
 <code -> <code ->
Line 426: Line 443:
 </code> </code>
  
-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 for IP addresses in the 192.168.1.XXX scope via the VPN connection.
  
-**BEWARE**: Remember that you also need to consider what is called "return routes"If your VPN client can access a host behind your VPN serverit does not mean that the host behind the VPN server will send the response via the same routeSo you need to ensure that your hosts behind your VPN server also knows which gateway to use for your VPN. Nowadays this is most commonly fixed by adding a route on your existing default gateway. And if you run OpenVPN on an existing gateway, you have this return route already impllicitly configured.+This is an example of a very basic setupAnd when we now start on the routing part, the VPN setup is mostly doneAll you need now is to add the needed routes you needjust like you would do for normal TCP/IP routing.
  
-For more detailed example using routingsee the%% ​%%Using routing%% %%section in the 'Bridiging and routing' wiki page.+Remember that you also need to consider "return routes". Just because your VPN client can access host behind your VPN serverdoesn't mean that the host behind the VPN server can/will send the response via the same route. Therefore, you must ensure the hosts behind your VPN server also knows which gateway to use for your VPN. This is most commonly fixed by adding a route on your existing default gateway. That way, if you run OpenVPN on an existing gateway, you have the return route already (implicitly) configured.
  
-==== Routing everything over the VPN ====+For a more detailed example of using routing, see the%% ​%%Using routing%% %%section in the 'Bridging and routing' wiki page.
  
-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''ll need to investigate how to configure NAT on your VPN server for the virtual tun adapter. 
 + 
 +You can either push a "route everything over VPN" setting via the server, or you can add it explicitly in the client configuration. Do not use both at the same time. 
 + 
 + \\
  
 Server push: Server push:
 +
 + \\
  
 <code -> <code ->
     push "redirect-gateway def1"     push "redirect-gateway def1"
 </code> </code>
 +
 + \\
  
 Client configuration alternative: Client configuration alternative:
 +
 + \\
  
 <code -> <code ->
Line 452: Line 480:
 </code> </code>
  
-==== What about IPv6? ====+ \\
  
-OpenVPN v2.3 and later supports IPv6. To set up IPv6 in the tunnel is roughly similar to the IPv4 examples already discussed. You need to use the //–server-ipv6// and //–route-ipv6//  options to configure IPv6.+ 
 +==== About IPv6 ==== 
 + 
 +OpenVPN v2.3 and later support IPv6. Setting up IPv6 in the tunnel is roughly similar to the IPv4 examples above. You need to use the //–server-ipv6// and //–route-ipv6//  options to configure IPv6. 
 + 
 + \\
  
 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:db8:cada::/64     server-ipv6 2001:db8:cada::/64
 </code> </code>
 +
 + \\
  
 You can use the //–route-ipv6// option, either by pushing it from the server, or using it directly in the client configuration. The same is true for the //–route// option. The syntax is similar too: You can use the //–route-ipv6// option, either by pushing it from the server, or using it directly in the client configuration. The same is true for the //–route// option. The syntax is similar too:
 +
 + \\
  
 <code -> <code ->
Line 468: Line 507:
 </code> </code>
  
 + \\
  
 + \\
  
  
vpn-server.1694539814.txt.gz · Last modified: 2023/09/12 18:30 by hogwild