Am 11.12.2009 10:46, schrieb dorian: > Anyway I would be obliged id you explain me what for is "multi yes" > parameter in the server config?
With "multi yes" any client can connect to the VPN-Server with the same "profile" and "password". How IPSEC do with the same Authentication-Key. Thats ok, when only you have the control about all, but it is highly recommended to create 1 profile for each connection. > I understand how "multi killold" and "multi no" work (at least I hope I > understand). > "multi killold" makes the previous connections sub-process to be killed > if the new connection appears. > "multi no" makes new connection trial to accepted but after a timeout > when connection sub-process dies itself (f.instance after no keepalive > responce) thats absolutly correct. > But "multi yes" is some kind of nonsense for me _if_ (?) it allows > reconnections only from the same client. "multi yes" accepts connections from any client. This option can be set in global-config and per profile-section. > Typical situation is that one client has one tunnel. If the connection > is broken the client will try to establish the new one. > So "multi killold" is natural setting because the old tunnel connection > is unimportant (and usually available). Correct. "multi killold" is the best solution, because VTUN is not able to detect connection-aborts when you use UDP as transfer-protocol. And UDP make sense. I will never give TCP a try ;-) > Could you give me any suggestions when "multi no" could be useful "multi no" is not useful in many environments. VTUN detects a connection-abort not fast enough. > And another quite different question. > Where can I change the connection timeout which is used for session close. > I've set "timeout 60;" is options section. But when I switch off my > Linksys the server closes the session after ~4minutes against assumed > 60secs. Thats exactly that what i mean. deadly to slow. When you use "multi no", you are not able to reconnect for more then 4 minutes. In some cases vtun take more then 4 minutes. I dont know for what "keepalive" standing for. vTUN never sent keepalive packets over the network. But the source-code have place for implementation ;-) ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Vtun-Users mailing list Vtun-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-users
