[Openvpn-devel] Summary of the IRC meeting (1st Jul 2010)

[Samuli Seppänen]

Hi,

Here's the summary of the previous community meeting.

---

COMMUNITY MEETING

Place: #openvpn-devel on irc.freenode.net
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thursday, 1st Jul 2010
Time: 18:00 UTC

Planned meeting topics for this meeting were on this page:



Next meeting next week, same place, same time. Your local meeting time
is easy to check from services such as



or with

$ date -u


SUMMARY

Discussed forums.openvpn.net. Announced August 13th (Friday, of course)
as the launch date. Data and users will be migrated from ovpnforums.com.
Server setup is done jointly by our community (Eric) and the company
(Samuli, Andrew and Patel).

--

Discussed Wiki usage. Agreed that our Trac wiki should be used as the
official OpenVPN wiki:



Also discussed backing up the Trac server to Secure Computing. Agreed
that it makes sense to have at least data backups in a
community-maintained server. Currently the LDAP directory, Trac database
& configs and /etc are being pushed to a (Eric's) Secure Computing
servers. These should be enough to restore Trac and LDAP users in case a
disaster happens. The backups should be tested to validate this, though.

--

Discussed BuildBot build failure notifications. Agreed that
notifications should be sent to the #openvpn-devel IRC channel in the
following fashion:

- Supybot (the famous vpnHelper) monitors BuildBot's RSS feed web page
- Supybot pushed the RSS notifications to #openvpn-devel channel

Also agreed that build failures should be sent to a mailinglist as
developers are not guaranteed to be on IRC all the time. Openvpn-devel
list could be used for this; however, ~500 people have subscribed to it
and maybe 10 are interested in build failures. If failures are not
frequent, this might not be an issue. The alternative is to create a new
mailinglist (e.g. openvpn-builds) and use that instead.

--

Discussed limiting access to BuildBot web interface (status display) for
security reasons. Agreed that access to it should be limited to core
community members. Agreed that eating our own dogfood makes sense, so
access to BuildBot would be granted with OpenVPN "testing" + LDAP
authentication. An alternative would be HTTPS+BASIC AUTH from LDAP.

--

Discussed where to get BuildSlaves for Buildbot. Agreed that a basic set
of i386/amd64 BuildSlaves could be simple virtual machines. Additional
architectural coverage could be obtained from volunteer community members.

--

Discussed build triggers BuildBot will use. Agreed that reading the
SF.net Git RSS feed would make most sense. Samuli agreed to see if this
is possible without hacking with Python.

The alternative approach is to make BuildBot read commits from commit
mails in a mailing list. A read-only openvpn-commits list would make
most sense from security perspective.

--

Discussed the Beta2.2 branch which lives in openvpn.net SVN repository.
The Git<->SVN interaction has a number of unsolved issues: see 22:17 -
22:29 in the full chatlog. Agreed that until we get James' view on those
issues we should maintain beta2.2 branch in Git instead of SVN.

---

Full chatlog as an attachment

-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock






(21:06:28) mattock: let's start the meeting, shall we?
(21:06:44) dazo: +1
(21:06:45) cron2: I just wanted to suggest that, yes :-) we have some items 
that don't need James
(21:06:54) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2010-07-01
(21:06:55) vpnHelper: Title: Topics-2010-07-01 – OpenVPN (at 
community.openvpn.net)
(21:07:19) mattock: ok, for your information we set the launch date for 
forums.openvpn.net
(21:07:24) mattock: which is...
(21:07:31) mattock: August 13th (Friday, of course :)
(21:07:53) mattock: one topic covered!
(21:08:06) ecrist: currently, openvpn tech folks are to be skinning the site
(21:08:15) mattock: yep
(21:08:19) ecrist: mattock is supposed to be working on integrating the 
authentication 
(21:08:24) ecrist: I am relaxing.
(21:08:34) cron2: ecrist: good planning :)
(21:08:37) dazo: ecrist:  job well done in other words!
(21:08:48) krzee: ecrist++
(21:09:14) mattock: I'll start working on the forums on monday
(21:09:34) mattock: I have a couple of tasks which should be finished in a day 
or two
(21:09:35) ecrist: let me know if there are php modules missing, etc
(21:09:53) mattock: ecrist: ok
(21:10:04) mattock: although I think I'll just install any missing ports myself
(21:10:48) mattock: ok, shall we move on to BuildBot stuff?
(21:10:54) ***krzee hears "ports", its fbsd?
(21:10:57) krzee: good stuff
(21:11:25) mattock: krzee: yep
(21:11:48) ecrist: krzee: of course
(21:11:51) ecrist: only the best
(21:12:11) krzee: =]
(21:12:11) mattock: sending mail to james...
(21:12:32) cron2: shall we cover the wiki thing in between?
(21:12:39) dazo: +1
(

Re: [Openvpn-devel] [Openvpn-users] Is it possible to access Windows XP shares over port 445?

[Henno Täht]

FWIW, I posted this issue to Microsoft's forum:
http://social.answers.microsoft.com/Forums/en-US/xpnetwork/thread/82388e04-1791-43a0-a678-de8475bce537

Everyone who like this to be answered can mark that article to up the "X
persons needs an answer" thing.

Henno


2010/6/26 Gert Doering 

> Hi,
>
> On Wed, Jun 23, 2010 at 10:50:45PM +0300, Henno Täht wrote:
> > On Wed, Jun 23, 2010 at 22:48, Gert Doering  wrote:
> > > On Wed, Jun 23, 2010 at 09:10:10AM +0200, Jan Just Keijser wrote:
> > > > assigns a 169.254 address. If this works for you as well then maybe
> the
> > > > tap-win32 developers can dive deeper into this and find out why
> windows
> > > > treats the 'always connected' adapter differently from an
> 'application
> > > > controlled' adapter .
> > >
> > > I'd assume that windows services are not "bound" to "dynamic"
> interfaces...
> >
> > By dynamic interface you mean an interface which has  "Obtain IP address
> > automatically" set?
>
> No, I was thinking about interfaces that sort of "are not always there".
>
> But that was a misconception, the TAP interface *is* always there - what's
> application controlled is whether it's "connected to an ethernet cable"
> (virtual, of course) all the time, or only if openvpn tells it so.
>
> But in that my idea doesn't really make sense - it's as if windows wouldn't
> start windows sharing if the ethernet cable is not plugged in at boot time.
>
> 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-35655025
> g...@net.informatik.tu-muenchen.de
>

Re: [Openvpn-devel] Beta 2.2 branch pushed

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all!

I've just pushed out a brand new beta2.2 branch on git.  The previous
attempt is renamed svn-beta2.2, and will most probably be deleted in the
near future.

The background for this is the discussion on #openvpn-devel meeting
yesterday.  As there are uncertainties regarding if the SVN push was
correct, it's better to start from scratch again as soon as possible and
work against the git branch for now.

The reason for this is that all commits, from the very beginning of the
SVN BETA2.1 branch, got rewritten and put me as the commiter of the
whole history.  It also meant that the complete history got duplicated
in the SVN history, one with the right commiter (James) and the
duplicate with my name on it.  In the meeting yesterday, we felt that
this was probably not correct and feared it might cause further merge
problems later on for James.

So it was considered better if a new SVN branch for the beta2.2 would be
created, branched out from r5701 (the latest SVN change).  All community
patches will then come on top of that new branch.  When I will do the
next SVN push, only those changes will be pushed (~50 commits) and not
the complete OpenVPN history once again.

Until these SVN push issues have been solved and James have had time to
review and comment the current SVN push, we will stay on git only for
the beta development.

> * What does the beta2.2 branch contain?
> As agreed to in the developers meeting June 10, OpenVPN 2.2 will contain:
> 
> - bugfix2.1 branch (lots of bugfixes)
> - feat_misc branch (several minor feature additions)
> - frp branch (https://community.openvpn.net/openvpn/wiki/FRP)
> - feat_eurephia branch (http://www.eurephia.net)
> - feat_ipv6_wintap (IPv6-enabled TAP driver for Windows)


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkwuJawACgkQDC186MBRfrrk9QCgrhUKNI+eZSjW5E5f/KnGIW62
9bsAn0VE1T3CAzs4mqIYKL1VO9cmNtZG
=v0g+
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN server listening both on udp and tcp?

[Henno Täht]

Hello!

2010/7/2 David Sommerseth 

> On 02/07/10 19:38, Henno Täht wrote:
> > Hello!
> >
> > Can anyone experienced and helpful scribble a little guide how to have
> > the same OpenVPN server listening both on 1194 UDP (reason: fast,
> > preferable) and 443 TCP (reason: always works, fallback)?
>
> That is not possible.  OpenVPN can only listen to TCP or UDP, not both.
>  To do this, you will need two independent OpenVPN configurations and
> run two separate OpenVPN daemons
>
> Having that said, this is a common question and a feature which is under
> evaluation for the next generation OpenVPN.
>

Great news!

A client config file should also support this. Something like this:
remote 198.51.100.15:1194 proto udp wait 10
remote 203.0.113.234:443 proto tcp  wait 1
remote 192.168.0.1:8080->203.0.113.234:443 proto tcp wait 1

Explanation:
First try direct connection to udp port 1194, wait 10 seconds (should be
enough to survive OpenVPN server restarts after config change).
If that fails (timeout of 10 seconds is past and no answer), try another ip
with tcp 443 and wait 1 second for reply (443 tcp is usually left open for
https).
If that too fails, assume that the user is again visiting NSA-like
institution but which luckily has a local proxy (which allows only for tcp
port 80 and 443 connections for that matter).

This is just some thoughts of me how OpenVPN should treat the --remote
option in the future.
I'm hoping that someone picks this up to start a discussion.

Henno

Re: [Openvpn-devel] Beta 2.2 branch pushed

[Carsten Krüger]

Hello,

> So it was considered better if a new SVN branch for the beta2.2 would be
> created, branched out from r5701 (the latest SVN change).

Why didn't James switch to git, too?
Using svn & git in parallel isn't effective and causes such problems.
And as far as I know is git a complete superset of subversion.

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN server listening both on udp and tcp?

[Jan Just Keijser]

Hi Henno,

Henno Täht wrote:

Hello!

2010/7/2 David Sommerseth >


On 02/07/10 19:38, Henno Täht wrote:
> Hello!
>
> Can anyone experienced and helpful scribble a little guide how
to have
> the same OpenVPN server listening both on 1194 UDP (reason: fast,
> preferable) and 443 TCP (reason: always works, fallback)?

That is not possible.  OpenVPN can only listen to TCP or UDP, not
both.
 To do this, you will need two independent OpenVPN configurations and
run two separate OpenVPN daemons

Having that said, this is a common question and a feature which is
under
evaluation for the next generation OpenVPN.


Great news!

A client config file should also support this. Something like this:
remote 198.51.100.15:1194  proto udp wait 10
remote 203.0.113.234:443  proto tcp  wait 1
remote 192.168.0.1:8080->203.0.113.234:443  
proto tcp wait 1


Explanation:
First try direct connection to udp port 1194, wait 10 seconds (should 
be enough to survive OpenVPN server restarts after config change).
If that fails (timeout of 10 seconds is past and no answer), try 
another ip with tcp 443 and wait 1 second for reply (443 tcp is 
usually left open for https).
If that too fails, assume that the user is again visiting NSA-like 
institution but which luckily has a local proxy (which allows only for 
tcp port 80 and 443 connections for that matter).


This is just some thoughts of me how OpenVPN should treat the --remote 
option in the future. 
I'm hoping that someone picks this up to start a discussion.
the client side already supports this (with a drawback): if you read the 
openvpn 2.1 manual page , section 'connection profiles' you'll see



 remote host:1194
 proto udp



 remote host:443
 proto tcp



 remote host:443
 proto tcp
 http-proxy host:port


etc. The drawback is that  you can no longer tweak some settings , such 
as fragment/tcp timeouts etc. This is an open bug which hopefully will 
be addressed in openvpn 2.2 ; the redesign of openvpn to allow multiple 
listeners on the server side is further off.


HTH,

JJK