Sampo,

We've added some features to 1.3.2 and pre-1.3.3 code that are a step in the
direction of full forking server support.

For example, 1.3.2 supports instantiation by inetd/xinetd.  xinetd has its own
DoS resistant features, and I added a new flag to the pre-1.3.3 code
(--replay-persist) in the CVS to do replay protection that is persistent
across sessions.

The only thing we don't have yet is the ability to define an incoming
connection template which can be applied to more than one client.  Also,
allowing multiple tunnels to share the same UDP port is problematic, mostly
for efficiency reasons (since packets must be dispatched, it increases the
number of context switches per packet).

James

Sampo Nurmentaus <audiopoppi...@audioriders.fi> said:

> 
> 
> Hello,
> 
> Sorry it took so long to reply, but I haven't read my work
> mail for a while due to all the exams.
> 
> We have been using openvpn with this multiple connection
> hack of mine for a while with our embedded linux systems
> and it has been running fine. Still there is a lot of
> testing to do and it ain't finnished in any sense.
> For example, at the moment it is very sensitive to reply attacks.
> 
> I have tried to make it as independent as possible from the
> openvon peer2peer version as possible. That's why I have
> used my own little protocol for handshaking and allocating
> a new UDP-port.
> 
> If you are intrested in giving it a try I can mail the source
> for you.
> 
> It still uses an old openvpn version but it should not
> be very difficult to merge with a newer version, haven't
> just got the time for that.
> 
> 
> Let me know if you wan't a tar-bal to try it out.
> 
> Sampo
> 
> > Hi,
> >
> > I am interested to know what is the update/status one above.
> > I see email thread  as:
> >
> > Hi Sampo,
> >
> >                                   > I have been busy writing a forking 
> > server
> >                                   > addon to openvpn.
> >
> >                                   Cool... Does each potential connecting
client need a separate config file,
> >                                   or does the server use a common client
template and then keep track of
> >                                   things like dynamic ports, dynamic
endpoint addresses, etc?
> >
> >                                   > In openvpn.c I have separated the
processing of
> >                                   > parameters from main() to a new
function and
> >                                   > moved main to another file to allow me 
> > to
> >                                   > link against different main() functions.
> >                                   >
> >                                   > One that implements normal peer2peer vpn
> >                                   > and two others that produces forkin'
server
> >                                   > and client.
> >                                   >
> >                                   > These use a simple UDP protocol to 
> > agree a
> >                                   > port to use, after which server forks do
> >                                   > some handshaking with client and then
> >                                   > calls openvpn() funcition from openvpn.c
> >
> >                                   Are you sure there needs to be a new
protocol to do this?
> >
> >                                   Suppose the master server listens on a
particular port, reads the initial
> >                                   datagram from a connecting client,
verifies the integrity of the datagram
> >                                   using a --tls-auth variant, allocates a
dynamic port, forks a new server
> >                                   process, and continues in its event loop.
> >
> >                                   When the forked process finishes up the
TLS authentication, it can take the
> >                                   Common Name from the client certificate
and use it to determine the
> >                                   appropriate config profile to use
(containing ifconfig addresses, route
> >                                   statements, etc.)
> >
> >                                   Or the handshaking could be done by
passing a configuration string in the
> >                                   TLS payload, similar to the string now
built by options_string().
> >
> >                                   > This way I have been able to keep
> >                                   > those well tested procedures and 
> > protocol
> >                                   > of openvpn untouched.
> >                                   >
> >                                   > I still have some questions unsolved 
> > like
> >                                   > DoS protection, dropping root 
> > priviledges
> >                                   > and how to handel SIGUSR1 and SIGHUP.
> >
> >                                   Maybe keep track of all children, so
when the master process gets a signal,
> >                                   it dispatches it to each child process,
then to itself.
> >
> >                                   > I hope I can overcome these and mail
> >                                   > you a patch.
> >                                   >
> >                                   >
> >                                   >
> >                                   >
> >                                   > Sampo
> >                                   >
> >                                   >
> >                                   >
> >                                   > > Hi Michael,
> >                                   > >
> >                                   > > Right now OpenVPN doesn't support a
forking-server model on a single
> >                                   port,
> >                                   > > it's strictly peer-to-peer with an
OpenVPN process instantiated at both
> >                                   ends
> >                                   > > of the connection, and each
connection on a unique port.
> >                                   > >
> >                                   > > There has been some recent
discussions about a forking-server
> >                                   implementation
> >                                   > > on this list -- see the "add a
server feature to openvpn to share udp
> >                                   > > ports?" thread in the openvpn-devel
archives.
> >                                   > >
> >                                   > > I think the simplest way to do this
would be something like:
> >                                   > >
> >                                   > > (1) Add a --forking-server flag that
causes the main OpenVPN event loop
> >                                   to
> >                                   > > fork a new process for each initial
datagram received from a client.
> >                                   > > (2) The newly forked server process
switches to a dynamic port before
> >                                   > > responding back to the connecting
client.  This is quite a bit simpler
> >                                   and
> >                                   > > more efficient than trying to run
all clients over the same UDP port.
> >                                   > > (3) OpenVPN already has code (see
the implementation of --float) that
> >                                   will
> >                                   > > adapt to the new port number
returned by the response to initial
> >                                   datagram
> >                                   > > sent from server to client.  I have
also confirmed that this type of UDP
> >                                   > > port switch is recognized by both
Linux and Cisco stateful firewalls.
> >                                   > >
> >                                   > > There are a some complications that
would need to be handled:
> >                                   > >
> >                                   > > (1) You would need to protect
against DoS attacks that flood the server
> >                                   with
> >                                   > > fork requests.  Possibly some
variation of --tls-auth that would
> >                                   > > authenticate the initial packet
before the fork call.
> >                                   > >
> >                                   > > (2) If a client connects, gets
disconnected, then connects again, you
> >                                   would
> >                                   > > need to make sure that the old
server process gets killed before a new
> >                                   > > server process is forked.
> >                                   > >
> >                                   > > Unfortunately I'm pretty busy right
now with my day job, so I may not
> >                                   get to
> >                                   > > this for a while.  If you want to
take a shot at some kind of
> >                                   > > implementation, I will do my best to
answer your questions.
> >                                   > >
> >                                   > > Best Regards,
> >                                   > > James
> >                                   > >
> >                                   > > ----- Original Message -----
> >                                   > > From: "Michael Grigoriev" <mag@ni...>
> >                                   > > To: <openvpn-devel@li...>
> >                                   > > Sent: Monday, July 22, 2002 6:53 PM
> >                                   > > Subject: [Openvpn-devel] Multiple
VPN connections on the same port
> >                                   > >
> >
> > __________________________________________________________________
> > The NEW Netscape 7.0 browser is now available. Upgrade now!
http://channels.netscape.com/ns/browsers/download.jsp
> >
> > Get your own FREE, personal Netscape Mail account today at
http://webmail.netscape.com/
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Openvpn-devel mailing list
> > Openvpn-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 





Reply via email to