Changing the NAT IP on demand?
tlambert2 at mindspring.com
Tue Oct 7 03:33:06 PDT 2003
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.
More information about the freebsd-hackers