Re: Unusual traffic over firewall?

["Gary O'Neill" <gary@hedgehog.dhs.org>]

Roger Seielstad wrote:
> 
> > Original poster here:
> >
> > My connection is cable, however the traffic is originating
> > from sources
> > well outside of my local cable network -- hotmail.com, for example.
> > Basically, any site I go to ends up getting logged.
> > Can this be explained by anybody?
> >
> > My concept of NAT is as follows:
> >       1) Externally originated packet travels in over external gateway
> > interface addressed to gateway.  Packet filtering occurs at
> > this point.
> >       2) Gateway then rewrites the destination address (and
> > port) to the
> > appropriate internal host's IP and port.
> >       3) Rewritten packet travels out over internal gateway interface,
> > addressed to an internal host.  Packet filtering can also
> > occur at this
> > point.
> >
> > Gary
> >
> 
> Hmmm... I saw a LOT of traffic (I just checked - all my logs have already
> rolled, so I don't have any examples) of RFC1918 addresses being presented
> to my outside interface with a destination of almost everywhere, but never
> with a source of that.
> 
> My understanding of the packet flow is the same as yours, so I think we're
> looking at the same things.
> 
> In your IPF.rules, do you have a line like: (ne3 is my external interface)
> pass out quick on ne3 proto tcp from any to any keep state
> 
> I wonder if you're logging your own NAT traffic by accident. The keep state
> directive, as you probably know, allows return traffic to bypass the filters
> on the way back in.
> 
> Roger

Roger:

The IPF rules concerning outgoing traffic are as follows:

pass out on xl0 all
pass out on xl0 proto tcp  from any to any keep state
pass out on xl0 proto udp  from any to any keep state
pass out on xl0 proto icmp from any to any keep state

(I currently have no other rules governing outgoing traffic so it is as
if I used the 'quick' directive)

This logging may be a result of state table timeouts, but that still
doesn't explain the destination address if the basic steps (1), (2), and
(3) as quoted above hold.  

If however NAT takes place before (1), then because the state rule
bypasses all filtering, the logging is accounted for.  So you are right;
I am logging my own NAT traffic after it has timed out.

Based on this, the conclusion is that there is nothing wrong with my
ruleset, but perhaps the timeout values affecting NAT should be
adjusted.

Will adjusting these defaults require editing kernel headers, or is this
configurable elsewhere?

Thanks for any ideas,

Gary