openvpn-users

Re: [Openvpn-users] Samba performance and ICMP

[Aleix D. <ad...@ud...>]

Hi again,

just to update the list on what I've found.

I've set up another VPN server, but this time using L2TP over IPSEC  
(OpenSWAN) using a similar routing like the one with OpenVPN. I've  
seen that the problem also happens in that setup. The performance  
copying files is horrible and I get the same:

ICMP (dest unrch) (DF set) from VPNMachine to SambaMachine

I guess then it has nothing to do with OpenVPN then, maybe Samba.  
Searching Google I've seen that if you look for "Samba and VPN"  
instead of OpenVPN the performance results are apolling...

Maybe I'll try how WebDAV over VPN works in comparison.

If someone, regardless my findings has a solution, please don't  
hesitate to share it :-)

Thanks again,

Aleix Dorca.

El 17/11/2008, a las 14:45, Brett Serkez escribió:

> On Mon, Nov 17, 2008 at 8:08 AM, Aleix Dorca <ad...@ud...> wrote:
>> Recently we moved a Windows Server machine sharing folders to a Linux
>> with samba. From that moment users have been complaining that while
>> accessing the new server through openvpn causes no problems at all,
>> working with files and directories is extremely slow.
>>
>
> I'd be very interested in other responses, as I have seen this
> behavior, I've found a partial solution.
>
> I've found that Windows doesn't tune itself well for file sharing.   I
> usually make these registry changes on the Windows sever and reboot:
>
> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver 
> \parameters]
> "Lmannounce"=dword:00000001
> "MaxWorkItems"=dword:0000ffff
> "MaxRawWorkItems"=dword:00000200
> "MaxThreadsPerQueue"=dword:0000ffff
> "InitWorkItems"=dword:00000200
> "MaxFreeConnections"=dword:00000064
> "MinFreeConnections"=dword:00000020
> "MaxMpxCt"=dword:00004000
> "SizReqBuf"=dword:0000ffff
>
> The above setting better maximize resources available to service SMB
> requests on the Windows Server machine.  I'd be interested if others
> have found better settings, I researched these some time back.
>
> On Windows clients, I also disable TCP/IP NetBIOS helper which forces
> use of UDP vs. TCP SMB protocol (at least this is how I understood it
> when I did the initial research) which best aligns its self with the
> recommended OpenVPN UDP protocol.  I'm presuming SAMBA has the same
> capability to turn off use of the optional TCP SMB protocol.
>
> Brett

Re: [Openvpn-users] Samba performance and ICMP

[Aleix D. <ad...@ud...>]

Hi,

after reading your messages it got me thinking. Maybe it is a problem in
my routing setup.

Let's see if is that. Here's how it works. I have a Linux box with
OpenVpn sitting in the net 192.168.100.0/24 with ip 192.168.100.100. The
samba machine is also sitting in this net with ip 192.168.100.2.

RoadWarriors connect to a router with a public IP that is Natted (with
iptables) into the the VPN machine.

There's nothing else involved... Routes also seem to be fine.

Here's another thing though that made me think that something wrong is
going on. I have a devel http server in the mentioned net. It has ip
192.168.100.3. Accessing this server through the tunnel is also painfull
and the same ICMP messages also appear.

Maybe it has something to do with fragmentation (because of the DF set
message on the ICMP packet)?

I continue investigating.

Thanks again,

Aleix Dorca.

Re: [Openvpn-users] Samba performance and ICMP

[David B. <Dav...@he...>]

1.) tell more details about the error ICMP message (src IP, dest IP,...)
2.) Is running SMB over NAT a good thing ?

Regards,
David 

> -----Original Message-----
> From: Aleix Dorca [mailto:ad...@ud...] 
> Sent: Monday, November 17, 2008 5:08 PM
> To: ope...@li...
> Subject: Re: [Openvpn-users] Samba performance and ICMP
> 
> Hi,
> 
> after reading your messages it got me thinking. Maybe it is a 
> problem in
> my routing setup.
> 
> Let's see if is that. Here's how it works. I have a Linux box with
> OpenVpn sitting in the net 192.168.100.0/24 with ip 
> 192.168.100.100. The
> samba machine is also sitting in this net with ip 192.168.100.2.
> 
> RoadWarriors connect to a router with a public IP that is Natted (with
> iptables) into the the VPN machine.
> 
> There's nothing else involved... Routes also seem to be fine.
> 
> Here's another thing though that made me think that something wrong is
> going on. I have a devel http server in the mentioned net. It has ip
> 192.168.100.3. Accessing this server through the tunnel is 
> also painfull
> and the same ICMP messages also appear.
> 
> Maybe it has something to do with fragmentation (because of the DF set
> message on the ICMP packet)?
> 
> I continue investigating.
> 
> Thanks again,
> 
> Aleix Dorca.
> 
> 
> --------------------------------------------------------------
> -----------
> This SF.Net email is sponsored by the Moblin Your Move 
> Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & 
> win great prizes
> Grand prize is a trip for two to an Open Source event 
> anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Openvpn-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvpn-users
> 

Re: [Openvpn-users] Samba performance and ICMP

[Aleix D. <ad...@ud...>]

 > 1.) tell more details about the error ICMP message (src IP, dest  
IP,...)
 > 2.) Is running SMB over NAT a good thing ?

I've captured these icmp packets with tshark:

192.168.100.100 -> 192.168.100.2 ICMP Dest Unreachable (Fragmentation  
needed)

This is: VPN -> Samba

These happen when any service (SMB, HTTP...) with high data transfer  
is accessed.

Let's see if we can get these messages to dissapear...

Thanks all of you... I'm reading all your comments, and it looks like  
I'm not alone in this crappy problem.

Aleix.

Re: [Openvpn-users] Samba performance and ICMP

[David B. <Dav...@he...>]

> From: Aleix Dorca [mailto:ad...@ud...] 
> 
>  > 1.) tell more details about the error ICMP message (src IP, dest  
> IP,...)
>  > 2.) Is running SMB over NAT a good thing ?
> 
> I've captured these icmp packets with tshark:
> 
> 192.168.100.100 -> 192.168.100.2 ICMP Dest Unreachable 
> (Fragmentation  
> needed)

WHICH destination ?
What packet triggered this reply ?

David

Re: [Openvpn-users] Samba performance and ICMP

[Jakob C. <jc...@in...>]

Aleix Dorca schrieb:
>
> 192.168.100.100 -> 192.168.100.2 ICMP Dest Unreachable (Fragmentation  
> needed)
This means you have an MTU problem. Try to set the MTU on the sending 
side to something like 1024 and switch off Path MTU discovery.
Check the MTU of all participating routers etc- at some point in the 
chain you have an MTU lower that the sending side has thought it to be.

HTH,
Jakob Curdes

Re: [Openvpn-users] Samba performance and ICMP

[Aleix D. <ad...@ud...>]

 > WHICH destination ?
 > What packet triggered this reply ?
 >
 > David

Hi David,

thanks for your help but I found the problem. It wasn't a "network"  
related problem, but a virtualization problem.

You see, I had OpenVPN running on a paravirtualized Debian Lenny under  
Xen 3.3.

I've just setup a new virtual machine, but this time using hvm (full  
virtualization) and everything works as expected and file transfer is  
back to "normal" (30 K/s on my ADSL). No more ICMP messages at all.  
Probably paravirtualization handles the network diferently or  
something...

I wonder if using my L2TP over IPSEC on this environment will also  
avoid the ICMP problems, most likely i think.

Now I'll go and see if anyone knows why this is happening on the Xen  
mailing list.

Thanks again to all who have contributed with their comments!

Aleix.

Re: [Openvpn-users] Samba performance and ICMP

[Jan J. K. <ja...@ni...>]

Hi Aleix,

Aleix Dorca wrote:
> Hi again,
>
> just to update the list on what I've found.
>
> I've set up another VPN server, but this time using L2TP over IPSEC 
> (OpenSWAN) using a similar routing like the one with OpenVPN. I've 
> seen that the problem also happens in that setup. The performance 
> copying files is horrible and I get the same:
>
> ICMP (dest unrch) (DF set) from VPNMachine to SambaMachine
>
> I guess then it has nothing to do with OpenVPN then, maybe Samba. 
> Searching Google I've seen that if you look for "Samba and VPN" 
> instead of OpenVPN the performance results are apolling...
>
> Maybe I'll try how WebDAV over VPN works in comparison.
>
>
this sounds like a routing issue, not a Samba/WebDav issue (nor an 
OpenVPN issue , for that matter :-) ).  The VPN machine is sending an 
ICMP (dest unreachable) back to the Samba machine because the Samba 
machine sent a packet to it that the VPN machine does not know how to 
handle... how is your network set up? are you using NATting at all? are 
the appropriate routes to and from the VPN machine and Samba machine set 
up?

The very quick&dirty fix (just to see if this makes things work) is to 
use masquerading on your (Linux) VPN server:
  iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
(substitute the right device for eth0).
Try using traceroute to see how packets are flowing to and from the 
Samba and VPN servers...

HTH,

JJK

> El 17/11/2008, a las 14:45, Brett Serkez escribió:
>
>> On Mon, Nov 17, 2008 at 8:08 AM, Aleix Dorca <ad...@ud... 
>> <mailto:ad...@ud...>> wrote:
>>> Recently we moved a Windows Server machine sharing folders to a Linux
>>> with samba. From that moment users have been complaining that while
>>> accessing the new server through openvpn causes no problems at all,
>>> working with files and directories is extremely slow.
>>>
>>
>> I'd be very interested in other responses, as I have seen this
>> behavior, I've found a partial solution.
>>
>> I've found that Windows doesn't tune itself well for file sharing.   I
>> usually make these registry changes on the Windows sever and reboot:
>>
>> [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters]
>> "Lmannounce"=dword:00000001
>> "MaxWorkItems"=dword:0000ffff
>> "MaxRawWorkItems"=dword:00000200
>> "MaxThreadsPerQueue"=dword:0000ffff
>> "InitWorkItems"=dword:00000200
>> "MaxFreeConnections"=dword:00000064
>> "MinFreeConnections"=dword:00000020
>> "MaxMpxCt"=dword:00004000
>> "SizReqBuf"=dword:0000ffff
>>
>> The above setting better maximize resources available to service SMB
>> requests on the Windows Server machine.  I'd be interested if others
>> have found better settings, I researched these some time back.
>>
>> On Windows clients, I also disable TCP/IP NetBIOS helper which forces
>> use of UDP vs. TCP SMB protocol (at least this is how I understood it
>> when I did the initial research) which best aligns its self with the
>> recommended OpenVPN UDP protocol.  I'm presuming SAMBA has the same
>> capability to turn off use of the optional TCP SMB protocol.
>>

Re: [Openvpn-users] Samba performance and ICMP

[Leonardo R. M. <leo...@so...>]

Aleix Dorca escreveu:
> Hi again,
>
> just to update the list on what I've found.
>
> I've set up another VPN server, but this time using L2TP over IPSEC 
> (OpenSWAN) using a similar routing like the one with OpenVPN. I've 
> seen that the problem also happens in that setup. The performance 
> copying files is horrible and I get the same:
>
> ICMP (dest unrch) (DF set) from VPNMachine to SambaMachine
>
> I guess then it has nothing to do with OpenVPN then, maybe Samba. 
> Searching Google I've seen that if you look for "Samba and VPN" 
> instead of OpenVPN the performance results are apolling...

    from time to time we always have someone complaining about M$ File 
Sharing protocols performance, even with Microsoft or with 3rd party 
implementations (Samba). I've seen these complains on OpenVPN lists, on 
IPSec lists, on every kind of network-related lists when there's a low 
bandwidth/little higher latency connection involved. Not only VPN, but 
even with WAN links.

    It seems to me that Microsoft file sharing protocols were simply not 
designed for those low bandwidth/little higher latency situations. It's 
interesting to compare these M$ file sharing protocols with other 
standards protocols, like HTTP/SMTP/FTP/whatever, which are purely TCP 
ones, and compare that they perform pretty nice on any kind of 
situation, being limited only by the bandwidth involved.

    But M$ sharing protocols no ..... they work fine on LAN networks but 
when it comes to WAN/VPN, it simply sucks.

    it can be some workarounds to make it a little worst, but it's clear 
to me that the protocol simply wasnt designed having these connections 
in mind. It seems clear to me that it was designed to run LAN only.


-- 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia
	http://www.solutti.com.br

	Minha armadilha de SPAM, NÃO mandem email
	ger...@so...
	My SPAMTRAP, do not email it

Re: [Openvpn-users] Samba performance and ICMP

[David H. <li...@ll...>]

Leonardo Rodrigues Magalhães wrote:
> 
> 
>     from time to time we always have someone complaining about M$ File 
> Sharing protocols performance, even with Microsoft or with 3rd party 
> implementations (Samba). I've seen these complains on OpenVPN lists, on 
> IPSec lists, on every kind of network-related lists when there's a low 
> bandwidth/little higher latency connection involved. Not only VPN, but 
> even with WAN links.
> 
>     It seems to me that Microsoft file sharing protocols were simply not 
> designed for those low bandwidth/little higher latency situations. It's 
> interesting to compare these M$ file sharing protocols with other 
> standards protocols, like HTTP/SMTP/FTP/whatever, which are purely TCP 
> ones, and compare that they perform pretty nice on any kind of 
> situation, being limited only by the bandwidth involved.
> 
>     But M$ sharing protocols no ..... they work fine on LAN networks but 
> when it comes to WAN/VPN, it simply sucks.
> 
>     it can be some workarounds to make it a little worst, but it's clear 
> to me that the protocol simply wasnt designed having these connections 
> in mind. It seems clear to me that it was designed to run LAN only.
> 
> 
SMB is very poor when used over a link with a high latency, regardless 
of whether it's OpenVPN or something else. Unfortunately you're stuck 
with it as soon as you leave your LAN behind. There are caching 
solutions available that can reduce the effects, but they are more use 
for inter-office VPN solutions where your local office can cache stuff 
from the remote end and give a better response time to local queries.

Dave

Re: [Openvpn-users] Samba performance and ICMP

[Colin R. <co...@ca...>]

David Hough wrote:
> Leonardo Rodrigues Magalhães wrote:
>   
>>     from time to time we always have someone complaining about M$ File 
>> Sharing protocols performance, even with Microsoft or with 3rd party 
>> implementations (Samba). I've seen these complains on OpenVPN lists, on 
>> IPSec lists, on every kind of network-related lists when there's a low 
>> bandwidth/little higher latency connection involved. Not only VPN, but 
>> even with WAN links.
>>
>>     It seems to me that Microsoft file sharing protocols were simply not 
>> designed for those low bandwidth/little higher latency situations. It's 
>> interesting to compare these M$ file sharing protocols with other 
>> standards protocols, like HTTP/SMTP/FTP/whatever, which are purely TCP 
>> ones, and compare that they perform pretty nice on any kind of 
>> situation, being limited only by the bandwidth involved.
>>
>>     But M$ sharing protocols no ..... they work fine on LAN networks but 
>> when it comes to WAN/VPN, it simply sucks.
>>
>>     it can be some workarounds to make it a little worst, but it's clear 
>> to me that the protocol simply wasnt designed having these connections 
>> in mind. It seems clear to me that it was designed to run LAN only.
>>
>>
>>     
> SMB is very poor when used over a link with a high latency, regardless 
> of whether it's OpenVPN or something else. Unfortunately you're stuck 
> with it as soon as you leave your LAN behind. There are caching 
> solutions available that can reduce the effects, but they are more use 
> for inter-office VPN solutions where your local office can cache stuff 
> from the remote end and give a better response time to local queries.
>
> Dave
>
>   

Dave et. al. speak the truth don't waste your time trying to fix the 
un-fixable. SMB is crap pure and simple. As I recall the biggest issue 
is that there is a little bit of "hi I need some more data, ok here's 
some more data" client->server chatter every 64k of data, that's right 
64k. This is horribly exaggerated on relatively "slow" high-latency 
links that even a decent Internet connection represents. Even take a 
moment to compare SMB transfer times over the LAN versus FTP or even 
HTTP and you'll see exactly how ugly this protocol is.

Too much detail on SMB can be found here: 

http://www.phrack.org/issues.html?issue=60&id=11#article

I with the truth were otherwise.

C