On 2007-01-04 22:43, Gary Mills wrote:
> I've already found most of those.  There are lots of daemons that will
> forward TCP connections.  I've tried some of them.  The problem with
> them is that they initiate new connections.  That means that the
> originating IP address is lost.  I want to preserve that information
> so that client logging works correctly on the destination server.

Think about what actually would happen in your desired scenario:

1. Remote client C sends a SYN packet from source endpoint C:P to
service destination endpoint D:S, which resides on a translating box D.
On the client, the socket is in SYN_SENT state with remote endpoint D:S.

2. Translating box receives SYN packet and translates destination to E:T
and retransmits it to serving box E. So now the SYN packet is C:P -> E:T.

3. Serving box E receives the SYN packet and responds with a SYN/ACK
from E:T -> C:P. The socket on the serving box is in SYN_RCVD state with
remote endpoint C:P. Since the SYN/ACK destination C is remote, E sends
the packet out through the default router, so the translating box D
never sees this packet.

4. Client box C receives SYN/ACK from E:T and discards it, because it
has no pending TCP connection in SYN_SENT state with E:T as the remote
endpoint.

To do it with IP Filter, you have to have the SYN/ACK packet travel back
through the IP Filter box so the inverse translation can happen. This
would map the E:T endpoint on the return traffic back to D:S so that the
remote client would recognize it. The normal way to accomplish this is
to have two interfaces on the IP Filter box and use it as a firewall
with C on the outside and E on the inside. Conceivably, if the IP Filter
box were designated as the default gateway for E, it could work, but I
wouldn't stake any money on it. IP Filter is not designed for that
application.

There is cluster load balancing that relies on shared IPs and ARP
balancing and does no translation of destinations, but this is a
completely different animal from IP Filter and requires a specialized
network setup.

-- 
Jefferson Ogata <[EMAIL PROTECTED]>
NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
"Never try to retrieve anything from a bear."--National Park Service

Reply via email to