|
List Info
Thread: nfs send errors
|
|
| nfs send errors |
 
United States |
2008-04-29 17:13:54 |
my kernel is logging errors like these:
Apr 26 04:15:13 xiombarg kernel: nfs send error 1 for server
10.69.69.21:/data0/music
Apr 27 23:20:21 xiombarg kernel: nfs send error 1 for
server
10.69.69.21:/data0/music
Apr 29 15:35:07 xiombarg kernel: nfs send error 1 for
server
10.69.69.21:/data0/music
NFS does not seem to be affected. it appears to retry the
send w/ a new
connection. all of my nfs mounts are affected, not just the
one shown
above.
it looks as if firewall is blocking packets due to state
timeouts, but
states should persist for up to 86400 seconds depending upon
state table
size and although i am nowhere near the max table size a
state appears
to have gone away in less than 2469 seconds:
14:53:58.835812 rule 45/0(match): pass out on rl0:
xiombarg.uffner.com.713 >
10.69.69.21.nfsd: S 1077685507:1077685507(0) win 65535
<mss 1460,nop,wscale
3,nop,nop,timestamp[|tcp]>
15:35:07.667381 rule 0/0(match): block out on rl0:
xiombarg.uffner.com.713 >
10.69.69.21.nfsd: P 1077857136:1077857240(104) ack
1091504052 win 16588
<nop,nop,timestamp 763469633 2221451579>
15:35:07.667571 rule 45/0(match): pass out on rl0:
xiombarg.uffner.com.1023 >
10.69.69.21.nfsd: S 772434453:772434453(0) win 65535 <mss
1460,nop,wscale
3,nop,nop,timestamp[|tcp]>
this is the pf config for the firewall between my desktop
(xiombarg) and a
mostly trusted DMZ where the nfs server lives
(10.69.69.0/24). (it also
contains rules controlling traffic to & from the
internet which duplicate the
ones on my exterior firewall)
ext_if = "rl0"
local_ip = "{ 127.0.0.1 10.69.69.60 71.162.143.94
207.245.121.212 }"
local_tcp_services ="{ 111 143 587 993 4949 5432
}" #sunrpc, imap,
submission, imaps, munin, postgres
global_tcp_services ="{ 22 25 53 80 143 443 993 }"
#ssh, smtp, domain,
http, imap, https, imaps
local_udp_services ="{ 111 514 }"
#sunrpc, syslog
global_udp_services ="{ 53 123 }"
#domain, ntp
icmp_types = "echoreq"
table <bruteforce> persist file
"/var/db/ssh-bruteforce"
# options
set block-policy return
set loginterface $ext_if
# scrub
scrub in on $ext_if all fragment reassemble
# filter rules
block log all
pass quick on lo0 all
block drop in log quick proto tcp from <bruteforce> to
any port ssh
pass in log on $ext_if inet proto tcp from any to ($ext_if)
port $global_tcp_services
pass in log on $ext_if inet proto tcp from $local_ip to
($ext_if)
port $local_tcp_services
pass in log on $ext_if inet proto tcp from 10.69.69.21 port
2049 to ($ext_if)
pass in log on $ext_if inet proto udp from any to ($ext_if)
port $global_udp_services
pass in log on $ext_if inet proto udp from $local_ip to
($ext_if)
port $local_udp_services
pass out log on $ext_if all
any suggestions on how to resolve or at least further debug
this?
_______________________________________________
freebsd-pf freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
|
|
| RE: nfs send errors |
|
2008-04-29 17:54:09 |
Hi Tom
The following rule sorted it on my nfs shares
scrub in all no-df
scrub out all no-df
I've seen this mentioned on some website and that cured the
same problem you
had
Regards
Torsten
-----Original Message-----
From: owner-freebsd-pffreebsd.org [mailto:owner-freebsd-pffreebsd.org] On
Behalf Of Tom Uffner
Sent: 29 April 2008 23:14
To: freebsd-pffreebsd.org
Subject: nfs send errors
my kernel is logging errors like these:
Apr 26 04:15:13 xiombarg kernel: nfs send error 1 for server
10.69.69.21:/data0/music
Apr 27 23:20:21 xiombarg kernel: nfs send error 1 for
server
10.69.69.21:/data0/music
Apr 29 15:35:07 xiombarg kernel: nfs send error 1 for
server
10.69.69.21:/data0/music
NFS does not seem to be affected. it appears to retry the
send w/ a new
connection. all of my nfs mounts are affected, not just the
one shown
above.
it looks as if firewall is blocking packets due to state
timeouts, but
states should persist for up to 86400 seconds depending upon
state table
size and although i am nowhere near the max table size a
state appears
to have gone away in less than 2469 seconds:
14:53:58.835812 rule 45/0(match): pass out on rl0:
xiombarg.uffner.com.713 >
10.69.69.21.nfsd: S 1077685507:1077685507(0) win 65535
<mss 1460,nop,wscale
3,nop,nop,timestamp[|tcp]>
15:35:07.667381 rule 0/0(match): block out on rl0:
xiombarg.uffner.com.713 >
10.69.69.21.nfsd: P 1077857136:1077857240(104) ack
1091504052 win 16588
<nop,nop,timestamp 763469633 2221451579>
15:35:07.667571 rule 45/0(match): pass out on rl0:
xiombarg.uffner.com.1023
>
10.69.69.21.nfsd: S 772434453:772434453(0) win 65535 <mss
1460,nop,wscale
3,nop,nop,timestamp[|tcp]>
this is the pf config for the firewall between my desktop
(xiombarg) and a
mostly trusted DMZ where the nfs server lives
(10.69.69.0/24). (it also
contains rules controlling traffic to & from the
internet which duplicate
the
ones on my exterior firewall)
ext_if = "rl0"
local_ip = "{ 127.0.0.1 10.69.69.60 71.162.143.94
207.245.121.212 }"
local_tcp_services ="{ 111 143 587 993 4949 5432
}" #sunrpc, imap,
submission, imaps, munin, postgres
global_tcp_services ="{ 22 25 53 80 143 443 993 }"
#ssh, smtp, domain,
http, imap, https, imaps
local_udp_services ="{ 111 514 }"
#sunrpc, syslog
global_udp_services ="{ 53 123 }"
#domain, ntp
icmp_types = "echoreq"
table <bruteforce> persist file
"/var/db/ssh-bruteforce"
# options
set block-policy return
set loginterface $ext_if
# scrub
scrub in on $ext_if all fragment reassemble
# filter rules
block log all
pass quick on lo0 all
block drop in log quick proto tcp from <bruteforce> to
any port ssh
pass in log on $ext_if inet proto tcp from any to ($ext_if)
port $global_tcp_services
pass in log on $ext_if inet proto tcp from $local_ip to
($ext_if)
port $local_tcp_services
pass in log on $ext_if inet proto tcp from 10.69.69.21 port
2049 to
($ext_if)
pass in log on $ext_if inet proto udp from any to ($ext_if)
port $global_udp_services
pass in log on $ext_if inet proto udp from $local_ip to
($ext_if)
port $local_udp_services
pass out log on $ext_if all
any suggestions on how to resolve or at least further debug
this?
_______________________________________________
freebsd-pffreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
_______________________________________________
freebsd-pffreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
|
|
| Re: nfs send errors |
United States |
2008-04-29 22:06:27 |
Torsten CNC-bond wrote:
> The following rule sorted it on my nfs shares
>
> scrub in all no-df
> scrub out all no-df
>
> I've seen this mentioned on some website and that cured
the same problem you
> had
changed my scrub rule to "scrub all no-df fragment
reassemble"
no effect.
if it makes difference, the nfs server runs debian stable w/
linux 2.6.18
kernel, and my client is FreeBSD 8.0-CURRENT #160: Tue Apr
8 07:49:18 EDT 2008
_______________________________________________
freebsd-pffreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
|
|
| Re: nfs send errors |
United States |
2008-04-30 03:19:00 |
Tom Uffner wrote:
> changed my scrub rule to "scrub all no-df fragment
reassemble"
>
> no effect.
>
> if it makes difference, the nfs server runs debian
stable w/ linux 2.6.18
> kernel, and my client is FreeBSD 8.0-CURRENT #160: Tue
Apr 8 07:49:18
> EDT 2008
adding random-id as discussed in pf.conf under no-df does
not help either.
it appears that somebody is seeing a FIN followed by a
timeout waiting for an
ACK, because if i watch the state table i see this before
the state goes away
completely:
all tcp 10.69.69.60:841 -> 10.69.69.21:2049
ESTABLISHED:FIN_WAIT_2
does this mean the server closed the connection? it can't
mean my client did,
otherwise it wouldn't be trying to send, right?
is there an explanation somewhere of what all the fields in
a pfctl -ss (and
pfctl -vvv -ss) mean?
_______________________________________________
freebsd-pffreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
|
|
[1-4]
|
|