gmane.network.openvpn.user

OpenVPN ethernet bridging

Otto Julio — 2012-05-24T00:32:54

Hi,

I have created 4 virtual machines (VMs) for purpose of testing OpenVPN
instalation and configuration before to implant it. These VMs are M1,
M2, M3, M4.
For installation of OpenVPN, I have followed this tutorial:
http://openvpn.net/index.php/open-source/documentation/howto.html. The
openvpn was installed on M2 (server) and M3 (client) and aparently is
working fine, but I'm not capable of execute ping command between VMs
that are in tunnel different sides.

Objective: provide comunication between M1 and M4.

The interfaces address of VMs are:

              eth0                   eth1
M1 - 192.168.1.2
M2 - 192,168.2.1   |   192.168.1.1
M3 - 192.168.2.2   |   192.168.1.11
M4 - 192.168.1.12

This is how VMs interfaces are connected:
M1 (eth0) <---> (eth1) M2 (eth0) <---> (eth0) M3 (eth1) <---> (eth0) M4.

When I ping M1 from M4, the arp request is delivered to M1 and the
response is generated by M1 on eth0. But the "tcpdump -ni eth1"
command on M2 don't show arp replies, show only the

Re: bufferbloat in the tunnel

Jason Haar — 2012-05-23T22:44:01

FWIW iperf doesn't send random data - it's sends the ASCII sequence over
and over again. i.e. it is "compressible" depending on what lies
between. We have Riverbeds here and I was amazed how our 10Mbs WAN links
suddenly jumped to 1Gbs according to iperf! Ended up the Riverbeds were
able to do a lot of smoke-n-mirrors with iperf traffic

You can run iperf as "iperf -c ser.ver.name -F /tmp/big.zip.file" so
that it is actually sending (effectively) random data - in order to
remove some of the potential tricks that could lie between your client
and server.

Also, "iperf -c ser.ver.name -P 4" is a good way of measuring BANDWIDTH
instead of THROUGHPUT - which a standard single-channel TCP stream measures

I love iperf :-)

Help with bridging setup

2012-05-23T16:31:21

Greetings All,

I'm having some trouble with bridging I can't quite figure out.  Here's
the scenario:

3 hosts, all Linux.  "Host 1" is the OpenVPN server.  It has a working
connection to "Host 2", which connects as a client.  This connection is a
normal routed ip connection.  "Host 3" is the host I wish to add to the
configuration.

Details:  "Host 2" has one public interface and two private interfaces. 
One of these private interfaces has it's subnet joined by routing to the
private subnet of "Host 1" via OpenVPN across the public interfaces.  This
works great.  "Host 2" also has another private interface, connected to a
switch with a bunch of WAPs on it.  This interface has no IP.  "Host 3"
has one public interface and one private interface.  It's private
interface is the gateway for a bunch of WAPs on one subnet.

The Goal: I'd like to connect the unnumbered interface on "Host 2" and
it's associated physical network to the private interface of "Host 3" via
a bridged connection over OpenVPN.  I have addit

Re: bufferbloat in the tunnel

Brian J. Murrell — 2012-05-23T12:26:46

That's exactly the mantra of the bufferbloat folks.  There is no one
right solution adjusting the fixed length of the queue since it's a
product of the bandwidth of what's upstream of the queue.

This is where codel comes in.  It's not clear however what codel will do
when stacked up against another codel (i.e. on the egress interface of
the machine openvpn is running on).

b.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Openvpn-users mailing list
Openvpn-users< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: bufferbloat in the tunnel

David Sommerseth — 2012-05-23T10:52:11

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

On 23/05/12 05:43, 규태 안 wrote:

Yeah, that's a good point.  But I would say that you need also
real-life testing as well - in this case over the internet.  You need
lab-testing to see how things behave and change - to prepare
hypothesis for real-life testing.  When you have these hypothesis, you
try them in a real-life environment to see if your hypothesis was correct.

So I would say just lab testing or just real-life testing is not
giving the complete picture of what really happens.


kind regards,

David Sommerseth



Live Security Virtual Conference
Live Security Virtual Conference

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

iEYEARECAAYFAk+8wVQACgkQDC186MBRfrqBTgCcD+zen2jPDVOUXe2NNVIKy89V
1FwAoJt6ueIV0s8i/gukfoSbAjXcSzmW
=yXRC
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Live Security Virtual Conference
E

Re: bufferbloat in the tunnel

Ralf Hildebrandt — 2012-05-23T08:41:24

Care to elaborate on the "if you do it right" bit? I'd be interested
on what one can to to optimize this :)

Re: bufferbloat in the tunnel

Jan Just Keijser — 2012-05-23T08:28:41

Hi,

Brian J. Murrell wrote:
this is my home ADSL line : the provider states it's a 1 Mbps connection 
but in practice you'll get ~ 900 kbps (if you do it right). I'm not 
doing any traffic shaping here. The difference in connection rate comes 
from ATM vs TCP/IP throughput: the DSL packets arrive at a 1 Mbps rate, 
but after subtracting the overhead you end up with ~ 900 kbps
that's what I did; iperf does not use any congestion management 
internally, it simply sends random traffic as fast as possible.

sending blocks of zeroes is actually tricky - it will affect both 
compression and encryption routines.
I ran your test as well on my home network (i.e. run 'dd ...' and ping 
the VPN server IP at the same time) . The results are nearly identical:

- ping time jumps from 24 ms (no 'dd') to ~ 63 ms (it was 72 ms with 
iperf running)
- txqueuelen does not effect things at all, but it does increase the 
likelihood of getting packet loss

In short, I think it's very interesting to read that for some setups the

Re: bufferbloat in the tunnel

규태 안 — 2012-05-23T03:43:01

Testing this over an internet may not a good idea as what sits between the two endpoints is a black box.

Cheers,
Dan.

On May 22, 2012, at 4:53 PM, David Sommerseth wrote:


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Openvpn-users mailing list
Openvpn-users< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: bufferbloat in the tunnel

David Sommerseth — 2012-05-22T07:53:01

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

On 21/05/12 18:07, Brian J. Murrell wrote:
[...snip...]

Beware that if ssh does compression, this will not saturate the link
that much.  It's far better to 'dd' a CD or DVD ISO image instead,
which provides more "random" data which is not that easily compressed.

Otherwise, for a much better saturation and measurement of the
performance, it's better to use iperf or other dedicated network
performance testers; just as JJK already mentioned.


kind regards,

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

iEYEARECAAYFAk+7RdsACgkQDC186MBRfrpQmgCdES14M09GYSu9J4TOkJ0pWxIw
3cUAnjNOXg2TuW2WwFMcTTkI3qR9b3Y8
=tky+
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can re

Re: bufferbloat in the tunnel

Brian J. Murrell — 2012-05-21T16:07:53

Hi,


Simply did an "dd" through ssh to a remote machine.


Given that you only got 900kbps from a 1Mbps and ping times were
relatively good, sounds like you are already shaping your upstream link
to make sure that the buffering occurs where you can control it rather
than buffering upstream.


So to be clear, you were pinging a machine on the remote side of the VPN
while you were saturating the uplink inside your VPN?  I'm not familiar
with iperf so I can't really confirm whether you were or not.  Maybe
iperf does some kind of congestion management itself, I don't know.

Personally, I find it so much easier to just do

$ dd if=/dev/zero bs=1M" | ssh $machine_on_remote_side_of_vpn "cat

to do the saturation.  It's just so easy to understand.

b.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include

Re: bufferbloat in the tunnel

Brian J. Murrell — 2012-05-21T16:14:15

It doesn't just hurt interactive performance.  Interactive performance
is a great way to experience the phenomenon, but these excessively large
queues are also mucking with TCP's congestion control because TCP
requires _timely_ notification of link saturation, typically by way of
noticing packets being dropped.  But if you have a long queue, it may
take several (10s even, of) seconds to notice the dropping.


More typically upload since the "fast to slow" for most people is in the
upload direction.


Indeed.  Nobody is arguing that buffers are needed to maximize
performance and the bigger the buffer, the better performance will be.
But only to a point where you are achieving maximum performance and
adding more buffers will not increase performance.  If you continue to
add more buffers all you are doing is increasing the amount of time it
takes to get a byte out of the system and get it's response back.  This
is the bloated buffer increasing latencies with no benefit.

b.



---------------------------------

Re: bufferbloat in the tunnel

Bonno Bloksma — 2012-05-21T08:12:42

Hi,

[....]
[....]

So far I understand what you are saying but....


Here is where I use the TC command to make sure interactive traffic gets moved to the front of the queue. At least that is what it does as far as I know, I only use a default script I got years ago from the net somewhere and it seems to do the job. Our VoIP traffic seems to flow without too many problems when something saturates our links.

Bonno Bloksma


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: bufferbloat in the tunnel

Samuli Seppänen — 2012-05-21T07:56:05

Il 21.05.2012 09:48, Jan Just Keijser ha scritto:
For those who are unfamiliar with the buffer bloat phenomenom, this
podcast is a good listen:

<http://media.grc.com/sn/sn-345.mp3>

There's also a transcript here (search for buffer bloat):

<http://www.grc.com/securitynow.htm>

Then there's the website Brian mentioned already:

<http://www.bufferbloat.net/projects/bloat/wiki/>

This is how I've understood the phenomenom: big buffers hurt interactive
performance when a router is transfering packet between a slow network
and a fast network, and there's also bandwith-intensive operation going
on (e.g. large download). This is because interactive packets always end
up at the end of the (long) queue filled with non-interactive packets...
and the router does not start dropping packets until the buffer is full.

Re: bufferbloat in the tunnel

Jan Just Keijser — 2012-05-21T06:48:45

Hi Brian,

Brian J. Murrell wrote:
interesting idea but I don't understand exactly how you "saturated your 
uplink".
Here's what I did to try and reproduce :
- testing ping time without an openvpn tunnel, no load on my 1 Mbps 
uplink : 24 ms
- testing ping time without an openvpn tunnel, while 'iperf' was 
running: 50 ms (iperf: 900 kbps)

Started a very basic OpenVPN session without any txqueuelen settings
- testing ping time of the VPN server IP, no load on my 1 Mbps uplink : 
24 ms
- testing ping time of the VPN server IP, while 'iperf' was running: 75 
ms (iperf: 840 kbps)
No packet loss, but yes there is a performance impact.

Next, start an openvpn session with '--txqueuelen 10' added on both ends:
- testing ping time of the VPN server IP, no load on my 1 Mbps uplink : 
24 ms
- testing ping time of the VPN server IP, while 'iperf' was running: 75 
ms (iperf: 850 kbps)
HOWEVER, I did see 10% packet loss with these settings!

Performance of the 'iperf' on the uplink was slightly higher with a 
lower txqu

Re: update openssl

Jan Just Keijser — 2012-05-21T06:35:15

Hi Bonno,

Bonno Bloksma wrote:
you should restart openvpn to ensure that it picks up the new openssl 
libs ; an openssl update cannot trigger this restart, as it does not 
know (or care) whether openvpn is installed.

HTH,

JJK




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

update openssl

Bonno Bloksma — 2012-05-21T06:09:58

Hi,

I was wondering, after an openssl update like we had this weekend.....
If I just do apt-get update ; apt-get upgrade on a Debian machine will OpenVPN automatically use the new openssl or do I need to restart something?

I do not see any restart as being part of the upgrade process:
[....]
Unpacking replacement openssl ...
Processing triggers for man-db ...
Setting up libssl0.9.8 (0.9.8o-4squeeze13) ...
Setting up openssl (0.9.8o-4squeeze13) ...
root< at >lola2:~#

 
Bonno Bloksma
senior systeembeheerder

tio
university of applied sciences


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: bufferbloat in the tunnel

Jan Just Keijser — 2012-05-18T07:49:08

on Linux it can be configured using
  --txqueuelen N
I'm not sure if there is an equivalent for the windows tap-win32 driver.

On a heavily loaded server you *DO* need to increase the txqueuelen, as 
otherwise you'll run the risk of getting dropped packets.
I'm curious what the exact setup was for the test: was the txqueuelen 
lowered on the client side only? how was the link saturated? is it a udp 
or tcp based setup etc etc.

HTH,

JJK


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Re: bufferbloat in the tunnel

Ralf Hildebrandt — 2012-05-18T07:22:04

Can this buffer size be configured or is it hard coded?

bufferbloat in the tunnel

Brian J. Murrell — 2012-05-17T12:34:11

Hello,

I'm not sure if you folks have been, but I have been following the
progress on the great work being done over at www.bufferbloat.net to
find and eliminate bloated buffers that are the cause of huge latencies
with no benefit.

I followed Jim Gettys' advise on how to ensure you can control the
buffers at the bottleneck by making sure that queuing is happening on
your own gear using traffic shaping.  Well, to be honest, I have been
doing that for a lot longer than www.bufferbloat.net has been on the
case but it just happens to be one of their mitigating solutions (absent
codel).

Gettys also has some interesting experiments that one can do with an
interface's txqueuelen to demonstrate just how small a queue one really
can use on slow (read: Internet) links and still keep the pipe full and
since of course, the longer the queue, the higher the latency we want
that queue to be only as long as is needed to keep the pipe full.

Where this gets interesting and relevant to OpenVPN is that OpenVPN
configures a

Re: Need to set an environment variable in openvpn for debuggung

Alon Bar-Lev — 2012-05-15T17:34:19

Hello,

On Tue, May 15, 2012 at 11:45 AM, Ralf Hildebrandt
<Ralf.Hildebrandt< at >charite.de> wrote:

I don't think that environment is unset for plugins, I see all at
/proc/PID/environ.
For scripts there is --setenv XXX YYYY configuration.

Alon.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Openvpn-users mailing list
Openvpn-users< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: Need to set an environment variable in openvpn for debuggung

Ralf Hildebrandt — 2012-05-15T08:45:15

* Alon Bar-Lev <alon.barlev< at >gmail.com>:

Server side. We're using libpam-krb5 and recent versions of the
plugin/krb5 libs cannot authenticate anymore.