Re: [Openvpn-devel] Running udp and tcp server in the same instance

2012-03-02 Thread Jason Haar
On 03/03/12 03:59, Gert Doering wrote:
> I would *love* to have that. And it's somewhere on my TODO list of
> things to implement in OpenVPN (multiple listening sockets in a single
> process).

Given the issue with the non-threaded nature of openvpn and the
bottlenecks that can cause under load, what's wrong with running
separate instances on multiple tcp and udp ports, and then using a
"--client-connect" script to return a unique IP to clients? We use that
so that all VPN users are always assigned "their" constant IP by mapping
an IP to the CN field - that also stops them using the same cert on >1
clients... (ie that's a feature for us - not a bug). Actually it doesn't
stop them using it on >1 clients - but it stops them running >1 clients
simultaneously :-)

With this, we have the luxury that every client always gets the same IP
- which makes asset management *much* easier and means you get
marvellous side-effects like I can be SSH-ed into a work machine at
home, suspend my laptop, go to another building and get an completely
different Internet address, and yet seconds later have openvpn
auto-reconnect to work and find my SSH session still works. So cool :-)

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +1 408 481 8171
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1




Re: [Openvpn-devel] [DISCUSSION] OpenVPN privilege separation (Windows)

2012-03-02 Thread Alon Bar-Lev
OK,
I will continue to discuss this with my-self, as apparently what I am
showing is not significant enough to have a proper technical
discussion. There is nothing wrong in open mind to other
possibilities, evaluate and with rational select the best approach.

For the lazy people of us, I added installation script[1] to do all
the steps automatically.

Compile the project, move the install.js, test.js,
OpenVPNUINetwork.dll, OpenVPNUITunnel.dll to some directory.

> cscript //nologo install.js --command=install --mode=enterprise
-- Add your user to OpenVPN Users group logout/login

> cscript //nologo test.js
> cscript //nologo install.js --command=update --mode=standalone
> cscript //nologo test.js
> cscript //nologo install.js --command=update --mode=enterprise
> cscript //nologo test.js

> cscript //nologo install.js --command=uninstall

BTW: For these who are not familiar with ATL programming, most of the
code is generated by the Microsoft wizards, the actual added code
resides in Network.cpp and Tunnel.cpp files.

Alon.

[1] 
https://github.com/alonbl/openvpn-gui-skeleton/blob/master/scripts/install.js

On Fri, Mar 2, 2012 at 1:20 AM, Alon Bar-Lev  wrote:
> Hello Again,
>
> To make it easier to understand and help to demonstrate the
> technology, I created skeleton[1] for the alternative I suggested.
>
> It uses the COM+ infrastructure to achieve what we need avoiding
> complex programming.
>
> We have two COM+ objects:
> OpenVPNUI.Network - runs under user belongs to the network
> configuration operators group.
> OpenVPNUI.Tunnel - runs under unprivileged user.
>
> We control the identity and access to these object using the COM+
> infrastructure. COM+ does all the work for us, we don't need to do
> communication or security check within code.
>
> The manual configuration is quite long, I wrote step-by-step, it is
> good for people who wish to understand what happening. There is more
> configuration than actual coding which is great.
>
> The script/test.js script is used to test this infrastructure.
>
> Use the setup instructions bellow, you will get the most secured
> configuration, total privilege separation. OpenVPN daemon which will
> be run by the OpenVPNUI.Tunnel object runs under its own unprivileged
> account and only this account can access the OpenVPNUI.Network object
> which is within the network operators group. As a result the
> interactive user cannot change routes or hack into the OpenVPN daemon
> address space. Of course that in this configuration only Administrator
> is allowed to modify the configuration files, to not allowing the user
> to execute own script under the openvpn context. In this case the UI
> it-self should execute user specific connect/disconnect scripts, it
> receives these events, no reason why the daemon needs to do so. But be
> patient, I will show how it can be done if desired.
>
> The output of the script in this configuration is:
> ---
> Trying to access OpenVPNUI.Network directly
> Creating OpenVPNUI.Network
> ERROR: Permission denied
>
>
> Trying to access OpenVPNUI.Tunnel
> Creating OpenVPNUI.Tunnel
> OpenVPNTunnel identity is: openvpn
> Creating Route for 1.0.0.0
> ==
> Active Routes:
> Network Destination        Netmask          Gateway       Interface  Metric
>          0.0.0.0          0.0.0.0    192.168.151.1  192.168.151.10       1
>          1.0.0.0          1.0.0.0          2.0.0.0  192.168.151.10      1
>        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
> 
> Default Gateway:     192.168.151.1
> ==
>
>
> Deleting Route for 1.0.0.0
> ==
> Active Routes:
> Network Destination        Netmask          Gateway       Interface  Metric
>          0.0.0.0          0.0.0.0    192.168.151.1  192.168.151.10       1
>        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
> 
> Default Gateway:     192.168.151.1
> ==
>
> ---
>
> So what do we see here?
> My interactive user cannot access the  OpenVPNUI.Network object, but
> can access the  OpenVPNUI.Tunnel. The user of the OpenVPNUI.Network
> object is openvpn, this user can access the  OpenVPNUI.Network object,
> so the it can modify the route.
>
> Now, let's change the permissions the the standalone configuration,
> meaning the interactive user can modify the openvpn configuration, and
> we may want openvpn to run under the interactive user account to
> execute some scripts.
>
> Before we do this, I would like to say that I disagree with the fact
> that "connect/disconnect" scripts should be run by the daemon, I think
> that these scripts should be run by the UI it-self that is already run
> under the interactive user. No *NEW* security issue issue will be
> created if user is allowed to change configuration but daemon runs
> under the openvpn unprivileged account.
>
> Anyway, as this was discussed as an option, lets do the 

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

2012-03-02 Thread Mr Dash Four



I've used "--route-nopull" together with specific "--route" statements
to work around VPN setups that didn't work under specific circumstances
(the server pushes a heap of routes, some of which caused problems in
my setup [*], and I only wanted to reach a specific subnet via the VPN).
  

+1

I've done exactly the same thing for exactly the same reasons, though I 
also use setcon as well (I have my own SELinux policy, so it makes sense 
for my own configuration/interfaces used).





Re: [Openvpn-devel] setting common-name from plugin

2012-03-02 Thread David Sommerseth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/03/12 15:32, michael-dev wrote:
> Hi,
> 
> I've got a openvpn radius authentication plugin (username/password) 
> here [1,2]. Though my radius server is really friendly to users (e.g.
>  you might add or strip the domain as you like, upper/lower-case does
> not matter, users might have multiple usernames for different
> reasons), I still want each user to connect only ones to openvpn in
> order to mitigate sharing credentials. Radius has the
> chargeable-user-identity reply attribute that could be used to set the
> common-name, but I did not find any way in openvpn to do this from
> plugin. Could a patch adding a way to set the common name from radius
> plugin similar to return_list in OPENVPN_PLUGIN_CLIENT_CONNECT_V2 be
> accepted?
> 

I'm probably not awake enough to really understand what you try to solve.
 But if you want to change the username to become the common-name after
the authentication, I struggle to see what that really solves.

You seem to have users with multiple usernames, but want them to only
connect once - no matter which user name they use.

The username itself is sent from the client and is never really used in
OpenVPN, except being sent further to either --auth-user-pass-verify or
the a --plugin which has set the OPENVPN_PLUGIN_AUTH_USER_PASS_VERIFY
flag set.

So changing the username from the plug-in would not really make any
difference at all, as a new connection from the same user would still
send the "other" username to the plug-in.

I would rather suggest enhancing your radius plug-in.  On each successful
authentication save the chargeable-user-identity response in a
lookup-table.

For each authentication, first check the user name against this
lookup-table.  If you get a match, tell OpenVPN to reject the connection
(OPENVPN_PLUGIN_FUNC_ERROR).  If there's no match, continue with the
radius authentication, retrieve chargeable-user-identity response and do
another lookup to see if you get a match on this identity instead.  If
you do, reject again.  If you don't have a match, save this identity and
report OPENVPN_PLUGIN_FUNC_SUCCESS.

You would also need to add an extra plug-in hook,
OPENVPN_PLUGIN_CLIENT_DISCONNECT.  This hook need to remove the user from
this lookup table, to allow the user to connect again later on.

Does this make sense to you?


kind regards,

David Sommerseth


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9RInoACgkQDC186MBRfrrA+wCgh3x98Q5d4qhoUyQz5K0Av2/q
KmUAn3DclppZHfR2YfNKJLwTlPcB47s/
=O5BL
-END PGP SIGNATURE-



Re: [Openvpn-devel] Running udp and tcp server in the same instance

2012-03-02 Thread Gert Doering
Hi,

On Fri, Mar 02, 2012 at 03:32:36PM +0100, michael-dev wrote:
> I've got multiple tcp und udp based OpenVPN instances here, that 
> prevent duplicate login of the same user by running some custom 
> connect-scripts with some extra user-cannot-connect-anywhere timeslide.
> Are there any plans to support clients connecting via tcp and udp in 
> the same instance?

I would *love* to have that.  And it's somewhere on my TODO list of things
to implement in OpenVPN (multiple listening sockets in a single process).

Alas, socket.c is not for the faint of heart, and I haven't had the time
yet to do so.  So I'd certainly welcome your patch :-)

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


pgppY8I5bFrUt.pgp
Description: PGP signature


Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

2012-03-02 Thread Gert Doering
Hi,

On Thu, Mar 01, 2012 at 11:58:39AM +0100, Heiko Hund wrote:
> Is there a use case for --route on the client?

I've used "--route-nopull" together with specific "--route" statements
to work around VPN setups that didn't work under specific circumstances
(the server pushes a heap of routes, some of which caused problems in
my setup [*], and I only wanted to reach a specific subnet via the VPN).

gert

(*) specifically: some of the hosts in my scenario can be reached 
through the VPN, and without VPN.  Firing up the VPN and routing these
hosts through the VPN would break existing SSH sessions, as further
packets would get routed through the VPN, and the VPN server would not
accept the existing source address (not from VPN range).  Yes, not
your daily issue, but I was quite happy to have that knob to fiddle.

-- 
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


pgpe8lYaFwA_2.pgp
Description: PGP signature


[Openvpn-devel] Running udp and tcp server in the same instance

2012-03-02 Thread michael-dev

Hi,

I've got multiple tcp und udp based OpenVPN instances here, that 
prevent duplicate login of the same user by running some custom 
connect-scripts with some extra user-cannot-connect-anywhere timeslide.
Are there any plans to support clients connecting via tcp and udp in 
the same instance?


Regards,
 M. Braun




[Openvpn-devel] setting common-name from plugin

2012-03-02 Thread michael-dev

Hi,

I've got a openvpn radius authentication plugin (username/password) 
here [1,2]. Though my radius server is really friendly to users (e.g. 
you might add or strip the domain as you like, upper/lower-case does not 
matter, users might have multiple usernames for different reasons), I 
still want each user to connect only ones to openvpn in order to 
mitigate sharing credentials.
Radius has the chargeable-user-identity reply attribute that could be 
used to set the common-name, but I did not find any way in openvpn to do 
this from plugin.
Could a patch adding a way to set the common name from radius plugin 
similar to return_list in OPENVPN_PLUGIN_CLIENT_CONNECT_V2 be accepted?


Regards,
 M. Braun
--
[1] 
http://subversion.fem.tu-ilmenau.de/websvn/wsvn/openvpn-radius-auth/trunk/
[2] 
http://subversion.fem.tu-ilmenau.de/repository/openvpn-radius-auth/trunk/





Re: [Openvpn-devel] GUI size

2012-03-02 Thread Alon Bar-Lev
This is already been done in the new build system.

On Fri, Mar 2, 2012 at 10:56 AM, Heiko Hund  wrote:
> Samuli,
>
> I've received a question about the size of the snapshot binaries in the issue
> tracker yesterday.
>
> https://sourceforge.net/tracker/?func=detail=1327094=3496102_id=248281
>
> Could you compile the GUI yourself and link against the openssl crypto DLL for
> the next release? The GUI shouldn't be linked statically if there a
> libeay32.dll lying next to it, really.
>
> Thanks
> Heiko
> --
> Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
> Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
> Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
>
> Represented by the General Partner Astaro Verwaltungs GmbH
> Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany
> Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
> Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel



[Openvpn-devel] GUI size

2012-03-02 Thread Heiko Hund
Samuli,

I've received a question about the size of the snapshot binaries in the issue 
tracker yesterday.

https://sourceforge.net/tracker/?func=detail=1327094=3496102_id=248281

Could you compile the GUI yourself and link against the openssl crypto DLL for 
the next release? The GUI shouldn't be linked statically if there a 
libeay32.dll lying next to it, really.

Thanks
Heiko
-- 
Heiko Hund | Software Engineer | Phone +49-721-25516-237 | Fax -200
Astaro a Sophos Company | Amalienbadstr. 41 Bau 52 | 76227 Karlsruhe | Germany
Commercial Register: Mannheim HRA 702710 | Headquarter Location: Karlsruhe
 
Represented by the General Partner Astaro Verwaltungs GmbH
Amalienbadstraße 41 Bau 52 | 76227 Karlsruhe | Germany 
Commercial Register: Mannheim HRB 708248 | Executive Board: Gert Hansen,
Markus Hennig, Jan Hichert, Günter Junk, Dr. Frank Nellissen




Re: [Openvpn-devel] OpenVPN and Android 4.0 VPN API

2012-03-02 Thread James Ring
Hey Arne,

On Thu, Mar 1, 2012 at 3:05 PM, Arne Schwabe  wrote:
>
>>> ... and for the rest, well, we'd need a volunteer that wants to *work* on
>>> this, not just ask for it...  I don't have an Android device (and no
>>> time) so it wouldn't be me.
>>
>> I'm raising my hand. This path sounds better than what I thought would
>> be necessary (writing OpenVPN client implementation in Java). I'm also
>> asking around here at Google to see if somebody with more experience
>> with Android is interested in helping out. I'm sure there is
>> sufficient interest on both sides (Android and OpenVPN) to get
>> something working. This would make a niche segment of Android users
>> very happy I'm sure.
>>
> Are you already actively working on this? Otherwise I would start working on
> the feature. I have already some experience with the android sdk and ndk. I
> think I would solve the problem of fd passing and so on by turning openvpn
> into a JNI library.

Unfortunately I haven't started anything. If you do get something
you'd like to share, I'd be happy to try it out and contribute
patches.

> Arne
>