pf blocking nfs

From: Aaron P. Martinez (ml_at_proficuous.com)
Date: 11/30/05

  • Next message: Chuck Swiger: "Re: pf blocking nfs" 
    Date: Tue, 29 Nov 2005 20:58:48 -0600 (CST)
To: freebsd-questions@freebsd.org

    I am running FreeBSD 6.0-release and setting up a very basic firewall
    using pf on my workstation. The ruleset is as follows:

    block in log all
    pass quick on lo0 all
    #pass in on $ext_if proto tcp from any to $ext_if port 22 keep state
    pass out on fxp0 proto { tcp, udp, icmp } all keep state

    I am mounting /home on a linux machine to /usr/home on my workstation as i
    have done for years. I'm new to freebsd but i have
    nfs_client_enable="YES" and rpcbind_enable="YES", which by all
    documentation i have read should be more than enough. The problem i'm
    experiencing is that pf is blocking nfs packets and my workstation thinks
    that the nfs server is not responding. to further complicate this,
    directories that don't have much in them on the exported server seem to
    work fine but users that have a ton of stuff just hang when trying to list
    the contents or switch to the direcotry. disabling pf will make things
    start working again. One more glitch is that sometimes, not often, things
    work as expected even with pf enabled. I can't figure what's going on.
    Below is some output from pflog as it's blocking the nfs packets.

    000235 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 0, offset
    0, flags [DF], proto: UDP (17), length: 239) 192.168.3.94.138 >
    192.168.3.95.138:
    >>> NBT UDP PACKET(138) Res=0x110A ID=0x42BE IP=192 (0xc0).168 (0xa8).3
    (0x3).94 (0x5e) Port=138 (0x8a) Length=197 (0xc5) Res2=0x0
    SourceName=
    WARNING: Short packet. Try increasing the snap length

    202. 510573 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.3.94.2049 >
    192.168.3.69.325876150: reply ok 1472
    000083 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000122 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 2960, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000121 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 4440, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000125 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 5920, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000072 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4076,
    offset 7400, flags [none], proto: UDP (17), length: 828) 192.168.3.94 >
    192.168.3.69: udp
    1. 587911 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.3.94.2049 >
    192.168.3.69.325876150: reply ok 1472
    000084 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000134 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 2960, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000124 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 4440, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000119 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 5920, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000051 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4077,
    offset 7400, flags [none], proto: UDP (17), length: 828) 192.168.3.94 >
    192.168.3.69: udp
    3. 167948 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.3.94.2049 >
    192.168.3.69.325876150: reply ok 1472
    000096 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000125 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 2960, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000118 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 4440, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000131 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 5920, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000078 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4078,
    offset 7400, flags [none], proto: UDP (17), length: 828) 192.168.3.94 >
    192.168.3.69: udp
    6. 326312 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 0, flags [+], proto: UDP (17), length: 1500) 192.168.3.94.2049 >
    192.168.3.69.325876150: reply ok 1472
    000094 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 1480, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000114 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 2960, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000124 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 4440, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000125 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 5920, flags [+], proto: UDP (17), length: 1500) 192.168.3.94 >
    192.168.3.69: udp
    000050 rule 0/0(match): block in on fxp0: (tos 0x0, ttl 64, id 4079,
    offset 7400, flags [none], proto: UDP (17), length: 828) 192.168.3.94 >
    192.168.3.69: udp

    I can't tell why this isn't working. I know that udp is stateless, but i
    was inclined to believe that you could still use state tracking with pf.
    I'd really like to have the firewall in place when this machine is
    connected to the internet...

    TIA,

    Aaron Martinez
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"

  • Next message: Chuck Swiger: "Re: pf blocking nfs"

    Relevant Pages

    • NFS Lock Problem Suse 7.3 <-> 8.2
      ... Everything worked fine with my workstation and server both running SuSe 7.3. ... 100000 2 udp 111 portmapper ... franz:~ # /etc/init.d/nfslock status ...
      (alt.os.linux.suse)
    • RE: logging in but then loss of domain connection
      ... It sounds like the workstation is unable to find the Domain controller. ... happens if you connect the laptop to the network using a network cable? ... The clients use UDP to authenticate. ... Kerberos to use TCP by making a registry change. ...
      (microsoft.public.windows.server.sbs)
    • Re: logging in but then loss of domain connection
      ... > It sounds like the workstation is unable to find the Domain controller. ... > happens if you connect the laptop to the network using a network cable? ... We have seem issues whereby the UDP ... > Kerberos to use TCP by making a registry change. ...
      (microsoft.public.windows.server.sbs)
    • Re: Messages being received in packs
      ... that makes sense Rich because it is only one user and only one workstation. ... Can you tell me what I need to do - I googled UDP packets and it didn't help ... there's a problem with the delivery of UDP ...
      (microsoft.public.exchange.admin)
    • Re: Messages being received in packs
      ... there's a problem with the delivery of UDP ... The Exchange server sends a UDP packet once every minute (as long as ... there are unread messages) to the workstation. ... if the packets don't arrive there's no harm and no missing data. ...
      (microsoft.public.exchange.admin)