PETER EASTHOPE wrote: > Recently the DDNS server hasn't been updating and I've wondered > about other configurations. But an openvpn configuration shouldn't be depending upon dynamic dns. Have your dynamic IP client contact your server. If the server is static and known then there shouldn't be a problem if the client ip address is dynamic and changes and isn't known. On sites I maintain since the IP address is static and known I use the IP address directly so as to avoid any dependency upon dns. (Especially if dns is using the vpn then it would be a circular dependency to use the dns name. In which case I must use the IP address directly and avoid the circular dependency. But it is static so that is okay.) > One possibility appears to be for Dalton to run in server mode and > for Joule to be an OpenVPN client. That is the standard operating mode for my laptop. It connects as a client from wherever it happens to be in the world to my server with the static ip address. Then all traffic is routed over the vpn. (And so the Firesheep issue is not a problem for my laptop on some random wifi network. The issue is moved to my server network where I have more control. It is still a problem but just on a different but more safe network.) > So I'm thinking to remove option "remote joule.yi.org" I have never had a "remote" configuration on the server. That is for the client on the dynamic IP. I think you might be able to use almost the same configuration you currently have but just with some tweaks. > and add "mode server" in the configuration file on Dalton. > No such thing as "mode client". Is a client connection > profile necessary on Joule when there is only one server? > > Any comments or criticisms or suggestions before I blunder > further? There are two main configurations. One is a special case shared key. That has the advantage of being very simple to set up. http://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html The disadvantage of the above is that it only works for two hosts. It doesn't scale to more. But you might start there as a simple way to get experience with the configuration. It will work fine with one server with a static IP and one client with an unknown dynamic IP. The second main way is to set up a certificate authority and enable multiple clients with your server. It is more complicated but if you are patient to work through the instructions it works quite well. http://openvpn.net/index.php/open-source/documentation/howto.html I started with the static key configuration between two hosts and eventually migrated to the CA configuration when I wanted to add a additional client host. Since then I have set up a couple of more vpns between sites and I start with the CA configuration. OpenVPN works well. However it isn't completely trivial to set up and I also have needs for something simpler. Therefore I also use autossh in addition to openvpn. It is a Debian package and you can install it directly. Autossh is quite useful. http://www.harding.motd.ca/autossh/ In short I use autossh to connect a host on a dynamic IP address to a server and to port forward connections back to the dynamic IP host. There are a few example scripts with the package. Unfortunately autossh does not package with an example /etc/init.d script to have it automatically start at boot time from the machine. That is the way I configure it. I would be happy to share those files if there is interest. Autossh is extremely simple and very reliable. It enables me to have a way to always connect to the dynamic IP host without needing dynamic dns for it. It enables a host behind a NAT firewall (such as my laptop connected to a private network) to be connected through a secure encrypted vpn-like connection to a server. My advice would be to try autossh and to port forward the ssh port to a local port on the server. That will give you an access path outside of openvpn. That way if you break your openvpn configuration during the transition you can use the ssh port forward for access. Then change your openvpn configuration. Having the two dual connection paths will prevent a mistake on one from blocking you for access because you can use the other path. Bob
Attachment:
signature.asc
Description: Digital signature