[Bismark-devel] initial openvpn results on capetown

[Bismark-devel] initial openvpn results on capetown

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1872 bytes --]

Using 1024 bit keys, openvpn over udp, an easy-rsa cert authority, using
certificates and a setup as per
http://openvpn.net/index.php/open-source/documentation/howto.html

(all the howtos on the web are obsolete, this one worked, I created a dir,
did a make install,
  and followed those instructions)

I hooked up 3 wndr3700 boxes in series for this test. I had to manually set
it up to
tunnel appropriately (it set up a tunnel to the wrong place, by default,
it's just a config
option I haven't figured out, or so I hope)

connected via jupiter (acting as an openvpn server)
                          |
                       leda  (acting as a router)
                          |
                       aitne  (acting as a client)

I get 19Mbits/second, using iperf. Obviously, using openvpn as a server on
these routers will not scale to a lot of users. However, 19Mbits is not bad,
for the clients, for a first try, and is
probably adversely effected by using a weak box as a server.

I'd be very interested to know if the clients can be made to work well
through NAT.

A ping

20:46:46.674942 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP, length
125
20:46:46.681440 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP, length
125
20:46:47.675078 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP, length
125
20:46:47.681193 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP, length
125
20:46:48.675203 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP, length
125
20:46:48.675818 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP, length
125

I'd like to give strongswan a shot at some point as the basic ipsec-tools,
but I was
pleased this turned out so easy once I found a piece of doc that was up to
date.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 2136 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2586 bytes --]

I got my (linux-based) laptop to punch through one layer of NAT just fine
and resolved the routing problem below.

Is there a willing victim^H^H^H^H^H^H tester out there that could test how
well mac support would work?

I'd need to generate a cert and script that worked with this:

http://code.google.com/p/tunnelblick/

After running overnight, the openvpn server grew to about 8MB in size, and
seems to have stabilized there.



On Sun, May 29, 2011 at 3:01 PM, Dave Taht <dave.taht@gmail.com> wrote:

> Using 1024 bit keys, openvpn over udp, an easy-rsa cert authority, using
> certificates and a setup as per
> http://openvpn.net/index.php/open-source/documentation/howto.html
>
> (all the howtos on the web are obsolete, this one worked, I created a dir,
> did a make install,
>   and followed those instructions)
>
> I hooked up 3 wndr3700 boxes in series for this test. I had to manually set
> it up to
> tunnel appropriately (it set up a tunnel to the wrong place, by default,
> it's just a config
> option I haven't figured out, or so I hope)
>
> connected via jupiter (acting as an openvpn server)
>                           |
>                        leda  (acting as a router)
>                           |
>                        aitne  (acting as a client)
>
> I get 19Mbits/second, using iperf. Obviously, using openvpn as a server on
> these routers will not scale to a lot of users. However, 19Mbits is not bad,
> for the clients, for a first try, and is
> probably adversely effected by using a weak box as a server.
>
> I'd be very interested to know if the clients can be made to work well
> through NAT.
>
> A ping
>
> 20:46:46.674942 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP,
> length 125
> 20:46:46.681440 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP,
> length 125
> 20:46:47.675078 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP,
> length 125
> 20:46:47.681193 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP,
> length 125
> 20:46:48.675203 IP 192.168.115.171.38804 > 192.168.22.1.openvpn: UDP,
> length 125
> 20:46:48.675818 IP 192.168.22.1.openvpn > 192.168.115.171.38804: UDP,
> length 125
>
> I'd like to give strongswan a shot at some point as the basic ipsec-tools,
> but I was
> pleased this turned out so easy once I found a piece of doc that was up to
> date.
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 3342 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]

On Mon, May 30, 2011 at 8:52 AM, Srikanth Sundaresan <srikanth@gatech.edu>wrote:

>
> On May 30, 2011, at 6:58 PM, Dave Taht wrote:
>
> > After running overnight, the openvpn server grew to about 8MB in size,
> and seems to have stabilized there.
>
> That's a lot, isn't it?


No. The server should run on a far more capable host than the router, which
would hardly notice.

More important is that I'm not observing unbounded memory growth, which is
important for long running processes.

The server size is also a function of the number of connected clients. There
are only two connected now.

The client (after much less abuse than I put the server through last night)
weighs in at

12932     1 root     S     4548   7%   0% /usr/sbin/openvpn --syslog
openvpn(cu

Note that using VSZ as per either of these measurements do is a bad idea in
that it inaccurately accounts for stack size and shared library usage.

But as a rough measure, it's not bad, and we currently have over 32MB of ram
to spare, even after openvpn is  running. dnsmasq, after some usage, will
grow larger than it is at present.

I'll put the client through some abuse in a bit.

As a client, openvpn has the ability to take a list of addresses, and ports,
to try an outgoing connection on.

As a server, multiple servers can listen also on multiple ports, on multiple
machines as well, so it is theoretically scalable to thousands of users.

My principal problem (long term) with openvpn, is as a user space daemon it
cannot take advantage of hardware acceleration on the client side, where
available (of the hardware projected to be in use for cerowrt, the only
thing that does hardware crypto is the dreamplug). I would also like to try
a heavier crypto algo than blowfish.

That said, once I got through the 'generate a cert setup hassle', it's nice
to be able to get to port 81 through the vpn, as well as see snmp stuff.

[-- Attachment #2: Type: text/html, Size: 2361 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Walter de Donato]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

I really like all these analysis on scalability and flexibility.
Anyway, I think we won't need to have many tunnels active at the same time.

The goal of having these tunnels is to be able to occasionally talk to the
devices,
access to their console/web_interface.
Do you have other goals in mind?

Walter

2011/5/30 Dave Taht <dave.taht@gmail.com>

> On Mon, May 30, 2011 at 8:52 AM, Srikanth Sundaresan <srikanth@gatech.edu>wrote:
>
>>
>> On May 30, 2011, at 6:58 PM, Dave Taht wrote:
>>
>> > After running overnight, the openvpn server grew to about 8MB in size,
>> and seems to have stabilized there.
>>
>> That's a lot, isn't it?
>
>
> No. The server should run on a far more capable host than the router, which
> would hardly notice.
>
> More important is that I'm not observing unbounded memory growth, which is
> important for long running processes.
>
> The server size is also a function of the number of connected clients.
> There are only two connected now.
>
> The client (after much less abuse than I put the server through last night)
> weighs in at
>
> 12932     1 root     S     4548   7%   0% /usr/sbin/openvpn --syslog
> openvpn(cu
>
> Note that using VSZ as per either of these measurements do is a bad idea in
> that it inaccurately accounts for stack size and shared library usage.
>
> But as a rough measure, it's not bad, and we currently have over 32MB of
> ram to spare, even after openvpn is  running. dnsmasq, after some usage,
> will grow larger than it is at present.
>
> I'll put the client through some abuse in a bit.
>
> As a client, openvpn has the ability to take a list of addresses, and
> ports, to try an outgoing connection on.
>
> As a server, multiple servers can listen also on multiple ports, on
> multiple machines as well, so it is theoretically scalable to thousands of
> users.
>
> My principal problem (long term) with openvpn, is as a user space daemon it
> cannot take advantage of hardware acceleration on the client side, where
> available (of the hardware projected to be in use for cerowrt, the only
> thing that does hardware crypto is the dreamplug). I would also like to try
> a heavier crypto algo than blowfish.
>
> That said, once I got through the 'generate a cert setup hassle', it's nice
> to be able to get to port 81 through the vpn, as well as see snmp stuff.
>
>
> _______________________________________________
> Bismark-devel mailing list
> Bismark-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bismark-devel
>
>


-- 
Walter de Donato, PhD Student
Dipartimento di Informatica e Sistemistica
Università  degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +39 081 76 83821 - Fax: +39 081 76 83816
Email: walter.dedonato@unina.it
WWW: http://wpage.unina.it/walter.dedonato

[-- Attachment #2: Type: text/html, Size: 3874 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 4487 bytes --]

On Mon, May 30, 2011 at 2:02 PM, Walter de Donato
<walter.dedonato@unina.it>wrote:

> I really like all these analysis on scalability and flexibility.


And redundancy, and security, and robustness.

I'm glad to share what I'm working on.


> Anyway, I think we won't need to have many tunnels active at the same time.
>
>
The current scope of bismark is a goal 200 devices in the field, as I
understand it.

How do you plan to push out new packages?


> The goal of having these tunnels is to be able to occasionally talk to the
> devices,
> access to their console/web_interface.
>

SNMP is used heavily by large scale corporate monitoring tools such as
nagios, cacti, etc.


Do you have other goals in mind?
>
>
Bismark is leveraging one project of 'uberwrt' and bufferbloat.net. There
are five others at present. There will hopefully be more.

While I do not expect to get a one-size-fits all solution to the needs of
all the projects, it is worth it to do more than a cursory investigation on
something that may need to be supported (by others) for a decade in the
field.

There is a need for a vpn solution in all the sub-projects,
(it's my number #1 request)

not just for monitoring boxes currently invisible behind NAT,

but for corporate connectivity, which is what vpns are usually used for.

I also like the idea of 'home router management as a service', which is
embedded in the 'network-dashboard' idea.

Additionally to the vpn issue, getting port mirroring to work comes from a
request from MIT to be able to leverage their monitoring box, which is an
external box that can run at wire speeds.

It may sit on top of bismark one day to verify results.




> Walter
>
> 2011/5/30 Dave Taht <dave.taht@gmail.com>
>
>> On Mon, May 30, 2011 at 8:52 AM, Srikanth Sundaresan <srikanth@gatech.edu
>> > wrote:
>>
>>>
>>> On May 30, 2011, at 6:58 PM, Dave Taht wrote:
>>>
>>> > After running overnight, the openvpn server grew to about 8MB in size,
>>> and seems to have stabilized there.
>>>
>>> That's a lot, isn't it?
>>
>>
>> No. The server should run on a far more capable host than the router,
>> which would hardly notice.
>>
>> More important is that I'm not observing unbounded memory growth, which is
>> important for long running processes.
>>
>> The server size is also a function of the number of connected clients.
>> There are only two connected now.
>>
>> The client (after much less abuse than I put the server through last
>> night) weighs in at
>>
>> 12932     1 root     S     4548   7%   0% /usr/sbin/openvpn --syslog
>> openvpn(cu
>>
>> Note that using VSZ as per either of these measurements do is a bad idea
>> in that it inaccurately accounts for stack size and shared library usage.
>>
>> But as a rough measure, it's not bad, and we currently have over 32MB of
>> ram to spare, even after openvpn is  running. dnsmasq, after some usage,
>> will grow larger than it is at present.
>>
>> I'll put the client through some abuse in a bit.
>>
>> As a client, openvpn has the ability to take a list of addresses, and
>> ports, to try an outgoing connection on.
>>
>> As a server, multiple servers can listen also on multiple ports, on
>> multiple machines as well, so it is theoretically scalable to thousands of
>> users.
>>
>> My principal problem (long term) with openvpn, is as a user space daemon
>> it cannot take advantage of hardware acceleration on the client side, where
>> available (of the hardware projected to be in use for cerowrt, the only
>> thing that does hardware crypto is the dreamplug). I would also like to try
>> a heavier crypto algo than blowfish.
>>
>> That said, once I got through the 'generate a cert setup hassle', it's
>> nice to be able to get to port 81 through the vpn, as well as see snmp
>> stuff.
>>
>>
>> _______________________________________________
>> Bismark-devel mailing list
>> Bismark-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bismark-devel
>>
>>
>
>
> --
> Walter de Donato, PhD Student
> Dipartimento di Informatica e Sistemistica
> Università  degli Studi di Napoli "Federico II"
> Via Claudio 21 -- 80125 Napoli (Italy)
> Phone: +39 081 76 83821 - Fax: +39 081 76 83816
> Email: walter.dedonato@unina.it
> WWW: http://wpage.unina.it/walter.dedonato
>
>


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 6842 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

This is a screenshot, of me, over a vpn...

http://www.bufferbloat.net/attachments/download/33/routertest.png

monitoring 5 clients' cpu and memory usage,
using pdsh and X to the routers in the lab,
while trying to understand why performance peaked at 130Mbits and latencies
had hit 100s of ms on connections capable of gigabytes.

(I had had several other problems on the way, which I'd quickly resolved)

http://www.bufferbloat.net/projects/bismark-testbed/wiki/Experiment_-_QoS

Doing updates in the field is a single command.

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

[-- Attachment #2: Type: text/html, Size: 914 bytes --]

Re: [Bismark-devel] initial openvpn results on capetown

[Walter de Donato]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

Ok, now that I have a better view of the big picture I understand.

Were you thinking of creating just one BIG VPN or clustering them
depending on the location?
I think the latter schema would scale better.

Walter

2011/5/31 Dave Taht <dave.taht@gmail.com>

> This is a screenshot, of me, over a vpn...
>
> http://www.bufferbloat.net/attachments/download/33/routertest.png
>
> monitoring 5 clients' cpu and memory usage,
> using pdsh and X to the routers in the lab,
> while trying to understand why performance peaked at 130Mbits and latencies
> had hit 100s of ms on connections capable of gigabytes.
>
> (I had had several other problems on the way, which I'd quickly resolved)
>
> http://www.bufferbloat.net/projects/bismark-testbed/wiki/Experiment_-_QoS
>
> Doing updates in the field is a single command.
>
>
> --
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://the-edge.blogspot.com
>



-- 
Walter de Donato, PhD Student
Dipartimento di Informatica e Sistemistica
Università  degli Studi di Napoli "Federico II"
Via Claudio 21 -- 80125 Napoli (Italy)
Phone: +39 081 76 83821 - Fax: +39 081 76 83816
Email: walter.dedonato@unina.it
WWW: http://wpage.unina.it/walter.dedonato

[-- Attachment #2: Type: text/html, Size: 2040 bytes --]