Subject: Re: Odd ipf behaviour?
To: None <tech-security@netbsd.org>
From: Kimmo Suominen <kim@tac.nyc.ny.us>
List: tech-security
Date: 09/20/1999 04:29:44
  by redmail.netbsd.org with SMTP; 20 Sep 1999 04:54:21 -0000
 by hrothgar.gw.com (8.9.3/8.8.6.Beta0/2.1.kim) with USENET id AAA02092
 for tech-security@netbsd.org; Mon, 20 Sep 1999 00:33:46 -0400 (EDT)
	for tech-security@netbsd.org (tech-security@netbsd.org)
To: tech-security@netbsd.org
Date: Mon, 20 Sep 1999 04:29:44 GMT
From: Kimmo Suominen <kim@tac.nyc.ny.us>
Message-ID: <FICCHK.1Gq@tac.nyc.ny.us>
Organization: Trans-Atlantic Communications
References: <19990919221430.L485@acheron.middleboro.ma.us>
Subject: Re: Odd ipf behaviour?

I think NAT happens on incoming packets before ipf gets them.  Outgoing
packets, on the other hand, are handed to NAT after ipf has seen them.

So the odd packets probably did not have any options set?

+ Kim


mason@acheron.middleboro.ma.us (Mason Loring Bliss) writes:

| Hi. I've been looking at some strange stuff in my ipmon logs lately, and I'd
| dearly love it if someone would give me a clue about what's happening here.
| The following isn't a complete log, but it's representative of what I'm seeing.
| 
| ep0 is my outside interface. I'm using the 10.x.x.x network internally.
| Since these packets were destined to something in the ten net, don't they
| have to be source routed? Dropping packets with options is my first rule,
| but this stuff didn't get processed until way further down, PAST the ipopts
| rule. Can someone make sense of this?
| 
| Sep 18 15:58:02 acheron ipmon[194]: 15:58:02.794832              ep0 @0:12 b 209.67.38.62,80 -> 10.0.0.3,2049 PR tcp len 20 44 -AS
| Sep 19 00:30:55 acheron ipmon[282]: 00:30:54.461336              ep0 @0:12 b 130.225.51.30,80 -> 10.0.0.3,2049 PR tcp len 20 48 -AS
| Sep 19 00:30:58 acheron ipmon[282]: 00:30:57.977229              ep0 @0:12 b 130.225.51.30,80 -> 10.0.0.3,2049 PR tcp len 20 40 -A
| 
| Thanks in advance for the help. I appear not to have been cracked open, but
| it bothers me that the ipopts rule didn't snag these. I've got both the
| specific ports filtered as well as filtering packets that should be impossible
| on particular interfaces - I just want to know why this particular rule failed
| to catch the packets.
| 
| Again, thanks in advance.
| 
| -- 
|     Mason Loring Bliss  mason@acheron.middleboro.ma.us  They also surf who
| awake ? sleep : dream;  http://acheron.ne.mediaone.net  only stand on waves.
| 
-- 
Kimmo Suominen