You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(14) |
Jun
(29) |
Jul
(33) |
Aug
(3) |
Sep
(8) |
Oct
(18) |
Nov
(1) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(3) |
Feb
(33) |
Mar
(7) |
Apr
(28) |
May
(30) |
Jun
(5) |
Jul
(10) |
Aug
(7) |
Sep
(32) |
Oct
(41) |
Nov
(20) |
Dec
(10) |
| 2004 |
Jan
(24) |
Feb
(18) |
Mar
(57) |
Apr
(40) |
May
(55) |
Jun
(48) |
Jul
(77) |
Aug
(15) |
Sep
(56) |
Oct
(80) |
Nov
(74) |
Dec
(52) |
| 2005 |
Jan
(38) |
Feb
(42) |
Mar
(39) |
Apr
(56) |
May
(79) |
Jun
(73) |
Jul
(16) |
Aug
(23) |
Sep
(68) |
Oct
(77) |
Nov
(52) |
Dec
(27) |
| 2006 |
Jan
(27) |
Feb
(18) |
Mar
(51) |
Apr
(62) |
May
(28) |
Jun
(50) |
Jul
(36) |
Aug
(33) |
Sep
(47) |
Oct
(50) |
Nov
(77) |
Dec
(13) |
| 2007 |
Jan
(15) |
Feb
(8) |
Mar
(14) |
Apr
(18) |
May
(25) |
Jun
(16) |
Jul
(16) |
Aug
(19) |
Sep
(32) |
Oct
(17) |
Nov
(5) |
Dec
(5) |
| 2008 |
Jan
(64) |
Feb
(25) |
Mar
(25) |
Apr
(6) |
May
(28) |
Jun
(20) |
Jul
(10) |
Aug
(27) |
Sep
(28) |
Oct
(59) |
Nov
(37) |
Dec
(43) |
| 2009 |
Jan
(40) |
Feb
(25) |
Mar
(12) |
Apr
(57) |
May
(46) |
Jun
(29) |
Jul
(39) |
Aug
(10) |
Sep
(20) |
Oct
(42) |
Nov
(50) |
Dec
(57) |
| 2010 |
Jan
(82) |
Feb
(165) |
Mar
(256) |
Apr
(260) |
May
(36) |
Jun
(87) |
Jul
(53) |
Aug
(89) |
Sep
(107) |
Oct
(51) |
Nov
(88) |
Dec
(117) |
| 2011 |
Jan
(69) |
Feb
(60) |
Mar
(113) |
Apr
(71) |
May
(67) |
Jun
(90) |
Jul
(88) |
Aug
(90) |
Sep
(48) |
Oct
(64) |
Nov
(69) |
Dec
(118) |
| 2012 |
Jan
(49) |
Feb
(528) |
Mar
(351) |
Apr
(190) |
May
(238) |
Jun
(193) |
Jul
(104) |
Aug
(100) |
Sep
(57) |
Oct
(41) |
Nov
(47) |
Dec
(51) |
| 2013 |
Jan
(94) |
Feb
(57) |
Mar
(96) |
Apr
(105) |
May
(77) |
Jun
(102) |
Jul
(27) |
Aug
(81) |
Sep
(32) |
Oct
(53) |
Nov
(127) |
Dec
(65) |
| 2014 |
Jan
(113) |
Feb
(59) |
Mar
(104) |
Apr
(259) |
May
(70) |
Jun
(70) |
Jul
(146) |
Aug
(45) |
Sep
(58) |
Oct
(149) |
Nov
(77) |
Dec
(83) |
| 2015 |
Jan
(53) |
Feb
(66) |
Mar
(86) |
Apr
(50) |
May
(135) |
Jun
(76) |
Jul
(151) |
Aug
(83) |
Sep
(97) |
Oct
(262) |
Nov
(245) |
Dec
(231) |
| 2016 |
Jan
(131) |
Feb
(233) |
Mar
(97) |
Apr
(138) |
May
(221) |
Jun
(254) |
Jul
(92) |
Aug
(248) |
Sep
(168) |
Oct
(275) |
Nov
(477) |
Dec
(445) |
| 2017 |
Jan
(218) |
Feb
(217) |
Mar
(146) |
Apr
(172) |
May
(216) |
Jun
(252) |
Jul
(164) |
Aug
(192) |
Sep
(190) |
Oct
(143) |
Nov
(255) |
Dec
(182) |
| 2018 |
Jan
(295) |
Feb
(164) |
Mar
(113) |
Apr
(147) |
May
(64) |
Jun
(262) |
Jul
(184) |
Aug
(90) |
Sep
(69) |
Oct
(364) |
Nov
(102) |
Dec
(101) |
| 2019 |
Jan
(119) |
Feb
(64) |
Mar
(64) |
Apr
(102) |
May
(57) |
Jun
(154) |
Jul
(84) |
Aug
(81) |
Sep
(76) |
Oct
(102) |
Nov
(233) |
Dec
(89) |
| 2020 |
Jan
(38) |
Feb
(170) |
Mar
(155) |
Apr
(172) |
May
(120) |
Jun
(223) |
Jul
(461) |
Aug
(227) |
Sep
(268) |
Oct
(113) |
Nov
(56) |
Dec
(124) |
| 2021 |
Jan
(121) |
Feb
(48) |
Mar
(334) |
Apr
(345) |
May
(207) |
Jun
(136) |
Jul
(71) |
Aug
(112) |
Sep
(122) |
Oct
(173) |
Nov
(184) |
Dec
(223) |
| 2022 |
Jan
(197) |
Feb
(206) |
Mar
(156) |
Apr
(212) |
May
(192) |
Jun
(170) |
Jul
(143) |
Aug
(380) |
Sep
(182) |
Oct
(148) |
Nov
(128) |
Dec
(269) |
| 2023 |
Jan
(248) |
Feb
(196) |
Mar
(264) |
Apr
(36) |
May
(123) |
Jun
(66) |
Jul
(120) |
Aug
(48) |
Sep
(157) |
Oct
(198) |
Nov
(300) |
Dec
(273) |
| 2024 |
Jan
(271) |
Feb
(147) |
Mar
(207) |
Apr
(78) |
May
(107) |
Jun
(168) |
Jul
(151) |
Aug
(51) |
Sep
(438) |
Oct
(221) |
Nov
(302) |
Dec
(357) |
| 2025 |
Jan
(451) |
Feb
(219) |
Mar
(326) |
Apr
(232) |
May
(306) |
Jun
(181) |
Jul
(452) |
Aug
(282) |
Sep
(620) |
Oct
(793) |
Nov
(3) |
Dec
|
|
From: Aaron S. <and...@ra...> - 2002-09-27 22:47:40
|
I've done some work on getting openvpn to tunnel ipv6 without having to
use TAP tunnels. I think to get ipv6 tunneling to work on other platforms
it may require changes in the tunnel driver. But I figure I'll post this
here as it might be of use to somebody.
Regards,
Aaron
Index: Makefile.in
===================================================================
RCS file: /cvsroot/openvpn/openvpn/Makefile.in,v
retrieving revision 1.6
diff -u -r1.6 Makefile.in
--- Makefile.in 25 Jun 2002 06:56:16 -0000 1.6
+++ Makefile.in 27 Sep 2002 22:41:09 -0000
@@ -1,4 +1,4 @@
-# Makefile.in generated by automake 1.6.1 from Makefile.am.
+# Makefile.in generated by automake 1.6.3 from Makefile.am.
# @configure_input@
# Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002
@@ -74,6 +74,7 @@
INSTALL_DATA = @INSTALL_DATA@
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_HEADER = $(INSTALL_DATA)
transform = @program_transform_name@
@@ -170,6 +171,9 @@
.SUFFIXES:
.SUFFIXES: .c .o .obj
+
+am__CONFIG_DISTCLEAN_FILES = config.status config.cache config.log \
+ configure.lineno
$(srcdir)/Makefile.in: Makefile.am $(top_srcdir)/configure.ac $(ACLOCAL_M4)
cd $(top_srcdir) && \
$(AUTOMAKE) --gnu Makefile
@@ -199,7 +203,7 @@
touch $(srcdir)/config.h.in
distclean-hdr:
- -rm -f config.h
+ -rm -f config.h stamp-h1
sbinPROGRAMS_INSTALL = $(INSTALL_PROGRAM)
install-sbinPROGRAMS: $(sbin_PROGRAMS)
@$(NORMAL_INSTALL)
@@ -208,8 +212,7 @@
p1=`echo $$p|sed 's/$(EXEEXT)$$//'`; \
if test -f $$p \
; then \
- p1=`echo "$$p1" | sed -e 's,^.*/,,'`; \
- f=`echo $$p1|sed '$(transform);s/$$/$(EXEEXT)/'`; \
+ f=`echo "$$p1" | sed 's,^.*/,,;$(transform);s/$$/$(EXEEXT)/'`; \
echo " $(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f"; \
$(INSTALL_PROGRAM_ENV) $(sbinPROGRAMS_INSTALL) $$p $(DESTDIR)$(sbindir)/$$f; \
else :; fi; \
@@ -218,8 +221,7 @@
uninstall-sbinPROGRAMS:
@$(NORMAL_UNINSTALL)
@list='$(sbin_PROGRAMS)'; for p in $$list; do \
- f=`echo $$p|sed 's/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
- f=`echo "$$f" | sed -e 's,^.*/,,'`; \
+ f=`echo "$$p" | sed 's,^.*/,,;s/$(EXEEXT)$$//;$(transform);s/$$/$(EXEEXT)/'`; \
echo " rm -f $(DESTDIR)$(sbindir)/$$f"; \
rm -f $(DESTDIR)$(sbindir)/$$f; \
done
@@ -286,6 +288,10 @@
if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \
else file=$$i; fi; \
ext=`echo $$i | sed -e 's/^.*\\.//'`; \
+ case "$$ext" in \
+ 8*) ;; \
+ *) ext='8' ;; \
+ esac; \
inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \
inst=`echo $$inst | sed -e 's/^.*\///'`; \
inst=`echo $$inst | sed '$(transform)'`.$$ext; \
@@ -361,7 +367,7 @@
distdir: $(DISTFILES)
$(am__remove_distdir)
mkdir $(distdir)
- @for file in $(DISTFILES); do \
+ @list='$(DISTFILES)'; for file in $$list; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
dir=`echo "$$file" | sed -e 's,/[^/]*$$,,'`; \
if test "$$dir" != "$$file" && test "$$dir" != "."; then \
@@ -459,7 +465,7 @@
clean-generic:
distclean-generic:
- -rm -f Makefile $(CONFIG_CLEAN_FILES) stamp-h stamp-h[0-9]*
+ -rm -f Makefile $(CONFIG_CLEAN_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@@ -469,7 +475,7 @@
clean-am: clean-generic clean-sbinPROGRAMS mostlyclean-am
distclean: distclean-am
- -rm -f config.status config.cache config.log
+ -rm -f $(am__CONFIG_DISTCLEAN_FILES)
distclean-am: clean-am distclean-compile distclean-depend \
distclean-generic distclean-hdr distclean-tags
@@ -492,7 +498,8 @@
installcheck-am:
maintainer-clean: maintainer-clean-am
-
+ -rm -f $(am__CONFIG_DISTCLEAN_FILES)
+ -rm -rf autom4te.cache
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
Index: aclocal.m4
===================================================================
RCS file: /cvsroot/openvpn/openvpn/aclocal.m4,v
retrieving revision 1.31
diff -u -r1.31 aclocal.m4
--- aclocal.m4 14 Sep 2002 21:54:10 -0000 1.31
+++ aclocal.m4 27 Sep 2002 22:41:11 -0000
@@ -1,4 +1,4 @@
-# aclocal.m4 generated automatically by aclocal 1.6.1 -*- Autoconf -*-
+# aclocal.m4 generated automatically by aclocal 1.6.3 -*- Autoconf -*-
# Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002
# Free Software Foundation, Inc.
@@ -96,7 +96,7 @@
dnl macros posted by AFC to the autoconf macro repository. We are also
dnl grateful for the helpful feedback of numerous users.
dnl
-dnl @version $Id: aclocal.m4,v 1.31 2002/09/14 21:54:10 jimyonan Exp $
+dnl @version $Id: acinclude.m4,v 1.1 2002/05/30 00:04:45 jimyonan Exp $
dnl @author Steven G. Johnson <st...@al...> and Alejandro Forero Cuervo <ba...@ba...>
AC_DEFUN([ACX_PTHREAD], [
@@ -490,7 +490,7 @@
# Call AM_AUTOMAKE_VERSION so it can be traced.
# This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
- [AM_AUTOMAKE_VERSION([1.6.1])])
+ [AM_AUTOMAKE_VERSION([1.6.3])])
# Helper functions for option handling. -*- Autoconf -*-
@@ -822,7 +822,7 @@
ifelse([$1], CC, [depcc="$CC" am_compiler_list=],
[$1], CXX, [depcc="$CXX" am_compiler_list=],
- [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc']
+ [$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
[$1], GCJ, [depcc="$GCJ" am_compiler_list='gcc3 gcc'],
[depcc="$$1" am_compiler_list=])
@@ -947,7 +947,13 @@
[for mf in $CONFIG_FILES; do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
- if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
+ # Check whether this is an Automake generated Makefile or not.
+ # We used to match only the files named `Makefile.in', but
+ # some people rename them; so instead we look at the file content.
+ # Grep'ing the first line is not enough: some people post-process
+ # each Makefile.in and add a new line on top of each file to say so.
+ # So let's grep whole file.
+ if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
Index: config.h.in
===================================================================
RCS file: /cvsroot/openvpn/openvpn/config.h.in,v
retrieving revision 1.6
diff -u -r1.6 config.h.in
--- config.h.in 28 Jul 2002 07:54:57 -0000 1.6
+++ config.h.in 27 Sep 2002 22:41:12 -0000
@@ -78,6 +78,9 @@
/* Define to 1 if you have the <netdb.h> header file. */
#undef HAVE_NETDB_H
+/* Define to 1 if you have the <netinet/if_ether.h> header file. */
+#undef HAVE_NETINET_IF_ETHER_H
+
/* Define to 1 if you have the <netinet/in.h> header file. */
#undef HAVE_NETINET_IN_H
Index: configure
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure,v
retrieving revision 1.37
diff -u -r1.37 configure
--- configure 14 Sep 2002 21:54:10 -0000 1.37
+++ configure 27 Sep 2002 22:41:39 -0000
@@ -6759,6 +6759,120 @@
done
+for ac_header in netinet/if_ether.h
+do
+as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+else
+ # Is the header compilable?
+echo "$as_me:$LINENO: checking $ac_header usability" >&5
+echo $ECHO_N "checking $ac_header usability... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+#include "confdefs.h"
+$ac_includes_default
+#include <$ac_header>
+_ACEOF
+rm -f conftest.$ac_objext
+if { (eval echo "$as_me:$LINENO: \"$ac_compile\"") >&5
+ (eval $ac_compile) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } &&
+ { ac_try='test -s conftest.$ac_objext'
+ { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5
+ (eval $ac_try) 2>&5
+ ac_status=$?
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); }; }; then
+ ac_header_compiler=yes
+else
+ echo "$as_me: failed program was:" >&5
+cat conftest.$ac_ext >&5
+ac_header_compiler=no
+fi
+rm -f conftest.$ac_objext conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_compiler" >&5
+echo "${ECHO_T}$ac_header_compiler" >&6
+
+# Is the header present?
+echo "$as_me:$LINENO: checking $ac_header presence" >&5
+echo $ECHO_N "checking $ac_header presence... $ECHO_C" >&6
+cat >conftest.$ac_ext <<_ACEOF
+#line $LINENO "configure"
+#include "confdefs.h"
+#include <$ac_header>
+_ACEOF
+if { (eval echo "$as_me:$LINENO: \"$ac_cpp conftest.$ac_ext\"") >&5
+ (eval $ac_cpp conftest.$ac_ext) 2>conftest.er1
+ ac_status=$?
+ egrep -v '^ *\+' conftest.er1 >conftest.err
+ rm -f conftest.er1
+ cat conftest.err >&5
+ echo "$as_me:$LINENO: \$? = $ac_status" >&5
+ (exit $ac_status); } >/dev/null; then
+ if test -s conftest.err; then
+ ac_cpp_err=$ac_c_preproc_warn_flag
+ else
+ ac_cpp_err=
+ fi
+else
+ ac_cpp_err=yes
+fi
+if test -z "$ac_cpp_err"; then
+ ac_header_preproc=yes
+else
+ echo "$as_me: failed program was:" >&5
+ cat conftest.$ac_ext >&5
+ ac_header_preproc=no
+fi
+rm -f conftest.err conftest.$ac_ext
+echo "$as_me:$LINENO: result: $ac_header_preproc" >&5
+echo "${ECHO_T}$ac_header_preproc" >&6
+
+# So? What about this header?
+case $ac_header_compiler:$ac_header_preproc in
+ yes:no )
+ { echo "$as_me:$LINENO: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&5
+echo "$as_me: WARNING: $ac_header: accepted by the compiler, rejected by the preprocessor!" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
+ no:yes )
+ { echo "$as_me:$LINENO: WARNING: $ac_header: present but cannot be compiled" >&5
+echo "$as_me: WARNING: $ac_header: present but cannot be compiled" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: check for missing prerequisite headers?" >&5
+echo "$as_me: WARNING: $ac_header: check for missing prerequisite headers?" >&2;}
+ { echo "$as_me:$LINENO: WARNING: $ac_header: proceeding with the preprocessor's result" >&5
+echo "$as_me: WARNING: $ac_header: proceeding with the preprocessor's result" >&2;};;
+esac
+echo "$as_me:$LINENO: checking for $ac_header" >&5
+echo $ECHO_N "checking for $ac_header... $ECHO_C" >&6
+if eval "test \"\${$as_ac_Header+set}\" = set"; then
+ echo $ECHO_N "(cached) $ECHO_C" >&6
+else
+ eval "$as_ac_Header=$ac_header_preproc"
+fi
+echo "$as_me:$LINENO: result: `eval echo '${'$as_ac_Header'}'`" >&5
+echo "${ECHO_T}`eval echo '${'$as_ac_Header'}'`" >&6
+
+fi
+if test `eval echo '${'$as_ac_Header'}'` = yes; then
+ cat >>confdefs.h <<_ACEOF
+#define `echo "HAVE_$ac_header" | $as_tr_cpp` 1
+_ACEOF
+
+fi
+
+done
+
+
for ac_header in netinet/tcp.h
do
as_ac_Header=`echo "ac_cv_header_$ac_header" | $as_tr_sh`
@@ -12646,7 +12760,13 @@
depfiles ) test x"$AMDEP_TRUE" != x"" || for mf in $CONFIG_FILES; do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
- if (sed 1q $mf | fgrep 'generated by automake') > /dev/null 2>&1; then
+ # Check whether this is an Automake generated Makefile or not.
+ # We used to match only the files named `Makefile.in', but
+ # some people rename them; so instead we look at the file content.
+ # Grep'ing the first line is not enough: some people post-process
+ # each Makefile.in and add a new line on top of each file to say so.
+ # So let's grep whole file.
+ if grep '^#.*generated by automake' $mf > /dev/null 2>&1; then
dirpart=`(dirname "$mf") 2>/dev/null ||
$as_expr X"$mf" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \
X"$mf" : 'X\(//\)[^/]' \| \
Index: configure.ac
===================================================================
RCS file: /cvsroot/openvpn/openvpn/configure.ac,v
retrieving revision 1.37
diff -u -r1.37 configure.ac
--- configure.ac 14 Sep 2002 21:54:10 -0000 1.37
+++ configure.ac 27 Sep 2002 22:41:39 -0000
@@ -169,6 +169,7 @@
AC_CHECK_HEADERS(netinet/in.h)
AC_CHECK_HEADERS(netinet/in_systm.h)
AC_CHECK_HEADERS(netinet/ip.h)
+AC_CHECK_HEADERS(netinet/if_ether.h)
AC_CHECK_HEADERS(netinet/tcp.h)
AC_CHECK_HEADERS(resolv.h)
AC_CHECK_HEADERS(arpa/inet.h)
Index: syshead.h
===================================================================
RCS file: /cvsroot/openvpn/openvpn/syshead.h,v
retrieving revision 1.10
diff -u -r1.10 syshead.h
--- syshead.h 28 Jul 2002 07:54:57 -0000 1.10
+++ syshead.h 27 Sep 2002 22:41:40 -0000
@@ -141,8 +141,16 @@
#ifdef TARGET_LINUX
+#ifdef HAVE_NETINET_IF_ETHER_H
+#include <netinet/if_ether.h>
+#endif
+
#ifdef HAVE_LINUX_IF_TUN_H
#include <linux/if_tun.h>
+#endif
+
+#ifdef HAVE_NETINET_IP_H
+#include <netinet/ip.h>
#endif
#endif /* TARGET_LINUX */
Index: tun.c
===================================================================
RCS file: /cvsroot/openvpn/openvpn/tun.c,v
retrieving revision 1.17
diff -u -r1.17 tun.c
--- tun.c 28 Jul 2002 07:54:57 -0000 1.17
+++ tun.c 27 Sep 2002 22:41:41 -0000
@@ -277,7 +277,6 @@
msg (M_ERR, "Cannot open tun/tap dev %s", dev_node);
CLEAR (ifr);
- ifr.ifr_flags = IFF_NO_PI;
if (is_dev_type (dev, dev_type, "tun"))
{
@@ -339,13 +338,43 @@
int
write_tun (struct tuntap* tt, uint8_t *buf, int len)
{
- return write (tt->fd, buf, len);
+ struct tun_pi pi;
+ struct iphdr *iph;
+ struct iovec vect[2];
+ int ret;
+
+ iph = (struct iphdr *)buf;
+
+ pi.flags = 0;
+
+ if(iph->version == 6)
+ pi.proto = htons(ETH_P_IPV6);
+ else
+ pi.proto = htons(ETH_P_IP);
+
+ vect[0].iov_len = sizeof(pi);
+ vect[0].iov_base = π
+ vect[1].iov_len = len;
+ vect[1].iov_base = buf;
+
+ ret = writev(tt->fd, vect, 2);
+ return(ret - sizeof(pi));
}
int
read_tun (struct tuntap* tt, uint8_t *buf, int len)
{
- return read (tt->fd, buf, len);
+ struct iovec vect[2];
+ struct tun_pi pi;
+ int ret;
+
+ vect[0].iov_len = sizeof(pi);
+ vect[0].iov_base = π
+ vect[1].iov_len = len;
+ vect[1].iov_base = buf;
+
+ ret = readv(tt->fd, vect, 2);
+ return(ret - sizeof(pi));
}
#elif defined(TARGET_SOLARIS)
|
|
From: Matthias A. <ma+...@dt...> - 2002-09-17 15:56:32
|
On Sun, 15 Sep 2002, James Yonan wrote:
> Well actually "Forking server support" is really a misnomer. It would
> be better titled "Server support for arbitrary number of connecting
> clients without requiring a separate config file and a
> pre-instantiated daemon for every client, or just "scalability
> support". xinetd is an interesting idea. Anyone using xinetd with
> OpenVPN?
I tried and failed, and the problem is that openvpn is not prepared to
be run from xinetd -- it would have to take the socket it is passed in,
rather than trying to opening a new one.
Here's how far I got, it would take openvpn to add an --inetd option,
I'll see if I get that done. Note that server_args is a single line.
service openvpn
{
type = UNLISTED
port = 5002
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/local/sbin/openvpn-log
server_args = --user vpn --verb 5 --float --dev tun0 --ifconfig 192.168.0.1 192.168.0.129 --up /service/openvpn/script-up --comp-lzo --mlock --secret /service/openvpn/openvpn.key --ping 60
}
--
Matthias Andree
|
|
From: R P H. <he...@ow...> - 2002-09-16 21:05:27
|
I was working through the openvpn material, and had been
testing with the following design checklist (see bottom)
The thought is to provide a hub and spoke design for isolated
non-routable subnets at the end of the spokes, behind
otherwise properly routed outbound-only NATting (which allow
return packets ...), where there is available a central
routable IP hub available (to allow static custom routing
between those subnets).
I can ping, and indeed set up an SSH session, out to the hub,
which indicates that encapsulation of TCP within the OpenVPN
client is occurring -- I leave encryption off, as I am in
process diagnosing where things are falling apart --
-- after a couple minutes, it locks up tight, and I have
to go kill the remote Hub routing, out of band.
As such, I have not gotten the second subnet set up yet.
The tracing shows packets for a while, but then the consoles
lock (in which the tracing is occurring), and I cannot
ctrl-C to regain control. Network connectivity remains active
-- I can work out of band on the Hub, the enar spoke terminus
is local ...
Any thoughts on a theoretical reason this should not work?
-- Russ Herrold
=============================================================
Hub and Spoke Topology:
HUB x.y.z.a is a static IP, in routable space -- all other
devices are masqueraded, and not reachible from the outside,
The VPN gateway will encapsulate VPN network destination traffic into the
TUN interface, and pass the rest along to the next hop exterior NAT device
Subnets:
|
10.1.1.1 |
client --- gateway ---- NAT ------ internet ----- HUB
10.1.1.2 | 10.1.1.254 0.0.0.0 x.y.z.a
\ |
\--- 192.168.1.2 ----------- 192.168.1.1
| P-t-P
10.1.1.x segment |
/
-----------------------/
|
10.10.10.1 |
client --- gateway ---- NAT ------ internet ----- HUB
10.10.10.2 | 10.10.10.254 0.0.0.0 x.y.z.a
\ |
\--- 192.168.10.2 ----------- 192.168.10.1
| P-t-P
10.10.10.x segment |
/
-----------------------/
Routing:
on VPN gateway-10.1.1.1
( next hop: route add default gateway 10.1.1.254 )
route add -host 192.168.1.1 gateway 192.168.1.2
route add -net 10.0.0.0 gateway 192.168.1.1
on VPN gateway-10.10.10.1
( next hop: route add default gateway 10.10.10.254 )
route add -host 192.168.10.1 gateway 192.168.10.2
route add -net 10.0.0.0 gateway 192.168.10.1
on HUB -- simple reciprocal routing for each VPN'd subnet
route add -host 192.168.1.2 gateway 192.168.1.1
route add -net 10.1.1.0 gateway 192.168.1.2
route add -host 192.168.10.2 gateway 192.168.10.1
route add -net 10.10.10.0 gateway 192.168.10.2
Local gateway behind NAT
modprobe tun
echo 1 > /proc/sys/net/ipv4/ip_forward
openvpn --remote x.y.z.a --dev tun --port 5001 \
--ifconfig 192.168.1.2 192.168.1.1 --verb 8
Local gateway behind NAT
modprobe tun
echo 1 > /proc/sys/net/ipv4/ip_forward
openvpn --remote x.y.z.a --dev tun --port 5010 \
--ifconfig 192.168.10.2 192.168.10.1 --verb 8
Central HUB (== x.y.z.a )
modprobe tun
echo 1 > /proc/sys/net/ipv4/ip_forward
openvpn --dev tun --port 5001 \
--ifconfig 192.168.1.1 192.168.1.2 --verb 8
openvpn --dev tun --port 5010 \
--ifconfig 192.168.10.1 192.168.10.2 --verb 8
===================================
|
|
From: James Y. <ji...@yo...> - 2002-09-15 19:17:10
|
Matthias Andree <ma+...@dt...> said: > On Sat, 14 Sep 2002, James Yonan wrote: > > > (1) Forking server support > > (2) Automatic Secure MTU discovery > > (3) IPv6 endpoints or IPv6 over tun device > > (4) Windows port > > > > While none of these (with perhaps the exception of the last :) is > > rocket science, all require some work, and given that OpenVPN has > > reached a nice stability plateau, I'd like to hear your opinions on > > future directions in the development effort. > > ad 1) what's this good for? Sharing one port? Won't really work with > UDP. Convenience? Go get daemontools, or let's figure if openvpn > can be run from xinetd. Not something that should be done unless > you're really bored or have some compelling reason (a malicious > person holding a gun against your head might be one). Don't waste > your time. Well actually "Forking server support" is really a misnomer. It would be better titled "Server support for arbitrary number of connecting clients without requiring a separate config file and a pre-instantiated daemon for every client, or just "scalability support". xinetd is an interesting idea. Anyone using xinetd with OpenVPN? > ad 2) I'd like to see that somewhen in the future, but I'd give IPv6 the > preference. > > ad 3) IPv6 is certainly something that will have to be added. > > ad 4) If they want secure networking, they shouldn't be running an > operating system of which the current version forces you to > register with the vendor, sending data you don't control. > > It may be a moot point, but IMHO Windows which is made and sold by > a company that's always looking at its own profit, acting to its > own advantage, no matter how ruthless, and that aims to harm > OpenSource just to fortify its monopoly, to make more money, and > to control ever more markets to further maximize its huge > revenues, should not be supported by OpenSource developers. While I agree that Windows is marketed by an aggressive monopoly, I don't agree that just because a company is anti-open-source, we shouldn't port open source software to its platform or make *nix implementations of its protocols. On the contrary, I would argue that the more ruthlessly Microsoft behaves, the more that Open Source can benefit by porting to Windows, because once we have a large body of cross-platform software, then suddenly the OS won't matter as much and people will be free to choose based on quality. And the ultimate weapon against a ruthless monopoly is this: Give customers a choice. Having said that, and having glimpsed the cries of agony on the cipe-win32 list from those who have faced the windows network driver model, I expect that a win port will not be a panacea. James > If your opinion differs from mine, that's called freedom. :-) > Matthias Andree |
|
From: Matthias A. <ma+...@dt...> - 2002-09-14 22:19:44
|
On Sat, 14 Sep 2002, James Yonan wrote:
> (1) Forking server support
> (2) Automatic Secure MTU discovery
> (3) IPv6 endpoints or IPv6 over tun device
> (4) Windows port
>
> While none of these (with perhaps the exception of the last :) is
> rocket science, all require some work, and given that OpenVPN has
> reached a nice stability plateau, I'd like to hear your opinions on
> future directions in the development effort.
ad 1) what's this good for? Sharing one port? Won't really work with
UDP. Convenience? Go get daemontools, or let's figure if openvpn
can be run from xinetd. Not something that should be done unless
you're really bored or have some compelling reason (a malicious
person holding a gun against your head might be one). Don't waste
your time.
ad 2) I'd like to see that somewhen in the future, but I'd give IPv6 the
preference.
ad 3) IPv6 is certainly something that will have to be added.
ad 4) If they want secure networking, they shouldn't be running an
operating system of which the current version forces you to
register with the vendor, sending data you don't control.
It may be a moot point, but IMHO Windows which is made and sold by
a company that's always looking at its own profit, acting to its
own advantage, no matter how ruthless, and that aims to harm
OpenSource just to fortify its monopoly, to make more money, and
to control ever more markets to further maximize its huge
revenues, should not be supported by OpenSource developers.
If your opinion differs from mine, that's called freedom. :-)
--
Matthias Andree
|
|
From: James Y. <ji...@yo...> - 2002-09-14 21:40:53
|
CURRENT STATUS -------------- Here's an update on OpenVPN progress for the last two months... 1.3.1 appears to be very stable and there haven't been a lot of new patches recently, though having said that there are certainly a few, most notably a minor patch to enable NetBSD support, and better support for intermediate CAs. WISH LIST --------- The current wish list stands as follows: (1) Forking server support (2) Automatic Secure MTU discovery (3) IPv6 endpoints or IPv6 over tun device (4) Windows port While none of these (with perhaps the exception of the last :) is rocket science, all require some work, and given that OpenVPN has reached a nice stability plateau, I'd like to hear your opinions on future directions in the development effort. DONATIONS --------- I'd also like to bring to your attention the fact that the OpenVPN project is now accepting donations. Please consider a small donation (such as $20) if you are actively using OpenVPN and possibly more if you are deriving significant utility from the software. Right now I am "between jobs" and therefore don't have as much time as I'd like to spend on open source, but with enough support from the user community I hope to forge ahead on more of the wish list. Having said that, I'd like to emphasize that OpenVPN has been a team effort with many individuals now cited in the change log or offering support on the lists. Still, there's a lot of less glamorous work required to keep an open source project alive, such as merging contributions, testing on multiple platforms, documentation, releases, web site and mailing list admin, tech support, answering questions, keeping up to date with libraries, staying on top of security issues, trying to figure out whether problem reports ar! e bugs or operator error, etc. etc. Those all add up to a significant time commitment, and bear in mind that even a small donation can go a long way towards funding this kind of work. If you would like to donate, you can do so via pay-pal: https://www.paypal.com/xclick/business=paypal%40yonan.net I you have deeper pockets and want to make a more dramatic gesture, you might even consider hiring me :) My resume is here: http://openvpn.sourceforge.net/resume2002/ PRE-1.3.2 BETA AVAILABLE ------------------------ While there hasn't been a great deal of development activity over the past two months, there are a small number of low-impact patches waiting in the queue that I'd like to release. Here's the change log: * Added SSL_CTX_set_client_CA_list call to follow the canonical form for TLS initialization recommended by the OpenSSL docs. This change allows better support for intermediate CAs and has no impact on security. * Added build-inter script to easy-rsa package, to facilitate the generation of intermediate CAs. * Ported to NetBSD (Dimitri Goldin). * Fixed minor bug in easy-rsa/sign-req. It refers to openssl.cnf file, instead of $KEY_CONFIG, like all other scripts (Ernesto Baschny). * Added --days 3650 to the root CA generation command in the howto to override the woefully small 30 day default (Dominik 'Aeneas' Schnitzer). * Added paypal links to website for project donations. * Configured sourceforge mailing lists to require admin approval for non-member posts to reduce spam. If you have time, are using TLS, and especially if you are using an intermediate CA, I would encourage you to test this beta and verify that the first point in the change log does not cause problems. Download beta: http://openvpn.sourceforge.net/beta/openvpn-1.3.1.4.tar.gz SPAM ---- In other news, openvpn-users got its first spam the other day. While spam certainly has not been a big problem here, I want to be as proactive as possible in keeping these lists from becoming spam vectors, so I've reconfigured the lists to require admin approval for non-member posts. I'm willing to be the admin on this as long as it doesn't become a big time sink, and you can make life easier for me by subscribing before you post. Thanks, James Yonan OpenVPN Project Leader |
|
From: James Y. <ji...@yo...> - 2002-08-27 19:19:31
|
Richard A Nelson <co...@vn...> said: > On Tue, 27 Aug 2002, James Yonan wrote: > > > Hello Richard, > > Hi, thanks for the quick feedback > > > Normally we shouldn't get EAGAIN in the UDP read loop because we block on select and don't call recvfrom until there is a datagram waiting for us. So the fact that you are getting a lot of EAGAIN messages is interesting and probably indicative of some kind of problem. Is there any correlation between the EAGAIN floods and some sort of real world factor such as a bad or congested network condition? > > Its hard to reproduce, but congestion is definitely a possiblity > > > If EAGAIN is received from recvfrom (or any other error for that matter), it is syslogged and the select event loop continues. So your potential solutions 1 and 2 below are already being done. Solution 3 doesn't work because OpenVPN is too asynchronous to be able to block on a single i/o call. That's why we use select instead. > > I thought that #3 might be out of the question, and I'm glad to know > that the IO is indeed retried > > > Also, floods of non-fatal error returns from recvfrom are generally logged for informational purposes, but can be controlled by the --mute option so as not to clog up the log files. > > I'll keep that in mind, but for now I think I'll keep the verbosity to > help in tracking > > > You also mention that sometimes the session drops. What do you mean? Does OpenVPN crash or exit? Does it try to renegotiate? Does the tunnel die for a while and then come back? What kind of encryption mode are you running in (Static Key, TLS, or cleartext)? > > The tunnel seems to survive, but any open telnet/ssh/etc. session over > it timeout and die. Unfortunately, OpenVPN doesn't have control over the timeouts of application protocols that run over the tunnel. So if there's a network outage, though OpenVPN will almost certainly recover when the network comes up, applications with connections on the tunnel may time out. > > For now, I'm using a static key, but would like to move to certificates. > > > Since I don't know how to reproduce this, I'll need more details. > > It happens here every other day or so, I'll be glad to provide any > information I can. > > -- > Rick Nelson > I can saw a woman in two, but you won't want to look in the box when I do > 'For My Next Trick I'll Need a Volunteer' -- Warren Zevon > James |
|
From: James Y. <ji...@yo...> - 2002-08-27 17:33:39
|
Hello Richard, Normally we shouldn't get EAGAIN in the UDP read loop because we block on select and don't call recvfrom until there is a datagram waiting for us. So the fact that you are getting a lot of EAGAIN messages is interesting and probably indicative of some kind of problem. Is there any correlation between the EAGAIN floods and some sort of real world factor such as a bad or congested network condition? If EAGAIN is received from recvfrom (or any other error for that matter), it is syslogged and the select event loop continues. So your potential solutions 1 and 2 below are already being done. Solution 3 doesn't work because OpenVPN is too asynchronous to be able to block on a single i/o call. That's why we use select instead. Also, floods of non-fatal error returns from recvfrom are generally logged for informational purposes, but can be controlled by the --mute option so as not to clog up the log files. You also mention that sometimes the session drops. What do you mean? Does OpenVPN crash or exit? Does it try to renegotiate? Does the tunnel die for a while and then come back? What kind of encryption mode are you running in (Static Key, TLS, or cleartext)? Since I don't know how to reproduce this, I'll need more details. James > ----- Forwarded message from Richard A Nelson <co...@vn...> ----- > > From: Richard A Nelson <co...@vn...> > Reply-To: Richard A Nelson <co...@vn...>, > 15...@bu... > To: su...@bu... > Subject: Bug#158404: openvpn: Improper error handling > Date: Mon, 26 Aug 2002 17:28:37 -0400 > X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND version=2.20 > > Package: openvpn > Version: 1.3.0-1 > Severity: important > > I often get a flood of these messages: > openvpn[1239]: read from UDP: Resource temporarily unavailable (errno=11) > > The condition persists for a bit, and then clears up... While the errors > are occuring, occasionally the session will drop ;( > > It seems to be improper handling of EAGAIN ! > The potential solutions would most likely be: > 1) re-try the systemcall > 2) redrive the read loop > 3) set blocking IO > > -- System Information > Debian Release: testing/unstable > Kernel Version: Linux badlands.lexington.ibm.com 2.4.20-pre4-ac1 #13 Sat Aug 24 19:11:43 EDT 2002 i686 unknown unknown GNU/Linux > > Versions of the packages openvpn depends on: > ii libc6 2.2.5-14 GNU C Library: Shared libraries and Timezone > ii liblzo1 1.07-1 A real-time data compression library. > ii libssl0.9.6 0.9.6g-2 SSL shared libraries > > ----- End forwarded message ----- > > -- > Alberto Gonzalez Iniesta | They that give up essential liberty > ag...@ag... | to obtain a little temporary safety > Encrypted mail preferred | deserve neither liberty nor safety. > > Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 > > > ------------------------------------------------------- > This sf.net email is sponsored by: OSDN - Tired of that same old > cell phone? Get a new here for FREE! > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > -- |
|
From: Alberto G. I. <ag...@ag...> - 2002-08-27 14:44:47
|
Hi James et al, I just came back from holidays and got this bug report in Debian. (Seems like IBM is using OpenVPN). I didn't have time to look at it yet, but I'm sure you'll handle it better anyway :) Best regards, Alberto ----- Forwarded message from Richard A Nelson <co...@vn...> ----- From: Richard A Nelson <co...@vn...> Reply-To: Richard A Nelson <co...@vn...>, 15...@bu... To: su...@bu... Subject: Bug#158404: openvpn: Improper error handling Date: Mon, 26 Aug 2002 17:28:37 -0400 X-Spam-Status: No, hits=-4.5 required=5.0 tests=SENT_BY_BTS,FORGED_RCVD_FOUND version=2.20 Package: openvpn Version: 1.3.0-1 Severity: important I often get a flood of these messages: openvpn[1239]: read from UDP: Resource temporarily unavailable (errno=11) The condition persists for a bit, and then clears up... While the errors are occuring, occasionally the session will drop ;( It seems to be improper handling of EAGAIN ! The potential solutions would most likely be: 1) re-try the systemcall 2) redrive the read loop 3) set blocking IO -- System Information Debian Release: testing/unstable Kernel Version: Linux badlands.lexington.ibm.com 2.4.20-pre4-ac1 #13 Sat Aug 24 19:11:43 EDT 2002 i686 unknown unknown GNU/Linux Versions of the packages openvpn depends on: ii libc6 2.2.5-14 GNU C Library: Shared libraries and Timezone ii liblzo1 1.07-1 A real-time data compression library. ii libssl0.9.6 0.9.6g-2 SSL shared libraries ----- End forwarded message ----- -- Alberto Gonzalez Iniesta | They that give up essential liberty ag...@ag... | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 |
|
From: James Y. <ji...@nt...> - 2002-07-30 21:14:28
|
As many of you have probably noticed, the OpenSSL project released a security update today which fixes potential remote buffer overflows. What you may not have known is that the ASN1 parser bug was independently discovered in the process of stress testing OpenVPN, earning yours truly the dubious distinction of being acknowledged in the security advisory. So here's the scoop for OpenVPN users: (1) If you are using preshared static key mode, you are not vulnerable. (2) If you are using TLS mode with --tls-auth, you are not vulnerable. (3) If you are using TLS mode without --tls-auth, you may be vulnerable if you are also using --float. If you think you are vulnerable, the quickest fix is to start using --tls-auth, which was explicitly designed to protect against buffer overflows in OpenSSL by creating a two-tier authentication hierarchy that forces ALL incoming packets to authenticate via HMAC before they are passed on to the TLS code in OpenSSL. Think of it as a kind of MAC firewall. In general you should also consider downgrading privileges with --user and/or --group, to limit the damage that would be caused by a remote buffer overflow attack. If for whatever reason you must run as root, then consider using the --chroot option to lock the OpenVPN daemon into a restricted filesystem, so that a remote attack would not be able to modify sensitive files. Of course most systems have a lot of other apps and daemons that depend on OpenSSL so upgrading ASAP is probably the best course. James |
|
From: Dimitri G. <dm...@su...> - 2002-07-27 10:21:37
|
Hi, >One question I have, were you able to connect OpenVPN running on NetBSD to >OpenVPN running on a different platform such as Linux? Yes, my peer is a Linux box. |
|
From: James Y. <ji...@nt...> - 2002-07-27 02:03:30
|
Dimitri, Thanks for the patch, I will apply it to the CVS shortly. One question I have, were you able to connect OpenVPN running on NetBSD to OpenVPN running on a different platform such as Linux? I ask because some tun/tap devices will prepend unnecessary stuff onto the datagram that must be disabled with an explicit ioctl call if cross-platform compatibility is to be preserved. You can see some examples of this in tun.c. If this is the case, you might find that NetBSD <-> NetBSD tunnels work fine, but NetBSD <-> Linux tunnels are broken. Just something to check for if possible... James ----- Original Message ----- From: "Dimitri Goldin" <dm...@su...> To: <ope...@li...> Sent: Friday, July 26, 2002 3:58 PM Subject: [Openvpn-devel] NetBSD patch for OpenVPN > Hello list, > > The patch for the NetBSD "support" ist ready. > I only added some entries for NetBSD and used the same ifconfig code > as OpenBSD in tun.c. > The patch is attached. > I hope I did everything right. > > Cheers, > Dimitri > -- > pub 1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...> > Fingerprint: 3AA9 1264 51AA 0BB5 EB29 A6E3 9648 F42A 3A26 4EA8 > "Don't Panic." > > |
|
From: Dimitri G. <dm...@su...> - 2002-07-26 21:58:28
|
Hello list,
The patch for the NetBSD "support" ist ready.
I only added some entries for NetBSD and used the same ifconfig code
as OpenBSD in tun.c.
The patch is attached.
I hope I did everything right.
Cheers,
Dimitri
--
pub 1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
Fingerprint: 3AA9 1264 51AA 0BB5 EB29 A6E3 9648 F42A 3A26 4EA8
"Don't Panic."
|
|
From: James Y. <ji...@nt...> - 2002-07-26 01:04:50
|
Hi Dimitri, Yes, it would be great if you would like to do a NetBSD port. I imagine it would be pretty straightforward, given the existence of FreeBSD, OpenBSD, and Mac OS X ports. The "PORTS" file has a nice rundown on making a clean port, with some points on testing to make sure all the major features work correctly. Best Regards, James > Hello developers, > > Tried to setup a vpn with a friend today. > The box ist running NetBSD 1.5.2. > But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in > my config file I've got the error > "Sorry, but I don't know how to do 'ifconfig' > commands on this operating system. You should ifconfig your tun/tap device > manually or use an --up script." > > The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2 > 10.0.0.2". I don't know why but it always did: > 4: tun/tap device /dev/tun1 opened > 5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344 > > After some testings I've decided to try the OpenBSD ifconfig code in tun.c > since the syntax is similar for such simple operations. > I replaced the message about unknown ifconfig with this code and it > worked without any problems. > It's quick and dirty, but if there is interest in a NetBSD port then I will add it properly. > > Greets, > Dimitri > -- > "A towel is about the most massively useful > thing an interstellar hitch hiker can have." -- Hitchicker's Guide > pub 1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...> > Fingerprint: 3AA9 1264 51AA 0BB5 EB29 A6E3 9648 F42A 3A26 4EA8 > > > ------------------------------------------------------- > This sf.net email is sponsored by: Jabber - The world's fastest growing > real-time communications platform! Don't just IM. Build it in! > http://www.jabber.com/osdn/xim > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > |
|
From: <dm...@th...> - 2002-07-25 21:01:01
|
Hello developers,
Tried to setup a vpn with a friend today.
The box ist running NetBSD 1.5.2.
But when I tried to start the openvpn with "ifconfig 10.0.0.2 10.0.0.1" in
my config file I've got the error
"Sorry, but I don't know how to do 'ifconfig'
commands on this operating system. You should ifconfig your tun/tap device
manually or use an --up script."
The --up thing didn't woked. I tried "--up ifconfig 10.0.0.2
10.0.0.2". I don't know why but it always did:
4: tun/tap device /dev/tun1 opened
5: ifconfig tun1 10.0.0.2 10.0.0.1 tun1 1300 1344
After some testings I've decided to try the OpenBSD ifconfig code in tun.c
since the syntax is similar for such simple operations.
I replaced the message about unknown ifconfig with this code and it
worked without any problems.
It's quick and dirty, but if there is interest in a NetBSD port then I will add it properly.
Greets,
Dimitri
--
"A towel is about the most massively useful
thing an interstellar hitch hiker can have." -- Hitchicker's Guide
pub 1024D/3A264EA8 2002-07-07 Dimitri Goldin <dm...@su...>
Fingerprint: 3AA9 1264 51AA 0BB5 EB29 A6E3 9648 F42A 3A26 4EA8
|
|
From: Sampo N. <aud...@au...> - 2002-07-24 12:59:10
|
> > > Hi Sampo, > > > > > > > I have been busy writing a forking server > > > > addon to openvpn. > > Will forking server only work for TLS mode? No, It works also with shared secret or without security. For prefork security I could use either the key used for tls-auth or preshared secret. Any examples of how to implement tls-auth like authentication in simples form? > > --remote as server addres in the client. > > > > I just got it running. Still with out dynamic ip address assigment > > and proper signal handling in parent process. And there ain't > > anykind of DoS protection yet. > > One way to do DoS protection would be to augment --tls-auth with persistent > anti-replay protection by saving the Session ID (struct session_id) and > reject any Session ID that was seen before. Let's see when I get it working. :-) > > port before calling openvpn(). Mayby I could add the exchange of > > address info here, since I don't think it needs to be > > transferred over a secure channel. > > Actually the temporary keys + options_string() get passed over the secure > TLS channel, so you could add further handshaking options and they would be > secure. > > > > > > This way I have been able to keep > > > > those well tested procedures and protocol > > > > of openvpn untouched. > > > > > > > > I still have some questions unsolved like > > > > DoS protection, dropping root priviledges > > > > and how to handel SIGUSR1 and SIGHUP. > > It would be cool if we could get the forking server to work with dropping > root privs. > > One of the goals of dropping privs is that no datagram is ever read from the > network with root privs. > > It would be great if we could preserve this behavior. > > Otherwise the split privileges model of the new openssh would be a > possibility, but it's more complex. For a forking server accepting connections from any ip, I consider it even more critical than for a peer2peer version. I did it simply by calling set_user() in the server's main process and everything seems to work at least for me. Don't know if this works in all cases since the server drops priviledges before opening tun dev. Sampo |
|
From: James Y. <ji...@nt...> - 2002-07-23 20:18:11
|
> > Hi Sampo, > > > > > I have been busy writing a forking server > > > addon to openvpn. Will forking server only work for TLS mode? > > > > Cool... Does each potential connecting client need a separate config file, > > or does the server use a common client template and then keep track of > > things like dynamic ports, dynamic endpoint addresses, etc? > > No they don't. I just use normal config files/command line and use > --remote as server addres in the client. > > I just got it running. Still with out dynamic ip address assigment > and proper signal handling in parent process. And there ain't > anykind of DoS protection yet. One way to do DoS protection would be to augment --tls-auth with persistent anti-replay protection by saving the Session ID (struct session_id) and reject any Session ID that was seen before. > > Lack of dynamic addresses still limits it to a single connection > but a pool of addresses should not be too hard to implement. > > There are also need for a few new options like the range > of ports/addresses used. > > Ofcourse there should also be an ability to define > addresses to each client. I haven't decided how to > do that yet. > > > > > > In openvpn.c I have separated the processing of > > > parameters from main() to a new function and > > > moved main to another file to allow me to > > > link against different main() functions. > > > > > > One that implements normal peer2peer vpn > > > and two others that produces forkin' server > > > and client. > > > > > > These use a simple UDP protocol to agree a > > > port to use, after which server forks do > > > some handshaking with client and then > > > calls openvpn() funcition from openvpn.c > > > > Are you sure there needs to be a new protocol to do this? > > > No, I am not. But found it easy to implement in this manner. > > > Suppose the master server listens on a particular port, reads the initial > > datagram from a connecting client, verifies the integrity of the datagram > > using a --tls-auth variant, allocates a dynamic port, forks a new server > > process, and continues in its event loop. > > It really sounds reasonable. I also though of some kind > of message authentication before fork. --tls-auth > sounds good since it is quite light-weight. > > > When the forked process finishes up the TLS authentication, it can take the > > Common Name from the client certificate and use it to determine the > > appropriate config profile to use (containing ifconfig addresses, route > > statements, etc.) > > > > Or the handshaking could be done by passing a configuration string in the > > TLS payload, similar to the string now built by options_string(). > > At the moment I do some handshaking in dynamically allocated > port before calling openvpn(). Mayby I could add the exchange of > address info here, since I don't think it needs to be > transferred over a secure channel. Actually the temporary keys + options_string() get passed over the secure TLS channel, so you could add further handshaking options and they would be secure. > > > > This way I have been able to keep > > > those well tested procedures and protocol > > > of openvpn untouched. > > > > > > I still have some questions unsolved like > > > DoS protection, dropping root priviledges > > > and how to handel SIGUSR1 and SIGHUP. It would be cool if we could get the forking server to work with dropping root privs. One of the goals of dropping privs is that no datagram is ever read from the network with root privs. It would be great if we could preserve this behavior. Otherwise the split privileges model of the new openssh would be a possibility, but it's more complex. > > > > Maybe keep track of all children, so when the master process gets a signal, > > it dispatches it to each child process, then to itself. > > Sounds good to me. I am going to keep track of childs anyway > to maintain address/port pool. > > > Trying to explain things to someone, > amazingly helps to figure out those things for one self! > I got a bunch of new ideas while writing this. > > > Got to go home now or I will sit coding here until > midnight :-) > > > > Sampo > James |
|
From: Sampo N. <aud...@au...> - 2002-07-23 15:57:17
|
hi, > Hi Sampo, > > > I have been busy writing a forking server > > addon to openvpn. > > Cool... Does each potential connecting client need a separate config file, > or does the server use a common client template and then keep track of > things like dynamic ports, dynamic endpoint addresses, etc? No they don't. I just use normal config files/command line and use --remote as server addres in the client. I just got it running. Still with out dynamic ip address assigment and proper signal handling in parent process. And there ain't anykind of DoS protection yet. Lack of dynamic addresses still limits it to a single connection but a pool of addresses should not be too hard to implement. There are also need for a few new options like the range of ports/addresses used. Ofcourse there should also be an ability to define addresses to each client. I haven't decided how to do that yet. > > In openvpn.c I have separated the processing of > > parameters from main() to a new function and > > moved main to another file to allow me to > > link against different main() functions. > > > > One that implements normal peer2peer vpn > > and two others that produces forkin' server > > and client. > > > > These use a simple UDP protocol to agree a > > port to use, after which server forks do > > some handshaking with client and then > > calls openvpn() funcition from openvpn.c > > Are you sure there needs to be a new protocol to do this? No, I am not. But found it easy to implement in this manner. > Suppose the master server listens on a particular port, reads the initial > datagram from a connecting client, verifies the integrity of the datagram > using a --tls-auth variant, allocates a dynamic port, forks a new server > process, and continues in its event loop. It really sounds reasonable. I also though of some kind of message authentication before fork. --tls-auth sounds good since it is quite light-weight. > When the forked process finishes up the TLS authentication, it can take the > Common Name from the client certificate and use it to determine the > appropriate config profile to use (containing ifconfig addresses, route > statements, etc.) > > Or the handshaking could be done by passing a configuration string in the > TLS payload, similar to the string now built by options_string(). At the moment I do some handshaking in dynamically allocated port before calling openvpn(). Mayby I could add the exchange of address info here, since I don't think it needs to be transferred over a secure channel. > > This way I have been able to keep > > those well tested procedures and protocol > > of openvpn untouched. > > > > I still have some questions unsolved like > > DoS protection, dropping root priviledges > > and how to handel SIGUSR1 and SIGHUP. > > Maybe keep track of all children, so when the master process gets a signal, > it dispatches it to each child process, then to itself. Sounds good to me. I am going to keep track of childs anyway to maintain address/port pool. Trying to explain things to someone, amazingly helps to figure out those things for one self! I got a bunch of new ideas while writing this. Got to go home now or I will sit coding here until midnight :-) Sampo |
|
From: James Y. <ji...@nt...> - 2002-07-23 10:09:00
|
Hi Sampo, > I have been busy writing a forking server > addon to openvpn. Cool... Does each potential connecting client need a separate config file, or does the server use a common client template and then keep track of things like dynamic ports, dynamic endpoint addresses, etc? > In openvpn.c I have separated the processing of > parameters from main() to a new function and > moved main to another file to allow me to > link against different main() functions. > > One that implements normal peer2peer vpn > and two others that produces forkin' server > and client. > > These use a simple UDP protocol to agree a > port to use, after which server forks do > some handshaking with client and then > calls openvpn() funcition from openvpn.c Are you sure there needs to be a new protocol to do this? Suppose the master server listens on a particular port, reads the initial datagram from a connecting client, verifies the integrity of the datagram using a --tls-auth variant, allocates a dynamic port, forks a new server process, and continues in its event loop. When the forked process finishes up the TLS authentication, it can take the Common Name from the client certificate and use it to determine the appropriate config profile to use (containing ifconfig addresses, route statements, etc.) Or the handshaking could be done by passing a configuration string in the TLS payload, similar to the string now built by options_string(). > This way I have been able to keep > those well tested procedures and protocol > of openvpn untouched. > > I still have some questions unsolved like > DoS protection, dropping root priviledges > and how to handel SIGUSR1 and SIGHUP. Maybe keep track of all children, so when the master process gets a signal, it dispatches it to each child process, then to itself. > I hope I can overcome these and mail > you a patch. > > > > > Sampo > > > > > Hi Michael, > > > > Right now OpenVPN doesn't support a forking-server model on a single port, > > it's strictly peer-to-peer with an OpenVPN process instantiated at both ends > > of the connection, and each connection on a unique port. > > > > There has been some recent discussions about a forking-server implementation > > on this list -- see the "add a server feature to openvpn to share udp > > ports?" thread in the openvpn-devel archives. > > > > I think the simplest way to do this would be something like: > > > > (1) Add a --forking-server flag that causes the main OpenVPN event loop to > > fork a new process for each initial datagram received from a client. > > (2) The newly forked server process switches to a dynamic port before > > responding back to the connecting client. This is quite a bit simpler and > > more efficient than trying to run all clients over the same UDP port. > > (3) OpenVPN already has code (see the implementation of --float) that will > > adapt to the new port number returned by the response to initial datagram > > sent from server to client. I have also confirmed that this type of UDP > > port switch is recognized by both Linux and Cisco stateful firewalls. > > > > There are a some complications that would need to be handled: > > > > (1) You would need to protect against DoS attacks that flood the server with > > fork requests. Possibly some variation of --tls-auth that would > > authenticate the initial packet before the fork call. > > > > (2) If a client connects, gets disconnected, then connects again, you would > > need to make sure that the old server process gets killed before a new > > server process is forked. > > > > Unfortunately I'm pretty busy right now with my day job, so I may not get to > > this for a while. If you want to take a shot at some kind of > > implementation, I will do my best to answer your questions. > > > > Best Regards, > > James > > > > ----- Original Message ----- > > From: "Michael Grigoriev" <ma...@ni...> > > To: <ope...@li...> > > Sent: Monday, July 22, 2002 6:53 PM > > Subject: [Openvpn-devel] Multiple VPN connections on the same port > > > > > > > Hi, > > > > > > Firstly I'd like to thank you a prompt responce to my last question - > > > it was most helpful. > > > > > > Now I am looking into the posibility of setting up a VPN server that > > > will accept incoming VPN connections from some number of clients. (I do > > > realize that client/server only really applies to TLS-mode, by client I > > > really just mean the machine that will initialize the connection, the > > > one that will be started with --remote) However I am not sure how to > > > best implement this since I don't know the number of clients in > > > advance, so I can't really have a port assigned to each client. Instead > > > I would like to have all clients to connect to the server on the same > > > port. I did not however find a way to do so with OpenVPN. When I tried > > > to have to have two clients connect to the same server, they just kept > > > periodically knocking each other off with error messages of the sort: > > > 105: TLS Error: Unroutable control packet received from > > > 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1) > > > So I guess my question is, is it supposed to work? The man page says > > > that you "should" have all the connections use a different port, which > > > would imply that it is possible to do the opposite, but I was not able > > > to get it to work.... > > > If it is not possible, as far as I understand it should not be too hard > > > to implement... We could have the server start out bound to the > > > listening port, but not connected, and when we get an incoming > > > connection from some ip, we fork and call connect in the child, so that > > > in the future all packets from that ip would go to that process. Right? > > > > > > Would this work? Is there a better way to accomplish this? > > > > > > -- > > > Thanks in advance, > > > mag > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Openvpn-devel mailing list > > > Ope...@li... > > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Openvpn-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > |
|
From: Sampo N. <aud...@au...> - 2002-07-23 07:11:59
|
Hello James and Michael, I have been busy writing a forking server addon to openvpn. In openvpn.c I have separated the processing of parameters from main() to a new function and moved main to another file to allow me to link against different main() functions. One that implements normal peer2peer vpn and two others that produces forkin' server and client. These use a simple UDP protocol to agree a port to use, after which server forks do some handshaking with client and then calls openvpn() funcition from openvpn.c This way I have been able to keep those well tested procedures and protocol of openvpn untouched. I still have some questions unsolved like DoS protection, dropping root priviledges and how to handel SIGUSR1 and SIGHUP. I hope I can overcome these and mail you a patch. Sampo > Hi Michael, > > Right now OpenVPN doesn't support a forking-server model on a single port, > it's strictly peer-to-peer with an OpenVPN process instantiated at both ends > of the connection, and each connection on a unique port. > > There has been some recent discussions about a forking-server implementation > on this list -- see the "add a server feature to openvpn to share udp > ports?" thread in the openvpn-devel archives. > > I think the simplest way to do this would be something like: > > (1) Add a --forking-server flag that causes the main OpenVPN event loop to > fork a new process for each initial datagram received from a client. > (2) The newly forked server process switches to a dynamic port before > responding back to the connecting client. This is quite a bit simpler and > more efficient than trying to run all clients over the same UDP port. > (3) OpenVPN already has code (see the implementation of --float) that will > adapt to the new port number returned by the response to initial datagram > sent from server to client. I have also confirmed that this type of UDP > port switch is recognized by both Linux and Cisco stateful firewalls. > > There are a some complications that would need to be handled: > > (1) You would need to protect against DoS attacks that flood the server with > fork requests. Possibly some variation of --tls-auth that would > authenticate the initial packet before the fork call. > > (2) If a client connects, gets disconnected, then connects again, you would > need to make sure that the old server process gets killed before a new > server process is forked. > > Unfortunately I'm pretty busy right now with my day job, so I may not get to > this for a while. If you want to take a shot at some kind of > implementation, I will do my best to answer your questions. > > Best Regards, > James > > ----- Original Message ----- > From: "Michael Grigoriev" <ma...@ni...> > To: <ope...@li...> > Sent: Monday, July 22, 2002 6:53 PM > Subject: [Openvpn-devel] Multiple VPN connections on the same port > > > > Hi, > > > > Firstly I'd like to thank you a prompt responce to my last question - > > it was most helpful. > > > > Now I am looking into the posibility of setting up a VPN server that > > will accept incoming VPN connections from some number of clients. (I do > > realize that client/server only really applies to TLS-mode, by client I > > really just mean the machine that will initialize the connection, the > > one that will be started with --remote) However I am not sure how to > > best implement this since I don't know the number of clients in > > advance, so I can't really have a port assigned to each client. Instead > > I would like to have all clients to connect to the server on the same > > port. I did not however find a way to do so with OpenVPN. When I tried > > to have to have two clients connect to the same server, they just kept > > periodically knocking each other off with error messages of the sort: > > 105: TLS Error: Unroutable control packet received from > > 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1) > > So I guess my question is, is it supposed to work? The man page says > > that you "should" have all the connections use a different port, which > > would imply that it is possible to do the opposite, but I was not able > > to get it to work.... > > If it is not possible, as far as I understand it should not be too hard > > to implement... We could have the server start out bound to the > > listening port, but not connected, and when we get an incoming > > connection from some ip, we fork and call connect in the child, so that > > in the future all packets from that ip would go to that process. Right? > > > > Would this work? Is there a better way to accomplish this? > > > > -- > > Thanks in advance, > > mag > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Openvpn-devel mailing list > > Ope...@li... > > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > |
|
From: James Y. <ji...@nt...> - 2002-07-23 06:44:53
|
Hi Michael, Right now OpenVPN doesn't support a forking-server model on a single port, it's strictly peer-to-peer with an OpenVPN process instantiated at both ends of the connection, and each connection on a unique port. There has been some recent discussions about a forking-server implementation on this list -- see the "add a server feature to openvpn to share udp ports?" thread in the openvpn-devel archives. I think the simplest way to do this would be something like: (1) Add a --forking-server flag that causes the main OpenVPN event loop to fork a new process for each initial datagram received from a client. (2) The newly forked server process switches to a dynamic port before responding back to the connecting client. This is quite a bit simpler and more efficient than trying to run all clients over the same UDP port. (3) OpenVPN already has code (see the implementation of --float) that will adapt to the new port number returned by the response to initial datagram sent from server to client. I have also confirmed that this type of UDP port switch is recognized by both Linux and Cisco stateful firewalls. There are a some complications that would need to be handled: (1) You would need to protect against DoS attacks that flood the server with fork requests. Possibly some variation of --tls-auth that would authenticate the initial packet before the fork call. (2) If a client connects, gets disconnected, then connects again, you would need to make sure that the old server process gets killed before a new server process is forked. Unfortunately I'm pretty busy right now with my day job, so I may not get to this for a while. If you want to take a shot at some kind of implementation, I will do my best to answer your questions. Best Regards, James ----- Original Message ----- From: "Michael Grigoriev" <ma...@ni...> To: <ope...@li...> Sent: Monday, July 22, 2002 6:53 PM Subject: [Openvpn-devel] Multiple VPN connections on the same port > Hi, > > Firstly I'd like to thank you a prompt responce to my last question - > it was most helpful. > > Now I am looking into the posibility of setting up a VPN server that > will accept incoming VPN connections from some number of clients. (I do > realize that client/server only really applies to TLS-mode, by client I > really just mean the machine that will initialize the connection, the > one that will be started with --remote) However I am not sure how to > best implement this since I don't know the number of clients in > advance, so I can't really have a port assigned to each client. Instead > I would like to have all clients to connect to the server on the same > port. I did not however find a way to do so with OpenVPN. When I tried > to have to have two clients connect to the same server, they just kept > periodically knocking each other off with error messages of the sort: > 105: TLS Error: Unroutable control packet received from > 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1) > So I guess my question is, is it supposed to work? The man page says > that you "should" have all the connections use a different port, which > would imply that it is possible to do the opposite, but I was not able > to get it to work.... > If it is not possible, as far as I understand it should not be too hard > to implement... We could have the server start out bound to the > listening port, but not connected, and when we get an incoming > connection from some ip, we fork and call connect in the child, so that > in the future all packets from that ip would go to that process. Right? > > Would this work? Is there a better way to accomplish this? > > -- > Thanks in advance, > mag > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > |
|
From: Michael G. <ma...@ni...> - 2002-07-22 23:47:24
|
Hi, Firstly I'd like to thank you a prompt responce to my last question - it was most helpful. Now I am looking into the posibility of setting up a VPN server that will accept incoming VPN connections from some number of clients. (I do realize that client/server only really applies to TLS-mode, by client I really just mean the machine that will initialize the connection, the one that will be started with --remote) However I am not sure how to best implement this since I don't know the number of clients in advance, so I can't really have a port assigned to each client. Instead I would like to have all clients to connect to the server on the same port. I did not however find a way to do so with OpenVPN. When I tried to have to have two clients connect to the same server, they just kept periodically knocking each other off with error messages of the sort: 105: TLS Error: Unroutable control packet received from 192.168.xx.xx:7000 (si=3 op=P_CONTROL_SOFT_RESET_V1) So I guess my question is, is it supposed to work? The man page says that you "should" have all the connections use a different port, which would imply that it is possible to do the opposite, but I was not able to get it to work.... If it is not possible, as far as I understand it should not be too hard to implement... We could have the server start out bound to the listening port, but not connected, and when we get an incoming connection from some ip, we fork and call connect in the child, so that in the future all packets from that ip would go to that process. Right? Would this work? Is there a better way to accomplish this? -- Thanks in advance, mag |
|
From: James Y. <ji...@nt...> - 2002-07-19 06:00:28
|
Hi Michael, You are right that it is not difficult for an attacker to replay UDP datagrams. OpenVPN uses a variant of the "sliding-window" algorithm used by IPSec where each packet is tagged with a unique, incrementing sequence number, allowing any replayed datagrams to be identified and dropped. Various methods are used to ensure the uniqueness of the sequence number. To prevent the sequence number from wrapping around in static-key mode (which uses a long-term, pre-shared key), the sequence number is 64 bits, where 32 bits is a unix timestamp at daemon initialization and the other 32 bits is an incrementing number. If the incrementing number wraps to 0, then we also update the unix timestamp to the current time. In TLS mode we use 32 bits for the sequence number, with a mandatory re-keying if the sequence number approaches its wrap around value. See packet_id.c for the anti-replay algorithm. While it is true that block cipher chaining is made more complex due to the unreliable nature of UDP transport (where packets can be dropped or received out-of-order), OpenVPN (and IPSec as well)make each datagram atomic and stateless by using an "Explicit IV" where the initialiation vector is explicitly recorded in the datagram header, rather than being implicitly assumed based on the residual IV of the previous datagram. This means that datagrams can be decrypted regardless of the order in which they are received. In CBC cipher mode (the default in OpenVPN), the initial IV on daemon initialization is randomized, and each subsequent datagram is encrypted using the current key and the residual IV of the previous datagram. The uncertainty in the IV combined with the uniqueness of the sequence number ensures that it is highly unlikely that two identical plaintext blocks would encrypt to the same ciphertext. OFB and CFB cipher modes handle the IV slightly differently (using the sequence number as the IV) to ensure that IV collisions never occur. Most of the IV logic can be found in crypto.c. Cut and paste attacks where the datagram ciphertext is modified are made infeasable by the use of a keyed HMAC hash controlled by the --auth option. For several papers on HMAC, see: http://www.cs.ucsd.edu/users/mihir/papers/hmac.html Note that OpenVPN takes the HMAC of the ciphertext rather than the plaintext, so it is not vulnerable to the ssh exploit described here: http://openvpn.sourceforge.net/papers/ssh-security.pdf For additional discussion into the problems of encrypting and authenticating an unreliable data stream (such as UDP), check out the IPSec ESP spec: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt OpenVPN borrows much in the way of theory and concepts from IPSec with the goal of producing a portable, lightweight, user-space VPN implementation. Since IPSec must also deal with securing an unreliable data stream, several concepts have been transferable such as sliding window-based replay protection and explicit IV. For additional theoretical documentation you might want to check out the book Applied Cryptography by Bruce Schneier, which while being an extremely well-written practical guide to cryptography, contains references to a great deal of theoretical material. James ----- Original Message ----- From: "Michael Grigoriev" <ma...@ni...> To: <ope...@li...> Sent: Thursday, July 18, 2002 4:04 PM Subject: [Openvpn-devel] Replay attacks > Hi all, > > I am wondering how OpenVPN overcomes the inherit vulnerability of UDP > comunications to "replay" or "cut-and-paste" attacks, since it is > impossible to implement cipher block chaining. > Also, if anybody could point me to any theoretical documentation on the > subject, it would be greatly appreciated. > Thanks in advance, > -- mag > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Openvpn-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openvpn-devel > |
|
From: Alberto G. I. <ag...@ag...> - 2002-07-18 21:29:36
|
On Thu, Jul 18, 2002 at 05:04:30PM -0500, Michael Grigoriev wrote: > Hi all, > > I am wondering how OpenVPN overcomes the inherit vulnerability of UDP > comunications to "replay" or "cut-and-paste" attacks, since it is > impossible to implement cipher block chaining. > Also, if anybody could point me to any theoretical documentation on the > subject, it would be greatly appreciated. > Thanks in advance, > -- mag From the man page: --no-replay Disable OpenVPN's protection against replay attacks. Don't use this option unless you are prepared to make a tradeoff of greater efficiency in exchange for less security. OpenVPN provides datagram replay protection by default. Replay protection is accomplished by tagging each outgoing datagram with an identifier that is guaranteed to be unique for the key being used. The peer that receives the datagram will check for the uniqueness of the identifier. If the identifier was already received in a previous datagram, OpenVPN will drop the packet. Replay protection is important to defeat attacks such as a SYN flood attack, where the attacker lis tens in the wire, intercepts a TCP SYN packet (identifying it by the context in which it occurs in relation to other packets), then floods the receiving peer with copies of this packet. OpenVPN's replay protection is implemented in slightly different ways, depending on the key management mode you have selected. In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses a 64 bit unique identifier that combines a time stamp with an incre menting sequence number. When using TLS mode for key exchange and a CBC cipher mode, OpenVPN uses only a 32 bit sequence number without a time stamp, since OpenVPN can guarantee the uniqueness of this value for each key. As in IPSec, if the sequence number is close to wrapping back to zero, OpenVPN will trig ger a new key exchange. To check for replays, OpenVPN uses the sliding window algorithm used by IPSec. Regards, Alberto -- Alberto Gonzalez Iniesta | They that give up essential liberty ag...@ag... | to obtain a little temporary safety Encrypted mail preferred | deserve neither liberty nor safety. Key fingerprint = 9782 04E7 2B75 405C F5E9 0C81 C514 AF8E 4BA4 01C3 |
|
From: Michael G. <ma...@ni...> - 2002-07-18 20:57:37
|
Hi all, I am wondering how OpenVPN overcomes the inherit vulnerability of UDP comunications to "replay" or "cut-and-paste" attacks, since it is impossible to implement cipher block chaining. Also, if anybody could point me to any theoretical documentation on the subject, it would be greatly appreciated. Thanks in advance, -- mag |