I am following along with this tutorial for setting up a VPN between my home server and my production server.
My issue is that in my network, the client (home server) is behind a dynamic IP and the server (production) is behind a static IP.
What do I have to do differently to create this VPN between my home and production network considering my home is behind an IP that my ISP changes often?
OpenVPN requires that one system is configured as the server and the other is configured as the client. Clients connect to the server.
So you would have the server instance running on your production server with the static IP, and the client instance running on your home server with the dynamic IP. Your client's IP doesn't matter as it will initiate the connection to the server.
An OpenVPN connection when at least one between client and server does not have a static IP address presents the following problem: if either one changes address during the course of the connection, this will be dropped.
There is however a standard way (see this OpenVPN official wiki page) to prompt automatically client and/or server to force a re-connection whenever the connection is dropped. It consists of using the following lines in the client and server configuration files:
ping 15
ping-restart 300 # 5 minutes
resolv-retry 300 # 5 minutes
persist-tun
persist-key
Notice however that these lines preserve the OpenVPN link whatever the cause for the temporary drop (never mind the change of public IP address), so I usually keep them in both client and server configuration files to allow an automatic reconnection.
According to the Manual:
--ping n
Ping remote over the TCP/UDP control channel if no packets have been sent for at least n seconds (specify --ping on both peers to cause ping packets to be sent in both directions since OpenVPN ping packets are not echoed like IP ping packets). When used in one of OpenVPN's secure modes (where --secret, --tls-server, or --tls-client is specified), the ping packet will be cryptographically secure.
--ping-restart n
Similar to --ping-exit, but trigger a SIGUSR1 restart after n seconds pass without reception of a ping or other packet from remote. This option is useful in cases where the remote peer has a dynamic IP address and a low-TTL DNS name is used to track the IP address using a service such as http://dyndns.org/ + a dynamic DNS client such as ddclient.
If the peer cannot be reached, a restart will be triggered, causing the hostname used with --remote to be re-resolved (if --resolv-retry is also specified).
In server mode, --ping-restart, --inactive, or any other type of internally generated signal will always be applied to individual client instance objects, never to whole server itself. Note also in server mode that any internally generated signal which would normally cause a restart, will cause the deletion of the client instance object instead.
In client mode, the --ping-restart parameter is set to 120 seconds by default. This default will hold until the client pulls a replacement value from the server, based on the --keepalive setting in the server configuration. To disable the 120 second default, set --ping-restart 0 on the client.
See the signals section below for more information on SIGUSR1.
Note that the behavior of SIGUSR1 can be modified by the --persist-tun, --persist-key, --persist-local-ip, and --persist-remote-ip options.
Also note that --ping-exit and --ping-restart are mutually exclusive and cannot be used together.
--resolv-retry n If hostname resolve fails for --remote, retry resolve for n seconds before failing. Set n to "infinite" to retry indefinitely.
By default, --resolv-retry infinite is enabled. You can disable by setting n=0.
--persist-tun
Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. SIGUSR1 is a restart signal similar to SIGHUP, but which offers finer-grained control over reset options.
--persist-key
Don't re-read key files across SIGUSR1 or --ping-restart. This option can be combined with --user nobody to allow restarts triggered by the SIGUSR1 signal. Normally if you drop root privileges in OpenVPN, the daemon cannot be restarted since it will now be unable to re-read protected key files.
This option solves the problem by persisting keys across SIGUSR1 resets, so they don't need to be re-read.
