OpenVPN

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/03/11 21:01, Thor wrote:
> Hi,
> 
>  
> 
> Does the management interface output of BYTECOUNT support 64-bit counters?
> 
>  
> 
> If OpenVPN uses a 32-bit unsigned integer, this limit would be 4294967295,
> and I guess the counter would then be reset as I see no mention of the use
> of gigawords?
>

This will be fixed in OpenVPN 2.2.  The 2.2-RC is just around the corner of
a release, and that will be a good testing point.  If you're impatient,
there's not big differences between 2.2-RC and 2.2-beta5, so beta5 is also
fine for testing this.

You can see git commit 41104b4e23aaa17257cadb7f6c4ba1325c025b46 [1] for
more info about it.


kind regards,

David Sommerseth


[1]
<http://openvpn.git.sourceforge.net/git/gitweb.cgi?p=openvpn/openvpn-testing.git;a=commitdiff;h=41104b4e23aaa17257cadb7f6c4ba1325c025b46>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk1uvbgACgkQDC186MBRfrpOQACgiggLJDrj5G0jNS4GfsoRwWU2
UYEAn3NNhbQaK6+3rMh7XGWx9WRMLTLV
=b8kl
-----END PGP SIGNATURE-----

>I'm just wondering generally what is best-practice for handling
>employees leaving who know the CA certificate and password?

Generate client certs signed by our internal CA ,then add them to
a revocation list when they leave... What other way would you?
Are you using static certs and sharing them? If so, that kind of
defeats the whole concept. We even go a step further and use LDAP
auth to a group enabled for vpn access.

>Do you generate a new CA, run them both in parallel and transition all users

Uh, no.

>- that sounds like a lot of work?

On Fri, Feb 25, 2011 at 12:08 PM, Joseph L. Casale
<jcasale@...> wrote:
>>I'm just wondering generally what is best-practice for handling
>>employees leaving who know the CA certificate and password?
>
> Generate client certs signed by our internal CA ,then add them to
> a revocation list when they leave... What other way would you?
> Are you using static certs and sharing them? If so, that kind of
> defeats the whole concept. We even go a step further and use LDAP
> auth to a group enabled for vpn access.

Hi Joseph,

Not sure you understood the question and its probably because I
phrased it badly. How do you handle a system administrator leaving who
knows the CA certificate and password?

I know how to handle a normal employee leaving through the revocation
of a certificate but clearly in this case the SA could generate new
certificates.

We also use LDAP as an additional step I'm wondering do you require a
username/password or do you match the certificate in LDAP somehow? Any
pointers on how you do this?

Thanks

Joel

On Fri, 2011-02-25 at 11:30 +1100, Joel Heenan wrote:
> I'm just wondering generally what is best-practice for handling
> employees leaving who know the CA certificate and password? Do you
> generate a new CA, run them both in parallel and transition all users
> - that sounds like a lot of work? Can we somehow accept all
> certificates up till now from the old CA but no new ones generated?
> 
> We use LDAP to push out dynamic routes (enforced by firewall rules) to
> users based on their job role so I'm thinking that this could be
> extended to match in LDAP a MD5 sum of the generated certificate. But
> I thought before going down this path I'm sure this is a problem faced
> by others on this list so I would gather the collective wisdom of the
> list.
<snip>
I'm not entirely sure I understand the problem.  If all the leaving
employee knows is the CA private key password and has the CA cert,
that's not a problem.  The CA cert is supposed to be widely distributed
and it is possible to change the password on the CA key.  The only
problem is if the have a copy of the CA key.  If they have that, then
you are very seriously compromised.  Hope this helps - John

On Fri, Feb 25, 2011 at 12:22 PM, John A. Sullivan III
<jsullivan@...> wrote:
>
> I'm not entirely sure I understand the problem.  If all the leaving
> employee knows is the CA private key password and has the CA cert,
> that's not a problem.  The CA cert is supposed to be widely distributed
> and it is possible to change the password on the CA key.  The only
> problem is if the have a copy of the CA key.  If they have that, then
> you are very seriously compromised.  Hope this helps - John
>

Yes the leaving employee has :

-  CA certificate public key
-  CA private key
-  CA private key password

So we will be transitioning to a new CA probably using multiple CA's
for the time being perhaps with some mechanism using LDAP that matches
present keys.

Joel

On 02/25/2011 02:28 PM, Joel Heenan wrote:
>
> Yes the leaving employee has :
>
> -  CA certificate public key
> -  CA private key
> -  CA private key password
>
> So we will be transitioning to a new CA probably using multiple CA's
> for the time being perhaps with some mechanism using LDAP that matches
> present keys.
>

Yup - that's about it. You can't rely on CRLs either - so some "out of
band" method like hashes is probably a good idea. The CA private key is
the "family jewels" - so anyone who knows it could create any signed
certs they want and you wouldn't know.

Myself and one other have access to our corporate private key, and if
either of us leave, the company will basically be obliged (simple due
diligence - it should be done regardless of how trustworthy anyone is)
to create a new CA. That means migrating several thousand users and
servers.  Before anyone suggests it, changing the password has no effect
if the user has access to a backup of the old private key and
passphrase. This same problem hits disk/file encryption: if someone
knows the old passphrase and keyfile, they can theoretically decrypt the
data after a passphrase change - as changing passphrases doesn't
re-encrypt the data (i.e. decrypt and encrypt with new passphrase is the
workaround)

Not nice - no way around it other than to limit the number of people who
have access to the private key, to reduce how often you have to do this.


-- 

Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

LinkedIn
------------

   
I'd like to add you to my professional network on LinkedIn.

- Nikos

Nikos Zaharioudakis
Mr at Freelance Computer Services 
Greece

Confirm that you know Nikos Zaharioudakis
https://www.linkedin.com/e/-ywtkei-gkgkqiey-1q/isd/2375049195/DgKgDrCd/


 
-- 
(c) 2011, LinkedIn Corporation

On Monday 21 Feb 2011 16:19:30 Florian Philipp wrote:

> > this has little to do with OpenVPN itself , but more with bridging: when
> > two adapters are bridged (eth+tun, eth+tap, or even eth+eth) they form a
> > single broadcast domain: *ALL* traffic that arrives on one adapter is
> > copied out to the other adapter - this means that the OS is continuously
> > copying packets back and forth, even if the packets are not "destined"
> > for the other side. When I do this on a CentOS server with GigE adapters
> > the maximum throughput when copying a file to the server drops from 800
> > Mbps to 450 Mbps.
> 
> So, basically, it works like a virtual hub and not like a virtual
> switch, i.e. it sends everything everywhere and not just broadcast
> packets everywhere and unicast packets to its receiver. Do I understand
> this correctly?
> 
> In that case, just out of curiosity: Why can't it work like a
> self-learning switch? I mean, it is still ethernet specific and can
> therefore use ethernet specifics, right? Therefore it could in theory
> inspect the headers and act like a switch. So, why doesn't it?

It does indeed work like a switch (ie, learns which MAC addresses are on which 
port and forward frames only to those ports). But in the case of applications 
or protocols that make heavy use of broadcasts (eg windows networking without 
WINS, some online games and others), the traffic generated by broadcasts alone 
may be very high (and higher and higher as the number of locations/clients in 
the bridged VPN increases). In a routed VPN, broadcasts are absent.

Furthermore, another thing to consider is the overhead caused by the fact that 
each and every packet that the VPN carries is longer (due to the ethernet 
header). At 14 extra bytes per packet, as the traffic increases, the bandwidth 
is consumed more quickly.

-- 
D.

Am 21.02.2011 17:44, schrieb Davide Brini:
> On Monday 21 Feb 2011 16:19:30 Florian Philipp wrote:
> 
>>> this has little to do with OpenVPN itself , but more with bridging: when
>>> two adapters are bridged (eth+tun, eth+tap, or even eth+eth) they form a
>>> single broadcast domain: *ALL* traffic that arrives on one adapter is
>>> copied out to the other adapter - this means that the OS is continuously
>>> copying packets back and forth, even if the packets are not "destined"
>>> for the other side. When I do this on a CentOS server with GigE adapters
>>> the maximum throughput when copying a file to the server drops from 800
>>> Mbps to 450 Mbps.
>>
>> So, basically, it works like a virtual hub and not like a virtual
>> switch, i.e. it sends everything everywhere and not just broadcast
>> packets everywhere and unicast packets to its receiver. Do I understand
>> this correctly?
>>
>> In that case, just out of curiosity: Why can't it work like a
>> self-learning switch? I mean, it is still ethernet specific and can
>> therefore use ethernet specifics, right? Therefore it could in theory
>> inspect the headers and act like a switch. So, why doesn't it?
> 
> It does indeed work like a switch (ie, learns which MAC addresses are on which 
> port and forward frames only to those ports). But in the case of applications 
> or protocols that make heavy use of broadcasts (eg windows networking without 
> WINS, some online games and others), the traffic generated by broadcasts alone 
> may be very high (and higher and higher as the number of locations/clients in 
> the bridged VPN increases). In a routed VPN, broadcasts are absent.
> 
> Furthermore, another thing to consider is the overhead caused by the fact that 
> each and every packet that the VPN carries is longer (due to the ethernet 
> header). At 14 extra bytes per packet, as the traffic increases, the bandwidth 
> is consumed more quickly.
> 

Thanks for clarification!

Florian Philipp

On Sun, 20 Feb 2011 19:28:16 -0600
Les Mikesell <lesmikesell@...> wrote:

> On 2/20/11 6:54 PM, David M. Besonen wrote:
> >
> > when you wrote, "It is often possibile to achieve the same
> > effect without using bridging . . ." you do not mean that an
> > identical effect will be achievable, correct?  for example,
> > it won't be possible to browse windows network shares when
> > using routing as opposed to bridging, correct?
> 
> Windows networking work nicely over routed networks (vpn or
> otherwise).  You just have to configure a WINS server or put
> everything in DNS.

so are saying that you can browse windows shares on a remote
subnet that is routed via a vpn using a TUN adapter?

if your answer is yes then your experience seems to contradict
what i read in this comment in a forum thread i found:

"I think things could be a lot cleaner if you used TUN and kept
the two on separate subnets. You wouldn't be able to browse
Network Neighborhood to find the computers, but they could be
accessed by name or IP (eg, \\GFComputer\ or \\192.168.2.140\)."
--
from:  http://www.linksysinfo.org/forums/showpost.php?s=3bc34738cf868e7baaec4ace5399ee08&p=347676&postcount=2



thanks,
david

On 2/21/11 12:46 PM, David M. Besonen wrote:
> On Sun, 20 Feb 2011 19:28:16 -0600
> Les Mikesell<lesmikesell@...>  wrote:
>
>> On 2/20/11 6:54 PM, David M. Besonen wrote:
>>>
>>> when you wrote, "It is often possibile to achieve the same
>>> effect without using bridging . . ." you do not mean that an
>>> identical effect will be achievable, correct?  for example,
>>> it won't be possible to browse windows network shares when
>>> using routing as opposed to bridging, correct?
>>
>> Windows networking work nicely over routed networks (vpn or
>> otherwise).  You just have to configure a WINS server or put
>> everything in DNS.
>
> so are saying that you can browse windows shares on a remote
> subnet that is routed via a vpn using a TUN adapter?
>
> if your answer is yes then your experience seems to contradict
> what i read in this comment in a forum thread i found:

Yes, I can browse windows shares on routed networks whether they go through a 
vpn or not (there's nothing special about them as far as routing goes).

> "I think things could be a lot cleaner if you used TUN and kept
> the two on separate subnets. You wouldn't be able to browse
> Network Neighborhood to find the computers, but they could be
> accessed by name or IP (eg, \\GFComputer\ or \\192.168.2.140\)."

You must have a common WINS server configured for the set of machines that need 
to discover each other through windows name services.  But, I don't do much of 
that because it is extremely slow on a large network and in general if I don't 
know the name of the share I want, I probably don't have any business trying to 
connect to it.

-- 
   Les Mikesell
    lesmikesell@...

On 02/22/2011 07:46 AM, David M. Besonen wrote:
> if your answer is yes then your experience seems to contradict
> what i read in this comment in a forum thread i found:
>
> "I think things could be a lot cleaner if you used TUN and kept
> the two on separate subnets. You wouldn't be able to browse
> Network Neighborhood to find the computers, but they could be
> accessed by name or IP (eg, \\GFComputer\ or \\192.168.2.140\)."
> --
> from:  http://www.linksysinfo.org/forums/showpost.php?s=3bc34738cf868e7baaec4ace5399ee08&p=347676&postcount=2
..if you kept looking, you would have found many other posts that
contradict that :-)

e.g. do you really think corporate networks, spanning 40+ countries over
*hundreds* of WAN links, rely on bridging to get the job done? If you
are running an Active Directory network, then DNS will be all that is
needed to allow Windows machines to "see" remote Windows machines - even
if separated by a WAN (ie Layer3)

It just works. If it doesn't, then the Windows admins have a job to do -
this hasn't been fundamentally a network problem since Win2000, when Microsoft decided DNS wasn't so stooopid after all...

Jason

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

On Mon, 21 Feb 2011 13:38:46 -0600
Les Mikesell <lesmikesell@...> wrote:

> You must have a common WINS server configured for the set of
> machines that need to discover each other through windows name
> services.

i suppose a hosts file would work just as well as a WINS server
in allowing browsing of shared resources?

thank you to everyone who's replied to my questions.  it's
definitely helping me to understand.


thanks,
david

"Browsing" depends on having a "Browsmaster", and on the Browsmaster knowing
WHAT is connected.

One way to handle the "knowing WHAT is connected" is to have a WINS server.

Using a HOSTS file or DNS are other ways of handling "knowing WHERE
everything is", but they aren't Browsemasters, and they don't keep track of
WHAT is connected - only WHERE it will be if it is connected -- so they
don't help with "Browsing".

If you have a small isolated Windows network, on of the Workstations will
become "Browsemaster", and it will know WHAT is connected on it's small
network. Nothing will know WHAT is connected on the wide area network.

Your DHCP Server (OpenVPN) can tell each client as it connects who the WINS
server is for your login domain. The client who becomes Browsemaster will
get updates from the WINS server, and will know (after an update interval)
WHAT is connected to your WAN, and those hosts will become visiable when you
"Browse",

Additionally, The WINS server can tell each client who the Browsemaster is
for the login domain, so you only have one Browsemaster. That Browsemaster
will only inherently know about hosts on it's own isolated segment, but it
can find out from WINS about other segments.

Specifying that your Central Hub is browsemaster won't help with Browsing,
because your Central Hub will not see any of the hosts on the isolated
segements. You still need WINS.

Your "DNS Client" and "ARP Cache" on a Windows machine do track WHAT is
connected, but AFAIK, they don't help with "Browsing".

There are alternatives to "Browsing". You may have persistent shares, or "My
Network Places", published printers, or other Windows Explorer virtual
hosts. You can use Simple Network Management Protocol or Scheduled Tasks to
keep track of WHAT is currently connected. "Browsing" was a way of discovery
in "Network Neighbourhood". If you are using Domain Login or "Homegroup"
instead of (Windows 98) Workgroups, perhaps you don't actually need
"Browsing".

Do your users really need to know to see a list of which PC's are currently
turned on? If so, WINS and Browsing are two popular ways of making that
happen.

(david) 

-----Original Message-----
From: David M. Besonen [mailto:davidb@...] 
Sent: Tuesday, 22 February 2011 12:19 PM
To: openvpn-users ml
Cc: Les Mikesell
Subject: Re: [Openvpn-users] [dbes] bridging - efficiency and scaling

On Mon, 21 Feb 2011 13:38:46 -0600
Les Mikesell <lesmikesell@...> wrote:

> You must have a common WINS server configured for the set of machines 
> that need to discover each other through windows name services.

i suppose a hosts file would work just as well as a WINS server in allowing
browsing of shared resources?

thank you to everyone who's replied to my questions.  it's definitely
helping me to understand.


thanks,
david


----------------------------------------------------------------------------
--
Index, Search & Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights. 
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Openvpn-users mailing list
Openvpn-users@...
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Hi to all,

>From today, on a normally working VPN, i have this problem into the log file:

 MBUF: mbuf packet dropped

After a lot of them, the connection was dropped. Here is my config file:

#device
dev tap0

#mode
mode server

proto tcp-server
port 19022

tls-server

# ping restart in caso di connessione down
ping 15
ping-restart 30

server-bridge 10.10.100.1 255.255.0.0 10.10.100.2 10.10.100.254

max-clients 100
tun-mtu 1500
mssfix 1400

client-config-dir /etc/openvpn/ccd
persist-key
persist-tun
ccd-exclusive
tcp-queue-limit 4096

#log files
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log

# user separation
user nobody
group nogroup

# cert and keys file
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
cipher AES-256-CBC

verb 4

Note: the parameter tcp-queue-limit is already increased from 256 to
4096, but nothing changed.

What can i do?

Cordially,

Claudio Prono.


-- 
--------------------------------------------------------------------------------
Claudio Prono                         OPST
System Developer               
                                      Gsm: +39-349-54.33.258
@PSS Srl                              Tel: +39-011-32.72.100
Via San Bernardino, 17                Fax: +39-011-32.46.497
10141 Torino - ITALY                  http://atpss.net/disclaimer
--------------------------------------------------------------------------------
PGP Key - http://keys.atpss.net/c_prono.asc

Hi Claudio,

Claudio Prono wrote:
> Hi to all,
>
> >From today, on a normally working VPN, i have this problem into the log
> file:
>
>  MBUF: mbuf packet dropped
>
>   
Nice error! I had to read the source code to find out what is going 
on... Try adding the option

  bcast-buffers = 4096

to the server config (and perhaps also the client config) . If I read 
the sources correctly this should alleviate your problem.
(If it works I want to try and figure out *why* it works :))


HTH,

JJK


> After a lot of them, the connection was dropped. Here is my config file:
>
> #device
> dev tap0
>
> #mode
> mode server
>
> proto tcp-server
> port 19022
>
> tls-server
>
> # ping restart in caso di connessione down
> ping 15
> ping-restart 30
>
> server-bridge 10.10.100.1 255.255.0.0 10.10.100.2 10.10.100.254
>
> max-clients 100
> tun-mtu 1500
> mssfix 1400
>
> client-config-dir /etc/openvpn/ccd
> persist-key
> persist-tun
> ccd-exclusive
> tcp-queue-limit 4096
>
> #log files
> status /var/log/openvpn-status.log
> log-append /var/log/openvpn.log
>
> # user separation
> user nobody
> group nogroup
>
> # cert and keys file
> ca /etc/openvpn/easy-rsa/keys/ca.crt
> cert /etc/openvpn/easy-rsa/keys/server.crt
> key /etc/openvpn/easy-rsa/keys/server.key
> dh /etc/openvpn/easy-rsa/keys/dh1024.pem
> crl-verify /etc/openvpn/easy-rsa/keys/crl.pem
> cipher AES-256-CBC
>
> verb 4
>
> Note: the parameter tcp-queue-limit is already increased from 256 to
> 4096, but nothing changed.
>
> What can i do?
>
> Cordially,
>
> Claudio Prono.
>
>
>
>

Il 21/02/2011 15.06, Jan Just Keijser ha scritto:
> Hi Claudio,
>
> Claudio Prono wrote:
>> Hi to all,
>>
>> >From today, on a normally working VPN, i have this problem into the log
>> file:
>>
>>  MBUF: mbuf packet dropped
>>
>>   
> Nice error! I had to read the source code to find out what is going
> on... Try adding the option
>
>  bcast-buffers = 4096
>
> to the server config (and perhaps also the client config) . If I read
> the sources correctly this should alleviate your problem.
> (If it works I want to try and figure out *why* it works :))
>
>
> HTH,
>
> JJK
> --

Well, the problem is not solved at all. But i think can be a problem of
connection (packet loss and poor upload bandwidth). Now we have called
the internet provider, for a quality check on the service... At this
point i don't think is a problem of OpenVPN at all......

When i have news i say to you... For now, tnx!

Cordially,

Claudio Prono.

--------------------------------------------------------------------------------
Claudio Prono                         OPST
System Developer               
                                      Gsm: +39-349-54.33.258
@PSS Srl                              Tel: +39-011-32.72.100
Via San Bernardino, 17                Fax: +39-011-32.46.497
10141 Torino - ITALY                  http://atpss.net/disclaimer
--------------------------------------------------------------------------------
PGP Key - http://keys.atpss.net/c_prono.asc