Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.1.0 released

[David Balazic]

James Yonan wrote:
> 
> I'm happy to announce the release of OpenVPN 2.1.0.  This release is 
> basically 2.1_rc22 + some last-minute trivial fixes to 
> documentation and plugin sample code.  Enjoy!

Does this mean patches are now accepted?

In other words: What is next? What is the plan?

Regards,
David

Re: [Openvpn-devel] OpenVPN 2.1_rc19 released

[David Balazic]

Hi!


As this discussion has not much to do with the rc19 release, would
you please change the subject ?
Like "OpenVPN and SELinux" or "Securing the OpenVPN process" ...

Thanks,
David


> -Original Message-
> From: Karl O. Pinc [mailto:k...@meme.com] 
> Sent: Wednesday, July 29, 2009 6:17 PM
> To: Alon Bar-Lev
> Cc: openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] OpenVPN 2.1_rc19 released
> 
> On 07/28/2009 11:47:57 PM, Alon Bar-Lev wrote:
> > Well,
> > I do not understand you guys.
> > 
> > If you think SELinux is so great, why do you need chroot?
> > It is like you put some money in safe, and then put the safe into
> > another safe, it never ends... Why only two safe, let's put another
> > safe...
> > I know that this is the approach many of security advisors 
> use, but I
> > never could have found the logic.
> > If you want to keep your money safe use a single safe and select the
> > strongest one.
> 
> The idea is more like selecting the strongest safe, then putting
> it behind a moat inside a ring of fire.  That way the thief not
> only has to be a good safe cracker, he must also be
> a fire walker and a swimmer, with experience wrestling
> alligators a decided advantage.  Multiple layers of _different_
> security raises the bar considerably.
> 
> 
> 
> Karl 
> Free Software:  "You don't pay back, you pay forward."
>  -- Robert A. Heinlein
> 
> 
> --
> 
> Let Crystal Reports handle the reporting - Free Crystal 
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and 
> deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 

Re: [Openvpn-devel] Patch Queue, was: Re: [PATCH] Fix for "Cannot read current defaultgateway" problem on Linux

[David Balazic]

James Yonan wrote:

> Alon Bar-Lev wrote:
> > On Tuesday 10 February 2009 13:35:35 David Balazic wrote:
> >> Ping ?
> >>
> >> Should I resend the patch without the end-of-line-spaces change ?
> > 
> > James has his own response times.
> > I suggest you have much patience :)
> > 
> > Alon.
> 
> I apologize for not having the bandwidth to focus as much on 
> the patch 
> queue as I would like, but please understand that we're on 
> the verge of 
> releasing 2.1 and we have to be very conservative about accepting 
> patches at this point.
> 
> I think it's fair to ask that we try to limit ourselves at this late 
> stage to patches that address issues that affect a large number of 
> users, or bug fixes that are sufficiently trivial that there 
> is little 
> or no chance of causing unforeseen breakage.  I think there 
> needs to be 
> an argument for why the patch is important right now, as opposed to 
> waiting a while for the 2.2 beta series.

Of course.

 - the bug has been reported in several instances (see my first mail)
 - the patch affects only one architecture (besides the unused parameter
on others;
I could have made different function declarations for different archs,
but that
would be less readable/maintainable IMO)
 - the patch affects only one code path, that is taken only when the bug
is triggered
 - it is simple:
   - a few lines to record the gateway interface name
   - a few lines to use it in case the gw addresss is 0.0.0.0
 - it is field tested (in a scenario which triggers the bug)

Regards,
David

Re: [Openvpn-devel] [PATCH] Fix for "Cannot read current defaultgateway" problem on Linux

[David Balazic]

Ping ?

Should I resend the patch without the end-of-line-spaces change ?

Regards,
David

> -Original Message-
> From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] 
> Sent: Tuesday, February 03, 2009 7:17 PM
> To: David Balazic
> Cc: James Yonan; openvpn-devel@lists.sourceforge.net
> Subject: Re: [PATCH] Fix for "Cannot read current 
> defaultgateway" problem on Linux
> 
> James,
> I guess you take over.
> There are many lines that does not change anything.
> Also, maybe it would be better to have one string variable and one
> type, (gateway, device) (gateway, address), so that it would be easier
> to manage if new type comes up.
> 
> Alon.
> 
> On 2/3/09, David Balazic <david.bala...@hermes-softlab.com> wrote:
> > James Yonan wrote:
> >
> >  > David,
> >  >
> >  > A couple issues with the patch:
> >  >
> >  > * sscanf usage doesn't check for buffer overflow.
> >
> >  See below.
> >
> >  > * You use gw_if_name in some places and gw_ifname in other
> >  > places.  To
> >  > eliminate confusion it would be best to use a consistent form.
> >
> >  Done.
> >
> >  > Also, to reiterate, try submitting the patch as an 
> attachment to deal
> >  > with email client munging issues.
> >
> >  OK.
> >
> >  About the sscanf:
> >  (copied from my earlier message to Alon)
> >
> > > 3. Please don't use scanf this way as it may overflow the buffer.
> >  > Use %##s and check that overflow is avoided.
> >
> >  I use "%32s\t" now.
> >  How do I check for overflow? sscanf always returns 1.
> >  Besides, the linux kernel headers declare 32 as maximum iface name
> >  length.
> >  Even in case of overflow, what shoudl I do ? Return false ?
> >  I think leaving it as is is good for 99,999% of cases and 
> in the rest
> >  (in case of overflow), either a gateway IP address is 
> present, so no
> >  problem, or the route add command will fail (or use the 
> wrong device).
> >  Not perfect, but what is in these days ? ;-)
> >
> >
> > Oh, my patch removes spaces at the end of some lines. My editor did
> >  this automatically. Is that a problem ? I thought to remove it from
> >  the patch, but then the next guy to edit it will have the 
> same problem.
> >
> >  The patch is attached.
> >
> >  Regards,
> >
> > David
> >
> >
> 

[Openvpn-devel] Diff format

[David Balazic]

Alon Bar-Lev wrote:

Subject: Fix for "Cannot read current default gateway" problem on Linux

> On Monday 02 February 2009 11:49:50 David Balazic wrote:
> > diff -u openvpn_trunk/route.c openvpn_patched/route.c
> > --- openvpn_trunk/route.c   2009-01-29 15:00:04.525034400 +0100
> > +++ openvpn_patched/route.c 2009-01-29 15:03:41.116012000 +0100
> > @@ -45,7 +45,7 @@
> >  
> >  static void add_route (struct route *r, const struct 
> tuntap *tt, unsigned int flags, const struct env_set *es);
> >  static void delete_route (const struct route *r, const 
> struct tuntap *tt, unsigned int flags, const struct env_set *es);
> > -static bool get_default_gateway (in_addr_t *ret);
> > +static bool get_default_gateway (in_addr_t *ret, char *gw_if_name);
> >  
> >  struct route_option_list *
> >  new_route_option_list (struct gc_arena *a)
> 
> Which version of diffutils do you use?
> How come there is a tab after file name in the header?

Well, I asked and it seems to be the normal state of things:


* From: Dave Korn 
* To: cygwin at cygwin dot com
* Date: Mon, 2 Feb 2009 17:56:10 +
* Subject: Re: diff inserts tab into header ?
* References: <worldclient-f200902021754.aa54240...@butn.net>

xerces8 wrote:
>>> I discovered this when trying to send a patch to a project and
>>> they rejected it because of this tab chars.
>> Are you sure this is the case? Can you send the exact message they
sent
>> you when they rejected the patch?
>
> Sure, they said this:
>
>>> Which version of diffutils do you use?
>>> How come there is a tab after file name in the header?

  They must be using a custom version or something strange like that.
The
TAB is placed there by the routine 'print_context_label()' in context.c,
you
can view the CVS history at

http://cvs.savannah.gnu.org/viewvc/diffutils/src/context.c?root=diffutil
s=log

and it's been right there since version 1.1, seventeen years ago (see
line 46).

  So AFAICT GNU diff has /always/ done this.


Regards,
David

Re: [Openvpn-devel] [PATCH] Fix for "Cannot read current default gateway" problem on Linux

[David Balazic]

diff -u openvpn_trunk/route.c openvpn_patched/route.c
--- openvpn_trunk/route.c   2009-01-29 15:00:04.525034400 +0100
+++ openvpn_patched/route.c 2009-01-29 15:03:41.116012000 +0100
@@ -45,7 +45,7 @@
 
 static void add_route (struct route *r, const struct tuntap *tt, unsigned int 
flags, const struct env_set *es);
 static void delete_route (const struct route *r, const struct tuntap *tt, 
unsigned int flags, const struct env_set *es);
-static bool get_default_gateway (in_addr_t *ret);
+static bool get_default_gateway (in_addr_t *ret, char *gw_if_name);
 
 struct route_option_list *
 new_route_option_list (struct gc_arena *a)
@@ -298,7 +298,7 @@
   rl->spec.remote_host_defined = true;
 }
 
-  rl->spec.net_gateway_defined = get_default_gateway (>spec.net_gateway);
+  rl->spec.net_gateway_defined = get_default_gateway (>spec.net_gateway, 
rl->spec.net_gateway_ifname);
   if (rl->spec.net_gateway_defined)
 {
   setenv_route_addr (es, "net_gateway", rl->spec.net_gateway, -1);
@@ -362,6 +362,7 @@
 add_route3 (in_addr_t network,
in_addr_t netmask,
in_addr_t gateway,
+   char * gateway_ifname,
const struct tuntap *tt,
unsigned int flags,
const struct env_set *es)
@@ -372,6 +373,7 @@
   r.network = network;
   r.netmask = netmask;
   r.gateway = gateway;
+  r.gateway_ifname = gateway_ifname;
   add_route (, tt, flags, es);
 }
 
@@ -418,6 +420,7 @@
add_route3 (rl->spec.remote_host,
~0,
rl->spec.net_gateway,
+   rl->spec.net_gateway_ifname,
tt,
flags,
es);
@@ -428,6 +431,7 @@
  add_route3 (0x,
  0x8000,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -436,6 +440,7 @@
  add_route3 (0x8000,
  0x8000,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -454,6 +459,7 @@
  add_route3 (0,
  0,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -511,6 +517,7 @@
  add_route3 (0,
  0,
  rl->spec.net_gateway,
+ rl->spec.net_gateway_ifname,
  tt,
  flags,
  es);
@@ -678,18 +685,24 @@
 
 #if defined(TARGET_LINUX)
 #ifdef CONFIG_FEATURE_IPROUTE
-  buf_printf (, IPROUTE_PATH " route add %s/%d via %s",
+  buf_printf (, IPROUTE_PATH " route add %s/%d",
  network,
- count_netmask_bits(netmask),
- gateway);
+ count_netmask_bits(netmask));
+  if (r->gateway)
+argv_printf_cat (, "via %s", gateway);
+  else
+argv_printf_cat (, "dev %s", r->gateway_ifname);
   if (r->metric_defined)
 buf_printf (, " metric %d", r->metric);
 
 #else
-  buf_printf (, ROUTE_PATH " add -net %s netmask %s gw %s",
+  buf_printf (, ROUTE_PATH " add -net %s netmask %s",
  network,
- netmask,
- gateway);
+ netmask);
+  if (r->gateway)
+argv_printf_cat (, "gw %s", gateway);
+  else
+argv_printf_cat (, "dev %s", r->gateway_ifname);
   if (r->metric_defined)
 buf_printf (, " metric %d", r->metric);
 #endif  /*CONFIG_FEATURE_IPROUTE*/
@@ -1014,7 +1027,7 @@
 }
 
 static bool
-get_default_gateway (in_addr_t *gateway)
+get_default_gateway (in_addr_t *gateway, char *gw_ifname)
 {
   struct gc_arena gc = gc_new ();
   int i;
@@ -1242,7 +1255,7 @@
 #elif defined(TARGET_LINUX)
 
 static bool
-get_default_gateway (in_addr_t *gateway)
+get_default_gateway (in_addr_t *gateway, char *gw_if_name)
 {
   struct gc_arena gc = gc_new ();
   bool ret = false;
@@ -1283,6 +1296,10 @@
  if (!net && !mask && metric < lowest_metric)
{
  best_gw = gw;
+ if (gw_if_name)
+   {
+ sscanf (line, "%" IFNAME_MAXLEN_STR "s\t", 
gw_if_name);
+   }
  lowest_metric = metric;
  best_count = count;
}
@@ -1292,7 +1309,7 @@
}
   fclose (fp);
 
-  if (best_gw)
+  if (best_count)
{
  *gateway = best_gw;
  ret = true;
@@ -1370,7 +1387,7 @@
 ((a) > 0 ? (1 + (((a) - 1) | (sizeof(long) - 1))) : sizeof(long))
 
 static bool
-get_default_gateway (in_addr_t *ret)
+get_default_gateway (in_addr_t *ret, char *gw_if_name)
 {
   struct gc_arena gc = gc_new ();
   

Re: [Openvpn-devel] [PATCH] Fix for "Cannot read current default gateway" problem on Linux

[David Balazic]

Alon Bar-Lev wrote:

> Some minor comments.
> 1. Please rebase against trunk.

Done.


> >  - gateway);
> >  + netmask);
> >  +  if (r->gateway)
> >  +argv_printf_cat (, "gw %s", gateway);
> >  +  else
> >  +argv_printf_cat (, "dev %s", r->gateway_ifname);
> >if (r->metric_defined)
> >  argv_printf_cat (, "metric %d", r->metric);
> >   #endif  /*CONFIG_FEATURE_IPROUTE*/
> 
> 2. Please declare a variable at the epilogue of the function 
> as gateway.

I don't understand what do you mean.
???

>  +   {
> >  + sscanf (line, "%s\t", gw_if_name);
> >  +   }
> 
> 3. Please don't use scanf this way as it may overflow the buffer.
> Use %##s and check that overflow is avoided.

I use "%32s\t" now.
How do I check for overflow? sscanf always returns 1.
Besides, the linux kernel headers declare 32 as maximum iface name
length.
Even in case of overflow, what shoudl I do ?
Return false ?
I think leaving it as is is good for 99,999% of cases and in the rest
(in case of overflow),
either a gateway IP address is present, so no problem, or the route add
command will
fail (or use the wrong device). Not perfect, but what is in these days ?
;-)


Regards,
David

PS: 

the new patch, against trunk:
diff -u openvpn_trunk/route.c openvpn_patched/route.c
--- openvpn_trunk/route.c   2009-01-29 15:00:04.525034400 +0100
+++ openvpn_patched/route.c 2009-01-29 15:03:41.116012000 +0100
@@ -45,7 +45,7 @@
 
 static void add_route (struct route *r, const struct tuntap *tt,
unsigned int flags, const struct env_set *es);
 static void delete_route (const struct route *r, const struct tuntap
*tt, unsigned int flags, const struct env_set *es);
-static bool get_default_gateway (in_addr_t *ret);
+static bool get_default_gateway (in_addr_t *ret, char *gw_if_name);
 
 struct route_option_list *
 new_route_option_list (struct gc_arena *a)
@@ -298,7 +298,7 @@
   rl->spec.remote_host_defined = true;
 }
 
-  rl->spec.net_gateway_defined = get_default_gateway
(>spec.net_gateway);
+  rl->spec.net_gateway_defined = get_default_gateway
(>spec.net_gateway, rl->spec.net_gateway_ifname);
   if (rl->spec.net_gateway_defined)
 {
   setenv_route_addr (es, "net_gateway", rl->spec.net_gateway, -1);
@@ -362,6 +362,7 @@
 add_route3 (in_addr_t network,
in_addr_t netmask,
in_addr_t gateway,
+   char * gateway_ifname,
const struct tuntap *tt,
unsigned int flags,
const struct env_set *es)
@@ -372,6 +373,7 @@
   r.network = network;
   r.netmask = netmask;
   r.gateway = gateway;
+  r.gateway_ifname = gateway_ifname;
   add_route (, tt, flags, es);
 }
 
@@ -418,6 +420,7 @@
add_route3 (rl->spec.remote_host,
~0,
rl->spec.net_gateway,
+   rl->spec.net_gateway_ifname,
tt,
flags,
es);
@@ -428,6 +431,7 @@
  add_route3 (0x,
  0x8000,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -436,6 +440,7 @@
  add_route3 (0x8000,
  0x8000,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -454,6 +459,7 @@
  add_route3 (0,
  0,
  rl->spec.remote_endpoint,
+ NULL,
  tt,
  flags,
  es);
@@ -511,6 +517,7 @@
  add_route3 (0,
  0,
  rl->spec.net_gateway,
+ rl->spec.net_gateway_ifname,
  tt,
  flags,
  es);
@@ -678,18 +685,24 @@
 
 #if defined(TARGET_LINUX)
 #ifdef CONFIG_FEATURE_IPROUTE
-  buf_printf (, IPROUTE_PATH " route add %s/%d via %s",
+  buf_printf (, IPROUTE_PATH " route add %s/%d",
  network,
- count_netmask_bits(netmask),
- gateway);
+ count_netmask_bits(netmask));
+  if (r->gateway)
+argv_printf_cat (, "via %s", gateway);
+  else
+argv_printf_cat (, "dev %s", r->gateway_ifname);
   if (r->metric_defined)
 buf_printf (, " metric %d", r->metric);
 
 #else
-  buf_printf (, ROUTE_PATH " add -net %s netmask %s gw %s",
+  buf_printf (, ROUTE_PATH " add -net %s netmask %s",
  network,
- netmask,
- gateway);
+ netmask);
+  if (r->gateway)
+argv_printf_cat (, "gw %s", gateway);
+  else
+argv_printf_cat (, "dev %s", r->gateway_ifname);
   if (r->metric_defined)
 buf_printf (, " metric %d", r->metric);
 

Re: [Openvpn-devel] windows 7 and openvpn

[David Balazic]

Did you try to run OpenVPN setup in compatibility mode ?
Set compatibility to Vista or XP.
 
Regards,
David




From: István Szukács [mailto:lecc...@gmail.com] 
Sent: Saturday, January 17, 2009 7:43 AM
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] windows 7 and openvpn


Hi folks!


I am wondering if you have ever had success to run openvpn on windows 
7. The problem is the latest 
installer(http://openvpn.net/release/openvpn-2.1_rc15-install.exe) says this 
version is not supporting windows I try to install 
http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe, 
works fine except the fact that the tap driver is not signed and because of 
this it remains disabled and you cannot use openvpn(but runs well up to the 
point when initialize the driver).

If you could point me a doc how to make it run on win7 it would be much 
appreciated. If I could help with anything the win7 build let me know


Regards,
Istvan


-- 
the sun shines for all

[Openvpn-devel] Fix for "Cannot read current default gateway" problem on Linux

[David Balazic]

Hi!

In the diff (agains 2.1_rc15) is the solution for the old*
problem of (not) detecting default gateway on linux systems
if it is a device route.

The patch is attached as a gzipped diff output to this mail message :
http://thread.gmane.org/gmane.network.openvpn.user/25117/focus=25127

(direct link to patch :
http://cache.gmane.org//gmane/network/openvpn/user/25127-001.bin
rename to patch.gz after download)

It was tested by one affected user (Antonis Tsolomitis, see the
thread "openvpn and ppp" on the openvpn-users list)

If I forgor anything, ask.

Regards,
David

*See mail list threads:
"Redirect-gateway on dialup"
 <http://thread.gmane.org/gmane.network.openvpn.user/20407>
"redirect-gateway + http-proxy + ppp problem"
 <http://thread.gmane.org/gmane.network.openvpn.user/20994>
"Cannot redirect gateway after pppd connection"
 <http://thread.gmane.org/gmane.network.openvpn.user/23972>
"openvpn and ppp"
 <http://thread.gmane.org/gmane.network.openvpn.user/25117>


> -Original Message-
> From: Antonis Tsolomitis [mailto:at...@aegean.gr] 
> Sent: Thursday, December 18, 2008 8:37 PM
> To: David Balazic
> Cc: Antonis Tsolomitis; openvpn-us...@lists.sourceforge.net
> Subject: Re: [Openvpn-users] openvpn and ppp
> 
> 
> Dear David, this binary works!! Here is the link to the full log.
> 
> http://myria.math.aegean.gr/~atsol/tmp/openvpnxs.log.gz
> 
> I will also try it in a few more configurations. I will try 
> to use your 
> patch to see if I can make an rpm.
> 
> Thank you for the help both you and Erich.
> 
> I will post again when I test in other machines with different 
> configurations.
> 
> thanks again,
> 
> Antonis.
> 
> 
> David Balazic wrote:
> > Hi!
> >
> > For the devs here is a patch.
> >
> > For you, here is  http://home.amis.net/dbalaic/openvpnxs.gz
> >
> > Try it instead of the old openvpn:
> >
> > wget http://home.amis.net/dbalaic/openvpnxs.gz
> > gzip -d openvpnxs.gz
> > ./openvpnxs --conf add the usual parameters here 
> > # do not put --conf twice ;-)
> >
> > Set full logging and send the logs in case id does not work.
> > Send them even if it works ;-)
> >
> > Regards,
> > David
> >
> >
> >   
> >> -Original Message-
> >> From: Antonis Tsolomitis [mailto:at...@aegean.gr] 
> >> Sent: Thursday, December 18, 2008 12:39 PM
> >> Cc: openvpn-us...@lists.sourceforge.net
> >> Subject: Re: [Openvpn-users] openvpn and ppp
> >>
> >> Antonis Tsolomitis wrote:
> >> 
> >>>>> --route-gateway has nothing to do with your problem.
> >>>>>
> >>>>> It can not help. (see the manual)
> >>>>> 
> >>>>>   
> >>>> You appear to have deeper insight in the route-gateway 
> >>>> 
> >> directive than I
> >> 
> >>>> do. The manual is pretty terse on this aspect. Could you 
> elaborate?
> >>>> 
> >> I verify that --route-gateway does not work. It produces the 
> >> same error 
> >> and does not manage to change the gateway (traceroute shows 
> >> the original 
> >> gateway)
> >>
> >> So it seems that we reached a dead end with respect to 
> >> "redirect-gateway 
> >> def1".
> >>
> >> Erich, I do not think that my situation is special in any 
> >> sense. I use 
> >> one of the well known distributions (Mandriva) (I promise to 
> >> try it on 
> >> Fedora too and report back) and I just want to connect to the 
> >> Internet 
> >> with ppp (simple dialup). I do not see why this setup is special.
> >>
> >> I am not a programmer (I am a Mathematician), so I can not 
> >> make a patch. 
> >> If I knew how to program I would do it of course.
> >>
> >> Are the developers members of this list? Do I have to make a 
> >> bug report?
> >>
> >> Finally, I would like to ask if it is possible to make a 
> >> script to fix 
> >> routing manually. How can this be done?
> >> I know how to find the Gateway. What are the proper 
> ip/route commands?
> >>
> >> thank you for your help,
> >>
> >> Antonis.
> >>
> >>
> >> --
> >> 
> >> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las 
> >> Vegas, Nevada.
> >> The future of the web can't happen without you.  Join us at 
> >> MIX09 to help
> >> pave the way to the Next Web now. Learn more and register at
> >> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009
> >> .visitmix.com/
> >> ___
> >> Openvpn-users mailing list
> >> openvpn-us...@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> >>
> >> 
> 
> 

Re: [Openvpn-devel] Bug with setting client gateway on reconnect ?

[David Balazic]

Hi!
 
I got bit by this bug again. Should I try the 2.1 beta ?
Are there any newer build than the OpenVPN 2.1_beta7 on openvpn.se ?
 
Regards,
David
 
PS: Is http://openvpn.net/ down ?
 



From: openvpn-devel-boun...@lists.sourceforge.net on behalf of David Balazic
Sent: Tue 27-Feb-07 12:01
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] Bug with setting client gateway on reconnect ?


Hi!
 
After a network failure, OpenVPN client reconnects to the server, but fails to 
set up the default route.
An USR1 signal then makes it reconnect properly (not visible in the logs below).
Note that the server IP is resolved just fine (how else could it then connect?)
 
Regards,
David
 
server : OpenVPN  2.0.8  on OpenWRT
client : OpenVPN 2.0.9 on Windows 2003
 
timeline :
09:47 establish connection for the first time , OK
10:43 network disconnect
10:44 network is back, reconnect OK, but gateway not set
 

Client log (I replaced real server IP with 99.88.77.66 and FQHN with 
my.openvpn.server.example.org):
 
Tue Feb 27 09:47:21 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 
2006
Tue Feb 27 09:47:21 2007 IMPORTANT: OpenVPN's default port number is now 1194, 
based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and 
earlier used 5000 as the default port.
Tue Feb 27 09:47:21 2007 *** WARNING ***: null cipher specified, no 
encryption will be used
Tue Feb 27 09:47:21 2007 TAP-WIN32 device [Local Area Connection 2] opened: 
\\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap 
 
Tue Feb 27 09:47:21 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 
10.4.0.2/255.255.255.252 on interface {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} 
[DHCP-serv: 10.4.0.1, lease-time: 31536000]
Tue Feb 27 09:47:21 2007 Successful ARP Flush on interface [2] 
{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}
Tue Feb 27 09:47:21 2007 UDPv4 link local (bound): [undef]:1194
Tue Feb 27 09:47:21 2007 UDPv4 link remote: 99.88.77.66:4500
Tue Feb 27 09:47:25 2007 Peer Connection Initiated with 99.88.77.66:4500
Tue Feb 27 09:47:26 2007 Initialization Sequence Completed
Tue Feb 27 10:43:54 2007 Inactivity timeout (--ping-restart), restarting
Tue Feb 27 10:43:54 2007 SIGUSR1[soft,ping-restart] received, process restarting
Tue Feb 27 10:43:56 2007 IMPORTANT: OpenVPN's default port number is now 1194, 
based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and 
earlier used 5000 as the default port.
Tue Feb 27 10:43:56 2007 *** WARNING ***: null cipher specified, no 
encryption will be used
Tue Feb 27 10:44:08 2007 RESOLVE: Cannot resolve host address: 
my.openvpn.server.example.org: [NO_DATA] The requested name is valid but does 
not have an IP address.
Tue Feb 27 10:44:08 2007 TAP-WIN32 device [Local Area Connection 2] opened: 
\\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap 
 
Tue Feb 27 10:44:08 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 
10.4.0.2/255.255.255.252 on interface {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} 
[DHCP-serv: 10.4.0.1, lease-time: 31536000]
Tue Feb 27 10:44:08 2007 Successful ARP Flush on interface [2] 
{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}
Tue Feb 27 10:44:08 2007 UDPv4 link local (bound): [undef]:1194
Tue Feb 27 10:44:08 2007 UDPv4 link remote: 99.88.77.66:4500
Tue Feb 27 10:44:16 2007 Peer Connection Initiated with 99.88.77.66:4500
Tue Feb 27 10:44:17 2007 NOTE: unable to redirect default gateway -- Cannot 
obtain current remote host address
Tue Feb 27 10:44:17 2007 Initialization Sequence Completed
 
server log (I replaced real client IP with 1.2.3.4):
 
Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58887
Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Initialization Sequence 
Completed
Feb 27 09:47:33 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58905
Feb 27 09:48:15 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58923
Feb 27 09:49:03 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58940
Feb 27 09:49:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58954
Feb 27 09:50:33 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58968
Feb 27 09:51:13 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58980
Feb 27 09:52:02 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58995
Feb 27 09:53:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59026
Feb 27 09:54:43 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59045
Feb 27 09:55:24 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59060
Feb 27 09:56:04 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59075
Feb 27 09:56:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59085
Feb 27 09:58:27 (none) kern.notice openvpn

[Openvpn-devel] Bug with setting client gateway on reconnect ?

[David Balazic]

Hi!
 
After a network failure, OpenVPN client reconnects to the server, but fails to 
set up the default route.
An USR1 signal then makes it reconnect properly (not visible in the logs below).
Note that the server IP is resolved just fine (how else could it then connect?)
 
Regards,
David
 
server : OpenVPN  2.0.8  on OpenWRT
client : OpenVPN 2.0.9 on Windows 2003
 
timeline :
09:47 establish connection for the first time , OK
10:43 network disconnect
10:44 network is back, reconnect OK, but gateway not set
 

Client log (I replaced real server IP with 99.88.77.66 and FQHN with 
my.openvpn.server.example.org):
 
Tue Feb 27 09:47:21 2007 OpenVPN 2.0.9 Win32-MinGW [SSL] [LZO] built on Oct  1 
2006
Tue Feb 27 09:47:21 2007 IMPORTANT: OpenVPN's default port number is now 1194, 
based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and 
earlier used 5000 as the default port.
Tue Feb 27 09:47:21 2007 *** WARNING ***: null cipher specified, no 
encryption will be used
Tue Feb 27 09:47:21 2007 TAP-WIN32 device [Local Area Connection 2] opened: 
\\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap
Tue Feb 27 09:47:21 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 
10.4.0.2/255.255.255.252 on interface {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} 
[DHCP-serv: 10.4.0.1, lease-time: 31536000]
Tue Feb 27 09:47:21 2007 Successful ARP Flush on interface [2] 
{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}
Tue Feb 27 09:47:21 2007 UDPv4 link local (bound): [undef]:1194
Tue Feb 27 09:47:21 2007 UDPv4 link remote: 99.88.77.66:4500
Tue Feb 27 09:47:25 2007 Peer Connection Initiated with 99.88.77.66:4500
Tue Feb 27 09:47:26 2007 Initialization Sequence Completed
Tue Feb 27 10:43:54 2007 Inactivity timeout (--ping-restart), restarting
Tue Feb 27 10:43:54 2007 SIGUSR1[soft,ping-restart] received, process restarting
Tue Feb 27 10:43:56 2007 IMPORTANT: OpenVPN's default port number is now 1194, 
based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and 
earlier used 5000 as the default port.
Tue Feb 27 10:43:56 2007 *** WARNING ***: null cipher specified, no 
encryption will be used
Tue Feb 27 10:44:08 2007 RESOLVE: Cannot resolve host address: 
my.openvpn.server.example.org: [NO_DATA] The requested name is valid but does 
not have an IP address.
Tue Feb 27 10:44:08 2007 TAP-WIN32 device [Local Area Connection 2] opened: 
\\.\Global\{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}.tap
Tue Feb 27 10:44:08 2007 Notified TAP-Win32 driver to set a DHCP IP/netmask of 
10.4.0.2/255.255.255.252 on interface {DED0C8F4-E03C-45AA-B64A-C128A7737FA5} 
[DHCP-serv: 10.4.0.1, lease-time: 31536000]
Tue Feb 27 10:44:08 2007 Successful ARP Flush on interface [2] 
{DED0C8F4-E03C-45AA-B64A-C128A7737FA5}
Tue Feb 27 10:44:08 2007 UDPv4 link local (bound): [undef]:1194
Tue Feb 27 10:44:08 2007 UDPv4 link remote: 99.88.77.66:4500
Tue Feb 27 10:44:16 2007 Peer Connection Initiated with 99.88.77.66:4500
Tue Feb 27 10:44:17 2007 NOTE: unable to redirect default gateway -- Cannot 
obtain current remote host address
Tue Feb 27 10:44:17 2007 Initialization Sequence Completed
 
server log (I replaced real client IP with 1.2.3.4):
 
Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58887
Feb 27 09:46:47 (none) kern.notice openvpn[7411]: Initialization Sequence 
Completed
Feb 27 09:47:33 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58905
Feb 27 09:48:15 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58923
Feb 27 09:49:03 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58940
Feb 27 09:49:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58954
Feb 27 09:50:33 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58968
Feb 27 09:51:13 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58980
Feb 27 09:52:02 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:58995
Feb 27 09:53:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59026
Feb 27 09:54:43 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59045
Feb 27 09:55:24 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59060
Feb 27 09:56:04 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59075
Feb 27 09:56:45 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59085
Feb 27 09:58:27 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59129
Feb 27 09:59:18 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59158
Feb 27 09:59:59 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59171
Feb 27 10:02:22 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59216
Feb 27 10:03:02 (none) kern.notice openvpn[7411]: Peer Connection Initiated 
with 1.2.3.4:59233
Feb 27