[Openvpn-devel] [PATCH 2.3] Use adapter index for add/delete_route_ipv6

2015-12-11 Thread Lev Stipakov
Trac #637
---
 src/openvpn/route.c | 8 
 src/openvpn/tun.c   | 6 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index 1775a9c..cf5a067 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1623,6 +1623,10 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct 
tuntap *tt, unsigned int fla

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
+  buf_printf (, "interface=%d", tt->adapter_index );
+  device = buf_bptr();
+
   /* netsh interface ipv6 add route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 add route %s/%d %s",
   get_win_sys_path(),
@@ -1954,6 +1958,10 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const 
struct tuntap *tt, unsigne

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
+  buf_printf (, "interface=%d", tt->adapter_index );
+  device = buf_bptr();
+
   /* netsh interface ipv6 delete route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 delete route %s/%d %s",
   get_win_sys_path(),
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index b4223b1..b08c827 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -1231,11 +1231,13 @@ do_ifconfig (struct tuntap *tt,
   {
char * saved_actual;
char iface[64];
+   DWORD idx;

if (!strcmp (actual, "NULL"))
  msg (M_FATAL, "Error: When using --tun-ipv6, if you have more than 
one TAP-Windows adapter, you must also specify --dev-node");

-   openvpn_snprintf(iface, sizeof(iface), "interface=%lu", 
get_adapter_index_flexible(actual));
+   idx = get_adapter_index_flexible(actual);
+   openvpn_snprintf(iface, sizeof(iface), "interface=%lu", idx);

/* example: netsh interface ipv6 set address interface=42 
2001:608:8003::d store=active */
argv_printf (,
@@ -1253,6 +1255,8 @@ do_ifconfig (struct tuntap *tt,
 */
saved_actual = tt->actual_name;
tt->actual_name = (char*) actual;
+   /* we use adapter_index in add_route_ipv6 */
+   tt->adapter_index = idx;
add_route_connected_v6_net(tt, es);
tt->actual_name = saved_actual;
   }
-- 
1.9.1




[Openvpn-devel] [PATCH v2 master] Use adapter index for add/delete_route_ipv6

2015-12-11 Thread Lev Stipakov
Trac #637

Signed-off-by: Lev Stipakov 
---
 src/openvpn/route.c | 16 
 src/openvpn/tun.c   |  6 +-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index 4a60345..2012b5c 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1770,13 +1770,17 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct 
tuntap *tt, unsigned int fla

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
   if ( r6->adapter_index ) /* vpn server special route */
 {
-  struct buffer out = alloc_buf_gc (64, );
   buf_printf (, "interface=%d", r6->adapter_index );
-  device = buf_bptr();
   gateway_needed = true;
 }
+  else
+{
+  buf_printf (, "interface=%d", tt->adapter_index );
+}
+  device = buf_bptr();

   /* netsh interface ipv6 add route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 add route %s/%d %s",
@@ -2168,13 +2172,17 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const 
struct tuntap *tt, unsigne

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
   if ( r6->adapter_index ) /* vpn server special route */
 {
-  struct buffer out = alloc_buf_gc (64, );
   buf_printf (, "interface=%d", r6->adapter_index );
-  device = buf_bptr();
   gateway_needed = true;
 }
+  else
+{
+  buf_printf (, "interface=%d", tt->adapter_index );
+}
+  device = buf_bptr();

   /* netsh interface ipv6 delete route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 delete route %s/%d %s",
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 014d988..efcd225 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -1306,11 +1306,13 @@ do_ifconfig (struct tuntap *tt,
   {
char * saved_actual;
char iface[64];
+   DWORD idx;

if (!strcmp (actual, "NULL"))
  msg (M_FATAL, "Error: When using --tun-ipv6, if you have more than 
one TAP-Windows adapter, you must also specify --dev-node");

-   openvpn_snprintf(iface, sizeof(iface), "interface=%lu", 
get_adapter_index_flexible(actual));
+   idx = get_adapter_index_flexible(actual);
+   openvpn_snprintf(iface, sizeof(iface), "interface=%lu", idx);

/* example: netsh interface ipv6 set address interface=42 
2001:608:8003::d store=active */
argv_printf (,
@@ -1328,6 +1330,8 @@ do_ifconfig (struct tuntap *tt,
 */
saved_actual = tt->actual_name;
tt->actual_name = (char*) actual;
+   /* we use adapter_index in add_route_ipv6 */
+   tt->adapter_index = idx;
add_route_connected_v6_net(tt, es);
tt->actual_name = saved_actual;
   }
-- 
1.9.1




[Openvpn-devel] [PATCH master] Use adapter index for add/delete_route_ipv6

2015-12-11 Thread Lev Stipakov
Trac #637

Signed-off-by: Lev Stipakov 
---
 src/openvpn/route.c | 16 
 src/openvpn/tun.c   |  2 ++
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index 4a60345..2012b5c 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1770,13 +1770,17 @@ add_route_ipv6 (struct route_ipv6 *r6, const struct 
tuntap *tt, unsigned int fla

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
   if ( r6->adapter_index ) /* vpn server special route */
 {
-  struct buffer out = alloc_buf_gc (64, );
   buf_printf (, "interface=%d", r6->adapter_index );
-  device = buf_bptr();
   gateway_needed = true;
 }
+  else
+{
+  buf_printf (, "interface=%d", tt->adapter_index );
+}
+  device = buf_bptr();

   /* netsh interface ipv6 add route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 add route %s/%d %s",
@@ -2168,13 +2172,17 @@ delete_route_ipv6 (const struct route_ipv6 *r6, const 
struct tuntap *tt, unsigne

 #elif defined (WIN32)

+  struct buffer out = alloc_buf_gc (64, );
   if ( r6->adapter_index ) /* vpn server special route */
 {
-  struct buffer out = alloc_buf_gc (64, );
   buf_printf (, "interface=%d", r6->adapter_index );
-  device = buf_bptr();
   gateway_needed = true;
 }
+  else
+{
+  buf_printf (, "interface=%d", tt->adapter_index );
+}
+  device = buf_bptr();

   /* netsh interface ipv6 delete route 2001:db8::/32 MyTunDevice */
   argv_printf (, "%s%sc interface ipv6 delete route %s/%d %s",
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 014d988..aed5e75 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -1328,6 +1328,8 @@ do_ifconfig (struct tuntap *tt,
 */
saved_actual = tt->actual_name;
tt->actual_name = (char*) actual;
+   /* we use adapter_index in add_route_ipv6 */
+   tt->adapter_index = idx;
add_route_connected_v6_net(tt, es);
tt->actual_name = saved_actual;
   }
-- 
1.9.1




Re: [Openvpn-devel] [PATCH v2] Use adapter index instead of name

2015-12-11 Thread Lev Stipakov

Thanks, I think (I think!) I got it now.

1) Since we have tt->adapter_index (which temporarily disappeared from 
my perception of reality), no need to add new member to tuntap or 
tuntap_options.


2) tt->adapter_index has nothing to do with rgi->adapter_index, first 
one is windows adapter index (which we pass to netsh), last one is for 
routing (which we pass to netsh too in special case).


3) In add/del_route* we (try to) use tt->adapter_index.

Regarding master's "special case" code. Should it be something like this:

  if ( r6->adapter_index )   /* vpn server special route */
{
  struct buffer out = alloc_buf_gc (64, );
  buf_printf (, "interface=%d", r6->adapter_index );
  device = buf_bptr();
  gateway_needed = true;
}
  else
{
  /* device = interface=tt->adapter_index */
}

-Lev




Re: [Openvpn-devel] Opttion "client-nat" not recognised

2015-12-11 Thread debbie10t


- Original Message - 
From: "Gert Doering" 

To: 
Cc: "Gert Doering" ; 


Sent: Friday, December 11, 2015 8:08 PM
Subject: Re: [Openvpn-devel] Opttion "client-nat" not recognised


the code says "four arguments
have to be there" and the git master code says "four arguments have
to be there, and if a fifth is given, it is a syntax error".

So just leave off the last argument - it was silently ignored all along.


Very well, I have dropped the second mask argument and the push is
at least accepted now.  Checking logs at --verb 6 for details ..
Thanks.






Re: [Openvpn-devel] Opttion "client-nat" not recognised

2015-12-11 Thread Gert Doering
Hi,

On Fri, Dec 11, 2015 at 08:06:45PM -, debbie...@gmail.com wrote:
> > According to the (slightly confusing, admittedly) man page entry, 
> > the way you are calling the option is not correct, and as such, 
> > git master will refuse the lines.  "client-nat" has *four* arguments,
> > not *five*.
> 
> Is it possible to provide some kind of example ?
> For those of us not familiar with C ..

I have no idea what these options *do*, but the code says "four arguments
have to be there" and the git master code says "four arguments have
to be there, and if a fifth is given, it is a syntax error".

So just leave off the last argument - it was silently ignored all along.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature


Re: [Openvpn-devel] [PATCH v2] Use adapter index instead of name

2015-12-11 Thread Gert Doering
Hi,

On Fri, Dec 11, 2015 at 09:41:56PM +0200, Lev Stipakov wrote:
> Hi,
> 
> >> So, if we want to use index also for "add/del route", I'd gently modify
> >> add/del_route_ipv6 and make it use "interface=" (without breaking
> >> "vpn server special route" case).
> >
> > For consistency, I think we should do that.  What I'd avoid is to do
> > the adapter_index lookup for every single route - which would imply adding
> > the index to struct tuntap_options or something like that which is
> > available in add/del_route[_ipv6]() already.  But this is less elegant
> > than I hoped for, and might have to look different for 2.3 and master.
> 
> Adding the index - you probably meant to "struct tuntap"?

Sort of.  Struct tuntap has a sub-struct "struct tuntap_options options"
which is mostly empty for all platforms but WIN32, and on WIN32 contains
stuff like

  /* --ip-win32 options */
  bool ip_win32_defined;
  int ip_win32_type;

already (tun.h).  So adding "tuntap_adapter_index" or something like this
here would be fully in line with the existing style of packing windows
specific bits nicely away, but having them available where needed...

route_add() gets passed a "struct tuntap *tt", so the option would be
in tt->options.tuntap_adapter_index...

> Master has member "adapter_index", which seems to be used for "special 
> case", release/2.3 does not have that.

Now that's an interesting finding.  I never noticed that, but it basically
*is* what I propose above - not in tuntap_options but in the "main"
struct tuntap - and I had no idea that this one existed (I tend to not
look very closely at #ifdef WIN32 bits unless I have to).

It *is* in 2.3, btw :-) - as per "git blame tun.h" it was introduced 
into James' svn repo before we even had a git repo...


> Do you think it is safe to store adapter index there (would have to add 
> it to 2.3) without breaking "special case"? I personally not so sure, 
> since that "adapter_index" is obtained via "adapter_index_of_ip" in 
> tun.c, which looks quite different from "get_adapter_index_flexible".
> 
> We might have a semantic problem here.

adapter_index_of_ip() seems to be a "find connect routes" thing, not
tied to the tuntap adapter - but that doesn't seem to be connected to
tt->adapter_index.

Don't confuse with "rgi->adapter_index" - *that* is for routing information,
and might point elsewhere.

tt->adapter_index seems to be set only in two places, namely

tun.c:  tt->adapter_index = TUN_ADAPTER_INDEX_INVALID;

and

tun.c:  tt->adapter_index = get_adapter_index (device_guid);
  (in open_tun())

... and that one seems to be sort of like "get_adapter_index_flexible()
lite" - the latter can search for guid *or name*, while the former only
searches by guid.


So... I think we can just *use* that in add/del_route*(), and be happy
everafter :-) - it's not available when we do "netsh... set address",
unfortunately, as open_tun() happens *after* do_ifconfig() on windows...

Definitely worth a try.

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature


Re: [Openvpn-devel] Opttion "client-nat" not recognised

2015-12-11 Thread debbie10t


- Original Message - 
From: "Gert Doering" 

To: 
Cc: 
Sent: Friday, December 11, 2015 7:38 PM
Subject: Re: [Openvpn-devel] Opttion "client-nat" not recognised

According to the (slightly confusing, admittedly) man page entry, 
the way you are calling the option is not correct, and as such, 
git master will refuse the lines.  "client-nat" has *four* arguments,

not *five*.


Is it possible to provide some kind of example ?
For those of us not familiar with C ..

Thanks




Re: [Openvpn-devel] [PATCH v2] Use adapter index instead of name

2015-12-11 Thread Lev Stipakov

Hi,


So, if we want to use index also for "add/del route", I'd gently modify
add/del_route_ipv6 and make it use "interface=" (without breaking
"vpn server special route" case).


For consistency, I think we should do that.  What I'd avoid is to do
the adapter_index lookup for every single route - which would imply adding
the index to struct tuntap_options or something like that which is
available in add/del_route[_ipv6]() already.  But this is less elegant
than I hoped for, and might have to look different for 2.3 and master.


Adding the index - you probably meant to "struct tuntap"?

Master has member "adapter_index", which seems to be used for "special 
case", release/2.3 does not have that.


Do you think it is safe to store adapter index there (would have to add 
it to 2.3) without breaking "special case"? I personally not so sure, 
since that "adapter_index" is obtained via "adapter_index_of_ip" in 
tun.c, which looks quite different from "get_adapter_index_flexible".


We might have a semantic problem here.

-Lev







Re: [Openvpn-devel] Opttion "client-nat" not recognised

2015-12-11 Thread Gert Doering
Hi,

On Fri, Dec 11, 2015 at 07:35:18PM -, debbie...@gmail.com wrote:
> today, I was working with an old config which uses --client-nat
> I upgraded that particular client to git-master for testing and
> discovered that git-master currently does not support --client-nat
[..]
> Fri Dec 11 19:08:12 2015 us=645088 PUSH: Received control message: 
> 'PUSH_REPLY,ifconfig-ipv6 2001:db8:0:123::101/64 
> 2001:db8:0:123::86,route-gateway 10.234.64.86,topology 
> subnet,explicit-exit-notify 3,ping 10,ping-restart 30,tun-ipv6,client-nat 
> snat   10.1.101.0 255.255.255.0 10.201.101.0 255.255.255.0,client-nat dnat 
> 10.201.101.0 255.255.255.0   10.1.101.0 255.255.255.0,setenv-safe 
> client_dynamic 1,ifconfig 10.234.64.101 255.255.255.0,peer-id 0'

According to the (slightly confusing, admittedly) man page entry, 
the way you are calling the option is not correct, and as such, 
git master will refuse the lines.  "client-nat" has *four* arguments,
not *five*.

This is backed by the 2.3 and git master code...

2.3:

#ifdef ENABLE_CLIENT_NAT
  else if (streq (p[0], "client-nat") && p[1] && p[2] && p[3] && p[4])
{
  VERIFY_PERMISSION (OPT_P_ROUTE);
  cnol_check_alloc (options);
  add_client_nat_to_option_list(options->client_nat, p[1], p[2], p[3], p[4],
 msglevel);
}
#endif

(so, argument 5 is silently ignored)

git master:

  else if (streq (p[0], "client-nat") && p[1] && p[2] && p[3] && p[4] && !p[5])
{
  VERIFY_PERMISSION (OPT_P_ROUTE);
  cnol_check_alloc (options);
  add_client_nat_to_option_list(options->client_nat, p[1], p[2], p[3], 
p[4], msglevel);
}

"if a 5th argument is given, refuse this option".

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature


[Openvpn-devel] Opttion "client-nat" not recognised

2015-12-11 Thread debbie10t

Hi,

today, I was working with an old config which uses --client-nat
I upgraded that particular client to git-master for testing and
discovered that git-master currently does not support --client-nat

This config works perfectly with older versions,
details follow:

GIT-master versions which --client-nat does *not* work:
- dated 2015Nov25 (My first test)
- dated 2015Aug02 (Another clone I had available)
- dated 2015Dec11 (make sure i was not going more nuts! than usual)

GIT-mater versions which --client-nat *does* work:
- dated 2015Jun12

Official version which --client-nat *does* work:
Linux-Mint: Ubuntu 14.04.1
- OpenVPN 2.3.2 x86_64-pc-linux-gnu <..> built on Dec  1 2014

If you prefer this reported on trac please let me know.

CLIENT LOG FILE WORKING:

Fri Dec 11 18:36:50 2015 us=948077 OpenVPN 2.3_git 12.June.2015 
[git:master/60fd44e501f20024+] x86_64-unknown-linux-gnu [SSL (OpenSSL)] 
[LZO] [LZ4] [EPOLL] [MH] [IPv

6] built on Dec 11 2015
Fri Dec 11 18:36:50 2015 us=948133 library versions: OpenSSL 1.0.1f 6 Jan 
2014, LZO 2.06


<..>

Fri Dec 11 18:36:54 2015 us=118430 PUSH: Received control message: 
'PUSH_REPLY,ifconfig-ipv6 2001:db8:0:123::101/64 
2001:db8:0:123::86,route-gateway 10.234.64.86,topology 
subnet,explicit-exit-notify 3,ping 10,ping-restart 30,tun-ipv6,client-nat 
snat   10.1.101.0 255.255.255.0 10.201.101.0 255.255.255.0,client-nat dnat 
10.201.101.0 255.255.255.0   10.1.101.0 255.255.255.0,setenv-safe 
client_dynamic 1,ifconfig 10.234.64.101 255.255.255.0,peer-id 0'
Fri Dec 11 18:36:54 2015 us=118553 Option 'explicit-exit-notify' in 
[PUSH-OPTIONS]:4 is ignored by previous  blocks
Fri Dec 11 18:36:54 2015 us=118691 OPTIONS IMPORT: timers and/or timeouts 
modified
Fri Dec 11 18:36:54 2015 us=118726 OPTIONS IMPORT: explicit notify parm(s) 
modified
Fri Dec 11 18:36:54 2015 us=118764 OPTIONS IMPORT: --ifconfig/up options 
modified

Fri Dec 11 18:36:54 2015 us=118798 OPTIONS IMPORT: route options modified
Fri Dec 11 18:36:54 2015 us=118832 OPTIONS IMPORT: route-related options 
modified

Fri Dec 11 18:36:54 2015 us=118867 OPTIONS IMPORT: environment modified
Fri Dec 11 18:36:54 2015 us=118904 OPTIONS IMPORT: peer-id set
Fri Dec 11 18:36:54 2015 us=118938 OPTIONS IMPORT: adjusting link_mtu to 
1605

Fri Dec 11 18:36:54 2015 us=119710 TUN/TAP device tun23464 opened
Fri Dec 11 18:36:54 2015 us=119802 TUN/TAP TX queue length set to 100
Fri Dec 11 18:36:54 2015 us=119873 do_ifconfig, tt->ipv6=1, 
tt->did_ifconfig_ipv6_setup=1
Fri Dec 11 18:36:54 2015 us=119971 /sbin/ifconfig tun23464 10.234.64.101 
netmask 255.255.255.0 mtu 1500 broadcast 10.234.64.255
Fri Dec 11 18:36:54 2015 us=125237 /sbin/ifconfig tun23464 add 
2001:db8:0:123::101/64

Fri Dec 11 18:36:54 2015 us=134693 Initialization Sequence Completed



CLIENT LOG FILE *NOT* WORKING:

Fri Dec 11 19:08:10 2015 us=348536 OpenVPN 2.3_git 
[git:master/4baec3ee10b8d682] x86_64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] 
[LZ4] [EPOLL] [MH] [IPv6] built on De

c 11 2015
Fri Dec 11 19:08:10 2015 us=348583 library versions: OpenSSL 1.0.1f 6 Jan 
2014, LZO 2.06


<..>

Fri Dec 11 19:08:12 2015 us=645088 PUSH: Received control message: 
'PUSH_REPLY,ifconfig-ipv6 2001:db8:0:123::101/64 
2001:db8:0:123::86,route-gateway 10.234.64.86,topology 
subnet,explicit-exit-notify 3,ping 10,ping-restart 30,tun-ipv6,client-nat 
snat   10.1.101.0 255.255.255.0 10.201.101.0 255.255.255.0,client-nat dnat 
10.201.101.0 255.255.255.0   10.1.101.0 255.255.255.0,setenv-safe 
client_dynamic 1,ifconfig 10.234.64.101 255.255.255.0,peer-id 0'
Fri Dec 11 19:08:12 2015 us=645213 Option 'explicit-exit-notify' in 
[PUSH-OPTIONS]:4 is ignored by previous  blocks
Fri Dec 11 19:08:12 2015 us=645281 Options error: Unrecognized option or 
missing or extra parameter(s) in [PUSH-OPTIONS]:8: client-nat (2.3_git)
Fri Dec 11 19:08:12 2015 us=645328 Options error: Unrecognized option or 
missing or extra parameter(s) in [PUSH-OPTIONS]:9: client-nat (2.3_git)
Fri Dec 11 19:08:12 2015 us=645418 OPTIONS IMPORT: timers and/or timeouts 
modified
Fri Dec 11 19:08:12 2015 us=645445 OPTIONS IMPORT: explicit notify parm(s) 
modified
Fri Dec 11 19:08:12 2015 us=645470 OPTIONS IMPORT: --ifconfig/up options 
modified
Fri Dec 11 19:08:12 2015 us=645494 OPTIONS IMPORT: route-related options 
modified

Fri Dec 11 19:08:12 2015 us=645519 OPTIONS IMPORT: environment modified
Fri Dec 11 19:08:12 2015 us=645543 OPTIONS IMPORT: peer-id set
Fri Dec 11 19:08:12 2015 us=645568 OPTIONS IMPORT: adjusting link_mtu to 
1605

Fri Dec 11 19:08:12 2015 us=646219 TUN/TAP device tun23464 opened
Fri Dec 11 19:08:12 2015 us=646324 TUN/TAP TX queue length set to 100
Fri Dec 11 19:08:12 2015 us=646403 do_ifconfig, tt->ipv6=1, 
tt->did_ifconfig_ipv6_setup=1
Fri Dec 11 19:08:12 2015 us=646506 /sbin/ifconfig tun23464 10.234.64.101 
netmask 255.255.255.0 mtu 1500 broadcast 10.234.64.255
Fri Dec 11 19:08:12 2015 us=663984 /sbin/ifconfig tun23464 add 
2001:db8:0:123::101/64

Fri Dec 11 19:08:12 2015 us=669056 Initialization 

Re: [Openvpn-devel] [PATCH v8-master] Add Windows DNS Leak fix using WFP ('block-outside-dns')

2015-12-11 Thread Lev Stipakov

On 10.12.2015 18:49, ValdikSS wrote:


I'd better go with just
closing the engine without deleting everything. I don't see any
drawbacks, that should be perfectly OK for a dynamic session.

Is this correct, Lev? If yes, I'll push v9 today or tomorrow morning.


Removing non-working FwpmSubLayerDeleteByKey0 call is indeed step into 
right direction, rest is up to you :) I already mentioned above what I 
would do.


Just for the record - this patch does not work on my only win10 box with 
DNS leak - it blocks leaks but each DNS request takes 10 seconds, so I 
cannot give an ACK. On the other hand, it works for others in this 
discussion and is optional in any case (should not break things). So I 
won't say NACK either.


-Lev






[Openvpn-devel] [PATCH] Make ValdikSS's DNS leak fix platform agnostic

2015-12-11 Thread Fish
Based on release/2.3 branch and ValdikSS's v9 patch, this patch is
cross-compiled on Linux and tested on Windows XP/10. The VC project file is
left untouched - you might want to add rpcrt4.lib to compile and link it under
MSVC.

Take ValdikSS's patch for "block-outside-dns" option and
make it Windows-version-agnostic.
---
 src/openvpn/Makefile.am |   2 +-
 src/openvpn/init.c  |   4 -
 src/openvpn/options.c   |  17 +--
 src/openvpn/win32.c | 309 +++-
 src/openvpn/win32.h |   1 +
 5 files changed, 315 insertions(+), 18 deletions(-)

diff --git a/src/openvpn/Makefile.am b/src/openvpn/Makefile.am
index 2e602f1..149a533 100644
--- a/src/openvpn/Makefile.am
+++ b/src/openvpn/Makefile.am
@@ -123,5 +123,5 @@ openvpn_LDADD = \
$(OPTIONAL_DL_LIBS)
 if WIN32
 openvpn_SOURCES += openvpn_win32_resources.rc
-openvpn_LDADD += -lgdi32 -lws2_32 -lwininet -lcrypt32 -liphlpapi -lwinmm
+openvpn_LDADD += -lgdi32 -lws2_32 -lwininet -lcrypt32 -liphlpapi -lrpcrt4 
-lwinmm
 endif
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index e8a96c2..960535d 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1468,14 +1468,12 @@ do_open_tun (struct context *c)
   "up",
   c->c2.es);

-#if _WIN32_WINNT >= 0x0600
   if (c->options.block_outside_dns)
   {
 dmsg (D_LOW, "Blocking outside DNS");
 if (!win_wfp_block_dns(c->c1.tuntap->adapter_index))
 msg (M_FATAL, "Blocking DNS failed!");
   }
-#endif

   /* possibly add routes */
   if (!c->options.route_delay_defined)
@@ -1603,13 +1601,11 @@ do_close_tun (struct context *c, bool force)
   "down",
   c->c2.es);

-#if _WIN32_WINNT >= 0x0600
 if (c->options.block_outside_dns)
 {
 if (!win_wfp_uninit())
 msg (M_FATAL, "Uninitialising WFP failed!");
 }
-#endif

  /* actually close tun/tap device based on --down-pre flag */
  if (c->options.down_pre)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 3a6aacd..8d85502 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -715,9 +715,7 @@ static const char usage_message[] =
   "   optional parameter controls the initial state of 
ex.\n"
   "--show-net-up   : Show " PACKAGE_NAME "'s view of routing table and net 
adapter list\n"
   "  after TAP adapter is up and routes have been added.\n"
-#if _WIN32_WINNT >= 0x0600
   "--block-outside-dns   : Block DNS on other network adapters to prevent DNS 
leaks\n"
-#endif
   "Windows Standalone Options:\n"
   "\n"
   "--show-adapters : Show all TAP-Windows adapters.\n"
@@ -1682,9 +1680,7 @@ show_settings (const struct options *o)
 #ifdef WIN32
   SHOW_BOOL (show_net_up);
   SHOW_INT (route_method);
-#if _WIN32_WINNT >= 0x0600
   SHOW_BOOL (block_outside_dns);
-#endif
   show_tuntap_options (>tuntap_options);
 #endif
 #endif
@@ -6252,13 +6248,20 @@ add_option (struct options *options,
   VERIFY_PERMISSION (OPT_P_IPWIN32);
   options->tuntap_options.register_dns = true;
 }
-#if _WIN32_WINNT >= 0x0600
   else if (streq (p[0], "block-outside-dns") && !p[1])
 {
   VERIFY_PERMISSION (OPT_P_IPWIN32);
-  options->block_outside_dns = true;
+  if (win_wfp_init_funcs())
+  {
+options->block_outside_dns = true;
+  }
+  else
+  {
+msg (msglevel_fc, "Failed to enable --block-outside-dns. "
+   "Maybe WFP is not supported on your system?");
+ goto err;
+  }
 }
-#endif
   else if (streq (p[0], "rdns-internal"))
  /* standalone method for internal use
   *
diff --git a/src/openvpn/win32.c b/src/openvpn/win32.c
index 9402361..f4d0433 100644
--- a/src/openvpn/win32.c
+++ b/src/openvpn/win32.c
@@ -49,11 +49,10 @@
 /*
  * WFP-related defines and GUIDs.
  */
-#if _WIN32_WINNT >= 0x0600
-#include 
 #include 
-#include 
 #include 
+#include 
+#include 

 #ifndef FWPM_SESSION_FLAG_DYNAMIC
 #define FWPM_SESSION_FLAG_DYNAMIC 0x0001
@@ -104,6 +103,264 @@ DEFINE_GUID(
0xb7, 0xf3, 0xbd, 0xa5, 0xd3, 0x28, 0x90, 0xa4
 );

+/* From fwptypes.h */
+
+#define FWP_ACTION_FLAG_TERMINATING (0x1000)
+#define FWP_ACTION_FLAG_NON_TERMINATING (0x2000)
+
+#define FWP_ACTION_BLOCK  (0x1 | FWP_ACTION_FLAG_TERMINATING)
+#define FWP_ACTION_PERMIT (0x2 | FWP_ACTION_FLAG_TERMINATING)
+
+typedef UINT32 FWP_ACTION_TYPE;
+
+typedef enum FWP_DATA_TYPE_ {
+FWP_EMPTY = 0,
+FWP_UINT8 = 1,
+FWP_UINT16 = 2,
+FWP_UINT32 = 3,
+FWP_UINT64 = 4,
+FWP_INT8 = 5,
+FWP_INT16 = 6,
+FWP_INT32 = 7,
+FWP_INT64 = 8,
+FWP_FLOAT = 9,
+FWP_DOUBLE = 10,
+FWP_BYTE_ARRAY16_TYPE = 11,
+FWP_BYTE_BLOB_TYPE = 12,
+FWP_SID = 13,
+FWP_SECURITY_DESCRIPTOR_TYPE = 14,
+FWP_TOKEN_INFORMATION_TYPE = 15,
+FWP_TOKEN_ACCESS_INFORMATION_TYPE = 16,
+ 

Re: [Openvpn-devel] [PATCH] Make ValdikSS's DNS leak fix platform agnostic

2015-12-11 Thread Selva Nair
Hi,

The patch is mangled by mailer (added linebreaks etc.). Could you please
resend using git send-email? While at it, one thing I noticed:

On Thu, Dec 10, 2015 at 6:48 PM, Fish Wang  wrote:

> -#if _WIN32_WINNT >= 0x0600
>else if (streq (p[0], "block-outside-dns") && !p[1])
>  {
>VERIFY_PERMISSION (OPT_P_IPWIN32);
> -  options->block_outside_dns = true;
> +  if (win_wfp_init_funcs())
> +  {
> +options->block_outside_dns = true;
> +  }
> +  else
> +  {
> +msg (msglevel, "Failed to enable --block-outside-dns. "
> +   "Maybe WFP is not supported on your system?");
>

I believe msglevel_fc is more appropriate, as otherwise forward compatible
and "setenv opt" usages will not be respected.

Selva