Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Jul 2001 00:04:51 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Matt Dillon <dillon@earth.backplane.com>
Cc:        Steven Ames <steve@virtual-voodoo.com>, "Jonathan M. Slivko" <jslivko@blinx.net>, Chris Dillon <cdillon@wolves.k12.mo.us>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Why two cards on the same segment...
Message-ID:  <3B611293.E29BF68A@mindspring.com>
References:  <Pine.BSF.4.32.0107261528390.2406-100000@mail.wolves.k12.mo.us> <001701c11614$94114000$6401a8c0@equinox> <00fa01c11615$73cccb10$28d90c42@eservoffice.com> <003401c11616$d2a8e460$6401a8c0@equinox> <011d01c11617$10b96950$28d90c42@eservoffice.com> <200107262136.f6QLaCX62360@earth.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Matt Dillon wrote:
>     I wish it were that easy.  If you have two interfaces on the same LAN
>     segment, but one is configured with an internal IP and one is
>     configured with an external IP, and the default route points out the
>     interface configured with the external IP, then you are ok.
> 
>     If you have one interface with *two* ip addresses.  For example (taking
>     a real life example):

[ ... ]

>     Then the 'source IP' address the machine uses is completely up in the
>     air.   It could be the external IP, or the internal IP, and it could
>     change out from under you if you manipulate the interface with ifconfig.
>     You have to explicitly bind to the correct source IP if you care.
> 
>     For our machines I bind our external services specifically to the
>     external IP.  Beyond that I usually don't care because I NAT-out our
>     internal IP space anyway, so any packets sent 'from' an internal IP
>     to the internet wind up going through the NAT, which hides the fact
>     that the source machine chose the wrong IP.

This doesn't really work well with DSR (Direct Server Return),
where you bind the loopback interface on a web server to a
common IP address, and then bind your front end processor to
that address by default, and then forward packet requests to
a back end server at random, when received by the front end.

This is also known as a Layer 4 load balancing switch.

As FreeBSD currently sits, it can't be used as the back end
server for this configuration, since it doesn't use the
destination address for the response, it uses the default
gateway, instead.

The problem here is that for the back end, the packet comes
in on the public interface with a destination address of the
alias on the loopback, and the response gets sent out the
public address instead of the loopback alias.

You actually need to send this out the loopback alias, so
that the client machine sees that the IP address to which
it sent the request is the IP address from which the reply
originated.

Linux, NT, and Solaris all do the right thing -- FreeBSD
does the wrong thing.  I haven't tested NetBSD or OpenBSD,
but since they appear to be running the standard (non-FreeBSD)
routing code, I expect that they probably do the right thing.

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B611293.E29BF68A>