OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [fw-wiġ˙ NAT
From: Bennett Todd (betrahul.net)
Date: Thu Apr 27 2000 - 16:02:49 CDT

2000-04-26-17:10:16 Paul D. Robertson:
> On 24 Mar 2000, Alexandre A. Rodioukov wrote:
> > What i wanted to do is for outsiders to be able to access some
> > machines/services inside the network via real-IPs (machines by
> > themselves are assigned fake addresses).
>
> I'm sure this is doable with Linux with some masquerading for the
> internal to external connections and Masquerading or redirection
> for the external to internal ones.

With ipfwadm (2.0.x kernels) and ipchains (2.2.x kernels), no, you can
only do Masquerading, not static NAT; there's no way to tell the
kernel to listen for connections on a particular ipaddr:port and
route them to a masqueraded machine. With netfilter (late 2.3.x
kernels, will be in 2.4 when it comes out) you can do this.

> You could also proxy the connections and/or use a transport layer
> tunnel like plug-gw and udprelay.

With current production Linux kernels that's the only way to tunnel
traffic back in to Masqueraded servers, and it works fine. There are
a _load_ of port-level proxies available. I recently did a skim of
the ones turned up by some searching on freshmeat, and produced a
little summary, which I append after my .sig.

-Bennett

Summary of various proxies from freshmeat, for the purpose of
simulating the effect of static NAT to reach masqueraded machines
behind a Linux ipchains firewall. These were all found on freshmeat.

aproxy is a port-forwarding proxy daemon written entirely in perl,
        and does not currently have support for binding to a
        specific interface. Also has a remote-admin network service
        it offers, where you can telnet to a configurable port and
        issue simple commands to reconfigure it. Ick.

delegate supports restricting the interface to bind to. It supports
        an almost infinite number of other things, too. It can do
        this job. It can do so much more that I'm not wildly fond
        of it, I'd rather see its functionality decomposed into an
        assortment of toolkits.

portfwd can bind to specific addresses. It seems to have a fairly
        elegant little config language, and yet it's as best I can
        tell just and solely a port forwarder. This one is a
        candidate, definitely.

proxy seems even simpler than portfwd, and can also specify a source
        port to bind to. Another candidate.

simpleproxy likewise looks like it'd do the job, and not obnoxiously
        much more.

tcpgate is too simple, doesn't allow specification of src addr to
        bind to. If there weren't already so many lovely
        alternatives, though, and we needed to code something to
        solve this problem, I might be tempted to start hacking on
        this one in preference to the others, because it's _so_
        small, and already has some appealing internal structure
        (separate networking library).

tcpproxy looks like another good choice.

tcpxd would have some appeal, since it's nearly nothing ---
        virtually all the distribution is GNU autoconf overhead, the
        actual program is teensy. No docs, even. But it's pretty
        clear from the help in the code that it doesn't support
        binding to a source addr. This would be another very
        attractive candidate for hacking on.

tinyproxy is a small and simple http-only proxy, with buffering and
        asynch dns resolver (using the GNU adns lib).

  • application/pgp-signature attachment: stored