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]"
