Re: [Openvpn-devel] Status of the VLAN patches review?

[michael-dev]

Hi,

any news on the VLAN feature?

Regards,
M. Braun

Am 11.08.2016 22:10, schrieb Mike Auty:

Hi there,

I was hoping to find out if there'd been any progress on getting the
VLAN patches reviewed?  Thanks,

Mike  5:)

[1] https://sourceforge.net/p/openvpn/mailman/message/3496/
[2] https://github.com/ikelos/openvpn

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and 
traffic
patterns at an interface-level. Reveals which users, apps, and 
protocols are
consuming the most bandwidth. Provides multi-vendor support for 
NetFlow,

J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] ECDH support

[michael-dev]

Hi,

thanks for writing the patch.

I'd like to propose to add a comment to the readme regarding the use of
ECDH instead of DH without using an EC certificate, because that
currently is not mentioned in it.

Thanks,
 M. Braun

Am 19.02.2014 14:21, schrieb pietrek --:
> On 02/18/14 12:50, Gert Doering wrote:
>> Hi,
>>
>> On Tue, Feb 18, 2014 at 12:15:16PM +0100, pietrek -- wrote:
 Which parts of the key handshake does it cover? 
 Signature/Certificates,
 or *only* DH?
>>> Handshake only, EC certificates worked for me without doing anything.
>>> Also, DH didn't work with EC certificates( no such cipher ).
>> I see.
>>
>> Seems what we need as well is a README file that explains about EC
>> crypto,
>> as in
>>
>>   - how do I generate and use an EC certificate?
>>   - how do I use an EC curve for DH?
>>   - how do I use EC for session keying?
>>
>> because otherwise our users will be even more confused than I am.
>>
>> gert
>>
> Hi,
> I added README.ec to my patch
>Piotr Jarosz
> 
> 
> 
> --
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471=/4140/ostg.clktrk
> 
> 
> 
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 

Re: [Openvpn-devel] [PATCH 4/6] build: msvc: upgrade to Visual Studio 2010 + fixups

[michael-dev]

Hi,

On Thu, 29 Mar 2012 18:10:24 +0200, Alon Bar-Lev wrote:

For example...

at your end:
---
./configure
make
make dist
---

at other people end:
---
tar -xf 
cp -a openvpn* openvpn*.org
cd openvpn*
msvc-dev



cd ..
diff -urNp openvp* openvpn*.org
---

will result in a complete change of all microsoft specific files
because of the new line issue.
is this enough problem?


so why don't use --strip-trailing-cr (diffutils) or something similar 
to avoid this?


So as long as msvc-dev does accept eol=lf input files, storing them as 
eol=lf files is without issue?


Regards,
 M. Braun
--
[1] http://stackoverflow.com/questions/1889559/git-diff-to-ignore-m

Re: [Openvpn-devel] OpenVPN Management Interface

[michael-dev]

Hi,

On Wed, 07 Mar 2012 09:00:04 +1300, Jason Haar wrote:

Your comments on rogue servers is certainly worth discussing too.
What can a rogue openvpn server push back to a client? Routes 
obviously - but

other than screwing the client, is there any new risk?


if you expect the server to be rouge, openvpn client has to be careful 
with input data validation - for example when running an ifconfig, you 
could try some injection into the run commands. (Or within the up/down 
scripts.)
If you don't expect the server to be rouge, SSL on client side would 
prevent most attacks.


As far as I can see, push/pull is already limited for security reasons.

Regards,
 M. Braun

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

[michael-dev]

Hi,

just to give you feedback that your thread is actually followed.
I believe the different types of configuration are good and correct and 
that a good threat analysis is a basic step to proper security, though I 
cannot say much about the isolation tricks on Windows. The important 
think is, as far as I get it, that the network component only changes 
the routes in a trusted way - otherways, there would be no difference in 
either doing this directly or by instrumenting the network component.


Regards,
 M. Braun

On Wed, 29 Feb 2012 20:52:15 +0200, Alon Bar-Lev wrote:

Hello,

Following recent discussion on Windows platform, I open a new thread.
I don't think this topic is Windows specific as the security
principals are the same.

VPN client product has [at least] two different type of 
configuration.


1. Standalone configuration.

2. Enterprise configuration.

The main difference of these types is who control the workstation. In
standalone configuration the workstation is controlled by the
end-user, and in enterprise configuration the enterprise 
administrator

controlling the workstation.

These two configurations have different purpose as well, the
standalone configuration usually protects the workstation against the
remote network, and the enterprise configuration usually protects the
remote network against the workstation.

The "enemy" of the two configurations is also different, in 
standalone

configuration the "enemy" is the remote network administrator, while
in the enterprise configuration the "enemy" is the local workstation
user.

The "scripts" in the standalone configuration or for the sake of the
user, but within the enterprise solution it usually need to scan the
computer, disconnect device and other privileged operations.

There is no single solution for both configurations.

Please read till the end before responding.

Provided we have the following components:
1. tap device aka tap - a virtual Ethernet interface.
2. openvpn - a tunneling implementation.
3. openvpn configuration - configuration files.
3. network utilities aka utils - a set of utilities to manipulate
workstation network settings.
4. user interaction aka UI - a program that manages user interaction.

What is the security attribute for each component in each 
configuration?


Standalone configuration
1. tap - accessed by interactive user.
2. openvpn - runs by the interactive user.
3. openvpn configuration - read/write by interactive user.
4. network utilities - privileged user required.
5. UI - runs by interactive user.

Enterprise configuration
1. tap - access by openvpn user.
2. openvpn - runs by openvpn user.
3. openvpn configuration - read by openvpn, read/write by 
administrator.

4. network utilities - privileged user required.
5. UI - runs by interactive user.

Major missing openvpn functionality:
Specify certificate via the management UI - this feature is required
so that a configuration in which openvpn knows nothing of
authentication can be established.

A while back I added to openvpn the ability to create tun/tap device
with custom permissions
and the ability to wrap ip utility with custom utility.
As for now I am using the standalone Linux configuration[1], in few 
words:

1. tap is configured so interactive user may access it.
2. openvpn is run by the interactive user.
3. openvpn configuration and keys are located at ~/openvpn
4. network utilities - (ip utility and DNS update) are wrapped within
sudo scripts.
5. UI is run by the interactive user.

The network utilities' wrapper can do validation before actually
executing the commands.

There is no reason why we cannot achieve the same in Windows:
1. tap - configure ACL of TAP to specific permissions (Users for 
example).

2. openvpn - runs by the interactive user, it will have permission to
open the tap.
3. openvpn configuration - read/write by interactive user.
4. network utilities are accessed by wrapper (I will discuss this 
bellow).

5. UI is run by the interactive user.

So the network utilities are the only component that needs privilege
escalation in this configuration.

Let's take the enterprise configuration:
1. tap - configure ACL of TAP to openvpn user.
2. openvpn - runs by openvpn user.
3. openvpn configuration - read by openvpn, read/write by 
administrator.
4. network utilities are accessed by wrapper (I will discuss this 
bellow).

5. UI runs by the interactive user.

So in this case, network utilities needs privilege escalation, but
also the ability of the UI to start/stop the tunnel requires special
privilege.

I gave an example of how this is done in Linux... Now, what is the
simplest solution to do the same in Windows?

There was a suggestion to use named pipes, services and 
impersonation,

I would like to discuss another option.

Windows Component Services provide the ability to create a component
that may be run in separate security context. It already implements
the process management and security isolation.

Let's define two 

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

[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

[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] [PATCH] Add option to disable priority tagged packets (VID=0)

[michael-dev]

Hi,

the usage here is with the FeM e.V. [1] WLAN project in order to reuse 
the existing vlans and ip assignments on them.


And Michael, would you be willing to review and test the full, 
rebased patch-set [...]?


Testing should be no problem. I currently use a gentoo ebuild that 
points to the git feature branch + patches
so that part should be easy. Further, the openvpn server here is 
currently testing only (until the wlan gets ready)
so I'm free to break it again ;). But I might need some time to put it 
into the schedule.


Regards,
 M. Braun
--
[1] http://www.fem.tu-ilmenau.de/

[Openvpn-devel] [PATCH] Add option to disable priority tagged packets (VID=0)

[michael-dev]

This patch adds an option to disable the creation of tagged priority 
packets

with VID=0. This is for the feature_vlan_tagging openvpn-testing head.

I tested the vlan feature and it works fine for me (no dhcp tested).
Therefore I bridged my eth0 (LAN) and tap0 (OpenVPN) but as my switch
flags arp replys with priority, the client ended up with 802.1q tagged
(VID=0) priority packets. These were not expected on the client (Ubuntu 
10.04 lts)
and I found a linux kernel discussion from summer 2010 about supporting 
VID=0
priority packets, so I expect more linux clients (windows untested) to 
not support

this kind of packets.
This option prevents the creating of these packets by ignoring the 
priority information.


This patch has already been tested and works fine for me.

Signed-off-by: Michael Braun 


---
 multi.c   |2 +-
 options.c |9 +
 options.h |1 +
 3 files changed, 11 insertions(+), 1 deletions(-)

diff --git a/multi.c b/multi.c
index b77791a..d09fa68 100644
--- a/multi.c
+++ b/multi.c
@@ -2246,7 +2246,7 @@ remove_vlan_tag (const struct context *c, struct buffer *buf)
   return c->options.vlan_pvid;
 }
 
-  if (pcp == 0)
+  if (pcp == 0 || c->options.vlan_disable_priority)
 {
   /* VLAN-tagged without priority information. */
 
diff --git a/options.c b/options.c
index 827b9f0..fe0eac6 100644
--- a/options.c
+++ b/options.c
@@ -763,6 +763,7 @@ init_options (struct options *o, const bool init_gc)
 #ifdef ENABLE_VLAN_TAGGING
   o->vlan_accept = VAF_ALL;
   o->vlan_pvid = 1;
+  o->vlan_disable_priority = false;
 #endif
 }
 
@@ -1037,6 +1038,7 @@ show_p2mp_parms (const struct options *o)
   SHOW_BOOL (vlan_tagging);
   msg (D_SHOW_PARMS, "  vlan_accept = %s", print_vlan_accept (o->vlan_accept));
   SHOW_INT (vlan_pvid);
+  SHOW_BOOL (vlan_disable_priority);
 #endif
 #endif /* P2MP_SERVER */
 
@@ -1783,6 +1785,8 @@ options_postprocess_verify_ce (const struct options *options, const struct conne
 	msg (M_USAGE, "--vlan-accept requires --vlan-tagging");
 	  if (options->vlan_pvid != defaults.vlan_pvid)
 	msg (M_USAGE, "--vlan-pvid requires --vlan-tagging");
+	  if (options->vlan_disable_priority != defaults.vlan_disable_priority)
+	msg (M_USAGE, "--vlan_disable_priority requires --vlan-tagging");
 	}
 #endif
 }
@@ -5782,6 +5786,11 @@ add_option (struct options *options,
   VERIFY_PERMISSION (OPT_P_GENERAL);
   options->vlan_tagging = true;
 }
+  else if (streq (p[0], "vlan-disable-priority"))
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->vlan_disable_priority = true;
+}
   else if (streq (p[0], "vlan-accept") && p[1])
 {
   VERIFY_PERMISSION (OPT_P_GENERAL);
diff --git a/options.h b/options.h
index a278561..5444e37 100644
--- a/options.h
+++ b/options.h
@@ -523,6 +523,7 @@ struct options
   bool vlan_tagging;
   enum vlan_acceptable_frames vlan_accept;
   uint16_t vlan_pvid;
+  bool vlan_disable_priority;
 #endif
 };
 
-- 
1.7.3.4