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:[EMAIL PROTECTED]] > Sent: Wednesday, June 26, 2002 5:31 PM > To: Matt Impett > Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' > 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 <[EMAIL PROTECTED]> USC Information > Sciences Institute > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
