On Fri, 29 Sep 2000 11:04:51 -0400 (Eastern Daylight Time)
	Jon Lindgren <jlindgren@slk.com>  wrote:
>	On Fri, 29 Sep 2000, Paul Newhouse wrote:
>
>	Strange.  With the exact same ruleset?  If so, then at least one version
>	contains a bug...

Well, I've changed it around some trying to get it to route these packets like
I want, but yeah, pretty close to the same rule set.

>	> Well, yes and no.  You're saying it shouldn't work which makes me wonder
>	> what the point of the rule is?  I thought it was to correct/coerce/subvert 
>	> the default routing.
>
>	That is correct... I didn't account for this rule:
>
>	pass out log quick on tlp1 to ne0 from 24.15.220.14 to any
>
>	Which should reroute exactly the packet you specified.  Do you have any
>	other matching 'quick' rules which would match before this one?  That's
>	the only thing I can think of now, besides perhaps a bug in ipf.  

This starts at the first rule:

   block in  proto tcp all with short
   #
   # drop any source routing options
   #
   block in log quick all with opt lsrr
   block in log quick all with opt ssrr
   block in log quick from any to any with ipopts
   block in log quick proto tcp from any to any with short
   #
   # return incoming cable modem connections back out cable modem
   #
   pass out log quick on tlp1 to ne0 from 24.15.220.14 to any      
   #
   #       deny at home's port scanning
   #
   block in log quick from 24.0.94.130 to any
   #
   #       multi-homed routing
   #
   pass out log quick on ne0 to tlp1 from 209.128.91.40/29 to any  
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.40 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.41 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.42 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.43 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.44 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.45 to any
   pass out log quick on ne0 to tlp1 proto tcp/udp from 209.128.91.46 to any
   pass out log quick on ne0 to ppp0 proto tcp/udp from any to 172.17/24
   pass out log quick on tlp1 to ppp0 proto tcp/udp from any to 172.17/24

The ppp0 munging is wrong of course since I don't know for sure that the 172.17
subnet will actually be assigned to ppp0 (it usually is).  I have two VPN's
(pppd tunnelled through ssh) that can be either ppp0 or ppp1 (and sometimes ppp2
or ppp3 or ppp4).  A solution for that would be useful as well, but it's a
petty (albiet annoying) problem compared to the ne0 routing breakage.

>	Either that, or you can try ipftest to see exactly what happens.

I'll look into ipftest.

>	> I'm running "routed -q" is that the right thing to be doing?  Should I
>	> be running some other routing daemon? (Gated or something?)
>
>	Mmmm... not sure.  Host-implemented routing and I have never been
>	the best of friends.  I prefer a router based solution which is
>	transparent to hosts, so my knowledge on gated/routed ain't what it should
>	be.  Sorry.

Well, the NetBSD box is functioning mostly as a router and not much else ;))

Thanks,
Paul