Re: NATD and Address Redirection

From: Yar Tikhiy (yar_at_comp.chem.msu.su)
Date: 07/26/03

  • Next message: Danny Braniss: "Re: recent mplayer port spinning?" 
    Date: Sat, 26 Jul 2003 11:13:59 +0400
To: Clement Laforet <sheepkiller@cultdeadsheep.org>

    On Sat, Jul 26, 2003 at 02:22:05AM +0200, Clement Laforet wrote:
    >
    > for incoming traffic, you must use -redirect_address, but for outgoing
    > you have to set -alias_address.
    > If you want to use a specific public IP to map incoming AND outgoing
    > packets, you need to run 2 natd, using ipfw matching.

    I'm afraid this is not exactly correct.

    IIRC when 5 years ago I was hacking natd and libalias to use them
    for transparent HTTP proxying, their internals looked rather clear.
    In a nutshell, they were as follows.

    There was a translation table inside libalias with 3 columns in it:
    the internal connection point (IP&port), alias point, and external
    point.

    When a packet was heading outside, its source IP&port were matched
    against the "internal" column, and its destination IP&port against
    the "external" column. If an entry were found, the packet's source
    IP&port would be replaced with the values from the "alias" column.

    When a packet was going in the opposite direction, inside, its
    source IP&port were matched against the "external" column, and its
    destination IP&port against the "alias" column. Then the packet's
    destination IP&port were replaced with the values from the "internal"
    column of the entry found.

    By specifying a redirect_address rule, just an entry was inserted
    to that table with a wildcard value for all the ports and for the
    external IP address. Upon matching, such an entry would clone into
    a new one containing the information specific for a particular
    session. Thus the solution was symmetric by design, without requiring
    2 natd's or additional ipfw rules.

    P.S. As I can see, today's libalias still uses the same approach. 

    -- 
Yar
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: Danny Braniss: "Re: recent mplayer port spinning?"

    Relevant Pages

    • Re: NATD and Address Redirection
      ... > There was a translation table inside libalias with 3 columns in it: ... > When a packet was heading outside, ... such an entry would clone into ... I didn't know the internals. ...
      (freebsd-hackers)
    • Re: setting the other ends TCP segment size
      ... peer to use a transmit segment size of, say, 640 bytes -- ... packet size directly. ... That would be better than setting the local mtu -- which has been ... -- the entry still expires and loses the mtu specification. ...
      (freebsd-questions)
    • Re: Intermittently Unable To Send Email
      ... > The last entry into the SMTP Log is 354 go ahead. ... Unfortunately that log entry may also mean that it has already sent ... The only way to know for sure is to take a packet ... In that case perhaps you have an MTU size issue to deal with. ...
      (microsoft.public.windows.inetexplorer.ie6_outlookexpress)
    • OT: IPTABLES TCP/IP ip_conntrack Record
      ... SYN packet has been sent, (the SYN_SENT flag is set), and to which as ... Now we have received a corresponding SYN/ACK in return. ... this connection tracking entry has now seen ...
      (Fedora)