From owner-freebsd-questions Wed Jun 26 17:17:44 2002 Delivered-To: freebsd-questions@freebsd.org Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by hub.freebsd.org (Postfix) with ESMTP id 0B57A37BABE; Wed, 26 Jun 2002 16:08:21 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 Jun 2002 17:42:55 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46FDE779@ftmail.lab.flarion.com> From: Matt Impett To: 'Lars Eggert' , Matt Impett Cc: "'freebsd-net@freebsd.org'" , "'freebsd-questions@freebsd.org'" Subject: RE: source address based routing Date: Wed, 26 Jun 2002 17:42:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Ok.. Modifying the ipfw stuff is where I ended up after looking at this for a while. I have thought about adding something like the following: ipfw add fwd-intf GIF-DEVICE all from SOURCE to any The only problem I have seen with this (besides needing to modify the kernel and the user space ipfw application) was this: Once this rule is matched, the output routine of the GIF-DEVICE will be called and it will expect a rtentry structure to be passed. Unfortunately, I won't really have a correct rtentry structure as I am now forwarding to the device on a firewall rule instead of a routing table entry. However, from looking at the gif code, I don't think it really uses the rtentry structure anyway, so hopefully I won't break too much by passing a bogus one. Sound reasonable?? matt > -----Original Message----- > From: Lars Eggert [mailto:larse@ISI.EDU] > Sent: Wednesday, June 26, 2002 5:31 PM > To: Matt Impett > Cc: 'freebsd-net@freebsd.org'; 'freebsd-questions@freebsd.org' > Subject: Re: source address based routing > > > Matt Impett wrote: > > gladly.. I am trying to implement reverse tunneling for > mobile-IP. The > > basic idea is that packets must be reverse tunneled to different IP > > addresses depending on the source address of the packet. > The reason the > > tunnel does not have an IP address associated with it is > that I don't want > > to forward traffic down the tunnel for any other reason > besides source > > addresses. As soon as I assign the tunnel interface an > address, traffic > > sent to that address will be tunneled. > > Thanks, that was really helpful to get an idea of what your > scenario is! > > >> route add DUMMY_NEXT_HOP -interface GIF > >> ipfw add fwd DUMMY_NEXT_HOP all from SOURCE to any > > > > > > I have thought about doing this, but am a little concerned > about assigning > > DUMMY_NEXT_HOP. As soon as I issue "route add > DUMMY_NEXT_HOP -interface > > GIF", that DUMMY_NEXT_HOP address is now unusable by anyone else. > > Therefore, I guess it would have to be private, but then > this would stop > > anyone from actually using this private address in the local domain. > > Well, nobody should be using a private address in any domain that's > connected to the Internet, so you may be safe there. > > If not, then you could do either > > (1) modify ipfw to allow specification of a local interface (as > opposed to a gatway IP adress) in the fwd rule > or > (2) buy a large enough IP block so you can use your own > addresses for DUMMY_NEXT_HOP > > > Plus, > > I don't know how many DUMMY_NEXT_HOPs to allocate, as I > would need one for > > each tunnel I have set up, and the number of tunnels I set > up is dependent > > on the number of mobile's that come into the system (which > is somewhat of an > > unknown). > > This makes (2) look infeasible, but (1) may still be an option. > > Lars > -- > Lars Eggert USC Information > Sciences Institute > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message