Hi,
I'm fighting with my firewall to get nfs-over-tcp through.
The server is outside the firewall, the client is inside. The firewall
allows all tcp back-connections (without syn), no UDPs. Mount on the
client side worked fine with kernel 2.6.16 in SLES 10.
Now when the NFS client is running SLES 11 with its kernel 2.6.27,
the NFS server tries to make UDP connections from its ports 111 and
700 to different ports on the client.
If the client is running SLES 10 with 2.6.16, those connections are
not tried from the server, no matter if the server runs 2.6.16 or
2.6.27.
So I've two questions:
1) Should nfs-over-tcp still use any UDP ports at all?
2) What has been changed in the client code between 2.6.16 and 2.6.27
that could cause this behaviour?
Is there a way to prevent those UDP connects?
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
> Now when the NFS client is running SLES 11 with its kernel 2.6.27,
> the NFS server tries to make UDP connections from its ports 111 and
> 700 to different ports on the client.
>
> If the client is running SLES 10 with 2.6.16, those connections are
> not tried from the server, no matter if the server runs 2.6.16 or
> 2.6.27.
>
> So I've two questions:
> 1) Should nfs-over-tcp still use any UDP ports at all?
> 2) What has been changed in the client code between 2.6.16 and 2.6.27
> ? that could cause this behaviour?
By default it is now using UDP to connect to mountd.
> Is there a way to prevent those UDP connects?
Yes, add "mountproto=tcp" to your mount options.
Regards,
Leonardo
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Thu, 2009-05-07 at 14:57 +0200, Frank Steiner wrote:
> Hi,
>
> I'm fighting with my firewall to get nfs-over-tcp through.
>
> The server is outside the firewall, the client is inside. The firewall
> allows all tcp back-connections (without syn), no UDPs. Mount on the
> client side worked fine with kernel 2.6.16 in SLES 10.
>
> Now when the NFS client is running SLES 11 with its kernel 2.6.27,
> the NFS server tries to make UDP connections from its ports 111 and
> 700 to different ports on the client.
>
> If the client is running SLES 10 with 2.6.16, those connections are
> not tried from the server, no matter if the server runs 2.6.16 or
> 2.6.27.
>
> So I've two questions:
> 1) Should nfs-over-tcp still use any UDP ports at all?
> 2) What has been changed in the client code between 2.6.16 and 2.6.27
> that could cause this behaviour?
>
> Is there a way to prevent those UDP connects?
The default behaviour is to always try to use UDP to talk to mountd and
the portmapper in order to minimize the number of ports that get left in
the TIME_WAIT state. If you only want to use TCP, then you might try
using '-omountproto=tcp'
Cheers
Trond
PS: Note that [email protected] is deprecated due to poor
anti-spam filtering. You should rather send posts directly to
[email protected]
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
Leonardo Chiquitto wrote
>> Is there a way to prevent those UDP connects?
>
> Yes, add "mountproto=tcp" to your mount options.
I was only aware of "proto=tcp" and indeed missed the mountproto option.
Thanks both Leonardo and Trond for your answers!
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
At 11:26 AM 5/7/2009, Frank Steiner wrote:
>Leonardo Chiquitto wrote
>
>>> Is there a way to prevent those UDP connects?
>>
>> Yes, add "mountproto=tcp" to your mount options.
>
>I was only aware of "proto=tcp" and indeed missed the mountproto option.
>
>Thanks both Leonardo and Trond for your answers!
>
There is one small caveat to using mountproto=tcp through firewalls:
while the mount will succeed, there are some side protocol exchanges
which may not.
In particular, if you do NLM file locking, there is a server callback (NLM
"granted") which the server may choose to issue via UDP. If this callback
is not seen by the client due to firewall blocking, there may be a 30-second
pause before a client retry unblocks the caller.
Also, the NSM (status monitor) exchanges are often performed via UDP.
Again, if you are using NLM and the server reboots, the client may not
become aware of this promptly, and lock reclaim will be affected.
OTOH, if your applications don't use locking on the NFS mounts, you'll
probably be fine.
Tom.
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Thu, May 7, 2009 at 11:35 AM, Tom Talpey <[email protected]> wrote:
>
> There is one small caveat to using mountproto=tcp through firewalls:
> while the mount will succeed, there are some side protocol exchanges
> which may not.
>
> In particular, if you do NLM file locking, there is a server callback (NLM
> "granted") which the server may choose to issue via UDP. If this callback
> is not seen by the client due to firewall blocking, there may be a 30-second
> pause before a client retry unblocks the caller.
>
> Also, the NSM (status monitor) exchanges are often performed via UDP.
> Again, if you are using NLM and the server reboots, the client may not
> become aware of this promptly, and lock reclaim will be affected.
Sorry for the slight threadjack, but a question along those lines...
My understanding is that currently portmap will not bind any UDP NLM
listeners unless there are UDP mounts on the machine. I know there
are servers out there that will always speak NLM over UDP
(netapp/ontap being the prominent one), and as a result there can be
problems without firewalls. If servers are out there that will speak
NLM over UDP regardless of the mount itself, shouldn't we be binding
NLM/UDP regardless of the mount transport?
(Or did I miss this change being reverted a while back?)
-Aaron
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On May 7, 2009, at 12:08 PM, Aaron Wiebe wrote:
> On Thu, May 7, 2009 at 11:35 AM, Tom Talpey <[email protected]>
> wrote:
>>
>> There is one small caveat to using mountproto=tcp through firewalls:
>> while the mount will succeed, there are some side protocol exchanges
>> which may not.
>>
>> In particular, if you do NLM file locking, there is a server
>> callback (NLM
>> "granted") which the server may choose to issue via UDP. If this
>> callback
>> is not seen by the client due to firewall blocking, there may be a
>> 30-second
>> pause before a client retry unblocks the caller.
>>
>> Also, the NSM (status monitor) exchanges are often performed via UDP.
>> Again, if you are using NLM and the server reboots, the client may
>> not
>> become aware of this promptly, and lock reclaim will be affected.
>
> Sorry for the slight threadjack, but a question along those lines...
>
> My understanding is that currently portmap will not bind any UDP NLM
> listeners unless there are UDP mounts on the machine.
It's not portmap... lockd decides which listeners to start.
> I know there
> are servers out there that will always speak NLM over UDP
> (netapp/ontap being the prominent one), and as a result there can be
> problems without firewalls. If servers are out there that will speak
> NLM over UDP regardless of the mount itself, shouldn't we be binding
> NLM/UDP regardless of the mount transport?
>
> (Or did I miss this change being reverted a while back?)
This change was reverted upstream; see commit 8c3916f4.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
At 12:42 PM 5/7/2009, Chuck Lever wrote:
>On May 7, 2009, at 12:08 PM, Aaron Wiebe wrote:
>> On Thu, May 7, 2009 at 11:35 AM, Tom Talpey <[email protected]>
>> wrote:
>>>
>>> There is one small caveat to using mountproto=tcp through firewalls:
>>> while the mount will succeed, there are some side protocol exchanges
>>> which may not.
>>>
>>> In particular, if you do NLM file locking, there is a server
>>> callback (NLM
>>> "granted") which the server may choose to issue via UDP. If this
>>> callback
>>> is not seen by the client due to firewall blocking, there may be a
>>> 30-second
>>> pause before a client retry unblocks the caller.
>>>
>>> Also, the NSM (status monitor) exchanges are often performed via UDP.
>>> Again, if you are using NLM and the server reboots, the client may
>>> not
>>> become aware of this promptly, and lock reclaim will be affected.
>>
>> Sorry for the slight threadjack, but a question along those lines...
>>
>> My understanding is that currently portmap will not bind any UDP NLM
>> listeners unless there are UDP mounts on the machine.
>
>It's not portmap... lockd decides which listeners to start.
Also, there is an important distinction between NLM and NLM *callbacks*.
The NLM client follows the NFS protocol selection in many client kernels,
i.e. if you mount with proto=tcp, you get both NFS and NLM over TCP.
The issue is NLM callbacks, which are used only in specific cases where
clients take blocking locks, which actually need to block due to being already
held by another client. The server replies over NLM (e.g. TCP) with an indication
that a callback will arive later. But when the other lock is released, the callback
comes on a second connection, initiated from the server back to the client and
not on the original NLM channel. To make matters worse, some servers only
ever perform the callback on UDP in order to simplify and reduce the overhead
required.
If this callback doesn't arrive at the client, or arrives in such a way that
it's not recognized (e.g traverses a NAT and therefore changes source IP),
then the client only wakes up on a timer. The long pauses can be a real
problem, and one which only arises occasionally - i.e. very hard to trace down.
Just something to be aware of... it's a day-one defect in the NLM protocol,
actually.
Tom.
>
>> I know there
>> are servers out there that will always speak NLM over UDP
>> (netapp/ontap being the prominent one), and as a result there can be
>> problems without firewalls. If servers are out there that will speak
>> NLM over UDP regardless of the mount itself, shouldn't we be binding
>> NLM/UDP regardless of the mount transport?
>>
>> (Or did I miss this change being reverted a while back?)
>
>This change was reverted upstream; see commit 8c3916f4.
>
>--
>Chuck Lever
>chuck[dot]lever[at]oracle[dot]com
>
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Thu, May 7, 2009 at 1:08 PM, Tom Talpey <[email protected]> wrote:
> At 12:42 PM 5/7/2009, Chuck Lever wrote:
>>It's not portmap... lockd decides which listeners to start.
Thanks Chuck and Tom - that clarifies it.
Take care,
-Aaron
> Also, there is an important distinction between NLM and NLM *callback=
s*.
> The NLM client follows the NFS protocol selection in many client kern=
els,
> i.e. if you mount with proto=3Dtcp, you get both NFS and NLM over TCP=
=2E
>
> The issue is NLM callbacks, which are used only in specific cases whe=
re
> clients take blocking locks, which actually need to block due to bein=
g already
> held by another client. The server replies over NLM (e.g. TCP) with a=
n indication
> that a callback will arive later. But when the other lock is released=
, the callback
> comes on a second connection, initiated from the server back to the c=
lient and
> not on the original NLM channel. To make matters worse, some servers =
only
> ever perform the callback on UDP in order to simplify and reduce the =
overhead
> required.
>
> If this callback doesn't arrive at the client, or arrives in such a w=
ay that
> it's not recognized (e.g traverses a NAT and therefore changes source=
IP),
> then the client only wakes up on a timer. The long pauses can be a re=
al
> problem, and one which only arises occasionally - i.e. very hard to t=
race down.
>
> Just something to be aware of... it's a day-one defect in the NLM pro=
tocol,
> actually.
>
> Tom.
>
>>
>>> =A0I know there
>>> are servers out there that will always speak NLM over UDP
>>> (netapp/ontap being the prominent one), and as a result there can b=
e
>>> problems without firewalls. =A0If servers are out there that will s=
peak
>>> NLM over UDP regardless of the mount itself, shouldn't we be bindin=
g
>>> NLM/UDP regardless of the mount transport?
>>>
>>> (Or did I miss this change being reverted a while back?)
>>
>>This change was reverted upstream; see commit 8c3916f4.
>>
>>--
>>Chuck Lever
>>chuck[dot]lever[at]oracle[dot]com
>>
>
>
-----------------------------------------------------------------------=
-------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! You=
r
production scanning environment may not be a perfect world - but thanks=
to
Kodak, there's a perfect scanner to get the job done! With the NEW KODA=
K i700
Series Scanner you'll get full speed at 300 dpi even with all image=20
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
Tom Talpey wrote
> In particular, if you do NLM file locking, there is a server callback (NLM
> "granted") which the server may choose to issue via UDP. If this callback
> is not seen by the client due to firewall blocking, there may be a 30-second
> pause before a client retry unblocks the caller.
>
> Also, the NSM (status monitor) exchanges are often performed via UDP.
> Again, if you are using NLM and the server reboots, the client may not
> become aware of this promptly, and lock reclaim will be affected.
>
> OTOH, if your applications don't use locking on the NFS mounts, you'll
> probably be fine.
We do use locking on nfs mounts, so I wonder what that would mean for the
firewall. Currently I see connections from the NFS server *from* port 700
and 111 (we've fixed mountd port to 700) to (it seems) arbitrary udp
ports on the NFS clients.
Would that be enough to allow those? Or could the source ports be arbitrary
with NLM, too? I.e., would we have to open all udp traffic from the NFS
servers to all the NFS clients?
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs
On Fri, 2009-05-08 at 08:03 +0200, Frank Steiner wrote:
> Tom Talpey wrote
>
>
> > In particular, if you do NLM file locking, there is a server callback (NLM
> > "granted") which the server may choose to issue via UDP. If this callback
> > is not seen by the client due to firewall blocking, there may be a 30-second
> > pause before a client retry unblocks the caller.
> >
> > Also, the NSM (status monitor) exchanges are often performed via UDP.
> > Again, if you are using NLM and the server reboots, the client may not
> > become aware of this promptly, and lock reclaim will be affected.
> >
> > OTOH, if your applications don't use locking on the NFS mounts, you'll
> > probably be fine.
>
> We do use locking on nfs mounts, so I wonder what that would mean for the
> firewall. Currently I see connections from the NFS server *from* port 700
> and 111 (we've fixed mountd port to 700) to (it seems) arbitrary udp
> ports on the NFS clients.
>
> Would that be enough to allow those? Or could the source ports be arbitrary
> with NLM, too? I.e., would we have to open all udp traffic from the NFS
> servers to all the NFS clients?
Most NFS servers allow you to pin the ports used by the lockd service.
In Linux, the kernel boot parameters lockd.nlm_tcpport and
lockd.nlm_udpport will suffice to do it for you (see
linux/Documentation/kernel-parameters.txt).
Trond
------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
Please note that [email protected] is being discontinued.
Please subscribe to [email protected] instead.
http://vger.kernel.org/vger-lists.html#linux-nfs