openvpn-devel — OpenVPN developers list

[Openvpn-devel] Fwd: Bug#158404: openvpn: Improper error handling

[Alberto G. I. <ag...@ag...>]

Hi James et al,

I just came back from holidays and got this bug report in Debian. (Seems
like IBM is using OpenVPN). I didn't have time to look at it yet, but
I'm sure you'll handle it better anyway :)

Best regards,

Alberto



----- Forwarded message from Richard A Nelson <co...@vn...> -----

From: Richard A Nelson <co...@vn...>
Reply-To: Richard A Nelson <co...@vn...>,
	15...@bu...
To: su...@bu...
Subject: Bug#158404: openvpn: Improper error handling
Date: Mon, 26 Aug 2002 17:28:37 -0400
X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND version=2.20

Package: openvpn
Version: 1.3.0-1
Severity: important

I often get a flood of these messages:
openvpn[1239]: read from UDP: Resource temporarily unavailable (errno=11)

The condition persists for a bit, and then clears up...  While the errors
are occuring, occasionally the session will drop ;(

It seems to be improper handling of EAGAIN !
The potential solutions would most likely be:
	1) re-try the systemcall
	2) redrive the read loop
	3) set blocking IO

-- System Information
Debian Release: testing/unstable
Kernel Version: Linux badlands.lexington.ibm.com 2.4.20-pre4-ac1 #13 Sat Aug 24 19:11:43 EDT 2002 i686 unknown unknown GNU/Linux

Versions of the packages openvpn depends on:
ii  libc6          2.2.5-14       GNU C Library: Shared libraries and Timezone
ii  liblzo1        1.07-1         A real-time data compression library.
ii  libssl0.9.6    0.9.6g-2       SSL shared libraries

----- End forwarded message -----

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

[Openvpn-devel] Ramifications on OpenVPN of OpenSSL security announcement

[James Y. <ji...@nt...>]

As many of you have probably noticed, the OpenSSL project released a
security update today which fixes potential remote buffer overflows.

What you may not have known is that the ASN1 parser bug was independently
discovered in the process of stress testing OpenVPN, earning yours truly the
dubious distinction of being acknowledged in the security advisory.

So here's the scoop for OpenVPN users:

(1) If you are using preshared static key mode, you are not vulnerable.

(2) If you are using TLS mode with --tls-auth, you are not vulnerable.

(3) If you are using TLS mode without --tls-auth, you may be vulnerable if
you are also using --float.

If you think you are vulnerable, the quickest fix is to start
using --tls-auth, which was explicitly designed to protect against buffer
overflows in OpenSSL by creating a two-tier authentication hierarchy that
forces ALL incoming packets to authenticate via HMAC before they are passed
on to the TLS code in OpenSSL.  Think of it as a kind of MAC firewall.

In general you should also consider downgrading privileges with --user
and/or --group, to limit the damage that would be caused by a remote buffer
overflow attack.  If for whatever reason you must run as root, then consider
using the --chroot option to lock the OpenVPN daemon into a restricted
filesystem, so that a remote attack would not be able to modify sensitive
files.

Of course most systems have a lot of other apps and daemons that depend on
OpenSSL so upgrading ASAP is probably the best course.

James

Re: [Openvpn-devel] NetBSD patch for OpenVPN

[Dimitri G. <dm...@su...>]

Hi,

>One question I have, were you able to connect OpenVPN running on NetBSD to
>OpenVPN running on a different platform such as Linux?

Yes, my peer is a Linux box.

Re: [Openvpn-devel] NetBSD patch for OpenVPN

[James Y. <ji...@nt...>]

Dimitri,

Thanks for the patch, I will apply it to the CVS shortly.

One question I have, were you able to connect OpenVPN running on NetBSD to
OpenVPN running on a different platform such as Linux?

I ask because some tun/tap devices will prepend unnecessary stuff onto the
datagram that must be disabled with an explicit ioctl call if cross-platform
compatibility is to be preserved.  You can see some examples of this in
tun.c.

If this is the case, you might find that NetBSD <-> NetBSD tunnels work
fine, but NetBSD <-> Linux tunnels are broken.  Just something to check for
if possible...

James

----- Original Message -----
From: "Dimitri Goldin" <dm...@su...>
To: <ope...@li...>
Sent: Friday, July 26, 2002 3:58 PM
Subject: [Openvpn-devel] NetBSD patch for OpenVPN


> Hello list,
>
> The patch for the NetBSD "support" ist ready.
> I only added some entries for NetBSD and used the same ifconfig code
> as OpenBSD in tun.c.
> The patch is attached.
> I hope I did everything right.
>
> Cheers,
>         Dimitri
> --
> pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
> Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8
>                                                 "Don't Panic."
>
>

[Openvpn-devel] NetBSD patch for OpenVPN

[Dimitri G. <dm...@su...>]

Hello list,                                                                     
                                                                                
The patch for the NetBSD "support" ist ready.                                   
I only added some entries for NetBSD and used the same ifconfig code            
as OpenBSD in tun.c.                                                            
The patch is attached.                                            
I hope I did everything right.              
                                                                                
Cheers,                                                                         
        Dimitri               
--                                                                              
pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>              
Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8                 
                                                "Don't Panic."                  
                                                                                                                    

Re: [Openvpn-devel] OpenVPN on NetBSD

[James Y. <ji...@nt...>]

Hi Dimitri,

Yes, it would be great if you would like to do a NetBSD port.  I imagine it
would be pretty straightforward, given the existence of FreeBSD, OpenBSD,
and Mac OS X ports.

The "PORTS" file has a nice rundown on making a clean port, with some points
on testing to make sure all the major features work correctly.

Best Regards,
James

> Hello developers,
>
> Tried to setup a vpn with a friend today.
> The box ist running NetBSD 1.5.2.
> But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in
> my config file I've got the error
> "Sorry, but I don't know how to do 'ifconfig'
> commands on this operating system. You should ifconfig your tun/tap device
> manually or use an --up script."
>
> The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2
> 10.0.0.2". I don't know why but it always did:
> 4: tun/tap device /dev/tun1 opened
> 5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344
>
> After some testings I've decided to try the OpenBSD ifconfig code in tun.c
> since the syntax is similar for such simple operations.
> I replaced the message about unknown ifconfig with this code and it
> worked without any problems.
> It's quick and dirty, but if there is interest in a NetBSD port then
I will add it properly.

>
> Greets,
>         Dimitri
> --
> "A towel is about the most massively useful
>  thing an interstellar hitch hiker can have." -- Hitchicker's Guide
> pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
> Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Jabber - The world's fastest growing
> real-time communications platform! Don't just IM. Build it in!
> http://www.jabber.com/osdn/xim
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

[Openvpn-devel] OpenVPN on NetBSD

[<dm...@th...>]

Hello developers,                                                               
                                                                                
Tried to setup a vpn with a friend today.                                       
The box ist running NetBSD 1.5.2.                                               
But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in      
my config file I've got the error                                               
"Sorry, but I don't know how to do 'ifconfig'                                   
commands on this operating system. You should ifconfig your tun/tap device      
manually or use an --up script."                                                
                                                                                
The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2                    
10.0.0.2". I don't know why but it always did:                                  
4: tun/tap device /dev/tun1 opened                                              
5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344                               
                                                                                
After some testings I've decided to try the OpenBSD ifconfig code in tun.c      
since the syntax is similar for such simple operations.                         
I replaced the message about unknown ifconfig with this code and it             
worked without any problems.                                                    
It's quick and dirty, but if there is interest in a NetBSD port then            I will add it properly.                                                         
                                                                                
Greets,                                                                         
        Dimitri                                                                 
--                                                                              
"A towel is about the most massively useful                                     
 thing an interstellar hitch hiker can have." -- Hitchicker's Guide             
pub  1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>              
Fingerprint: 3AA9 1264 51AA 0BB5 EB29  A6E3 9648 F42A 3A26 4EA8                 

Re: [Openvpn-devel] Multiple VPN connections on the same port

[Sampo N. <aud...@au...>]

> > > Hi Sampo,
> > >
> > > > I have been busy writing a forking server
> > > > addon to openvpn.
>
> Will forking server only work for TLS mode?

No, It works also with shared secret or without
security.

For prefork security I could use either the key used
for tls-auth or preshared secret.

Any examples of how to implement tls-auth like
authentication in simples form?

> > --remote as server addres in the client.
> >
> > I just got it running. Still with out dynamic ip address assigment
> > and proper signal handling in parent process. And there ain't
> > anykind of DoS protection yet.
>
> One way to do DoS protection would be to augment --tls-auth with persistent
> anti-replay protection by saving the Session ID (struct session_id) and
> reject any Session ID that was seen before.

Let's see when I get it working. :-)

> > port before calling openvpn(). Mayby I could add the exchange of
> > address info here, since I don't think it needs to be
> > transferred over a secure channel.
>
> Actually the temporary keys + options_string() get passed over the secure
> TLS channel, so you could add further handshaking options and they would be
> secure.



> >
> > > > 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.
>
> It would be cool if we could get the forking server to work with dropping
> root privs.
>
> One of the goals of dropping privs is that no datagram is ever read from the
> network with root privs.
>
> It would be great if we could preserve this behavior.
>
> Otherwise the split privileges model of the new openssh would be a
> possibility, but it's more complex.


For a forking server accepting connections from any ip, I
consider it even more critical than for a peer2peer version.

I did it simply by calling set_user() in the
server's main process and everything seems to work at least
for me.

Don't know if this works in all cases since the server drops
priviledges before opening tun dev.


Sampo

Re: [Openvpn-devel] Multiple VPN connections on the same port

[James Y. <ji...@nt...>]

> > Hi Sampo,
> >
> > > I have been busy writing a forking server
> > > addon to openvpn.

Will forking server only work for TLS mode?

> >
> > 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?
>
> No they don't. I just use normal config files/command line and use
> --remote as server addres in the client.
>
> I just got it running. Still with out dynamic ip address assigment
> and proper signal handling in parent process. And there ain't
> anykind of DoS protection yet.

One way to do DoS protection would be to augment --tls-auth with persistent
anti-replay protection by saving the Session ID (struct session_id) and
reject any Session ID that was seen before.

>
> Lack of dynamic addresses still limits it to a single connection
> but a pool of addresses should not be too hard to implement.
>
> There are also need for a few new options like the range
> of ports/addresses used.
>
> Ofcourse there should also be an ability to define
> addresses to each client. I haven't decided how to
> do that yet.
>
>
>
> > > 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?
>
>
> No, I am not. But found it easy to implement in this manner.
>
> > 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.
>
> It really sounds reasonable. I also though of some kind
> of message authentication before fork.  --tls-auth
> sounds good since it is quite light-weight.
>
> > 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().
>
> At the moment I do some handshaking in dynamically allocated
> port before calling openvpn(). Mayby I could add the exchange of
> address info here, since I don't think it needs to be
> transferred over a secure channel.

Actually the temporary keys + options_string() get passed over the secure
TLS channel, so you could add further handshaking options and they would be
secure.

>
> > > 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.

It would be cool if we could get the forking server to work with dropping
root privs.

One of the goals of dropping privs is that no datagram is ever read from the
network with root privs.

It would be great if we could preserve this behavior.

Otherwise the split privileges model of the new openssh would be a
possibility, but it's more complex.

> >
> > Maybe keep track of all children, so when the master process gets a
signal,
> > it dispatches it to each child process, then to itself.
>
> Sounds good to me. I am going to keep track of childs anyway
> to maintain address/port pool.
>
>
> Trying to explain things to someone,
> amazingly helps to figure out those things for one self!
> I got a bunch of new ideas while writing this.
>
>
> Got to go home now or I will sit coding here until
> midnight :-)
>
>
>
> Sampo
>

James

Re: [Openvpn-devel] Multiple VPN connections on the same port

[Sampo N. <aud...@au...>]

hi,

> 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?

No they don't. I just use normal config files/command line and use
--remote as server addres in the client.

I just got it running. Still with out dynamic ip address assigment
and proper signal handling in parent process. And there ain't
anykind of DoS protection yet.

Lack of dynamic addresses still limits it to a single connection
but a pool of addresses should not be too hard to implement.

There are also need for a few new options like the range
of ports/addresses used.

Ofcourse there should also be an ability to define
addresses to each client. I haven't decided how to
do that yet.



> > 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?


No, I am not. But found it easy to implement in this manner.

> 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.

It really sounds reasonable. I also though of some kind
of message authentication before fork.  --tls-auth
sounds good since it is quite light-weight.

> 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().

At the moment I do some handshaking in dynamically allocated
port before calling openvpn(). Mayby I could add the exchange of
address info here, since I don't think it needs to be
transferred over a secure channel.

> > 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.

Sounds good to me. I am going to keep track of childs anyway
to maintain address/port pool.


Trying to explain things to someone,
amazingly helps to figure out those things for one self!
I got a bunch of new ideas while writing this.


Got to go home now or I will sit coding here until
midnight :-)



Sampo

Re: [Openvpn-devel] Multiple VPN connections on the same port

[James Y. <ji...@nt...>]

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" <ma...@ni...>
> > To: <ope...@li...>
> > Sent: Monday, July 22, 2002 6:53 PM
> > Subject: [Openvpn-devel] Multiple VPN connections on the same port
> >
> >
> > > Hi,
> > >
> > > Firstly I'd like to thank you a prompt responce to my last question -
> > > it was most helpful.
> > >
> > > Now I am looking into the posibility of setting up a VPN server that
> > > will accept incoming VPN connections from some number of clients. (I
do
> > > realize that client/server only really applies to TLS-mode, by client
I
> > > really just mean the machine that will initialize the connection, the
> > > one that will be started with --remote)  However I am not sure how to
> > > best implement this since I don't know the number of clients in
> > > advance, so I can't really have a port assigned to each client.
Instead
> > > I would like to have all clients to connect to the server on the same
> > > port. I did not however find a way to do so with OpenVPN. When I tried
> > > to have to have two clients connect to the same server, they just kept
> > > periodically knocking each other off with error messages of the sort:
> > > 105: TLS Error: Unroutable control packet received from
> > > 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1)
> > > So I guess my question is, is it supposed to work? The man page says
> > > that you "should" have all the connections use a different port, which
> > > would imply that it is possible to do the opposite, but I was not able
> > > to get it to work....
> > > If it is not possible, as far as I understand it should not be too
hard
> > > to implement... We could have the server start out bound to the
> > > listening port, but not connected, and when we get an incoming
> > > connection from some ip, we fork and call connect in the child, so
that
> > > in the future all packets from that ip would go to that process.
Right?
> > >
> > > Would this work? Is there a better way to accomplish this?
> > >
> > > --
> > > Thanks in advance,
> > > mag
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:ThinkGeek
> > > Welcome to geek heaven.
> > > http://thinkgeek.com/sf
> > > _______________________________________________
> > > Openvpn-devel mailing list
> > > Ope...@li...
> > > 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
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> >
>

Re: [Openvpn-devel] Multiple VPN connections on the same port

[Sampo N. <aud...@au...>]

Hello James and Michael,

I have been busy writing a forking server
addon to openvpn.

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

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.

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" <ma...@ni...>
> To: <ope...@li...>
> Sent: Monday, July 22, 2002 6:53 PM
> Subject: [Openvpn-devel] Multiple VPN connections on the same port
>
>
> > Hi,
> >
> > Firstly I'd like to thank you a prompt responce to my last question -
> > it was most helpful.
> >
> > Now I am looking into the posibility of setting up a VPN server that
> > will accept incoming VPN connections from some number of clients. (I do
> > realize that client/server only really applies to TLS-mode, by client I
> > really just mean the machine that will initialize the connection, the
> > one that will be started with --remote)  However I am not sure how to
> > best implement this since I don't know the number of clients in
> > advance, so I can't really have a port assigned to each client. Instead
> > I would like to have all clients to connect to the server on the same
> > port. I did not however find a way to do so with OpenVPN. When I tried
> > to have to have two clients connect to the same server, they just kept
> > periodically knocking each other off with error messages of the sort:
> > 105: TLS Error: Unroutable control packet received from
> > 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1)
> > So I guess my question is, is it supposed to work? The man page says
> > that you "should" have all the connections use a different port, which
> > would imply that it is possible to do the opposite, but I was not able
> > to get it to work....
> > If it is not possible, as far as I understand it should not be too hard
> > to implement... We could have the server start out bound to the
> > listening port, but not connected, and when we get an incoming
> > connection from some ip, we fork and call connect in the child, so that
> > in the future all packets from that ip would go to that process. Right?
> >
> > Would this work? Is there a better way to accomplish this?
> >
> > --
> > Thanks in advance,
> > mag
> >
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Openvpn-devel mailing list
> > Ope...@li...
> > 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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] Multiple VPN connections on the same port

[James Y. <ji...@nt...>]

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" <ma...@ni...>
To: <ope...@li...>
Sent: Monday, July 22, 2002 6:53 PM
Subject: [Openvpn-devel] Multiple VPN connections on the same port


> Hi,
>
> Firstly I'd like to thank you a prompt responce to my last question -
> it was most helpful.
>
> Now I am looking into the posibility of setting up a VPN server that
> will accept incoming VPN connections from some number of clients. (I do
> realize that client/server only really applies to TLS-mode, by client I
> really just mean the machine that will initialize the connection, the
> one that will be started with --remote)  However I am not sure how to
> best implement this since I don't know the number of clients in
> advance, so I can't really have a port assigned to each client. Instead
> I would like to have all clients to connect to the server on the same
> port. I did not however find a way to do so with OpenVPN. When I tried
> to have to have two clients connect to the same server, they just kept
> periodically knocking each other off with error messages of the sort:
> 105: TLS Error: Unroutable control packet received from
> 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1)
> So I guess my question is, is it supposed to work? The man page says
> that you "should" have all the connections use a different port, which
> would imply that it is possible to do the opposite, but I was not able
> to get it to work....
> If it is not possible, as far as I understand it should not be too hard
> to implement... We could have the server start out bound to the
> listening port, but not connected, and when we get an incoming
> connection from some ip, we fork and call connect in the child, so that
> in the future all packets from that ip would go to that process. Right?
>
> Would this work? Is there a better way to accomplish this?
>
> --
> Thanks in advance,
> mag
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

[Openvpn-devel] Multiple VPN connections on the same port

[Michael G. <ma...@ni...>]

Hi,

Firstly I'd like to thank you a prompt responce to my last question - 
it was most helpful.

Now I am looking into the posibility of setting up a VPN server that 
will accept incoming VPN connections from some number of clients. (I do 
realize that client/server only really applies to TLS-mode, by client I 
really just mean the machine that will initialize the connection, the 
one that will be started with --remote)  However I am not sure how to 
best implement this since I don't know the number of clients in 
advance, so I can't really have a port assigned to each client. Instead 
I would like to have all clients to connect to the server on the same 
port. I did not however find a way to do so with OpenVPN. When I tried 
to have to have two clients connect to the same server, they just kept 
periodically knocking each other off with error messages of the sort:
105: TLS Error: Unroutable control packet received from 
192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1)
So I guess my question is, is it supposed to work? The man page says 
that you "should" have all the connections use a different port, which 
would imply that it is possible to do the opposite, but I was not able 
to get it to work....
If it is not possible, as far as I understand it should not be too hard 
to implement... We could have the server start out bound to the 
listening port, but not connected, and when we get an incoming 
connection from some ip, we fork and call connect in the child, so that 
in the future all packets from that ip would go to that process. Right?

Would this work? Is there a better way to accomplish this?

--
Thanks in advance,
	mag
  

Re: [Openvpn-devel] Replay attacks

[James Y. <ji...@nt...>]

Hi Michael,

You are right that it is not difficult for an attacker to replay UDP
datagrams.  OpenVPN uses a variant of the "sliding-window" algorithm used by
IPSec where each packet is tagged with a unique, incrementing sequence
number, allowing any replayed datagrams to be identified and dropped.

Various methods are used to ensure the uniqueness of the sequence number.
To prevent the sequence number from wrapping around in static-key mode
(which uses a long-term, pre-shared key), the sequence number is 64 bits,
where 32 bits is a unix timestamp at daemon initialization and the other 32
bits is an incrementing number.  If the incrementing number wraps to 0, then
we also update the unix timestamp to the current time.  In TLS mode we use
32 bits for the sequence number, with a mandatory re-keying if the sequence
number approaches its wrap around value.  See packet_id.c for the
anti-replay algorithm.

While it is true that block cipher chaining is made more complex due to the
unreliable nature of UDP transport (where packets can be dropped or received
out-of-order), OpenVPN (and IPSec as well)make each datagram atomic and
stateless by using an "Explicit IV" where the initialiation vector is
explicitly recorded in the datagram header, rather than being implicitly
assumed based on the residual IV of the previous datagram.  This means that
datagrams can be decrypted regardless of the order in which they are
received.  In CBC cipher mode (the default in OpenVPN), the initial IV on
daemon initialization is randomized, and each subsequent datagram is
encrypted using the current key and the residual IV of the previous
datagram.  The uncertainty in the IV combined with the uniqueness of the
sequence number ensures that it is highly unlikely that two identical
plaintext blocks would encrypt to the same ciphertext.  OFB and CFB cipher
modes handle the IV slightly differently (using the sequence number as the
IV) to ensure that IV collisions never occur. Most of the IV logic can be
found in crypto.c.

Cut and paste attacks where the datagram ciphertext is modified are made
infeasable by the use of a keyed HMAC hash controlled by the --auth option.
For several papers on HMAC, see:

http://www.cs.ucsd.edu/users/mihir/papers/hmac.html

Note that OpenVPN takes the HMAC of the ciphertext rather than the
plaintext, so it is not vulnerable to the ssh exploit described here:

http://openvpn.sourceforge.net/papers/ssh-security.pdf

For additional discussion into the problems of encrypting and authenticating
an unreliable data stream (such as UDP), check out the IPSec ESP spec:

http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt

OpenVPN borrows much in the way of theory and concepts from IPSec with the
goal of producing a portable, lightweight, user-space VPN implementation.
Since IPSec must also deal with securing an unreliable data stream, several
concepts have been transferable such as sliding window-based replay
protection and explicit IV.

For additional theoretical documentation you might want to check out the
book Applied Cryptography by Bruce Schneier, which while being an extremely
well-written practical guide to cryptography, contains references to a great
deal of theoretical material.

James

----- Original Message -----
From: "Michael Grigoriev" <ma...@ni...>
To: <ope...@li...>
Sent: Thursday, July 18, 2002 4:04 PM
Subject: [Openvpn-devel] Replay attacks


> Hi all,
>
> I am wondering how OpenVPN overcomes the inherit vulnerability of UDP
> comunications to "replay" or "cut-and-paste" attacks, since it is
> impossible to implement cipher block chaining.
> Also, if anybody could point me to any theoretical documentation on the
> subject, it would be greatly appreciated.
> Thanks in advance,
> -- mag
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: [Openvpn-devel] Replay attacks

[Alberto G. I. <ag...@ag...>]

On Thu, Jul 18, 2002 at 05:04:30PM -0500, Michael Grigoriev wrote:
> Hi all,
> 
> I am wondering how OpenVPN overcomes the inherit vulnerability of UDP 
> comunications to "replay" or "cut-and-paste" attacks, since it is 
> impossible to implement cipher block chaining.
> Also, if anybody could point me to any theoretical documentation on the 
> subject, it would be greatly appreciated. 
> Thanks in advance,
> 	-- mag

From the man page:
--no-replay
Disable OpenVPN's protection against replay attacks.  Don't use this option unless you are prepared to make a tradeoff of greater efficiency in
exchange for less security.

OpenVPN provides datagram replay protection by default.

Replay  protection is accomplished by tagging each outgoing datagram with an identifier that is guaranteed to be unique for the key being used.
The peer that receives the datagram will check for the uniqueness of the identifier.  If the identifier was  already  received  in  a  previous
datagram,  OpenVPN  will drop the packet.  Replay protection is important to defeat attacks such as a SYN flood attack, where the attacker lis­
tens in the wire, intercepts a TCP SYN packet (identifying it by the context in which it occurs in relation to other packets), then floods  the
receiving peer with copies of this packet.

OpenVPN's replay protection is implemented in slightly different ways, depending on the key management mode you have selected.

In  Static  Key mode or when using an CFB or OFB mode cipher, OpenVPN uses a 64 bit unique identifier that combines a time stamp with an incre­
menting sequence number.

When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses only a 32 bit sequence number without a time stamp, since OpenVPN  can
guarantee the uniqueness of this value for each key.  As in IPSec, if the sequence number is close to wrapping back to zero, OpenVPN will trig­
ger a new key exchange.

To check for replays, OpenVPN uses the sliding window algorithm used by IPSec.


Regards,

Alberto

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
ag...@ag...                     | to obtain a little temporary safety
Encrypted mail preferred       | deserve neither liberty nor safety.

Key fingerprint = 9782 04E7 2B75 405C F5E9  0C81 C514 AF8E 4BA4 01C3

[Openvpn-devel] Replay attacks

[Michael G. <ma...@ni...>]

Hi all,

I am wondering how OpenVPN overcomes the inherit vulnerability of UDP 
comunications to "replay" or "cut-and-paste" attacks, since it is 
impossible to implement cipher block chaining.
Also, if anybody could point me to any theoretical documentation on the 
subject, it would be greatly appreciated. 
Thanks in advance,
	-- mag

[Openvpn-devel] 1.3.1 released due to oops

[James Y. <ji...@nt...>]

1.3.0 had a small bug in openvpn.spec and openvpn.init that caused an RPM
upgrade failure.

This bug is fixed in 1.3.1.

1.3.1 Release Notes:

If you are trying to upgrade OpenVPN via an RPM package, there is a bug in
the RPM uninstall script from 1.2.1 that doesn't handle RPM upgrades
properly. The fix is to uninstall and reinstall using rpm -e and rpm -i.
Once the 1.3.1 RPM is installed, then future RPM upgrades will work
correctly, including the automatic restart logic that will shut down open
tunnels and reopen them with the new version (using the openvpn.init
script).

James

[Openvpn-devel] OpenVPN 1.3.0 Released

[James Y. <ji...@nt...>]

Download:

http://sourceforge.net/projects/openvpn/

Release Notes:

This is a housekeeping release containing minor fixes and finishing touches
on larger features introduced in previous versions. The version number has
incremented to 1.3.x due to a change in default MTU values.

The default values for --udp-mtu and --tun-mtu have been lowered to 1300 as
a conservative measure to reduce the possibility of packet fragmentation and
loss for users who do not explicitly set a value.

If you are using OpenVPN 1.3.0 to connect to previous versions of OpenVPN,
you should set the MTU explicitly on both peers, keeping in mind that in
pre-1.3.0 versions of OpenVPN, --udp-mtu defaulted to 1500 and --tun-mtu
defaulted to 1450.

Change Log from 1.2.1 -> 1.3.0:

* Added --dev-node option to allow explicit selection of
  tun/tap device node.
* Removed mlockall call from child thread, as it doesn't
  appear to be necessary (child thread inherits mlockall
  state from parent).
* Added --ping-timer-rem which causes timer for --ping-exit
  and --ping-restart not to run unless we have a remote IP
  address.
* Added condrestart to openvpn.init and openvpn.spec
  (Bishop Clark).
* Added --ifconfig case for FreeBSD (Matthias Andree).
* Call openlog with facility=LOG_DAEMON (Matthias Andree).
* Changed LOG_INFO messages to LOG_NOTICE.
* Added warning when key files are group/others accessible.
* Added --single-session flag for TLS mode.
* Fixed bug where --writepid would segfault if used with
  an invalid filename.
* Fixed bug where --ipchange status message was formatted
  incorrectly.
* Print more concise error message when system() call
  fails.
* Added --disable-occ option.
* Added --local, --remote, and --ifconfig options sanity
  check.
* Changed default UDP MTU to 1300 and TUN/TAP MTU to
  1300.
* Successfully tested with OpenSSL 0.9.7 Beta 2.
* Broke out debug level definitions to errlevel.h
* Minor documentation and web site changes.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0, however default
  MTU changes will require setting the MTU explicitly
  by command line option, if you want 1.3.0 to
  communicate with previous versions.

James

Re: [Openvpn-devel] Default MTU

[Matthias A. <mat...@st...>]

On Sun, 07 Jul 2002, James Yonan wrote:

> (1) Static, pre-shared key mode is stateless and handshake-free, so there
> isn't really an existing context in which PMTU discovery could be
> implemented.

Must the MTU be known to the protocol after all? It might be assymmetric
when asymmetric routing (satellite downlink with ISDN uplink) is in
place.

Is not it sufficient if your own secure PMTU discovery is done
independently for either side? Sorry, I'm still not acquainted with the
OpenVPN protocol for lack of time.

> (2) Path MTU discovery could work in TLS mode, however every time the the
> MTU changes, the tun or tap device would need to be re-ifconfiged -- this
> might also involve closing and reopening the tun device which would fail =
if
> root privileges have been dropped.

If you do it in the application, yes. If you leave it to the kernel,
then it's not necessary.

> So at this point a static default is certainly the simpler way to go, but
> any changes to the static default should be carefully considered since th=
ey
> would introduce backward incompatibility issues.

--=20
Matthias Andree

Re: [Openvpn-devel] Default MTU

[James Y. <ji...@nt...>]

On 8 Jul 2002, Jan Johansson wrote:

> On Sun, 2002-07-07 at 22:19, James Yonan wrote:
> > What should the default MTU be?
> > 
> > Right now the default UDP MTU is 1500 if you use --ifconfig, which is
> > probably too high, because as Matthias Andree pointed out, 1500 + IP header
> > size is greater than 1500 and will cause fragmentation on ethernet networks
> > where the MTU is 1500.
> > 
> > 1450 might make more sense because that leaves ample space for the IP
> > header, forming a total packet size of less than 1500.
> 
> > So at this point a static default is certainly the simpler way to go, but
> > any changes to the static default should be carefully considered since they
> > would introduce backward incompatibility issues.
> 
> I'd go for 1300 or so. Even if 1450 works now, you could still encounter
> more issues later that require another change. I don't think the
> performance loss will be that great, since all that run TLS now with
> 1500-ish packetsizes probably already split lots of packets into one
> large and one tiny packet as it is.

I'm inclined to agree that the default MTU should be set conservatively 
low so it has a high probability of working, even if it is slightly less 
efficient.

Once somebody has a setup working, they will be in a better position to 
optimize the MTU to their liking.
 
> If you are to go for new major version that breaks compat, go for lower
> defaults on MTU too. You might aswell backport some sort of small logic
> for the older OpenVPN-track that tries the lower MTU in case it seems
> like it doesn't work, or a "--compat-v2" setting.

I plan to increment the version number to 1.3.0 due to the default MTU
change, though there won't be any other breaks in compatibility, and of 
course 1.3.0 will be able to talk to previous versions simply by defining 
MTU size explicitly in the config.

James

[Openvpn-devel] Re: OpenVPN and UDP fragmentation

[James Y. <ji...@nt...>]

On Mon, 8 Jul 2002, Matthias Andree wrote:

> On Tue, 02 Jul 2002, James Yonan wrote:
> 
> > At one point I considered using adaptive code to automatically set the
> > MTU, then I read a paper that described various DoS attacks against common
> > path MTU discovery algorithms, so I held off on that.
> 
> Is not the kernel itself also susceptible in that case unless PMTU
> discovery is disabled for that route?

Right, you would need to set the Don't Fragment bit in the socket to 
disable the kernel's PMTU then implement your own secure PMTU.

> 
> OTOH, I haven't read a single paper on PMTU discovery DoS attacks, so
> I cannot comment on the details.

http://www.off.net/~jme/ietf/draft-etienne-secure-pmtud-00.txt

> 
> > It would be great if there was an easy way of getting the dynamic path MTU 
> > from the OS, but I'm not aware of any portable method to do this.
> > 
> > While reducing the default to 1472 or lower might work, it would also
> > break compatibility...  right now we can brag that the protocol hasn't
> > changed since 1.1.0, and while this isn't really a protocol change, it
> > does introduce a slight incompatibility with prior versions.  I would
> > prefer to hold off on patches that break compatibility until 1.3.0.
> 
> Sure. Documenting that the admin who sets up OpenVPN should experiment
> with the UDP-MTU and lower it until no fragmentation occurs is fine with
> me.
> 
> > > If OpenVPN adapting the UDP MTU, I'd appreciate if the adaption progress
> > > would be logged akin to LZO adaption.
> > 
> > There is a common algorithm known as Path MTU Discovery where you set the 
> > Don't Fragment bit on the socket then figure out by heuristics the largest 
> > packet size that will get through.  But it would be better to let the OS 
> > figure this out and then tell us in a portable way, if this is possible.
> 
> Yes. I recently made some experiences with obtaining interface/netmask
> configuration. Don't try this for IPv6, it'll boggle your mind. Each
> system has its own approach. Netlink, a "long" SIOCGIFNETMASK variant,
> whatever.
> 
> > > Again, please apologize if I wrote nonsense, I'm not really aware of the
> > > packet encapsulation and framing process in OpenVPN.
> > 
> > No, your ideas are good.  In fact I would vote that we move these 
> > discussions to openvpn-devel so that more people can participate.
> 
> OK, I'll look at that list then. Feel free to bounce this mail and my
> last one there so people know what we're talking about.
> 
> Thanks,
> 
> 

Re: [Openvpn-devel] Default MTU

[Jan J. <jan...@bi...>]

On Sun, 2002-07-07 at 22:19, James Yonan wrote:
> What should the default MTU be?
>=20
> Right now the default UDP MTU is 1500 if you use --ifconfig, which is
> probably too high, because as Matthias Andree pointed out, 1500 + IP head=
er
> size is greater than 1500 and will cause fragmentation on ethernet networ=
ks
> where the MTU is 1500.
>=20
> 1450 might make more sense because that leaves ample space for the IP
> header, forming a total packet size of less than 1500.

> So at this point a static default is certainly the simpler way to go, but
> any changes to the static default should be carefully considered since th=
ey
> would introduce backward incompatibility issues.

I'd go for 1300 or so. Even if 1450 works now, you could still encounter
more issues later that require another change. I don't think the
performance loss will be that great, since all that run TLS now with
1500-ish packetsizes probably already split lots of packets into one
large and one tiny packet as it is.

If you are to go for new major version that breaks compat, go for lower
defaults on MTU too. You might aswell backport some sort of small logic
for the older OpenVPN-track that tries the lower MTU in case it seems
like it doesn't work, or a "--compat-v2" setting.

--=20
Jan Johansson (jan...@bi...)
BioMat System AB
Klarabergsgatan 37, III
SE-111 21 Stockholm, Sweden
Phone: +46-(0)8-233500, Fax: +46-(0)70-3873952

THIS COMMUNICATION IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL, OR
ENTITY, TO WHICH IT IS DIRECTED AND MAY CONTAIN INFORMATION THAT IS
PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM DISCLOSURE UNDER APPLICABLE
LAW.  IF RECEIVED IN ERROR: PLEASE NOTIFY US IMMEDIATELY THROUGH
IN...@BI....

[Openvpn-devel] new beta available

[James Y. <ji...@nt...>]

Download:

http://openvpn.sourceforge.net/beta/openvpn-1.2.1.10.tar.gz

Changes since 1.2.1:

* Added --dev-node option to allow explicit selection of
  tun/tap device node.
* Removed mlockall call from child thread, as it doesn't
  appear to be necessary (child thread inherits mlockall
  state from parent).
* Added --ping-timer-rem which causes timer for --ping-exit
  and --ping-restart not to run unless we have a remote IP
  address.
* Added condrestart to openvpn.init and openvpn.spec
  (Bishop Clark).
* Added --ifconfig case for FreeBSD (Matthias Andree).
* Call openlog with facility=LOG_DAEMON (Matthias Andree).
* Changed LOG_INFO messages to LOG_NOTICE.
* Added warning when key files are group/others accessible.
* Added --single-session flag for TLS mode.
* Fixed bug where --writepid would segfault if used with
  an invalid filename.
* Fixed bug where --ipchange status message was formatted
  incorrectly.
* Print more concise error message when system() call
  fails.
* Added --disable-occ option.
* Added --local, --remote, and --ifconfig options sanity
  check.
* Changed default UDP MTU to 1450 and TUN/TAP MTU to
  1400.
* Successfully tested with OpenSSL 0.9.7 Beta 2.
* Broke out debug level definitions to errlevel.h
* Minor documentation and web site changes.
* All changes maintain protocol compatibility
  with OpenVPN versions since 1.1.0, however default
  MTU changes will require setting the MTU explicitly
  by command line option, if you want MYVERSION to
  communicate with previous versions.

James

[Openvpn-devel] Default MTU

[James Y. <ji...@nt...>]

What should the default MTU be?

Right now the default UDP MTU is 1500 if you use --ifconfig, which is
probably too high, because as Matthias Andree pointed out, 1500 + IP header
size is greater than 1500 and will cause fragmentation on ethernet networks
where the MTU is 1500.

1450 might make more sense because that leaves ample space for the IP
header, forming a total packet size of less than 1500.

Then again there are arguments for even lower values, 1350 or 1300 to allow
multiple levels of encapsulation such as PPPoE, IP, ethernet, etc.

It would also be possible to set the MTU automatically through some sort of
initial or ongoing handshake that does secure pings of various packet sizes
with the Don't Fragment bit set to determine the optimal MTU for the path
(i.e. Secure Path MTU Discovery).

With OpenVPN however, there are some complications to the automatic Path MTU
discovery approach:

(1) Static, pre-shared key mode is stateless and handshake-free, so there
isn't really an existing context in which PMTU discovery could be
implemented.

(2) Path MTU discovery could work in TLS mode, however every time the the
MTU changes, the tun or tap device would need to be re-ifconfiged -- this
might also involve closing and reopening the tun device which would fail if
root privileges have been dropped.

(3) Path MTU discovery in a secure application such as a VPN must itself be
secure to protect against DoS attacks, so the standard garden-variety PMTU
approaches that depend on return ICMP packets probably won't work securely
or reliably.

So at this point a static default is certainly the simpler way to go, but
any changes to the static default should be carefully considered since they
would introduce backward incompatibility issues.

Comments?

James