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 arp requests.

P.S. There is no firewall blocking traffic and the forwarding was activated.

Below I posted both M2 and M3 configuration.


***M2 configuration (OpenVPN server):

IFCONFIG
# ifconfig
br0       Link encap:Ethernet  HWaddr 08:00:27:6a:88:08
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe6a:8808/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5668 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1552 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:306299 (306.2 KB)  TX bytes:164663 (164.6 KB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:9f:ec:2b
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe9f:ec2b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4523 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1298 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:638103 (638.1 KB)  TX bytes:166373 (166.3 KB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:6a:88:08
          inet6 addr: fe80::a00:27ff:fe6a:8808/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:1879 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:154502 (154.5 KB)  TX bytes:420042 (420.0 KB)

tap0      Link encap:Ethernet  HWaddr f2:30:ff:33:b6:a8
          inet6 addr: fe80::f030:ffff:fe33:b6a8/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4014 errors:0 dropped:0 overruns:0 frame:0
          TX packets:454 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:258604 (258.6 KB)  TX bytes:53738 (53.7 KB)


BRCTL
# brctl show
bridge name    bridge id                       STP enabled   interfaces
br0                   8000.0800276a8808   no                    eth1

             tap0

OPENVPN.CONF
port 1194
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.1.1 255.255.255.0 192.168.1.11 192.168.1.11
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3




***M2 configuration (OpenVPN client):
IFCONFIG
# ifconfig
br0       Link encap:Ethernet  HWaddr 08:00:27:9e:6c:db
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe9e:6cdb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4410 errors:0 dropped:0 overruns:0 frame:0
          TX packets:187 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:220153 (220.1 KB)  TX bytes:19659 (19.6 KB)

eth0      Link encap:Ethernet  HWaddr 08:00:27:40:24:b0
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe40:24b0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1354 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5056 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:172542 (172.5 KB)  TX bytes:706873 (706.8 KB)

eth1      Link encap:Ethernet  HWaddr 08:00:27:9e:6c:db
          inet6 addr: fe80::a00:27ff:fe9e:6cdb/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:4478 errors:0 dropped:0 overruns:0 frame:0
          TX packets:435 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:277071 (277.0 KB)  TX bytes:57606 (57.6 KB)

tap0      Link encap:Ethernet  HWaddr 52:d5:c9:46:30:c5
          inet6 addr: fe80::50d5:c9ff:fe46:30c5/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:493 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4512 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:56269 (56.2 KB)  TX bytes:288594 (288.5 KB)


BRCTL
# brctl show
bridge name   bridge id                       STP enabled    interfaces
br0                  8000.0800279e6cdb    no                    eth1

             tap0

OPENVPN.CONF
client
dev tap0
proto udp
remote 192.168.2.1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/client1.crt
key /etc/openvpn/keys/client1.key
ns-cert-type server
comp-lzo
verb 3



Thanks for any help,
Otto Julio.

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

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 additional interfaces available
on "Host 3" if needed.

I've read through the howtos, and came up with the following config for
"Host 3":

-----8<----- /etc/openvpn/common.conf
secret /etc/openvpn/static.key
float
ping 10
verb 5
comp-lzo
persist-tun
persist-remote-ip
persist-key
-----8<----- /etc/openvpn/opentuns.sh
#!/bin/bash

/usr/sbin/brctl addbr br0
/usr/sbin/brctl addif br0 eth1

TAPS="public host2"

for name in $TAPS
do
    openvpn --mktun --dev tap$name
    brctl addif br0 tap$name
done

ifconfig eth2 0.0.0.0 promisc up

for name in $TAPS
do
    ifconfig tap$name 0.0.0.0 promisc up
done

ifconfig br0 privateip netmask 255.255.255.0 broadcast privatebc

exit 0
-----8<-----
#!/bin/bash

/etc/openvpn/opentuns.sh

VPN="openvpn --config /etc/openvpn/common.conf"

$VPN --dev tappublic --port 1194 --daemon tappublic
$VPN --dev taphost2 --port 4444 --daemon taphost2

exit 0
-----8<-----

In this case, on Host 3, eth0 is the public if, eth1 is the private.

On Host 2, I've got:
-----8<----- bridge.conf
dev tap0

remote host3pubip
port 4444

user openvpn
group openvpn

secret /etc/openvpn/static.key

ping 10
verb 5
comp-lzo

mute 10
-----8<-----

...and another working config for the routed ip part.

This tunnel comes up, or at least, connects and doesn't throw any error
messages, but the bridging isn't working.

Any ideas, input, etc. would be greatly appreciated!

Thanks,

-John



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

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

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 
txqueuelen has an impact, BUT it does not have any effect on my home 
network connection.  It does tend to increase packet loss over the VPN 
connection, however. To me, this proves that it is VERY tricky to 
optimize a (VPN) network connection and that there simply is no 'one 
size fits all solution' : modifying the (Linux only) txqueuelen 
certainly does not help me.

cheers,

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

규태 안 — 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 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

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

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.

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

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 txqueuelen value but for me this is not enough compared to a 10% 
packet loss.

How did you do your tests?

cheers,

JJ "The OpenVPN speed guy" K


------------------------------------------------------------------------------
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: 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 default queue of 100 packets. That's 100 packets of
buffering on top of the buffering that will be done at the egress
interface. I have not tested that 100 packet queue length with Ethernet
(10/100/1000Mb/s) speeds but that 100 packets is far, far too high for
consumer grade internet connections (i.e. 512Kb/s-1Mb/s uplink) and was
resulting in huge latencies inside my VPN while latencies outside the
VPN (i.e. across the same Internet) link where being managed very well.

Anyway, for the tests and data:

I proved my shaping was working by pinging the router across my "last
mile" connection to the internet and then saturated my uplink and could
maintain a sub-30ms ping time, proving that I was indeed managing the
bottleneck queues.

I then moved the ping into the VPN and saturated the uplink inside the
VPN and was observing ping times on the order of 2000-3000ms or higher.
I then tried reducing the txqueuelen on the tun0 interface in steps
down from 100 to 50 to 10 to 5 and eventually got down to a value of 1
on an uplink of 512Kb/s while maintaining full upstream bandwidth. At a
txqueuelen of 1, pinging inside the tunnel was a nice respectable
20-30ms. When I stepped it up to 2, it went to 100-200ms. But clearly
since 1 still achieves full bandwidth, that is the "ideal" value.

On the other side of this OpenVPN tunnel the upstream is actually 1MB/s
and I did all of the preliminary tests described above to prove that I
was managing the bottleneck queue and repeated my steps in reducing the
tun0 txqueuelen and observing ping times. I had to again get down all
the way to 1 to get ping times in the 20-30ms time range, but that was
at a cost of only utilizing half of the upstream bandwidth, which is not
acceptable. So I bump the txqueuelen up to 2 and get full upstream
bandwidth utilization but at a cost of ~75ms latencies.

This all clearly fits well with Gettys' [paraphrased] mantra of "there
is no single correct value", indeed, so I don't know what I am
recommending here. I don't know if 100 is even needed for Gige speeds
but maybe somebody wants to do that test.

I just thought I would share my findings for anyone else who is trying
to manage latency in their tunnels.

Cheers,
b.

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.