Re: ipf/ipnat behavior

[Darren Reed <darrenr%netbsd.org@localhost>]

Paul Goyette wrote:
> On Sat, 31 May 2008, Darren Reed wrote:
>
> > > bad packets: in 0 out 0
> > > IPv6 packets: in 0 out 0
> > > input packets: blocked 0 passed 3154 nomatch 1623 counted 0 short 0
> > > output packets: blocked 0 passed 3149 nomatch 1616 counted 0 short 0
> ...snip...
> > > Result cache hits(in): 1531 (out): 1533
> ...snip...
>
> > I see nothing to indicate that any packets are blocked.
>
> Yeah, I misunderstood the 'nomatch' entries.  It seems that nomatch is 
> the opposite of cache-hit

Not quite.
"no-match" is a count of packets that didn't match any rules from ipf.conf
"cache hit" is the number of successive packets that matched.


> > That said, IPFilter will automatically drop a packet if:
> > - it matched a NAT rule but it could not create a new NAT session
> > - ipfilter to get the entire packet in one mbuf but could not do so
> > - it matched a "keep state" rule but ipf could not add the state
>
> Well, the NFS accesses are happening on the non-natted side of things,
> and there are no ipfilter rules other than the nat rules.  And new nat 
> sessions are being created all the time.
>
> It's odd.  One of the remote file systems fails on any access, even a 
> ls for its top level directory (which contains only five entries).  On 
> the other remote file system I can actually cd several directory 
> levels down.  But as soon as I try to read a file it hangs.  In all 
> cases, the hang is for wchan=netio
>
> I'd really like to dig deeper and resolve this, but I'm totally 
> clueless when it comes to the ipfilter/ipnat code.  If you can give me 
> a hint on how to approach this I'd appreciate it. 

How much of your NFS traffic is TCP vs UDP?
If you force it to all be UDP, does the problem go away?

Darren