.bash_profile and .bashrc are specific to bash, whereas .profile is read by many shells in the absence of their own shell-specific config files. (.profile was used by the original Bourne shell.) .bash_profile or .profile is read by login shells, along with .bashrc; subshells read only .bashrc. (Between job control and modern windowing systems, .bashrc by itself doesn't get used much. If you use screen or tmux, screens/windows usually run subshells instead of login shells.)
The idea behind this was that one-time setup was done by .profile (or shell-specific version thereof), and per-shell stuff by .bashrc. For example, you generally only want to load environment variables once per session instead of getting them whacked any time you launch a subshell within a session, whereas you always want your aliases (which aren't propagated automatically like environment variables are).
Other notable shell config files:
/etc/bash_profile (fallback /etc/profile) is read before the user's .profile for system-wide configuration, and likewise /etc/bashrc in subshells (no fallback for this one). Many systems including Ubuntu also use an /etc/profile.d directory containing shell scriptlets, which are . (source)-ed from /etc/profile; the fragments here are per-shell, with *.sh applying to all Bourne/POSIX compatible shells and other extensions applying to that particular shell.
As it said, add a float option to the client config and try again.
--float
Allow remote peer to change its IP address and/or port number, such
as due to DHCP (this is the default if --remote is not used). --float
when specified with --remote allows an OpenVPN session to initially
connect to a peer at a known address, however if packets arrive from
a new address and pass all authentication tests, the new address will
take control of the session. This is useful when you are connecting
to a peer which holds a dynamic address such as a dial-in user or DHCP
client.
Essentially, --float tells OpenVPN to accept authenticated
packets from any address, not only the address which was specified in
the --remote option.
Best Answer
SSH VPN tunnels still use the ssh connection, no? Last I checked it did. And since ssh runs over TCP that means that the VPN runs over TCP.
This is not a good way to do it. A single dropped packet will cause i hickup of ALL communication that's going through the tunnel.
Tunneling IP over TCP is a bad idea.
OpenVPN can use TCP or UDP. UDP is preferred for the reason I explained (poorly).
Better explanation: http://sites.inka.de/~W1011/devel/tcp-tcp.html
That being said, SSH VPN is probably easier to set up.