openvpn-devel — OpenVPN developers list

Re: [Openvpn-devel] Pre-1.3.3 beta available for testing

[Matthias A. <ma+...@dt...>]

On Sun, 16 Feb 2003, James Yonan wrote:

> Beta is available on CVS as well as here:
> 
> http://openvpn.sourceforge.net/beta/openvpn-1.3.2.9.tar.gz

I tried the current CVS as of some minutes ago on Linux, Solaris and
FreeBSD.  This first mail is about Linux, Solaris status is in a
separate mail.

This mail has four sections.

1. Here are important complaints of my compiler (SuSE 8.1, gcc 3.2, with
lzo):

packet_id.c: In function `packet_id_add':
packet_id.c:67: warning: comparison between signed and unsigned
socket.c: In function `getaddr':
socket.c:69: warning: comparison between signed and unsigned
tun.c:254: warning: `open_tun_generic' defined but not used

2. SuSE 7.3, gcc 2.95, without lzo installed is a no-go despite
--disable-lzo:

source='/home/ma/tmp/openvpn/lzo.c' object='lzo.o' libtool=no \
depfile='.deps/lzo.Po' tmpdepfile='.deps/lzo.TPo' \
depmode=gcc /bin/sh /home/ma/tmp/openvpn/depcomp \
gcc -DHAVE_CONFIG_H -I. -I/home/ma/tmp/openvpn -I.     -g -O2 -c `test -f '/home/ma/tmp/openvpn/lzo.c' || echo '/home/ma/tmp/openvpn/'`/home/ma/tmp/openvpn/lzo.c
In file included from /home/ma/tmp/openvpn/lzo.c:32:
/home/ma/tmp/openvpn/lzo.h:28: lzo1x.h: No such file or directory
make[1]: *** [lzo.o] Error 1

I tracked this down to flaws in the Makefile.am that ships a config.h
(which breaks VPATH builds). Here's a patch to rectify this and to
enable you to "make dist" to get the tarball with all subdirectories
included:


Index: openvpn.spec
===================================================================
RCS file: /cvsroot/openvpn/openvpn/openvpn.spec,v
retrieving revision 1.59
diff -u -r1.59 openvpn.spec
--- openvpn.spec	16 Feb 2003 19:01:49 -0000	1.59
+++ openvpn.spec	19 Feb 2003 13:34:48 -0000
@@ -22,7 +22,6 @@
 %setup -q
 
 %build
-./pre-touch
 %configure --enable-pthread
 %__make
 
Index: Makefile.am
===================================================================
RCS file: /cvsroot/openvpn/openvpn/Makefile.am,v
retrieving revision 1.3
diff -u -r1.3 Makefile.am
--- Makefile.am	25 Jun 2002 06:56:16 -0000	1.3
+++ Makefile.am	19 Feb 2003 13:24:25 -0000
@@ -24,9 +24,23 @@
 #
 
 sbin_PROGRAMS = openvpn
-openvpn_SOURCES = basic.h buffer.c buffer.h circ_list.h common.h config.h crypto.c crypto.h errlevel.h error.c error.h fdmisc.c fdmisc.h gremlin.c gremlin.h interval.h lzo.c lzo.h memdbg.h misc.c misc.h mtu.h openvpn.c openvpn.h options.c options.h packet_id.c packet_id.h reliable.c reliable.h session_id.c session_id.h shaper.c shaper.h socket.c socket.h ssl.c ssl.h syshead.h thread.c thread.h tun.c tun.h
+nodist_openvpn_SOURCES = config.h
+openvpn_SOURCES = basic.h buffer.c buffer.h circ_list.h common.h \
+		  crypto.c crypto.h errlevel.h error.c error.h \
+		  fdmisc.c fdmisc.h gremlin.c gremlin.h interval.h \
+		  lzo.c lzo.h memdbg.h misc.c misc.h mtu.h openvpn.c \
+		  openvpn.h options.c options.h packet_id.c \
+		  packet_id.h reliable.c reliable.h session_id.c \
+		  session_id.h shaper.c shaper.h socket.c socket.h \
+		  ssl.c ssl.h syshead.h thread.c thread.h tun.c tun.h
 
 KEY_FILES = dh1024.pem client.crt client.key server.crt server.key tmp-ca.crt tmp-ca.key
 
 man_MANS = openvpn.8
-EXTRA_DIST = $(KEY_FILES)
+EXTRA_DIST = $(KEY_FILES) $(man_MANS) \
+	     COPYRIGHT.GPL PORTS openvpn.spec \
+	     easy-rsa sample-config-files sample-keys \
+	     sample-scripts
+
+dist-hook:
+	cd $(distdir) && for i in $(EXTRA_DIST) ; do find $$i -name CVS -type d -prune -exec rm -r '{}' ';' ; done

3. I also suggest this patch to enhance portability, particularly for older,
possibly non-gcc, configurations:

Index: configure.ac
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure.ac,v
retrieving revision 1.51
diff -u -r1.51 configure.ac
--- configure.ac	16 Feb 2003 19:01:49 -0000	1.51
+++ configure.ac	19 Feb 2003 12:46:32 -0000
@@ -137,8 +137,11 @@
 dnl Checks for typedefs, structures, and compiler characteristics.
 AC_C_CONST
 AC_C_INLINE
+AC_C_VOLATILE
+AC_TYPE_OFF_T
 AC_TYPE_PID_T
 AC_TYPE_SIZE_T
+AC_TYPE_UID_T
 AC_HEADER_TIME
 
 dnl Check for more header files.

4. don't use autogen.sh, it has been superseded by "autoreconf". Try
   autoreconf -i -v (be chary about passing -f, it will kill your COPYING and
   INSTALL files!)

   I think you then don't need pre-touch either. In fact, I usually discourage
   keeping generated files in CVS. They only bloat things and cause unnecessary
   rebuilds and commits.

   Please consider doing:
   cvs rm -f Makefile.in aclocal.m4 config.h.in configure
   cvs rm -f config.guess config.sub depcomp install-sh missing
   cvs rm -f mkinstalldirs
   cvs commit -m "Remove generated files from CVS."

-- 
Matthias Andree

[Openvpn-devel] Pre-1.3.3 beta available for testing

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

Hello OpenVPN Users & Developers,

I thought it would be a good time to wrap up the minor fixes that have gone
into the codebase over the last couple months.

So here's a beta which I would encourage you to test as much as possible. 
While the changes are mostly minor, some of the fixes such as --tun-mtu-extra
resulted in major changes to the MTU sizing algorithm.  As well, I have only
built for RH Linux in my testing, so please test on other OSes, distros,
processor architectures, etc.

Beta is available on CVS as well as here:

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

Change Log:

2003.02.16 -- Version 1.3.2.9

* Added --replay-persist feature to allow replay
  protection across sessions.
* Fixed bug where --ifconfig could not be used
  with --tun-mtu.
* Added --tun-mtu-extra parameter to deal with
  the situation where a read on a TUN/TAP device
  returns more data than the device's MTU size.
* Fixed bug where some IPv6 support code for
  Linux was not being properly ifdefed out for
  Linux 2.2, causing compile errors.
* Added OPENVPN_EXIT_STATUS_x codes to
  openvpn.h to control which status value
  openvpn returns to its caller (such as
  a shell or inetd/xinetd) for various conditions.
* Added OPENVPN_DEBUG_COMMAND_LINE flag to
  openvpn.h to allow debugging in situations
  where stdout, stderr, and syslog cannot be used
  for message output, such as when OpenVPN is
  instantiated by inetd/xinetd.
* Removed owner-execute permission from file
  created by static key generator (Herbert Xu
  and Alberto Gonzalez Iniesta).
* Added --passtos option to allow IPv4 TOS bits
  to be passed from TUN/TAP input packets to
  the outgoing UDP socket (Craig Knox).
* Added code to prevent open socket file descriptors
  from being accessible to called scripts.

James

Re: [Openvpn-devel] Opened file descriptors in script calls

[Aaron S. <and...@ra...>]

On Mon, 10 Feb 2003, Christoph Pfisterer wrote:
>
>    fcntl(fd, F_SETFD, FD_CLOEXEC);
>
> Ideally, one would do this for each file descriptor as it is opened.
>

Yeah I hadn't thought about that, James already added this to the CVS
tree.

Aaron

Re: [Openvpn-devel] Opened file descriptors in script calls

[Aaron S. <and...@ra...>]

On Tue, 11 Feb 2003, James Yonan wrote:
> /* Set a file descriptor to not be passed across execs */
> void
> set_cloexec (int fd)
> {
>   if (fcntl (fd, F_SETFD, FD_CLOEXEC) < 0)
>     msg (M_ERR, "Set file descriptor to FD_CLOEXEC failed");
> }
>
> Just set the FD_CLOEXEC flag on the fd and it won't be passed across the exec
> that runs the shell.

That works even better then :)

Regards,

Aaron

Re: [Openvpn-devel] Opened file descriptors in script calls

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

Aaron Sethman <and...@ra...> said:

> On Mon, 10 Feb 2003, Alberto Gonzalez Iniesta wrote:
> 
> >
> > Hi,
> >
> > Again, I'm no C hacker, but I think this should be better:
> >
> > for(x = 3; x < 100; x++)
> >
> > Since the first 3 fds (stdin, stdout and stderr) should be kept open.
> >
> Wasn't sure if stdin, stdout and stderr needed to be left open or not in
> this case.  Obviously this is an easy fix :)

Actually, I was just thinking what a pain to have to reimplement system() just
to close a few fds.  There must be a better way, and as it turns out, there is:

/* Set a file descriptor to not be passed across execs */
void
set_cloexec (int fd)
{
  if (fcntl (fd, F_SETFD, FD_CLOEXEC) < 0)
    msg (M_ERR, "Set file descriptor to FD_CLOEXEC failed");
}

Just set the FD_CLOEXEC flag on the fd and it won't be passed across the exec
that runs the shell.

I already wrote the patch and it's in the CVS.

James

Re: [Openvpn-devel] Opened file descriptors in script calls

[Aaron S. <and...@ra...>]

On Mon, 10 Feb 2003, Alberto Gonzalez Iniesta wrote:

>
> Hi,
>
> Again, I'm no C hacker, but I think this should be better:
>
> for(x = 3; x < 100; x++)
>
> Since the first 3 fds (stdin, stdout and stderr) should be kept open.
>
Wasn't sure if stdin, stdout and stderr needed to be left open or not in
this case.  Obviously this is an easy fix :)

Regards,

Aaron

Re: [Openvpn-devel] Opened file descriptors in script calls

[Wolfgang O. <we...@re...>]

On Mon, 2003-02-10 at 02:01, Aaron Sethman wrote:
> Here is a simple little replacement for system() that does close file
> descriptors.  The main issue with it is though, it ends up picking an
> arbitrary number of fds to close.  I picked closing 0 to 99.

You can use getdtablesize() to determine the maximum number of open files
available to the process.

Wolfgang

Re: [Openvpn-devel] Opened file descriptors in script calls

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

On Sun, Feb 09, 2003 at 08:01:12PM -0500, Aaron Sethman wrote:
> 
> Here is a simple little replacement for system() that does close file
> descriptors.  The main issue with it is though, it ends up picking an
> arbitrary number of fds to close.  I picked closing 0 to 99.
> 
> Aaron
> 
> 
> int s_system(const char *string)
> {
> 	pid_t pid;
> 	int x;
>  	pid = fork()
> 
>  	if(pid == -1)
>  	{
>          	return -1;
>  	}
> 
>  	if(pid > 0)
>  	{
>  	 	int status;
>          	wait(&status);
>          	return(status);
>         }
> 
>         for(x = 0; x < 100; x++)
>  	{
>  		close(x);
>  	}
>         execlp("/bin/sh", "-c", string);
> 
> }
> 

Hi,

Again, I'm no C hacker, but I think this should be better:

for(x = 3; x < 100; x++)

Since the first 3 fds (stdin, stdout and stderr) should be kept open.

Regards,

Alberto


-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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

Re: [Openvpn-devel] Opened file descriptors in script calls

[Christoph P. <cp...@ch...>]

Aaron Sethman wrote:

> Here is a simple little replacement for system() that does close file
> descriptors.  The main issue with it is though, it ends up picking an
> arbitrary number of fds to close.  I picked closing 0 to 99.

I don't think this is necessary. Every file descriptor has a "close on 
exec" flag that you can set with fcntl(). Then, you can use plain 
system(). It should work like this:

   fcntl(fd, F_SETFD, FD_CLOEXEC);

Ideally, one would do this for each file descriptor as it is opened.

Hope this helps,
chrisp

-- 
chrisp a.k.a. Christoph Pfisterer   "A computer scientist is
cp...@ch... - http://chrisp.de      someone who fixes things
PGP key & geek code available        that aren't broken."

Re: [Openvpn-devel] Opened file descriptors in script calls

[Aaron S. <and...@ra...>]

Here is a simple little replacement for system() that does close file
descriptors.  The main issue with it is though, it ends up picking an
arbitrary number of fds to close.  I picked closing 0 to 99.

Aaron


int s_system(const char *string)
{
	pid_t pid;
	int x;
 	pid = fork()

 	if(pid == -1)
 	{
         	return -1;
 	}

 	if(pid > 0)
 	{
 	 	int status;
         	wait(&status);
         	return(status);
        }

        for(x = 0; x < 100; x++)
 	{
 		close(x);
 	}
        execlp("/bin/sh", "-c", string);

}

Re: [Openvpn-devel] Opened file descriptors in script calls

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

Alberto,

Yes, I agree.  The child process that executes a script doesn't need those
file descriptors, so they can be closed.  Since openvpn uses the system()
function to run scripts, and because the system() function doesn't close any
file descriptors on its own, it would be necessary to write an alternate
version of the function (unless it already exists somewhere) which closes the
file descriptors between the fork and the execve calls.

James

Alberto Gonzalez Iniesta <ag...@in...> said:

> Hi,
> 
> I got another bug report on Debian's openvpn package. It states that
> openvpn's file descriptors are kept open while scripts are called. It
> claims they should be closed. My C knowledge is far from make a patch
> for this one :) And maybe you don't agree with this (James?).
> 
> You can see the report here:
> 
> http://bugs.debian.org/179551
> 
> Thanks.
> 
> -- 
> Alberto Gonzalez Iniesta       | They that give up essential liberty
> agi@(agi.as|debian.org)        | 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
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] Opened file descriptors in script calls

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

Hi,

I got another bug report on Debian's openvpn package. It states that
openvpn's file descriptors are kept open while scripts are called. It
claims they should be closed. My C knowledge is far from make a patch
for this one :) And maybe you don't agree with this (James?).

You can see the report here:

http://bugs.debian.org/179551

Thanks.

-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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

Re: [Openvpn-devel] Trimmed down permissions for generated keys

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

Hi Alberto,

Yes, I agree.  The owner-execute permission is unnecessary.  I will add patch
to next release.

James

Alberto Gonzalez Iniesta <ag...@in...> said:

> Hi James et al!
> 
> Intro
> -----
> openvpn creates pre-shared secret files, for latter use in static key
> encryption mode (non-TLS), with the --genkey option
> 
> The minor/anecdotal glitch
> --------------------------
> 
> The permissions for the created file may be/seem to be excessive (0700)
> Pointed out by Herbert Xu <he...@go...> [1]
> 
> The patch
> ---------
> 
> --- openvpn-1.3.2.orig/crypto.c
> +++ openvpn-1.3.2/crypto.c
> @@ -968,7 +968,7 @@
>    struct buffer out = alloc_buf_gc (512);
> 
>    /* open key file */
> -  fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRWXU);
> +  fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
>    if (fd == -1)
>      msg (M_ERR, "Cannot open shared secret file %s for write", filename);
> 
> 
> Let me know if you like it/agree, James. Thanks,
> 
> Alberto
> 
> 
> 
> [1] http://bugs.debian.org/178849
> 
> (PS. I resent this mail, since I first sent it from the wrong address,
> sorry James)
> -- 
> Alberto Gonzalez Iniesta       | They that give up essential liberty
> agi@(agi.as|debian.org)        | 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
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] Trimmed down permissions for generated keys

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

Hi James et al!

Intro
-----
openvpn creates pre-shared secret files, for latter use in static key
encryption mode (non-TLS), with the --genkey option

The minor/anecdotal glitch
--------------------------

The permissions for the created file may be/seem to be excessive (0700)
Pointed out by Herbert Xu <he...@go...> [1]

The patch
---------

--- openvpn-1.3.2.orig/crypto.c
+++ openvpn-1.3.2/crypto.c
@@ -968,7 +968,7 @@
   struct buffer out = alloc_buf_gc (512);

   /* open key file */
-  fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRWXU);
+  fd = open (filename, O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
   if (fd == -1)
     msg (M_ERR, "Cannot open shared secret file %s for write", filename);


Let me know if you like it/agree, James. Thanks,

Alberto



[1] http://bugs.debian.org/178849

(PS. I resent this mail, since I first sent it from the wrong address,
sorry James)
-- 
Alberto Gonzalez Iniesta       | They that give up essential liberty
agi@(agi.as|debian.org)        | 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] Linux kernel crashes when incoming/outgoing paths differ

[Eric E. B. <er...@bo...>]

[i'm resending this... sorry if it appears twice]

Hi there,

I've been experiencing kernel crashes with OpenVPN on Linux under a 
certain set of conditions, and wondered if anybody else (James?) can 
reproduce this.

Here are the steps needed to cause the crash:

  1. Create an OpenVPN TUN link between two hosts, Host-A and Host-B.

  2. Add an iptables rule to Host-A to REJECT connections from unauthorized 
     networks, generating an ICMP port unreachable.  Typically, this would
     be the "default deny" rule in a firewall, for example:

       iptables -A reject -j REJECT --reject-with icmp-port-unreachable

  3. Make a TCP connection (e.g., ssh) from Host-B to Host-A's tunnel
     interface, using a source address for which Host-A:
       (a) doesn't have a route directed across the tunnel, and
       (b) doesn't explicitly permit (so that the iptables rule above will 
           apply)

     [The connection doesn't have to be made to Host-A's tunnel interface; it 
      could be to any interface on Host-A that causes the connection to 
      traverse the tunnel from Host-B to Host-A.]

What I think is happening is this: when an incoming connection arrives
on Host-A's TUN interface, the REJECT rule is triggered, causing an 
"ICMP unreachable" to be sent back.  However, since there is no return 
route back across the tunnel, the default route is selected, which causes 
the ICMP packet to be <<returned on an interface that is different from the
incoming interface>> (i.e., the tunnel).  Since the incoming (tun) and 
outgoing (eth) interfaces have different link layer header sizes, the 
kernel is crashing in skb_push().

Software:
  openvpn 1.3.1.7, 1.3.2, 1.3.2.5
  linux kernel 2.4.19, 2.4.20
  iptables 1.2.7a
  iptables patch-o-matic 20020930, 20021127

I've attached the kernel oops output below.

I hope I've provided sufficient information to reproduce the crash.
Please let me know if you need more information, since I'm interested
in helping solve this problem.

Thanks,

--eric

===========================================================================
% kernel BUG at skbuff.c:109!
invalid operand: 0000
CPU:    0
EIP:    0010:[<c01c5627>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010282
eax: 00000028   ebx: 00000000   ecx: cf7d8000   edx: cc52f11c
esi: cc463f00   edi: 00000800   ebp: cf77f000   esp: ce531c68
ds: 0018   es: 0018   ss: 0018
Process openvpn (pid: 3954, stackpage=ce531000)
Stack: c02374a0 c01d0215 00000036 0000000e cf77f000 c01d021e cc463f00
0000000e
       c01d0215 ce927d80 cc463f00 cb58c0c0 cf77f000 c01cca1a cc463f00
cf77f000
       00000800 cb58c0e4 00000000 00000028 cc463f00 00000000 cf77f000
00000000
Call Trace:    [<c01d0215>] [<c01d021e>] [<c01d0215>] [<c01cca1a>]
[<c01ddb05>]
  [<c01cf12e>] [<c01dd975>] [<c01dda78>] [<c01cf12e>] [<d00e3384>]
[<c01dd936>]
  [<d00e7906>] [<d00e3835>] [<d00402e2>] [<d0042660>] [<d0042660>]
[<d0042660>]
  [<c01da0c6>] [<d0044080>] [<d00445c0>] [<c01cee0d>] [<c01da0c6>]
[<c01cf0ee>]
  [<c01da0c6>] [<d0044600>] [<c01d9eb5>] [<c01da0c6>] [<c01da3a9>]
[<c01cf12e>]
  [<c01da03d>] [<c01da1fa>] [<c01c9780>] [<c01c9889>] [<c01c9983>]
[<c011b6ad>]
  [<d00e1b4c>] [<d00e12d6>] [<c0132c2f>] [<c0108933>]
Code: 0f 0b 6d 00 8b 64 23 c0 83 c4 14 c3 90 a1 28 2c 2a c0 56 03


>>EIP; c01c5627 <skb_under_panic+29/36>   <=====

>>ecx; cf7d8000 <_end+f513308/fd48368>
>>edx; cc52f11c <_end+c26a424/fd48368>
>>esi; cc463f00 <_end+c19f208/fd48368>
>>ebp; cf77f000 <_end+f4ba308/fd48368>
>>esp; ce531c68 <_end+e26cf70/fd48368>

Trace; c01d0215 <eth_header+15d/16e>
Trace; c01d021e <eth_header+166/16e>
Trace; c01d0215 <eth_header+15d/16e>
Trace; c01cca1a <neigh_resolve_output+a6/198>
Trace; c01ddb05 <ip_finish_output2+8d/c4>
Trace; c01cf12e <nf_hook_slow+a0/144>
Trace; c01dd975 <ip_finish_output+3f/44>
Trace; c01dda78 <ip_finish_output2+0/c4>
Trace; c01cf12e <nf_hook_slow+a0/144>
Trace; d00e3384 <[ipt_REJECT]send_reset+308/37e>
Trace; c01dd936 <ip_finish_output+0/44>
Trace; d00e7906 <[ipt_LOG].text.end+ad/1ff>
Trace; d00e3835 <[ipt_REJECT]reject+5f/62>
Trace; d00402e2 <[ip_tables]ipt_do_table+262/2e4>
Trace; d0042660 <[ip_tables]__kstrtab_ipt_register_table+0/0>
Trace; d0042660 <[ip_tables]__kstrtab_ipt_register_table+0/0>
Trace; d0042660 <[ip_tables]__kstrtab_ipt_register_table+0/0>
Trace; c01da0c6 <ip_local_deliver_finish+0/134>
Trace; d0044080 <[iptable_filter]ipt_hook+20/24>
Trace; d00445c0 <[iptable_filter]packet_filter+0/40>
Trace; c01cee0d <nf_iterate+51/86>
Trace; c01da0c6 <ip_local_deliver_finish+0/134>
Trace; c01cf0ee <nf_hook_slow+60/144>
Trace; c01da0c6 <ip_local_deliver_finish+0/134>
Trace; d0044600 <[iptable_filter]ipt_ops+0/48>
Trace; c01d9eb5 <ip_local_deliver+35/54>
Trace; c01da0c6 <ip_local_deliver_finish+0/134>
Trace; c01da3a9 <ip_rcv_finish+1af/1fa>
Trace; c01cf12e <nf_hook_slow+a0/144>
Trace; c01da03d <ip_rcv+169/1f2>
Trace; c01da1fa <ip_rcv_finish+0/1fa>
Trace; c01c9780 <netif_receive_skb+100/1a0>
Trace; c01c9889 <process_backlog+69/104>
Trace; c01c9983 <net_rx_action+5f/ea>
Trace; c011b6ad <do_softirq+89/8c>
Trace; d00e1b4c <[tun]tun_get_user+d0/13f>
Trace; d00e12d6 <[tun]tun_chr_write+28/2c>
Trace; c0132c2f <sys_write+85/ea>
Trace; c0108933 <system_call+33/40>

Code;  c01c5627 <skb_under_panic+29/36>
00000000 <_EIP>:
Code;  c01c5627 <skb_under_panic+29/36>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c01c5629 <skb_under_panic+2b/36>
   2:   6d                        insl   (%dx),%es:(%edi)
Code;  c01c562a <skb_under_panic+2c/36>
   3:   00 8b 64 23 c0 83         add    %cl,0x83c02364(%ebx)
Code;  c01c5630 <skb_under_panic+32/36>
   9:   c4 14 c3                  les    (%ebx,%eax,8),%edx
Code;  c01c5633 <skb_under_panic+35/36>
   c:   90                        nop    
Code;  c01c5634 <alloc_skb+0/1a6>
   d:   a1 28 2c 2a c0            mov    0xc02a2c28,%eax
Code;  c01c5639 <alloc_skb+5/1a6>
  12:   56                        push   %esi
Code;  c01c563a <alloc_skb+6/1a6>
  13:   03 00                     add    (%eax),%eax

 <0>Kernel panic: Aiee, killing interrupt handler!

2 errors issued.  Results may not be reliable.
===========================================================================

Re: [Openvpn-devel] some questions

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

Hello Julien,

julien Touche <jul...@ly...> said:

> 
> Hi
> 
> first greetings for openvpn which is a best of for easy VPN :)

Thanks!

> 
> i have a small list of questions i can't answer myself:
> 
> - at which stage is the win32 port ? always looking for tun driver ?
> i give a glimpse to cipe driver which seems "simple unix2win" NDIS
> driver but 1-cannot compile (need ndis.h part of windows DDK which is
> not free download) 2-lot bigger compare to unix tun code (from vtun
> site) even if it does more 3- there is no /dev in win so what's best ?
> pipe i believe ?

I've received email from people in the past who were going to go off and write
a tun or tap driver for win32, but none were ever heard from again :(

> - is there any way to connect someone which is not-root ? for example,
> i'm at work with a desktop computer without root access (maybe even not
> sure to have tun/tap driver) but i have only two or three apps i need to
> connect to my home vpn (ssh, ftp, ...). i can modify them in order to
> send data not on a socket but a pipe (or anything else) which send data
> to a modified openvpn and send it on my home vpn.
> is it possible or i'm completely dreaming ?

It might be possible to run as non-root if you can get read/write access to
the TUN/TAP device node.

> 
> another solution is: having a list of port tunneled local (8080, 2222,
> ...) to local (9991, 9992, ...) (by stunnel for example) and the latter
> list of port i send to vpn by openvpn/nonroot
> (of course, we need to define for each local port the distant port AND
> host, but if we can change on fly, it will be ok; or maybe someone know
> a way for common user to forward all data address to a port to another
> host ?)
> 
> the tun/tap driver is only required if want a complete real network
> interface, right ? (which is necessary if we want to work with
> unmodified apps)

There's not much you can do with OpenVPN if you lack a tun/tap driver.

James

> 
> 
> Regards
> 
> 
> PS: please cc.
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] some questions

[julien T. <jul...@ly...>]

Hi

first greetings for openvpn which is a best of for easy VPN :)

i have a small list of questions i can't answer myself:

- at which stage is the win32 port ? always looking for tun driver ?
i give a glimpse to cipe driver which seems "simple unix2win" NDIS
driver but 1-cannot compile (need ndis.h part of windows DDK which is
not free download) 2-lot bigger compare to unix tun code (from vtun
site) even if it does more 3- there is no /dev in win so what's best ?
pipe i believe ?


- is there any way to connect someone which is not-root ? for example,
i'm at work with a desktop computer without root access (maybe even not
sure to have tun/tap driver) but i have only two or three apps i need to
connect to my home vpn (ssh, ftp, ...). i can modify them in order to
send data not on a socket but a pipe (or anything else) which send data
to a modified openvpn and send it on my home vpn.
is it possible or i'm completely dreaming ?

another solution is: having a list of port tunneled local (8080, 2222,
...) to local (9991, 9992, ...) (by stunnel for example) and the latter
list of port i send to vpn by openvpn/nonroot
(of course, we need to define for each local port the distant port AND
host, but if we can change on fly, it will be ok; or maybe someone know
a way for common user to forward all data address to a port to another
host ?)

the tun/tap driver is only required if want a complete real network
interface, right ? (which is necessary if we want to work with
unmodified apps)


Regards


PS: please cc.

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

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

> Hello James,
> 
> That's good to hear,
> 
> There are some questions that I had to over come with
> my experimental forking server, like when does a forked
> process exit? Should we always use something line --inactive
> or --ping-exit? Or should there be a control command for closing
> the connection?

Good question, though nobody so far has complained that an openvpn session
cannot be closed remotely.  Most have been happy with --inactive & --ping-exit.

> I still mainly consentrated on using shared secret but how
> about managing client sertificates. Does openvpn understand
> sertificate revocation lists so that some sertificates
> can be bloked?

It's not supported right now, but would probably be easy to add.

> I think that there should also be some secure way in the protocol
> to pass the tunnel parameters to the other end
> so that both ends don't have to have all the configuration
> data available. For example, in our case embedded clients
> can tell the server the endpoint addresses so each of them
> can be reach trough a pre configured static ip.
> Or other way round, the server can pass the addresses to
> the client from a pool of addressess, when server
> is given the endpoint address ranges to use.

I think trying to do this in the openvpn protocol itself could be a bug
magnet, and would probably involve changing the protocol.  A better idea IMHO
would be to create a new server daemon which deals with negotiating the
configuration parameters, then this daemon instantiates a server openvpn
process.  This daemon would probably communicate via vanilla TLS, i.e. TLS
over a TCP connection.  In OpenVPN 1.3.2 this server daemon can be
inetd/xinetd, but without the feature that allows configuration information to
be provided by a single end of the connection (which must still be written).

We could develop and rework this daemon independently of openvpn, thereby
destabilizing neither the openvpn code nor the protocol during the development
and prototype stages.

Another complexity that comes from allowing a client to produce configuration
parameters for the server side as well is one of security.  To what extent
does the server trust the client to provide it, and how is this trust
controlled and configured?

> 
> Managing the parameters at the both end propably causes
> more problems due to config errors, than
> passing the parameters over the untrusted communication
> channel. :-)

I definitely wouldn't want to pass the parameters over an untrusted channel.

You might check out the archives for a patch that was posted last spring or
summer (autovpn?) for a script that does most of what I suggested above using
a shell script and ssh.

James

> 
> 
> SaBe
> 
> > 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 <aud...@au...> 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
> > > > 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] Re: Multiple VPN connections on the same port

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

Hello James,

That's good to hear,

There are some questions that I had to over come with
my experimental forking server, like when does a forked
process exit? Should we always use something line --inactive
or --ping-exit? Or should there be a control command for closing
the connection?

I still mainly consentrated on using shared secret but how
about managing client sertificates. Does openvpn understand
sertificate revocation lists so that some sertificates
can be bloked?

I think that there should also be some secure way in the protocol
to pass the tunnel parameters to the other end
so that both ends don't have to have all the configuration
data available. For example, in our case embedded clients
can tell the server the endpoint addresses so each of them
can be reach trough a pre configured static ip.
Or other way round, the server can pass the addresses to
the client from a pool of addressess, when server
is given the endpoint address ranges to use.

Managing the parameters at the both end propably causes
more problems due to config errors, than
passing the parameters over the untrusted communication
channel. :-)


SaBe

> 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 <aud...@au...> 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
> > > 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] Re: Multiple VPN connections on the same port

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

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 <aud...@au...> 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
> > 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] Re: Multiple VPN connections on the same port

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

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
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>

Re: Re[2]: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

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

Richard Mueller <mu...@te...> said:

> Hello James,
> 
> Thursday, December 19, 2002, 3:59:16 PM, you wrote:
> 
> JY> * How is --peerinit different from --ipchange?
> Good question. None. sh*t Please see below. :)
> 
> JY> * Shouldn't
> JY>   if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
> JY>    ...
> JY> be
> JY>   if (signal_received == SIGUSR1 && options->sigusr1_script)
> JY>    ...
> JY> ?
> d*mn. yes. this is the sprit of "cut'n'paste" coding. Think I pasted
> the condition some lines above.
> 
> I wrote it short afer visiting "Lord of the Rings II" and a 18h
> workday without any coffee (I am allergic).

Hey, that's an interesting excuse...  Tolkien had a great sense of foreboding
about the advancing march of technology and industrialization and he would
probably have taken some pleasure in knowing that his storyweaving would throw
a wrench into the workings of someone's machinery...  not to mention being
under the influence of a lack of caffeine :)

> So sorry for the bad code, I won't do it again. ;-(
> I took the conclusion for me:
> $ patch && test && sleep && test && submit
> 
> 
> JY> The failover idea is interesting.
> It works quite good in my enviroment here (even better after fixing the
> patch ;) ).
> 
> - If openvpn is stopped on both sides, the alternative route is taken
>   immediateley.
> 
> - If the link between the two tun-endpoints breaks it takes as long
--ping-restart.
>   The prefered route is taken immediateley when the tunnel returns.

So it looks like all we need is a --sigusr1-script option.  That seems pretty
reasonable.  After you've tested it somewhat, would you mind writing an entry
for the HOWTO that explains how to use the ipchange and sigusr1 scripts to set
up a failover configuration?  Probably just a restatement of what you've
described in your emails, but maybe with a bit more detail such as how to set
up the Linux Advanced Routing component of the setup.  I think people would
find it very useful, and this is certainly a case where the code itself (i.e.
the script patch) is fairly trivial but the documentation on how to do it is
the far more essential component.

Thanks,
James

> 
> 
> Best regards and sorry again for the bad code,
> 
> Richard Mueller
> 



-- 

Re[2]: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[Richard M. <mu...@te...>]

Hello James,

Thursday, December 19, 2002, 3:59:16 PM, you wrote:

JY> * How is --peerinit different from --ipchange?
Good question. None. sh*t Please see below. :)

JY> * Shouldn't
JY>   if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
JY>    ...
JY> be
JY>   if (signal_received == SIGUSR1 && options->sigusr1_script)
JY>    ...
JY> ?
d*mn. yes. this is the sprit of "cut'n'paste" coding. Think I pasted
the condition some lines above.

I wrote it short afer visiting "Lord of the Rings II" and a 18h
workday without any coffee (I am allergic).
So sorry for the bad code, I won't do it again. ;-(
I took the conclusion for me:
$ patch && test && sleep && test && submit


JY> The failover idea is interesting.
It works quite good in my enviroment here (even better after fixing the
patch ;) ).

- If openvpn is stopped on both sides, the alternative route is taken
  immediateley.

- If the link between the two tun-endpoints breaks it takes as long --ping-restart.
  The prefered route is taken immediateley when the tunnel returns.


Best regards and sorry again for the bad code,

Richard Mueller

Re: [Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

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

Hi Richard,

The failover idea is interesting.  I have a couple comments on the patch:

* How is --peerinit different from --ipchange?

* Shouldn't
  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
   ...
be
  if (signal_received == SIGUSR1 && options->sigusr1_script)
   ...
?

James

Richard Mueller <mu...@te...> said:

> Hello openvpn-developers,
> 
> I needed two more places in openvpn where to exec some scripts
> because I wanted to build a "fail-over" solution between two
> tuns.
> 
> 
> 1.) Situation:
>   +---------+       tun0 (ISP0)    +---------+
>   | BOX 1   +----------------------+ BOX 2   |
>   |         |                      |         |
>   |         +----------------------+         |
>   +---------+       tun1 (ISP1)    +---------+
> 
> tun0 is prefered but if tun0 fails tun1 should do
> the job.
> 
> Linux advanced routing has a usable solution for this:
>   Two routing tables with one prefered.
> 
> Because of this I needed to add/delete routes at this points:
> 
> - After the first "answer" from the peer (add route for tun?)
> - At a SIGUSR1 == "peer dead" (del route for tun?)
> 
> 
> 2.) I used following configs:
> 
> [BOX1: tun0]
> 
> # interface configuration
> dev tun0
> 
> # Peer connect configuartion
>  remote 172.16.90.4
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> # 10.255.253.8 is our local  VPN endpoint
> # 10.255.253.9 is our remote VPN endpoint
> ifconfig 10.255.254.122  10.255.254.121
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box1.crt
> key  /etc/openvpn/certs/box1.key
> tls-verify "/usr/local/sbin/verify-cn box2"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun0.up
> sigusr1  /etc/openvpn/scripts/tun0.down
> 
> lport 5006
> rport 5007
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX1: tun1]
> 
> # interface configuration
> dev tun1
> 
> # Peer connect configuartion
>  remote 172.16.90.4
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> # 10.255.253.8 is our local  VPN endpoint
> # 10.255.253.9 is our remote VPN endpoint
> ifconfig 10.255.253.122  10.255.253.121
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box1.crt
> key  /etc/openvpn/certs/box1.key
> tls-verify "/usr/local/sbin/verify-cn box2"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun1.up
> sigusr1  /etc/openvpn/scripts/tun1.down
> 
> lport 5506
> rport 5507
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX2: tun0]
> 
> # interface configuration
> dev tun0
> 
> # Peer connect configuartion
>  remote 172.16.90.1
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> ifconfig 10.255.254.121  10.255.254.122
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box2.crt
> key  /etc/openvpn/certs/box2.key
> tls-verify "/usr/local/sbin/verify-cn box1"
> 
> # Routen setzen
> peerinit /etc/openvpn/scripts/tun0.up
> sigusr1  /etc/openvpn/scripts/tun0.down
> 
> lport 5007
> rport 5006
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> [BOX1: tun1]
> 
> # interface configuration
> dev tun1
> 
> # Peer connect configuartion
>  remote 172.16.90.1
> # float
> 
> persist-tun
> persist-key
> ping 7
> ping-restart 21
> 
> ifconfig 10.255.253.121  10.255.253.122
> 
> # TSL-Client
> tls-client
> ca   /etc/openvpn/certs/ca.crt
> cert /etc/openvpn/certs/box2.crt
> key  /etc/openvpn/certs/box2.key
> tls-verify "/usr/local/sbin/verify-cn box1"
> 
> peerinit /etc/openvpn/scripts/tun1.up
> sigusr1  /etc/openvpn/scripts/tun1.down
> 
> lport 5507
> rport 5506
> 
> comp-lzo
> #daemon
> 
> reneg-sec 600
> 
> verb 5
> 
> 4.) Here is the patch:
> 
> [PATCH START]
> diff -u openvpn-1.3.2/openvpn.c openvpn-1.3.2-droute/openvpn.c
> --- openvpn-1.3.2/openvpn.c     Mon Oct 21 03:46:52 2002
> +++ openvpn-1.3.2-droute/openvpn.c      Wed Dec 18 19:18:12 2002
> @@ -341,7 +341,7 @@
>                      options->local_port, options->remote_port,
>                      options->bind_local, options->remote_float,
>                      options->inetd,
> -                    udp_socket_addr, options->ipchange,
> +                    udp_socket_addr, options->ipchange,
options->peerinit_script,
>                      options->resolve_retry_seconds);
>  
>  #ifdef USE_CRYPTO
> @@ -1406,6 +1406,15 @@
>        run_script (options->down_script, tuntap_actual, MAX_RW_SIZE_TUN
(&frame),
>                   max_rw_size_udp, options->ifconfig_local,
options->ifconfig_remote);
>      }
> +   /*
> +    * Execute sigusr1 script 
> +    */
> +  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
> +    {
> +     msg (M_INFO, "Executing sigusr1 script %s",options->sigusr1_script);
> +     system_check (options->sigusr1_script, "sigusr1 command failed", false);
> +    }
> +
>   done:
>    /* pop our garbage collection level */
>    gc_free_level (gc_level);
> diff -u openvpn-1.3.2/options.c openvpn-1.3.2-droute/options.c
> --- openvpn-1.3.2/options.c     Sat Oct 19 23:26:11 2002
> +++ openvpn-1.3.2-droute/options.c      Wed Dec 18 18:52:24 2002
> @@ -316,6 +316,9 @@
>    SHOW_STR (writepid);
>    SHOW_STR (up_script);
>    SHOW_STR (down_script);
> +  SHOW_STR (peerinit_script);
> +  SHOW_STR (sigusr1_script);
> +  SHOW_STR (down_script);
>    SHOW_BOOL (daemon);
>    SHOW_BOOL (inetd);
>    SHOW_INT (nice);
> @@ -726,6 +729,16 @@
>      {
>        ++i;
>        options->down_script = p2;
> +    }
> +  else if (streq(p1, "peerinit") && p2) 
> +    {
> +      ++i;
> +      options->peerinit_script = p2;
> +    }
> +  else if (streq(p1, "sigusr1") && p2) 
> +    {
> +      ++i;
> +      options->sigusr1_script = p2;
>      }
>    else if (streq (p1, "daemon"))
>      {
> diff -u openvpn-1.3.2/options.h openvpn-1.3.2-droute/options.h
> --- openvpn-1.3.2/options.h     Sat Oct 19 22:25:46 2002
> +++ openvpn-1.3.2-droute/options.h      Wed Dec 18 18:25:46 2002
> @@ -87,6 +87,8 @@
>    const char *writepid;
>    const char *up_script;
>    const char *down_script;
> +  const char *peerinit_script;
> +  const char *sigusr1_script;
>    bool daemon;
>    bool inetd;
>    int nice;
> diff -u openvpn-1.3.2/socket.c openvpn-1.3.2-droute/socket.c
> --- openvpn-1.3.2/socket.c      Sat Oct 19 23:23:19 2002
> +++ openvpn-1.3.2-droute/socket.c       Wed Dec 18 18:56:18 2002
> @@ -105,6 +105,7 @@
>                  bool inetd,
>                  struct udp_socket_addr *usa,
>                  const char *ipchange_command,
> +                const char *peerinit_command,
>                  int resolve_retry_seconds)
>  {
>    CLEAR (*sock);
> @@ -112,6 +113,7 @@
>    sock->remote_float = remote_float;
>    sock->addr = usa;
>    sock->ipchange_command = ipchange_command;
> +  sock->peerinit_command = peerinit_command;
>  
>    /* were we started by inetd or xinetd? */
>    if (inetd)
> @@ -190,6 +192,22 @@
>           sock->set_outgoing_initial = true;
>           mutex_unlock (L_SOCK);
>           msg (M_INFO, "Peer Connection Initiated with %s", print_sockaddr
(&usa->actual));
> +
> +         if (sock->peerinit_command) 
> +           {
> +             char command[256];
> +             struct buffer out;
> +
> +             msg (M_INFO, "Executing peerinit_script
%s",sock->peerinit_command);
> +
> +             buf_set_write (&out, command, sizeof (command));
> +             buf_printf (&out, "%s %s",
> +                         sock->peerinit_command,
> +                         print_sockaddr_ex (&usa->actual, true, " "));
> +             msg (D_TLS_DEBUG, "executing ip-change command: %s", command);
> +             system_check (command, "peerinit command failed", false);
> +            }
> +
>           if (sock->ipchange_command)
>             {
>               char command[256];
> diff -u openvpn-1.3.2/socket.h openvpn-1.3.2-droute/socket.h
> --- openvpn-1.3.2/socket.h      Sat Oct 19 23:26:10 2002
> +++ openvpn-1.3.2-droute/socket.h       Wed Dec 18 18:49:01 2002
> @@ -42,6 +42,7 @@
>    bool remote_float;
>    struct udp_socket_addr *addr;
>    const char *ipchange_command;
> +  const char *peerinit_command;
>    int sd;                      /* file descriptor for socket */
>  };
>  
> @@ -56,6 +57,7 @@
>                  bool inetd,
>                  struct udp_socket_addr *addr,
>                  const char *ipchange_command,
> +                 const char *peerinit_command,
>                  int resolve_retry_seconds);
>  
>  void
> [PATCH START]
> 
> 5.) If it is interesting for you, James, you are free to clean the
>     code and fix the documentation and merge it in your branch.
>     Just write a Creditline in the changelog. ;-)
> 
> 6.) Feel free to ask, if you have some questions.
> 
> bye
> richard
> 
> -- 
> Richard Mueller     mailto:mu...@te...  Fon: +49 9171 896287
> Teamix GmbH         http://www.teamix.de       Fax: +49 9171 896286
> 
> PGP Public Key      http://www.teamix.net/pgp/rm_public_key_2048
> Fingerprint:        ea 50 21 6c a5 39 e9 03 a6 59 af e3 c5 1f 63 8e
> 
> Networks - Consulting - Training - Software Development - eCommerce
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
> Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
> MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
> T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
> _______________________________________________
> Openvpn-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 

[Openvpn-devel] [PATCH] Exec scripts at sigusr1 and established tunnel

[Richard M. <mu...@te...>]

Hello openvpn-developers,

I needed two more places in openvpn where to exec some scripts
because I wanted to build a "fail-over" solution between two
tuns.


1.) Situation:
  +---------+       tun0 (ISP0)    +---------+
  | BOX 1   +----------------------+ BOX 2   |
  |         |                      |         |
  |         +----------------------+         |
  +---------+       tun1 (ISP1)    +---------+

tun0 is prefered but if tun0 fails tun1 should do
the job.

Linux advanced routing has a usable solution for this:
  Two routing tables with one prefered.

Because of this I needed to add/delete routes at this points:

- After the first "answer" from the peer (add route for tun?)
- At a SIGUSR1 == "peer dead" (del route for tun?)


2.) I used following configs:

[BOX1: tun0]

# interface configuration
dev tun0

# Peer connect configuartion
 remote 172.16.90.4
# float

persist-tun
persist-key
ping 7
ping-restart 21

# 10.255.253.8 is our local  VPN endpoint
# 10.255.253.9 is our remote VPN endpoint
ifconfig 10.255.254.122  10.255.254.121

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box1.crt
key  /etc/openvpn/certs/box1.key
tls-verify "/usr/local/sbin/verify-cn box2"

# Routen setzen
peerinit /etc/openvpn/scripts/tun0.up
sigusr1  /etc/openvpn/scripts/tun0.down

lport 5006
rport 5007

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX1: tun1]

# interface configuration
dev tun1

# Peer connect configuartion
 remote 172.16.90.4
# float

persist-tun
persist-key
ping 7
ping-restart 21

# 10.255.253.8 is our local  VPN endpoint
# 10.255.253.9 is our remote VPN endpoint
ifconfig 10.255.253.122  10.255.253.121

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box1.crt
key  /etc/openvpn/certs/box1.key
tls-verify "/usr/local/sbin/verify-cn box2"

# Routen setzen
peerinit /etc/openvpn/scripts/tun1.up
sigusr1  /etc/openvpn/scripts/tun1.down

lport 5506
rport 5507

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX2: tun0]

# interface configuration
dev tun0

# Peer connect configuartion
 remote 172.16.90.1
# float

persist-tun
persist-key
ping 7
ping-restart 21

ifconfig 10.255.254.121  10.255.254.122

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box2.crt
key  /etc/openvpn/certs/box2.key
tls-verify "/usr/local/sbin/verify-cn box1"

# Routen setzen
peerinit /etc/openvpn/scripts/tun0.up
sigusr1  /etc/openvpn/scripts/tun0.down

lport 5007
rport 5006

comp-lzo
#daemon

reneg-sec 600

verb 5

[BOX1: tun1]

# interface configuration
dev tun1

# Peer connect configuartion
 remote 172.16.90.1
# float

persist-tun
persist-key
ping 7
ping-restart 21

ifconfig 10.255.253.121  10.255.253.122

# TSL-Client
tls-client
ca   /etc/openvpn/certs/ca.crt
cert /etc/openvpn/certs/box2.crt
key  /etc/openvpn/certs/box2.key
tls-verify "/usr/local/sbin/verify-cn box1"

peerinit /etc/openvpn/scripts/tun1.up
sigusr1  /etc/openvpn/scripts/tun1.down

lport 5507
rport 5506

comp-lzo
#daemon

reneg-sec 600

verb 5

4.) Here is the patch:

[PATCH START]
diff -u openvpn-1.3.2/openvpn.c openvpn-1.3.2-droute/openvpn.c
--- openvpn-1.3.2/openvpn.c     Mon Oct 21 03:46:52 2002
+++ openvpn-1.3.2-droute/openvpn.c      Wed Dec 18 19:18:12 2002
@@ -341,7 +341,7 @@
                     options->local_port, options->remote_port,
                     options->bind_local, options->remote_float,
                     options->inetd,
-                    udp_socket_addr, options->ipchange,
+                    udp_socket_addr, options->ipchange, options->peerinit_script,
                     options->resolve_retry_seconds);
 
 #ifdef USE_CRYPTO
@@ -1406,6 +1406,15 @@
       run_script (options->down_script, tuntap_actual, MAX_RW_SIZE_TUN (&frame),
                  max_rw_size_udp, options->ifconfig_local, options->ifconfig_remote);
     }
+   /*
+    * Execute sigusr1 script 
+    */
+  if ( !(signal_received == SIGUSR1 && !options->sigusr1_script ) )
+    {
+     msg (M_INFO, "Executing sigusr1 script %s",options->sigusr1_script);
+     system_check (options->sigusr1_script, "sigusr1 command failed", false);
+    }
+
  done:
   /* pop our garbage collection level */
   gc_free_level (gc_level);
diff -u openvpn-1.3.2/options.c openvpn-1.3.2-droute/options.c
--- openvpn-1.3.2/options.c     Sat Oct 19 23:26:11 2002
+++ openvpn-1.3.2-droute/options.c      Wed Dec 18 18:52:24 2002
@@ -316,6 +316,9 @@
   SHOW_STR (writepid);
   SHOW_STR (up_script);
   SHOW_STR (down_script);
+  SHOW_STR (peerinit_script);
+  SHOW_STR (sigusr1_script);
+  SHOW_STR (down_script);
   SHOW_BOOL (daemon);
   SHOW_BOOL (inetd);
   SHOW_INT (nice);
@@ -726,6 +729,16 @@
     {
       ++i;
       options->down_script = p2;
+    }
+  else if (streq(p1, "peerinit") && p2) 
+    {
+      ++i;
+      options->peerinit_script = p2;
+    }
+  else if (streq(p1, "sigusr1") && p2) 
+    {
+      ++i;
+      options->sigusr1_script = p2;
     }
   else if (streq (p1, "daemon"))
     {
diff -u openvpn-1.3.2/options.h openvpn-1.3.2-droute/options.h
--- openvpn-1.3.2/options.h     Sat Oct 19 22:25:46 2002
+++ openvpn-1.3.2-droute/options.h      Wed Dec 18 18:25:46 2002
@@ -87,6 +87,8 @@
   const char *writepid;
   const char *up_script;
   const char *down_script;
+  const char *peerinit_script;
+  const char *sigusr1_script;
   bool daemon;
   bool inetd;
   int nice;
diff -u openvpn-1.3.2/socket.c openvpn-1.3.2-droute/socket.c
--- openvpn-1.3.2/socket.c      Sat Oct 19 23:23:19 2002
+++ openvpn-1.3.2-droute/socket.c       Wed Dec 18 18:56:18 2002
@@ -105,6 +105,7 @@
                 bool inetd,
                 struct udp_socket_addr *usa,
                 const char *ipchange_command,
+                const char *peerinit_command,
                 int resolve_retry_seconds)
 {
   CLEAR (*sock);
@@ -112,6 +113,7 @@
   sock->remote_float = remote_float;
   sock->addr = usa;
   sock->ipchange_command = ipchange_command;
+  sock->peerinit_command = peerinit_command;
 
   /* were we started by inetd or xinetd? */
   if (inetd)
@@ -190,6 +192,22 @@
          sock->set_outgoing_initial = true;
          mutex_unlock (L_SOCK);
          msg (M_INFO, "Peer Connection Initiated with %s", print_sockaddr (&usa->actual));
+
+         if (sock->peerinit_command) 
+           {
+             char command[256];
+             struct buffer out;
+
+             msg (M_INFO, "Executing peerinit_script %s",sock->peerinit_command);
+
+             buf_set_write (&out, command, sizeof (command));
+             buf_printf (&out, "%s %s",
+                         sock->peerinit_command,
+                         print_sockaddr_ex (&usa->actual, true, " "));
+             msg (D_TLS_DEBUG, "executing ip-change command: %s", command);
+             system_check (command, "peerinit command failed", false);
+            }
+
          if (sock->ipchange_command)
            {
              char command[256];
diff -u openvpn-1.3.2/socket.h openvpn-1.3.2-droute/socket.h
--- openvpn-1.3.2/socket.h      Sat Oct 19 23:26:10 2002
+++ openvpn-1.3.2-droute/socket.h       Wed Dec 18 18:49:01 2002
@@ -42,6 +42,7 @@
   bool remote_float;
   struct udp_socket_addr *addr;
   const char *ipchange_command;
+  const char *peerinit_command;
   int sd;                      /* file descriptor for socket */
 };
 
@@ -56,6 +57,7 @@
                 bool inetd,
                 struct udp_socket_addr *addr,
                 const char *ipchange_command,
+                 const char *peerinit_command,
                 int resolve_retry_seconds);
 
 void
[PATCH START]

5.) If it is interesting for you, James, you are free to clean the
    code and fix the documentation and merge it in your branch.
    Just write a Creditline in the changelog. ;-)

6.) Feel free to ask, if you have some questions.

bye
richard

-- 
Richard Mueller     mailto:mu...@te...  Fon: +49 9171 896287
Teamix GmbH         http://www.teamix.de       Fax: +49 9171 896286

PGP Public Key      http://www.teamix.net/pgp/rm_public_key_2048
Fingerprint:        ea 50 21 6c a5 39 e9 03 a6 59 af e3 c5 1f 63 8e

Networks - Consulting - Training - Software Development - eCommerce