Re: pf blocking nfs
On Thu, 2005-12-01 at 02:40 +0100, J65nko BSD wrote: > [snip] > > In your original post, there was something about a short packet. I'm > > guessing this might screw things up. You might try adding 'scrub in all' > > before the filtering rules. > > > [smip] > > Be careful with scrub and NFS. From http://openbsd.bay13.net/faq/pf/scrub.html > > "One reason not to scrub on an interface is if one is passing NFS > through PF. Some non-OpenBSD platforms send (and expect) strange > packets -- fragmented packets with the "do not fragment" bit set, > which are (properly) rejected by scrub." Well, it looks like scrub fixed the issue. I had originally removed the scrub in all line because i too had read in the OBSD faq that scrub might be what was messing up my nfs connection. I put it back and i'm back to my one one state tracting rule for all outbound traffic for this machine. Just so everyone can see, this is the ruleset and it's working properly: scrub in all block in log all pass quick on lo0 all pass out on fxp0 proto { tcp, udp, icmp } all keep state thanks to everyone that helped, Aaron Martinez ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
[snip] > In your original post, there was something about a short packet. I'm > guessing this might screw things up. You might try adding 'scrub in all' > before the filtering rules. > [smip] Be careful with scrub and NFS. From http://openbsd.bay13.net/faq/pf/scrub.html "One reason not to scrub on an interface is if one is passing NFS through PF. Some non-OpenBSD platforms send (and expect) strange packets -- fragmented packets with the "do not fragment" bit set, which are (properly) rejected by scrub." ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
On Wed, Nov 30, 2005 at 05:42:30PM -0600, Aaron Martinez wrote: > On Wednesday 30 November 2005 11:02, Roland Smith wrote: > > On Tue, Nov 29, 2005 at 08:58:48PM -0600, Aaron P. Martinez wrote: > > > 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 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... > > > > Reading the pf manuals, it is supposed to work. > > > > Have you tried explicitly letting the required traffic through? > > > > pass out on fxp0 proto { tcp, udp } to $nfsserver port { sunrpc, > > nfsd-status, nfsd, lockd } keep state > > > > Where $nfsserver is the server's IP address. > > > > If that still doesn't work, try: > > > > pass out on fxp0 proto { tcp, udp } from any to $nfsserver port { sunrpc, > > nfsd-status, nfsd, lockd } pass in on fxp0 proto { tcp, udp } from > > $nfsserver to any port { sunrpc, nfsd-status, nfsd, lockd } > > > > > > Roland > > I thought for sure the last example here would solve the issue, but i'm still > stumped. My current 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 > pass out on fxp0 proto { tcp, udp } to 192.168.3.94 port { sunrpc, nfsd, > nfsd-status, lockd } keep state > pass in on fxp0 proto { tcp, udp } from 192.168.3.94 port { sunrpc, nfsd, > nfsd-status, lockd } keep state > > That didn't work so i tried: > > 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 > pass out on fxp0 proto { tcp, udp } to 192.168.3.94 port { sunrpc, nfsd, > nfsd-status, lockd } > pass in on fxp0 proto { tcp, udp } from 192.168.3.94 port { sunrpc, nfsd, > nfsd-status, lockd } I think this should be pass in on fxp0 proto { tcp, udp } from 192.168.3.94 to any port { sunrpc, nfsd, nfsd-status, lockd } You could also try: pass in on fxp0 proto { tcp, udp } from 192.168.3.94 to $workstation pass out on fxp0 proto { tcp, udp } from $workstation to 192.168.3.94 If that doesn't work, I don't know what will. > which was even worse, with this setup i couldn't even switch to the /home > directory. > > Still no go. I'm not sure if i have to reboot after changing the pf.conf > ruleset, i have just been stopping pf with pfctl -d, flushing the rules with > pfctl -F rules, loading the modified rules from /etc/pf.con with, pfctl > -f /etc/pf.conf and then re-enabling pf with, pfctl -e. Hope someone can > shed some light on this. Part of my whole reason for switcing to the BSDs > was my interest in pf, but this not keeping state is really letting me down. I think the best way is to use '/etc/rc.d/pf reload'. > I've said this before but i feel like it's worth mentioning again, even with > the single line: > pass out on fxp0 proto { tcp, udp, icmp } all keep state > > i can switch to the /usr/home directory and even go into any directory that > doesn't have a lot of files/folders in it. I only seem to have problem with > one home directory that is really loaded up. In your original post, there was something about a short packet. I'm guessing this might screw things up. You might try adding 'scrub in all' before the filtering rules. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpJqFztPKXSJ.pgp Description: PGP signature
Re: pf blocking nfs
On Wednesday 30 November 2005 11:02, Roland Smith wrote: > On Tue, Nov 29, 2005 at 08:58:48PM -0600, Aaron P. Martinez wrote: > > 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 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... > > Reading the pf manuals, it is supposed to work. > > Have you tried explicitly letting the required traffic through? > > pass out on fxp0 proto { tcp, udp } to $nfsserver port { sunrpc, > nfsd-status, nfsd, lockd } keep state > > Where $nfsserver is the server's IP address. > > If that still doesn't work, try: > > pass out on fxp0 proto { tcp, udp } from any to $nfsserver port { sunrpc, > nfsd-status, nfsd, lockd } pass in on fxp0 proto { tcp, udp } from > $nfsserver to any port { sunrpc, nfsd-status, nfsd, lockd } > > > Roland I thought for sure the last example here would solve the issue, but i'm still stumped. My current 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 pass out on fxp0 proto { tcp, udp } to 192.168.3.94 port { sunrpc, nfsd, nfsd-status, lockd } keep state pass in on fxp0 proto { tcp, udp } from 192.168.3.94 port { sunrpc, nfsd, nfsd-status, lockd } keep state That didn't work so i tried: 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 pass out on fxp0 proto { tcp, udp } to 192.168.3.94 port { sunrpc, nfsd, nfsd-status, lockd } pass in on fxp0 proto { tcp, udp } from 192.168.3.94 port { sunrpc, nfsd, nfsd-status, lockd } which was even worse, with this setup i couldn't even switch to the /home directory. Still no go. I'm not sure if i have to reboot after changing the pf.conf ruleset, i have just been stopping pf with pfctl -d, flushing the rules with pfctl -F rules, loading the modified rules from /etc/pf.con with, pfctl -f /etc/pf.conf and then re-enabling pf with, pfctl -e. Hope someone can shed some light on this. Part of my whole reason for switcing to the BSDs was my interest in pf, but this not keeping state is really letting me down. I've said this before but i feel like it's worth mentioning again, even with the single line: pass out on fxp0 proto { tcp, udp, icmp } all keep state i can switch to the /usr/home directory and even go into any directory that doesn't have a lot of files/folders in it. I only seem to have problem with one home directory that is really loaded up. Thanks again, Aaron martinez ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
Will Maier <[EMAIL PROTECTED]> writes: > On Tue, Nov 29, 2005 at 09:56:59PM -0600, Aaron P. Martinez wrote: > > > Aaron P. Martinez wrote: > [...] > > I realize i could just accept all udp packets from the NFS server or even > > just ports 2049, but the underlying question is, why isn't my "keep state" > > rule handling this. > > I don't use pf (or NFS), but UDP is a stateless protocol. I wouldn't > be surprised if pf couldn't keep track of its state... No, that's a big part of *why* you want pf to keep track of its state. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
On Wed, Nov 30, 2005 at 06:52:25AM -0600, Will Maier wrote: > On Tue, Nov 29, 2005 at 09:56:59PM -0600, Aaron P. Martinez wrote: > > > Aaron P. Martinez wrote: > [...] > > I realize i could just accept all udp packets from the NFS server or even > > just ports 2049, but the underlying question is, why isn't my "keep state" > > rule handling this. > > I don't use pf (or NFS), but UDP is a stateless protocol. I wouldn't > be surprised if pf couldn't keep track of its state... It is supposed to work, except for FTP. Roland -- R.F.Smith (http://www.xs4all.nl/~rsmith/) Please send e-mail as plain text. public key: http://www.xs4all.nl/~rsmith/pubkey.txt pgpqrdTn87PMP.pgp Description: PGP signature
Re: pf blocking nfs
On Tue, Nov 29, 2005 at 09:56:59PM -0600, Aaron P. Martinez wrote: > > Aaron P. Martinez wrote: [...] > I realize i could just accept all udp packets from the NFS server or even > just ports 2049, but the underlying question is, why isn't my "keep state" > rule handling this. I don't use pf (or NFS), but UDP is a stateless protocol. I wouldn't be surprised if pf couldn't keep track of its state... -- o--{ Will Maier }--o | jabber:[EMAIL PROTECTED] | email:[EMAIL PROTECTED] | | [EMAIL PROTECTED] | [EMAIL PROTECTED] | *--[ BSD Unix: Live Free or Die ]--* ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
> Aaron P. Martinez wrote: > [ ... ] >> Actually my network looks like this: >> >> INT---firewall--internal router/firewall-good lan >> || >> ||-insecure lan (windoze >> machines) >> | >> |DMZ >> >> the good lan is the only one that does nfs, so the nfs doesn't actually >> pass through the firewall, just connects to the internal >> router/firewall. >> I am simply trying to avoid a worst case scenario (internal router gets >> compromised) so trying to allow ONLY return packets. Is this >> unfeasable? > > I take it that your internal firewall box has three NICs, then? > > Normally, your firewall should not be doing anything else but security > and would not be mounting NFS or depending on any other services on your > network. If that is not possible, you should permit traffic through the > interface on the "good LAN". > > -- > -Chuck the "main" firewall, which connects to the internet does nothing else but filter incoming connections, but i'm a little more lax with the internal which seperates my my lans (and actually there are 3 bad lans, one good, and the connection to the main firewall... so 5 nics) the problem i'm experiencing isn't with the firewall on the nfs server, it has always seemed to work, even with linux workstation when i had only one rule in iptables on the input chain: iptables -A INPUT -m state -ESTABLISHED -j ACCEPT ..that seems to be fine (iptables), the workstation is where the problems seem to arise. When the aforementioned 3 line pf.conf is enabled i can connect to and mount the nfs /home directory, just when i try to go into or list the contents of a large directory, it seems that pf loses the state for some reason. I realize i could just accept all udp packets from the NFS server or even just ports 2049, but the underlying question is, why isn't my "keep state" rule handling this. thanks again, Aaron Martinez ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
Aaron P. Martinez wrote: [ ... ] > Actually my network looks like this: > > INT---firewall--internal router/firewall-good lan > || > ||-insecure lan (windoze machines) > | > |DMZ > > the good lan is the only one that does nfs, so the nfs doesn't actually > pass through the firewall, just connects to the internal router/firewall. > I am simply trying to avoid a worst case scenario (internal router gets > compromised) so trying to allow ONLY return packets. Is this unfeasable? I take it that your internal firewall box has three NICs, then? Normally, your firewall should not be doing anything else but security and would not be mounting NFS or depending on any other services on your network. If that is not possible, you should permit traffic through the interface on the "good LAN". -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
> Aaron P. Martinez wrote: >> 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 > > Your firewall config is not enough to permit NFS to pass. You might > consider adding a "pass all" rule for machines on the local subnet. > > [ Perhaps you should re-evaluate your network so that you do not attempt > to pass NFS through the firewall. If you have to do filesharing between > machines over an untrusted connection, should should consider a VPN or > SSH tunnel approach instead. ] > > -- > -Chuck Actually my network looks like this: INT---firewall--internal router/firewall-good lan || ||-insecure lan (windoze machines) | |DMZ the good lan is the only one that does nfs, so the nfs doesn't actually pass through the firewall, just connects to the internal router/firewall. I am simply trying to avoid a worst case scenario (internal router gets compromised) so trying to allow ONLY return packets. Is this unfeasable? Can you suggest a rule instead of: pass out on fxp0 proto { tcp, udp, icmp } all keep state or in addition to that would still keep me very secure and at the same time allow me to use nfs as i'm trying? thanks for the quick reply, Aaron Martinez ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf blocking nfs
Aaron P. Martinez wrote: > 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 Your firewall config is not enough to permit NFS to pass. You might consider adding a "pass all" rule for machines on the local subnet. [ Perhaps you should re-evaluate your network so that you do not attempt to pass NFS through the firewall. If you have to do filesharing between machines over an untrusted connection, should should consider a VPN or SSH tunnel approach instead. ] -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
pf blocking nfs
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 83 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 72 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 84 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 51 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 96 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 78 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 94 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, f