Re: [Openvpn-devel] [PATCH] Depreciate IPv4-related options.

[Samuel Thibault]

Hello,

Jonathan K. Bullard, on dim. 01 avril 2018 06:17:55 -0400, wrote:
> Either way, can anyone give an approximate release date for 2.5, so we
> can have a time frame for the change? (Even a "not before" date would
> be very helpful in evaluating the impact of these proposed changes.)

I guess it'll be "not before" tomorrow.

Samuel

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Adding "protocol static" to Linux routes?

[Samuel Thibault]

Hello,

Gert Doering, on Mon 20 Jun 2016 08:40:12 +0200, wrote:
> I'm wondering how you do the resiliency.  Traditionally, one would set up
> the routes on client-connect/client-disconnect (or via --learn-address),
> so it's under your control anyway

Ah, right, yes, we do that, and we announce those routes via bgp.

So what remains is the "converse": the routes set by openvpn with the
"route" configuration element. When a client manages to connect to the
server and thus get access to the network, it is useful to add the
routes with "protocol static" so that the access to the network is
announced through bgp to the network behind the client. Of course we
could drop the "route" configuration element, and add the route ourself
in a route-up script, but that's less clean.

> Besides, I'm a bit reluctant to change something like this, which might
> break someone *else*'s setup, which relies on the route being what they
> are today ("boot") - can't you teach bird to do "redistribute boot"?

You mean patching bird?  AIUI that would be counter-productive: the
boot/static separation was explicitly made to separate between routes
which shouldn't be announced and routes which should be announced...

Setting static could also be made an option, e.g.

--route network/IP [netmask] [gateway] [metric] [announce]

and putting "announce" would make openvpn set "protocol static" in the
route command.

Samuel

Re: [Openvpn-devel] Adding "protocol static" to Linux routes?

[Samuel Thibault]

David Sommerseth, on Mon 20 Jun 2016 01:23:34 +0200, wrote:
> On 19/06/16 22:21, Samuel Thibault wrote:
> > Samuel Thibault, on Sun 19 Jun 2016 21:45:38 +0200, wrote:
> >> So we need the attached change, which just adds "protocol static", to
> >> express that the routes created by openvpn are to override other
> >> dynamic routing.
> > 
> > Of course, v6 needs it too.
> 
> Which platforms have this change been tested on?

I'm not sure what you mean by "platforms" exactly?  The modified code
is built on Linux only, and the iproute2 software supports "protocol
static" since at least 2004, so I don't see any potential for breakage.

Samuel

Re: [Openvpn-devel] Adding "protocol static" to Linux routes?

[Samuel Thibault]

Samuel Thibault, on Sun 19 Jun 2016 21:45:38 +0200, wrote:
> So we need the attached change, which just adds "protocol static", to
> express that the routes created by openvpn are to override other
> dynamic routing.

Of course, v6 needs it too.

Samuel
--- a/route.c
+++ b/route.c
@@ -1113,7 +1113,7 @@ add_route (struct route *r, const struct

 #if defined(TARGET_LINUX)
 #ifdef CONFIG_FEATURE_IPROUTE
-  argv_printf (, "%s route add %s/%d via %s",
+  argv_printf (, "%s route add %s/%d via %s protocol static",
  iproute_path,
  network,
  count_netmask_bits(netmask),
@@ -1328,7 +1328,7 @@ add_route_ipv6 (struct route_ipv6 *r6, c

 #if defined(TARGET_LINUX)
 #ifdef CONFIG_FEATURE_IPROUTE
-  argv_printf (, "%s -6 route add %s/%d dev %s",
+  argv_printf (, "%s -6 route add %s/%d dev %s protocol static",
  iproute_path,
  network,
  r6->netbits,

[Openvpn-devel] Adding "protocol static" to Linux routes?

[Samuel Thibault]

Hello,

Here we used two openvpn servers for resiliency, and we use the bird
bgp daemon to make the two boxes exchange routes. Bird however does not
pick up openvpn's routes because they are considered as "protocol boot"
in Linux' "ip route" terms, i.e. they are assumed to be an automatic
configuration, and not an administratively-configured route (see the
protocol RTPROTO part of man ip-route for the details).

So we need the attached change, which just adds "protocol static", to
express that the routes created by openvpn are to override other
dynamic routing.

What do you think?

Samuel
diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index a90195f..62ea633 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1418,7 +1418,7 @@ add_route (struct route_ipv4 *r,

 #if defined(TARGET_LINUX)
 #ifdef ENABLE_IPROUTE
-  argv_printf (, "%s route add %s/%d",
+  argv_printf (, "%s route add %s/%d protocol static",
  iproute_path,
  network,
   netmask_to_netbits2(r->netmask));

Re: [Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

David Sommerseth, on Wed 10 Feb 2016 01:56:57 +0100, wrote:
> > 2 minutes after the client disconnected, which would probably be fine
> > enough for our use case.
> 
> If you use --proto udp, then it can take up to --ping-reset $SEC to trigger
> (IIRC).  You can use explicit-exit-notify to avoid this behaviour.

Apparently I forgot to uncomment the option, indeed.

Samuel

Re: [Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

Hello,

Gert Doering, on Tue 09 Feb 2016 10:28:21 +0100, wrote:
> Alternatively, using
> --learn-address might actually be much easier than --client-connect, as
> it will already tell you which networks are "new for this client" - from
> the description, I'm fairly sure it handles iroute/iroute-ipv6 as well,
> but for whatever reason I've never actually used this combination...

That works indeed:

#!/bin/bash

add_del="$1"
route="$2"
cname="$3"

case "$route" in 
*:*) six=-6 ;;
*)   six="" ;;
esac

if [ -n "$dev" ]
then
  device="dev $dev"
else
  device=""
fi

ip $six route "$add_del" "$route" $device

Samuel

Re: [Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

Gert Doering, on Tue 09 Feb 2016 12:58:26 +0100, wrote:
> On Tue, Feb 09, 2016 at 11:58:39AM +0100, Samuel Thibault wrote:
> > I have tried putting
> > 
> > iroute-ipv6 2a01:474:5:1100::/56
> > 
> > in the ccd, but from the learn-address script the environment does not
> > contain this route.
> 
>--learn-address cmd
>   Run  command cmd to validate client virtual addresses or routes.
> ...
>   Three arguments will be appended to any arguments in cmd as fol-
>   lows:

D'oh.

Busy people talking to busy people :) I didn't even take the time to
check that, sorry.

I indeed see the learn-address script called with

add 2a01:474:5:1100::/56 samuel.thibault.test

And seen it called with 

delete 2a01:474:5:1100::/56 samuel.thibault.test

2 minutes after the client disconnected, which would probably be fine
enough for our use case.

Thanks,
Samuel

Re: [Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

Gert Doering, on Tue 09 Feb 2016 11:46:25 +0100, wrote:
> On Tue, Feb 09, 2016 at 11:15:33AM +0100, Samuel Thibault wrote:
> > Gert Doering, on Tue 09 Feb 2016 10:28:21 +0100, wrote:
> > > On Mon, Feb 08, 2016 at 10:39:29PM +0100, Samuel Thibault wrote:
> > > > Is there a reason for not being allowed to set route / route-ipv6
> > > > options in the ccd?
> > > 
> > > "Nobody has implemented it yet" - plain and simple...
> > 
> > Ok :)
> 
> Could you test and report whether --learn-address does the job for you?

I have tried putting

iroute-ipv6 2a01:474:5:1100::/56

in the ccd, but from the learn-address script the environment does not
contain this route.

Samuel

Re: [Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

Samuel Thibault, on Mon 08 Feb 2016 22:39:29 +0100, wrote:
> We could of course use the --up script to set the routes,

Oops, sorry, I didn't mean --up, but client-connect of course.

Samuel

[Openvpn-devel] route / route-ipv6 can not be used in ccd

[Samuel Thibault]

Hello,

Is there a reason for not being allowed to set route / route-ipv6
options in the ccd?

Here is our need: we have two openvpn daemons running on the same
server, one in udp mode, the other in tcp mode. Both have the same
configuration, that setup is meant for our users to use whichever
happens to be working from their network, preferring udp whenever
possible. The server thus has tun0 and tun1. Our users may have some
additional IPs routed to them, so we record these in the ccd files, for
instance:

iroute-ipv6 2a01:474:5:100::/56
route-ipv6 2a01:474:5:100::/56

However, while iroute-ipv6 is accepted by openvpn, route-ipv6 is not
accepted:

samuel.thibault/:::83.200.171.86 Options error: option 'route-ipv6' cannot 
be used in this context

The problem is that since one can not know in advance which openvpn
daemon users will connect to (and thus which of tun0 or tun1 should have
the route), we can not set these routes statically before the users
connect.

We could of course use the --up script to set the routes, but it looks
much simpler and straightforward to set it from the ccd, since we need
to set the iroute there already anyway.

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Gert Doering, le Tue 11 Aug 2015 07:59:06 +0200, a écrit :
> > I can see that when accounting fails, an
> > exception is thrown, to return an error to openvpn and thus prevent
> > the connection.  I guess this is an important part that shouldn't be
> > dropped, but I don't see a way to make it asynchronous without modifying
> > the openvpn core.
> > 
> > In our case we don't actually make use of radius accounting...
> 
> ... you could modify the radiusplugin to just "do not do accounting" -
> just return "success!" right away, and quickly so...

Yep, already done so on our platform, so we at least avoid the issue :)

It still needs to be fixed upstream :)

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Samuel Thibault, le Tue 11 Aug 2015 01:28:02 +0200, a écrit :
> Here is the log I'm having, for instance on a :

user connection, I meant

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Hello,

Lev Stipakov, le Fri 31 Jul 2015 11:19:15 +0300, a écrit :
> Do you use radius plugin from http://www.nongnu.org/radiusplugin/ ? I
> think the way OpenVPN delegates authentication to a plugin
> (OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY hook) is asynchronous, as well
> as plugin implementation, i. e. OpenVPN does not wait for a response.
> Instead it periodically checks a tmp file to where plugin is supposed
> to write authentication result (1 or 0).

Since I was still getting trafic misses even with acf properly
working, I dug a bit further, and the issue I'm still having is with
accounting. Here is the log I'm having, for instance on a :

Tue Aug 11 00:54:10 2015 RADIUS-PLUGIN: BACKGROUND ACCT: New User.
Tue Aug 11 00:54:10 2015 RADIUS-PLUGIN: BACKGROUND ACCT: New user acct: 
username: b...@bar.com, interval: 0, calling station: :::92.146.150.249, 
commonname: b...@bar.com, framed ip: 80.67.179.7, framed ipv6: 
2001:0910:0802:::::1307.

[during these two seconds, openvpn doesn't trafic any more]

Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND-ACCT:  Get 
ACCOUNTING_RESPONSE-Packet.
Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND ACCT: Start packet was send.
Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND ACCT: User was added to 
accounting scheduler.
Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND-ACCT:  No routes for user.
Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND-ACCT:  Create IPv6 route 
string ip -6 route add 2001:910:1307::/48 dev tun2 proto static 2> /dev/null 
dev tun2.
Tue Aug 11 00:54:12 2015 RADIUS-PLUGIN: BACKGROUND-ACCT:  Add route to system 
routing table.

[and now trafic passes again]

Looking at the source code in openvpn_plugin_open_v2, I see:

context->acctsocketbackgr.send ( ADD_USER );
...
context->acctsocketbackgr.send ( newuser->getVsaBuf(), newuser->getVsaBufLen() 
);
//get the response
const int status = context->acctsocketbackgr.recvInt();

This is again synchronous code, and this time I don't see any option
to make it asynchronous...  I can see that when accounting fails, an
exception is thrown, to return an error to openvpn and thus prevent
the connection.  I guess this is an important part that shouldn't be
dropped, but I don't see a way to make it asynchronous without modifying
the openvpn core.

In our case we don't actually make use of radius accounting...

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Илья Шипицин, le Fri 31 Jul 2015 14:54:02 +0500, a écrit :
> it is too early to talk about central repository, currently I'm the
> only user of that plugin

But without a central repository where people would get to know about
your version, then it's even more probable that you'll remain the only
user...

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Samuel Thibault, le Fri 31 Jul 2015 11:32:06 +0200, a écrit :
> # Allows the plugin to use auth control files if OpenVPN (>= 2.1 rc8) 
> provides them.
> # default is false
> # useauthcontrolfile=false
> 
> Why is the default false??

And still... The main loop uses

   pthread_mutex_lock(context->getMutexSend());
   context->addNewUser(newuser);
   pthread_cond_signal( context->getCondSend( ));
   pthread_mutex_unlock (context->getMutexSend());
   return OPENVPN_PLUGIN_FUNC_DEFERRED;

to signal the auth thread that a new connection is being tried, and the
auth thread basically does

   pthread_mutex_lock(context->getMutexSend());
   while(1)
   {
 if (nobody_yet)
   pthread_cond_wait(context->getCondSend(),context->getMutexSend());
 ...
 Do auth
 ...
   }
   pthread_mutex_unlock(context->getMutexSend());

I.e. it keeps the MutexSend busy all along the authentication! So even
with deferred authentication, the main loop can not manage to grasp the
mutex until the auth thread has finished authenticating the previous
user...

Anyway, this is an issue in the plugin, I'll switch over to the plugin
mailing list.

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Samuel Thibault, le Fri 31 Jul 2015 11:24:51 +0200, a écrit :
> Lev Stipakov, le Fri 31 Jul 2015 11:19:15 +0300, a écrit :
> > Do you use radius plugin from http://www.nongnu.org/radiusplugin/ ? I
> > think the way OpenVPN delegates authentication to a plugin
> > (OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY hook) is asynchronous, as well
> > as plugin implementation, i. e. OpenVPN does not wait for a response.
> > Instead it periodically checks a tmp file to where plugin is supposed
> > to write authentication result (1 or 0).
> 
> Ok, I see where that is implemented, and I do see acf temp files being
> created. For some reason the plugin doesn't seem to be using the
> deferred case, so I'll dig further.

Err...

# Allows the plugin to use auth control files if OpenVPN (>= 2.1 rc8) provides 
them.
# default is false
# useauthcontrolfile=false

Why is the default false??

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Hello,

Lev Stipakov, le Fri 31 Jul 2015 11:19:15 +0300, a écrit :
> Do you use radius plugin from http://www.nongnu.org/radiusplugin/ ? I
> think the way OpenVPN delegates authentication to a plugin
> (OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY hook) is asynchronous, as well
> as plugin implementation, i. e. OpenVPN does not wait for a response.
> Instead it periodically checks a tmp file to where plugin is supposed
> to write authentication result (1 or 0).

Ok, I see where that is implemented, and I do see acf temp files being
created. For some reason the plugin doesn't seem to be using the
deferred case, so I'll dig further.

Samuel

Re: [Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Илья Шипицин, le Fri 31 Jul 2015 14:09:51 +0500, a écrit :
> I've rewritten radius thing with .net, my plugin performs queries to
> multiple radius servers in parallel, I'm using it with Mono in
> production for few months:
> 
> https://github.com/skbkontur/openvpn-auth-radius
> 
> I can help with that plugin if you are interested

Mmm, it'd be great if the openvpn-auth-radius plugin could have a
central repository, instead of a flurry of patched versions...

Samuel

[Openvpn-devel] Packet loss due to radius issues

[Samuel Thibault]

Hello,

We've been having issues on our VPN server due to the way authentication
is done in openvpn.  Basically, when a user would connect to the VPN
server, no trafic would pass for a couple of seconds, thus making
the VPN way less effective...  This was an unfortunate combination
of several issues described below.  Our current setup is openvpn in
multiple client mode, with the openvpn-auth-radius plugin to get
authentication from a couple of radius servers on two other machines
next to our VPN server.

Here is what happens:

- AIUI, when openvpn receives an authentication request, it gives hand
to the authentication plugin, and thus while the authentication plugin
is working on it, no trafic can be handled by openvpn.  That is, I
believe, an important issue, and will turn that into a bug report.  The
issue is that authentication might take time for whatever reason (see
below for an example).

- The radius authentication plugin interrogates our two radius servers,
gets a response, and gives back hand to openvpn.

- The issue we were having is that the first of the two radius servers
is being replaced, and is thus currently turned off.  Since the radius
plugin tries the first server first and waits for a couple of seconds
before trying the second one, the authentication currently always takes
a couple of seconds. Unfortunately, that thus makes openvpn not process
traffic for that couple of seconds...  Of course I have now disabled the
first radius server to avoid the issue, but a radius server downtime
(e.g. reboot or whatever) should *not* make trafic stall, so it's not
acceptable.

One could argue that the radius plugin should perhaps try both servers
at the same time and take the first answer it gets.  That however drops
the idea of load balancing, and in case both radius servers are down,
the openvpn trafic will get interrupted everytime somebody tries to
connect (and retry shortly after again and again since it'll fail),
that's really not acceptable either.

Samuel

Re: [Openvpn-devel] [PATCH] openvpn ipv6 pool env variables

[Samuel Thibault]

Hello,

Any news on this issue?

Samuel

Samuel Thibault, le Mon 27 May 2013 22:05:19 +0200, a écrit :
> Gert Doering, le Mon 27 May 2013 09:25:12 +0200, a écrit :
> > On Mon, May 27, 2013 at 12:36:39AM +0200, Samuel Thibault wrote:
> > > Gert Doering, le Sat 25 May 2013 13:58:19 +0200, a écrit :
> > > > > To make it short: yes, the ipv6 pool environment variables are useful,
> > > > > for user-defined scripts to be run at connection for instance to
> > > > > propagate routes, do accounting, etc.  The patch below adds them.
> > > > 
> > > > You keep claiming that "yes it's useful".  The lack of feedback on the
> > > > list is partly due to the "To make it short" part of your mail...
> > > 
> > > Ok. I was simply wondering whether it had perhaps got somehow dropped
> > > without reason.
> > > 
> > > As I mentioned too briefly, the reason we need it is the same as for the
> > > IPv4 case: to announce the route to our bird daemon on connection, and
> > > drop it on disconnection.
> > 
> > Mmmmh.  Trying to understand this: so you're not using a common /64 for
> > the tun addresses (= the ifconfig-ipv6-pool),
> 
> We are, but,
> 
> > which is then announced on-demand by bird?
> 
> we need to announce it on-demand by bird, because we plan to possibly
> have several servers. Actually we also add the routes because we already
> have several openvpn daemons, because we have to let people connect
> through either udp and tcp, depending on the wild area they happen to
> have landed on. So we need to tell the kernel which tun (i.e. which
> openvpn daemon) to push paquets to.
> 
> > Have you looked at the learn-address script?  I use something similar
> > at a customer (adding and removing proxy-arp entries on client connect)
> > and learn-address does all I need just fine...
> 
> That could do it yes, however,
> 
> > Well, learn-address is run on disconnect, but not "right away" - true,
> > so having it in disconnect is useful.
> 
> yes. The rather random delay hurts by preventing from reconnecting
> immediately (either to the same daemon, or to another one or even
> another server), which is a pain when trying to set up the VPN in a wild
> area :)
> 
> > I wonder whether we should also export iroute-ipv6 settings, as that would
> > enable on-demand routing of more than a single IPv6 address.
> 
> Actually in our case iroute is fed by radiusplugin, which happens to
> also already add the route for us, so we didn't have to add that one.
> But it could be better to have radiusplugin just pass iroute to openvpn,
> and let the userscript add the route if needed.

Re: [Openvpn-devel] [PATCH] Fix temporary file leak

[Samuel Thibault]

David Sommerseth, le Fri 10 Oct 2014 12:13:42 +0200, a écrit :
> I think it would be better to move the unlink() code from
> multi_client_connect_post() into multi_connection_established(), where
> these temp files are created.  This makes the code clearer and easier to
> understand.

Right, how about this?

Samuel

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 5910154..25e7384 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1459,10 +1465,6 @@ multi_client_connect_post (struct multi_context *m,
 option_types_found,
 mi->context.c2.es);
 
-  if (!platform_unlink (dc_file))
-   msg (D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
-dc_file);
-
   /*
* If the --client-connect script generates a config file
* with an --ifconfig-push directive, it will override any
@@ -1705,6 +1707,11 @@ multi_connection_established (struct multi_context *m, 
struct multi_instance *mi
  multi_client_connect_post (m, mi, dc_file, 
option_permissions_mask, _types_found);
  ++cc_succeeded_count;
}
+
+ if (!platform_unlink (dc_file))
+   msg (D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
+dc_file);
+
 script_depr_failed:
  argv_reset ();
}
@@ -1758,6 +1765,11 @@ multi_connection_established (struct multi_context *m, 
struct multi_instance *mi
}
  else
cc_succeeded = false;
+
+ if (!platform_unlink (dc_file))
+   msg (D_MULTI_ERRORS, "MULTI: problem deleting temporary file: %s",
+dc_file);
+
 script_failed:
  argv_reset ();
}

[Openvpn-devel] [PATCH] Fix temporary file leak

[Samuel Thibault]

Hello,

Our openvpn server got out of free inodes in /tmp, making it quite
completely nonworking.  This is due to some codepath in multi.c which
does not remove its temporary file (when a plugin callback returns an
error, or a client-connect script returns an error).  Please see the
attached patch which fixes this.

Samuel
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 5910154..d0ed147 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1699,6 +1705,9 @@ multi_connection_established (struct multi_context *m, 
struct multi_instance *mi
{
  msg (M_WARN, "WARNING: client-connect plugin call failed");
  cc_succeeded = false;
+ if (!platform_unlink (dc_file))
+   msg (D_MULTI_ERRORS, "MULTI: problem deleting temporary file: 
%s",
+dc_file);
}
  else
{
@@ -1757,7 +1766,12 @@ multi_connection_established (struct multi_context *m, 
struct multi_instance *mi
  ++cc_succeeded_count;
}
  else
-   cc_succeeded = false;
+   {
+ cc_succeeded = false;
+ if (!platform_unlink (dc_file))
+   msg (D_MULTI_ERRORS, "MULTI: problem deleting temporary file: 
%s",
+dc_file);
+   }
 script_failed:
  argv_reset ();
}

Re: [Openvpn-devel] ipv6 env vars to client scripts

[Samuel Thibault]

David Sommerseth, le Fri 02 May 2014 01:39:05 +0200, a écrit :
> On 17/04/14 14:07, Lev Stipakov wrote:
> > Hello,
> >
> > Are there any plans to support ipv6 env vars in
> > client-connect/disconnect scripts?
> >
> > There are at least 2 tickes on that feature:
> >
> > https://community.openvpn.net/openvpn/ticket/230
> > https://community.openvpn.net/openvpn/ticket/369
> >
> > Is there anything that prevents merging any of suggested patches to
> > the master branch?
> 
> I don't think I've seen these patches on the mailing list (I'm going through 
> the list now).

My patches were sent on 2013 May 24th on openvpn-devel.

Samuel

Re: [Openvpn-devel] [PATCH] openvpn ipv6 pool env variables

[Samuel Thibault]

Gert Doering, le Mon 27 May 2013 09:25:12 +0200, a écrit :
> On Mon, May 27, 2013 at 12:36:39AM +0200, Samuel Thibault wrote:
> > Gert Doering, le Sat 25 May 2013 13:58:19 +0200, a écrit :
> > > > To make it short: yes, the ipv6 pool environment variables are useful,
> > > > for user-defined scripts to be run at connection for instance to
> > > > propagate routes, do accounting, etc.  The patch below adds them.
> > > 
> > > You keep claiming that "yes it's useful".  The lack of feedback on the
> > > list is partly due to the "To make it short" part of your mail...
> > 
> > Ok. I was simply wondering whether it had perhaps got somehow dropped
> > without reason.
> > 
> > As I mentioned too briefly, the reason we need it is the same as for the
> > IPv4 case: to announce the route to our bird daemon on connection, and
> > drop it on disconnection.
> 
> Mmmmh.  Trying to understand this: so you're not using a common /64 for
> the tun addresses (= the ifconfig-ipv6-pool),

We are, but,

> which is then announced on-demand by bird?

we need to announce it on-demand by bird, because we plan to possibly
have several servers. Actually we also add the routes because we already
have several openvpn daemons, because we have to let people connect
through either udp and tcp, depending on the wild area they happen to
have landed on. So we need to tell the kernel which tun (i.e. which
openvpn daemon) to push paquets to.

> Have you looked at the learn-address script?  I use something similar
> at a customer (adding and removing proxy-arp entries on client connect)
> and learn-address does all I need just fine...

That could do it yes, however,

> Well, learn-address is run on disconnect, but not "right away" - true,
> so having it in disconnect is useful.

yes. The rather random delay hurts by preventing from reconnecting
immediately (either to the same daemon, or to another one or even
another server), which is a pain when trying to set up the VPN in a wild
area :)

> I wonder whether we should also export iroute-ipv6 settings, as that would
> enable on-demand routing of more than a single IPv6 address.

Actually in our case iroute is fed by radiusplugin, which happens to
also already add the route for us, so we didn't have to add that one.
But it could be better to have radiusplugin just pass iroute to openvpn,
and let the userscript add the route if needed.

Samuel

Re: [Openvpn-devel] [PATCH] openvpn ipv6 pool env variables

[Samuel Thibault]

Gert Doering, le Sat 25 May 2013 13:58:19 +0200, a écrit :
> > To make it short: yes, the ipv6 pool environment variables are useful,
> > for user-defined scripts to be run at connection for instance to
> > propagate routes, do accounting, etc.  The patch below adds them.
> 
> You keep claiming that "yes it's useful".  The lack of feedback on the
> list is partly due to the "To make it short" part of your mail...

Ok. I was simply wondering whether it had perhaps got somehow dropped
without reason.

As I mentioned too briefly, the reason we need it is the same as for the
IPv4 case: to announce the route to our bird daemon on connection, and
drop it on disconnection.

> Specifically, "ifconfig_ipv6_local" and "ifconfig_ipv6_netbits" already exist,

Ah, ifconfig_ipv6_netbits didn't when I worked on this patch, I hadn't
noticed that had changed. These can indeed go away.

> So the only thing that I couldn't see right away
> in the environment is "what IPv6 address did the remote receive?" and
> that one *is* available as parameter to the "learn-address" script already
> today...

But we need it from the disconnect script too, to remove the route
announcement. It is available for IPv4, I don't see why things should
be different between IPv6 and IPv4 here. It would make our script way
more obscure for sure (having to record the route somewhere, re-read on
disconnect).

> This whole bit is overly complicated.  Unlike IPv4, there is no "this
> could be a remote or a netmask" distinction,

Right, here is a simpler patch.

Samuel


Add IPv6 pool environment variable

Add the ifconfig_ipv6_pool_remote_ip environment variable, similar to
ifconfig_pool_remote_ip.

Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 397e2bf..afcedef 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5776,6 +5776,22 @@ and
 scripts.
 .\"*
 .TP
+.B ifconfig_ipv6_pool_remote_ip
+The remote
+virtual IPv6 address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
 .B link_mtu
 The maximum packet size (not including the IP header)
 of tunnel data in UDP tunnel transport mode.
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 5d2c36c..23f2714 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -2384,6 +2384,7 @@ env_filter_match (const char *env_str, const int 
env_filter_level)
 "dev=",
 "ifconfig_pool_remote_ip=",
 "ifconfig_pool_netmask=",
+"ifconfig_ipv6_pool_remote_ip=",
 "time_duration=",
 "bytes_sent=",
 "bytes_received="
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index f016b14..d5267db 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1437,10 +1437,16 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct multi_instance *mi)
}
 }
 
-/* TODO: I'm not exactly sure what these environment variables are
- *   used for, but if we have them for IPv4, we should also have
- *   them for IPv6, no?
- */
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_remote_ip");
+
+  if (mi->context.c2.push_ifconfig_ipv6_defined)
+{
+  setenv_in6_addr_t (mi->context.c2.es,
+   "ifconfig_ipv6_pool_remote_ip",
+   >context.c2.push_ifconfig_ipv6_local,
+   SA_SET_IF_NONZERO);
+}
+
 }
 
 /*
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 94d2b10..74320ce 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -2391,7 +2391,10 @@ setenv_sockaddr (struct env_set *es, const char 
*name_prefix, const struct openv
}
   break;
 case AF_INET6:
-  openvpn_snprintf (name_buf, sizeof (name_buf), "%s_ip6", name_prefix);
+  if (flags & SA_IP_PORT)
+   openvpn_snprintf (name_buf, sizeof (name_buf), "%s_ip6", name_prefix);
+  else
+   openvpn_snprintf (name_buf, sizeof (name_buf), "%s", name_prefix);
   getnameinfo(>addr.sa, sizeof (struct sockaddr_in6),
  buf, sizeof(buf), NULL, 0, NI_NUMERICHOST);
   setenv_str (es, name_buf, buf);
@@ -2419,6 +2422,19 @@ setenv_in_addr_t (struct env_set *es, const char 
*name_prefix, in_addr_t addr, c
 }
 
 void
+setenv_in6_addr_t (struct env_set *es, const char *name_prefix, struct 
in6_addr *addr, const bool flags)
+{
+  if ( memcmp(add

[Openvpn-devel] [PATCH] openvpn ipv6 pool env variables

[Samuel Thibault]

Hello,

To make it short: yes, the ipv6 pool environment variables are useful,
for user-defined scripts to be run at connection for instance to
propagate routes, do accounting, etc.  The patch below adds them.

Thanks,
Samuel


Add IPv6 pool environment variables

Add ifconfig_ipv6_pool_local_ip, ifconfig_ipv6_pool_remote_ip and
ifconfig_ipv6_pool_netbits environment variables, similar to
ifconfig_pool_local_ip, ifconfig_pool_remote_ip, and
ifconfig_pool_netmask.

Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index d590714..70a8f35 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5755,6 +5755,60 @@ and
 scripts.
 .\"*
 .TP
+.B ifconfig_ipv6_pool_local_ip
+The local
+virtual IPv6 address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+Only set for
+.B \-\-dev tun
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
+.B ifconfig_ipv6_pool_netbits
+The
+size of the virtual IPv6 netmask for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+Only set for
+.B \-\-dev tap
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
+.B ifconfig_ipv6_pool_remote_ip
+The remote
+virtual IPv6 address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
 .B link_mtu
 The maximum packet size (not including the IP header)
 of tunnel data in UDP tunnel transport mode.
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 0a4542a..72686f3 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -2283,6 +2283,8 @@ env_filter_match (const char *env_str, const int 
env_filter_level)
 "dev=",
 "ifconfig_pool_remote_ip=",
 "ifconfig_pool_netmask=",
+"ifconfig_ipv6_pool_remote_ip=",
+"ifconfig_ipv6_pool_netbits=",
 "time_duration=",
 "bytes_sent=",
 "bytes_received="
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index ab3f10c..d38cc8e 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1426,10 +1426,35 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct multi_instance *mi)
}
 }

-/* TODO: I'm not exactly sure what these environment variables are
- *   used for, but if we have them for IPv4, we should also have
- *   them for IPv6, no?
- */
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_local_ip");
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_remote_ip");
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_netbits");
+
+  if (mi->context.c2.push_ifconfig_ipv6_defined)
+{
+  const int tunnel_type = TUNNEL_TYPE (mi->context.c1.tuntap);
+  const int tunnel_topology = TUNNEL_TOPOLOGY (mi->context.c1.tuntap);
+
+  setenv_in6_addr_t (mi->context.c2.es,
+   "ifconfig_ipv6_pool_remote_ip",
+   >context.c2.push_ifconfig_ipv6_local,
+   SA_SET_IF_NONZERO);
+
+  if (tunnel_type == DEV_TYPE_TAP || (tunnel_type == DEV_TYPE_TUN && 
tunnel_topology == TOP_SUBNET))
+   {
+ setenv_int (mi->context.c2.es,
+   "ifconfig_ipv6_pool_netbits",
+   mi->context.c2.push_ifconfig_ipv6_netbits);
+   }
+  else if (tunnel_type == DEV_TYPE_TUN)
+   {
+ setenv_in6_addr_t (mi->context.c2.es,
+   "ifconfig_ipv6_pool_local_ip",
+   >context.c2.push_ifconfig_ipv6_remote,
+   SA_SET_IF_NONZERO);
+   }
+}
+
 }

 /*
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 8eb112b..8eb27f6 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -2381,7 +2381,10 @@ setenv_sockaddr (struct env_set *es, const char 
*name_prefix, const struct openv
}
   break;
 case AF_INET6:
-  openvpn_snprintf (name_buf, sizeof (name_buf), "%s

Re: [Openvpn-devel] users of the OpenVPN management interface?

[Samuel Thibault]

Gert Doering, le Thu 11 Apr 2013 11:36:08 +0200, a écrit :
> On Thu, Apr 11, 2013 at 10:36:57AM +0200, Samuel Thibault wrote:
> > Gert Doering, le Thu 11 Apr 2013 10:30:02 +0200, a écrit :
> > > Now, I'm wondering who is actually *using* the management interface on
> > > the server side (where stuff like "status 2" makes a bigger difference).
> > 
> > We use kill to shut down the current VPN session of somebody who has
> > stopped paying for the service.
> 
> To clarify: of these variants are you using?
> 
> kill cn: Kill the client instance(s) having common name cn.

This one: when the user has stopped paying for the service, the radius
account gets disabled, and then we kill the cn to make sure all existing
sessions are shut down, and the user can't establish another one. We
don't really care how he is connected.

Samuel

Re: [Openvpn-devel] users of the OpenVPN management interface?

[Samuel Thibault]

Gert Doering, le Thu 11 Apr 2013 10:30:02 +0200, a écrit :
> Now, I'm wondering who is actually *using* the management interface on
> the server side (where stuff like "status 2" makes a bigger difference).

We use kill to shut down the current VPN session of somebody who has
stopped paying for the service.

Samuel

Re: [Openvpn-devel] openvpn ipv6 pool env variables

[Samuel Thibault]

Hello,

To make it short: yes, the ipv6 pool environment variables are useful,
for user-defined scripts to be run at connection for instance to
propagate routes, do accounting, etc.  The patch below adds them.

Thanks,
Samuel


Add IPv6 pool environment variables

Add ifconfig_ipv6_pool_local_ip, ifconfig_ipv6_pool_remote_ip and
ifconfig_ipv6_pool_netbits environment variables, similar to
ifconfig_pool_local_ip, ifconfig_pool_remote_ip, and
ifconfig_pool_netmask.

Signed-off-by: Samuel Thibault <samuel.thiba...@ens-lyon.org>

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index d590714..70a8f35 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5755,6 +5755,60 @@ and
 scripts.
 .\"*
 .TP
+.B ifconfig_ipv6_pool_local_ip
+The local
+virtual IPv6 address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+Only set for
+.B \-\-dev tun
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
+.B ifconfig_ipv6_pool_netbits
+The
+size of the virtual IPv6 netmask for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+Only set for
+.B \-\-dev tap
+tunnels.
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
+.B ifconfig_ipv6_pool_remote_ip
+The remote
+virtual IPv6 address for the TUN/TAP tunnel taken from an
+.B \-\-ifconfig-ipv6-push
+directive if specified, or otherwise from
+the ifconfig pool (controlled by the
+.B \-\-ifconfig-ipv6-pool
+config file directive).
+This option is set on the server prior to execution
+of the
+.B \-\-client-connect
+and
+.B \-\-client-disconnect
+scripts.
+.\"*
+.TP
 .B link_mtu
 The maximum packet size (not including the IP header)
 of tunnel data in UDP tunnel transport mode.
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 0a4542a..72686f3 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -2283,6 +2283,8 @@ env_filter_match (const char *env_str, const int 
env_filter_level)
 "dev=",
 "ifconfig_pool_remote_ip=",
 "ifconfig_pool_netmask=",
+"ifconfig_ipv6_pool_remote_ip=",
+"ifconfig_ipv6_pool_netbits=",
 "time_duration=",
 "bytes_sent=",
 "bytes_received="
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index ab3f10c..d38cc8e 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1426,10 +1426,35 @@ multi_set_virtual_addr_env (struct multi_context *m, 
struct multi_instance *mi)
}
 }

-/* TODO: I'm not exactly sure what these environment variables are
- *   used for, but if we have them for IPv4, we should also have
- *   them for IPv6, no?
- */
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_local_ip");
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_remote_ip");
+  setenv_del (mi->context.c2.es, "ifconfig_ipv6_pool_netbits");
+
+  if (mi->context.c2.push_ifconfig_ipv6_defined)
+{
+  const int tunnel_type = TUNNEL_TYPE (mi->context.c1.tuntap);
+  const int tunnel_topology = TUNNEL_TOPOLOGY (mi->context.c1.tuntap);
+
+  setenv_in6_addr_t (mi->context.c2.es,
+   "ifconfig_ipv6_pool_remote_ip",
+   >context.c2.push_ifconfig_ipv6_local,
+   SA_SET_IF_NONZERO);
+
+  if (tunnel_type == DEV_TYPE_TAP || (tunnel_type == DEV_TYPE_TUN && 
tunnel_topology == TOP_SUBNET))
+   {
+ setenv_int (mi->context.c2.es,
+   "ifconfig_ipv6_pool_netbits",
+   mi->context.c2.push_ifconfig_ipv6_netbits);
+   }
+  else if (tunnel_type == DEV_TYPE_TUN)
+   {
+ setenv_in6_addr_t (mi->context.c2.es,
+   "ifconfig_ipv6_pool_local_ip",
+   >context.c2.push_ifconfig_ipv6_remote,
+   SA_SET_IF_NONZERO);
+   }
+}
+
 }

 /*
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 8eb112b..8eb27f6 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -2381,7 +2381,10 @@ setenv_sockaddr (struct env_set *es, const char 
*name_prefix, const struct openv
}
   break;
 case AF_INET6:
-  openvpn_snprintf (name_buf, sizeof (name_buf), "%s