> Return-Path: tech-net-owner-sommerfeld=netbsd.org@netbsd.org
> Delivery-Date: Wed Apr 19 17:42:44 2000
> Received: from orchard.arlington.ma.us (stack.hamachi.org [4.255.0.97])
> 	by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id RAA26567
> 	for <sommerfeld@orchard.arlington.ma.us>; Wed, 19 Apr 2000 17:42:44 GMT
> Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253])
> 	by  orchard.arlington.ma.us (8.8.8/8.8.8) with SMTP id NAA14366
> 	for <sommerfeld@orchard.arlington.ma.us>; Wed, 19 Apr 2000 13:42:43 -0400 (EDT)
> Received: (qmail 11260 invoked by uid 1099); 19 Apr 2000 17:42:30 -0000
> Delivered-To: sommerfeld@netbsd.org
> Received: (qmail 11135 invoked by uid 605); 19 Apr 2000 17:42:28 -0000
> Received: (qmail 11129 invoked from network); 19 Apr 2000 17:42:24 -0000
> Received: from twig.rodents.montreal.qc.ca (root@216.46.5.3)
>   by mail.netbsd.org with SMTP; 19 Apr 2000 17:42:24 -0000
> Received: (from mouse@localhost)
> 	by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA17004;
> 	Wed, 19 Apr 2000 13:42:16 -0400 (EDT)
> Date: Wed, 19 Apr 2000 13:42:16 -0400 (EDT)
> From: der Mouse  <mouse@Rodents.Montreal.QC.CA>
> Message-Id: <200004191742.NAA17004@Twig.Rodents.Montreal.QC.CA>
> Mime-Version: 1.0
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: 8bit
> To: tech-net@netbsd.org
> Subject: Re: ipip and gif
> Sender: tech-net-owner@netbsd.org
> Precedence: list
> Delivered-To: tech-net@netbsd.org
> 
> >> I implemented a tunnel for my home netlink (I found I couldn't use
> >> existing tunnel code; I can explain why if anyone cares)
> > Did it have something to do with many, many sites blocking all ICMP
> > packets, including "must fragment"?
> 
> No, though that is a problem - when a host trying to do MTU discovery
> is behind such a misconfigured router, communication breaks down.  I've
> tried writing to a few such; so far I've gotten only one response, from
> a site saying "we used to but then we fixed it because of exactly the
> problem you bring up - I don't know why you're still having trouble".
> I offered to do what I could to help track down the problem, but never
> got a reply to that.
> 
> No, the reasons I couldn't use existing tunnel code were:
> 
> - One of the inner tunnel addresses (my home end) is liable to change
>    with no warning; somehow this has to be communicated to the other
>    end so it knows where to send packets.
> 
> - The packets are signed.  (I could encrypt them as well, but haven't
>    perceived a need yet.)
> 
> - There are actually two tunnels, decision between which is made based
>    on the *source* address of the packet.  (For example, 132.206.78.3
>    and 216.46.5.3 are the same machine; if an outgoing packet has
>    source address 132.206.78.3 it goes down one tunnel, whereas if it
>    has source address 216.46.5.3 it goes down the other.)

it's a hack, but you can use ipf to select the outbound interface
based on the source address.

an ipf rule of the form:

pass out quick on ep0 to gif1 from 4.255.0.96/27 to any

works for me.  ("ep0" is the interface attached to the cable modem;
gif1 is the local tunnel endpoint.)

						- Bill