Julian Elischer wrote: > On Mon, 6 Oct 2003, Leo Bicknell wrote: > > In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote: > > > In addition to keeping your NAT translations (as suggested by > > > Wes), you need to also keep routes for those entries as well, so > > > that preserved traffic remains to route out the right ISP even if > > > a switch occurs. > > > > You're right, however I would go with a different mechanism, but one > > I've also never tried to do. What you want is routing based on the > > source address of the packet, not the destination as per usual. You > > want to be able to say "source a.a.a.a goes out link A". I've never > > tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a > > performance hit on some platforms). > > this is very easy using the ipfw 'fwd' rule..
Actually, it's very hard; the 'fwd' rule doesn't quite cut it for things like, for example, NFS. It also fails to work with aliases, when you want the packet sent from a specific IP on a given interface. There are some workarounds, like binding it locally to an IP, but that's not so good when you are wanting to be able to change IP addresses, as in the case in point. Cisco really does routing differently. One thing that would be handy is a socket type that was a TCP stream socket, but which was bound to an interface, rather than to a specific IP address. This only solves some of the problems, like not having to restart your already listening servers when the IP address changes out from under it (e.g. the "kick sendmail in the head" issue we had with the InterJet I's & II's when they were running dialup in dial-on-demand mode). Really, you need to have routing implemented like it's implemented in Cisco's, and associate the reverse route with the last packet you received from a given IP address (you always have this because you had to have it to do the handshake). The FreeBSD routing code tends to get the routing wrong some of the time, particularly in picking the local address to send a packet "from". The problem with the ipfw forwarding is that you don't apriori know who's going to be talking to you, so you can't really make preestablished rules for the forwarding for every possible IP address that's non-local and across one link or the other. I suppose you could establish rules when you saw packets, but that would require running as root, and hacking all your servers to "do the right thing" anytime you got a connection. -- Terry _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
