[306] in linux-net channel archive
Re: IP forwarding the diald way
daemon@ATHENA.MIT.EDU (Aleph One)
Thu May 11 13:55:32 1995
Date: Thu, 11 May 1995 11:16:17 -0500 (CDT)
From: Aleph One <aleph1@dfw.net>
To: steve@work.bellingham.wa.us
Cc: linux-diald@vger.rutgers.edu, linux-net@vger.rutgers.edu
In-Reply-To: <m0s95Uf-0005j2C@work.bellingham.wa.us>
This is not an issue for linux-diald. Its an issue for the net channel
since the logic you propose would be in the kernel net code.
You are correct that the TIS firewall toolkit is overkill. I do recall
someone (Alan?) mentioning how to do this for a network connecting to the
internet that did not whish to change the IP address for all their
machines. But I belive it was a standalone router (hardware) not some
software for linux (please someone correct me if I'am wrong). The main
problem I see with using TIS toolkit its that its not invisible to the
user. My recommendation would be to use SOCKS. It's a proxy firewall, and
many applications come with support for it (Netscape). And those that
dont are easily change to do if you have src.
a1
On Tue, 9 May 1995 steve@work.bellingham.wa.us wrote:
> DISCLAIMERS: I don't know what I'm talking about. This isn't
> specifically about diald. I'm speculating and wondering, and maybe
> someone else is interested. Maybe not.
>
> There's been some discussion recently about using a machine running
> diald to gateway a network to the Internet through an Internet service
> provider. If the network is registered everything is easy: the diald
> Linux box is the default gateway, and when it sees a packet from
> another host on the local network (maybe a windoze PC running
> Netscape) it raises the ISP link and sends the packet out into the
> world. Since the issuing host's address is registered and legal, the
> magic of IP routes replies back through the gateway to the issuer.
>
> The problem discussed here recently involved the case where the
> private network is NOT a registered Class [ABC] network. The
> consensus seems to be that you run firewall software (a "proxy") on
> the diald machine to adjust the outgoing packets so they look legal to
> the Internet and adjust the reply packets so they make it back to the
> issuing host. The discussion here suggested using the Firewall
> Toolkit "fwtk" for the proxying.
>
> It seems to me that fwtk is overkill for this situation. (Here I risk
> parading my ignorance. Please be good parents: patient but firm.)
> Fwtk's proxies dig deep into packets for various protocols, extracting
> and adjusting information to hide the issuing host's details from the
> outside world. For http, for example, fwtk's http-gw proxy appears to
> rewrite all HTML links, tacking on the gateway name at the front of
> each. Other protocols' packets undergo similar munging.
>
> If you're after maximum firewall security, this stuff is great I'm
> sure. But consider the common diald user in a LAN environment. He or
> she administers a single gateway Linux box running diald to an ISP,
> and an unregistered LAN of users that want to use WWW, FTP etc. across
> that ISP link transparently. Security isn't really an issue here: I
> understand that things can be arranged so only the gateway machine is
> visible to the outside world, and since this hypothetical diald user's
> users want (in my mind anyway) to _use_ Internet services, not
> _provide_ them, there's no reason to allow unsolicited packets past
> the gateway.
>
> All that matters is that replies to outgoing packets get back to the
> issuer. And all that requires (right?) is that the gateway box, in
> forwarding packets, rewrites the headers such that the Internet sees
> the issuer as the gateway, and the gateway can recognize replies and
> forward them back to the right host on the LAN.
>
> Now I'm at the edge of my ignorance here, but couldn't this be
> accomplished fairly simply? And (if so) couldn't this functionality
> be built into diald itself, since it's throwing packets around between
> kernel and user space anyway? Here's the proposal (which may be so
> full of holes it'll sink without comment):
>
> diald box accepts an outgoing packet from issuing host on LAN (pretend
> it's an HTML request, since these look easy). IP packet has source IP
> address (which must not get through the gateway), associated port
> number (right?), destination IP address and destination port (80 for
> WWW, right?). The diald box keeps track of source address and port and
> replaces them with IP number associated with ISP link and an unused,
> unreserved port number. When the reply comes, the remote IP address
> and port number clue diald to the original source and port; diald
> munges the packet appropriately and drops it onto the LAN. Incoming
> packets that don't match expectations are managed by the diald box's
> kernel normally, so it looks to the rest of the world like a
> standalone machine.
>
> Now my relative ignorance of the protocols guarantees some holes must
> be filled (and quite probably that some of them are unfillable). A
> connection-oriented protocol like telnet will expect some kind of
> continuity in the port numbers, for example. Some higher-level
> protocols might stick IP addresses in other places in the packet, not
> just the raw IP header area, I don't know.
>
> Is this scheme workable? If so, would it be best implemented like a
> firewall proxy, as some kind of gatekeeper standing between the
> interfaces for diald and for the LAN, or would it be better off
> integrated into diald? Maybe I'm all wet here: is the functionality
> I'm reaching for already available? Or is it impossible?
>
> The fwtk http-gw mechanism seems so _messy_.
>
> Steven Work
> Renaissance Labs
> +1 360 647-1833, fax too
> steve@work.bellingham.wa.us
>
