[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

Re: [Openvpn-users] Connection problems


  • Subject: Re: [Openvpn-users] Connection problems
  • From: Charles Duffy <cduffy@xxxxxxxxxxx>
  • Date: Thu, 08 Jun 2006 09:55:20 -0500

Nigel Allen wrote:
> Thanks Charles for pointing me in the correct direction. The problem
> (omitting fat fingers and a bad ip address) was indeed UDP. Once we
> switched to TCP it "just worked". Wonderful.

I don't recommend TCP as an underlying carrier for use long-term -- it 
has some cases where performance can get quite bad, which is why I 
suggested trying it as a debugging aid (such that if everything works 
with TCP, you can have a great deal of confidence that the network is 
dropping or failing to do proper connection-tracking for UDP packets). 
See http://sites.inka.de/~W1011/devel/tcp-tcp.html for an introduction 
to some of the performance issues with TCP-over-TCP VPNs.

That said, there are folks who *are* using it happily, and who haven't 
experienced such issues, so take my advice with a grain of salt.

> I now have a working "server.conf" file (on the server funnily enough)
> that works well for the connection I have been testing. If I add more
> clients into the mix, am I right in thinking that they will all be dealt
> with by the same server.conf with IP addresses allocated to them from
> the pool we have defined in the server-bridge parameter or do we have to
> have a separate "conf" file for each client.

In multi-client server mode, yes. (If you have a "server" directive, or 
"mode server", that means you're in multi-client server mode. 
"tls-server" does *not* put you in multi-client server mode).

> If the former is the case, is there any way I can generate a separate
> log file for each connection?

Well, if you *had* to, you could pipe your output to a process which is 
responsible for filtering the logs into per-client files... but in 
practice, I've not seen a need to do such a thing. What would you want 
these per-client logs for? If they're strictly intended for accounting, 
you could implement a crude form of such via having scripting hooks that 
  dump output. It really depends on what you're intending to do though; 
with a reasonably low verbosity level, I haven't found unified logs to 
be cumbersome at all.

(I'm using runit, a daemontools workalike, for process supervision; this 
makes having a separate log filter process handling stdout quite easy -- 
and, in fact, the normal mode of operation).



_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users