peasthope@shaw.ca wrote: > > Only my dynamic client has a remote set. > > ?? > We are on the same frequency here. The dynamic-ip system > has a remote parameter pointing to the static-ip system. The > static-ip system lacks the remote parameter ... unless I revert > to my old dependance upon a DDNS server, ... which had failed. I was mostly just confirming that you don't need remote on both ends. You only need remote on one side to initiate the connection. The dynamic ip host can be the only one with a remote set and then it will be the only one to initiate the connection. The server is happy to wait for clients to connect. Without a remote option set the server won't initiate a connection but will respond to clients who connect. Also the remote tells the daemon to filter packets to only those from the specified address. Filtering to a specific address isn't going to be compatible with a client that changes addresses. (Openvpn, if --resolv-retry is specified, resolves the hostname every time it tries to connect specifically to allow use of dynamic address clients.) > > Yes. But the tunnel will start when the client connects. If you > > restart the server then the client will detect this and connect. > > From what you have said I'll infer that your dynamic-ip system > is what people call a "road warrior". Usually a laptop which the > user takes on a field trip. It connects for a session with the user > present. In addition to my "road warrior" laptop I also use an almost identical configuration on several other client systems that all exist on dynamic IP addresses on various networks behind NAT firewalls. All have an almost identical client configuration. It isn't just for road warrior laptops. > My situation is different. The dynamic-ip system Joule remains at > my residence running 24/7. It is unattended when I am in the city > at work. If the tunnel on the static-ip Dalton is restarted, I prefer > that Joule reconciles and the tunnel is open again within a few > minutes. That is exactly the same situation I am in. No difference that I can tell. I don't think we are in a different case. (Except I don't commute to the city. :-) Why do you think that Joule won't try to reconnect? You don't actually say that it won't but you do imply that it won't unless you do something special. > > I use keepalive 20 120 on my server. This is the same as specifying > > all of four different ping parameters. > > Nice. Thanks. I'll use it. > > > Same as: > > ping 20 > > ping-restart 120 > > push "ping 20" > > push "ping-restart 120" > > I'll guess that ping-restart listens for a signal but doesn't emit > one. Well, there isn't a need to guess. It is documented in the manual. I will refrain from repeating it here. > The purpose in the static-ip system emitting pings and the > dynamic-ip doing "ping-restart 120" is obvious. Why is the converse > needed? When none of your road warriors are on-line the static-ip > "server" will be restarting openvpn every 120 s. Why? Primarily because that is what is recommended in the OpenVPN documentation. It seemed reasonable to me. This way both sides will detect and react to the connection going down. I had no reason to go against the documentation and didn't think about it too much further. Secondly on the server the openvpn daemon isn't restarted. It just does internal cleanup on the client instance object. That is according to the documentation anyway. I haven't actually looked at the code to verify that but instead just read the documentation. If the server doesn't detect that the client dropped offline then I could see it causing problems when the client tries to establish a new connection. Without detecting this the server could be trying to /continue/ a connection when the client wants to /start/ a connection and I doubt those are compatible. I haven't looked at the code but it just seemed so reasonable to me that I don't expect anything different. But among other things restarting the client instance object on the server would cause the it to re-resolve any names used by dynamic clients. This way if the name has changed addresses through a dynamic dns server then the server will get the new address for the packet filter. (However I don't use "remote" on the server and so I personally don't need it for that reason. But others might.) I could also imagine it would trigger other hooks too. > Incidentally, does your "server" really have "mode server" It really has "mode server" in the form of the "server" directive such as "server 10.8.0.0 255.255.255.0" which expands to a lot of configuration code which is documented in the manual. I prefer using the shorter: server 10.8.0.0 255.255.255.0 which expands to the following for my case: mode server tls-server ifconfig 10.8.0.1 10.8.0.2 ifconfig-pool 10.8.0.4 10.8.0.251 route 10.8.0.0 255.255.255.0 push "route 10.8.0.1" > or just a collection of "mode p2p" tunnels? I am definitely not using "mode p2p" but I am using "topology p2p". Since I don't have any MS Windows machines I am using "topology p2p". in server mode. I know it's confusing. Bob
Attachment:
signature.asc
Description: Digital signature