> What are the main differences between using ipautofw, and
>ipportfw? Can everythin achieved by one be achieved also by the
>other? Which is "the lists" choice?
IPPORTFW.
This is what Fuzzy Fox had to say...
--
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Delivered-To: mailing list [EMAIL PROTECTED]
Date: Wed, 30 Sep 1998 17:53:36 -0500
From: Fuzzy Fox <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED]
X-Mailer: Mutt 0.93.1i
Subject: Re: [masq] Want to divert one port to one machine.
Michael Kohne <[EMAIL PROTECTED]> wrote:
>
> 1) ipautofw - From the docs, this seems to add a range of ports to the
> masqerading list in the kernel whenever a packet is received on a
> specific port. This is a kernel patch. Some people on the list
> have complained of trouble with it, others have no problems.
Ipautofw is an interesting beast. It can be run in one of several
modes:
a. It can wait until a machine behind the firewall sends a certain
type of request out, then it can start redirecting return
traffic, on a different port or range of ports, back to that
originating host. This way, multiple machines behind the
firewall can be serviced by a single port-forwarding request.
b. It can be set up to forward a port or range of ports
unconditionally, to a machine behind the firewall. This seems
to be a more popular mode than the previous, since it's easier
for people to set up.
The problems that most people have, occur when they use that second
mode. When running in this mode, ipautofw forwards all packets that
appear on that port, or range of ports, regardless of the reason they
are arriving. This can conflict with legitimate use of the machine,
because a network connection originating on the firewall might attempt
to make use of one of those ports as its "source" port, but when a
remote machine tries to reply, the reply gets forwarded to the machine
behind the firewall, so the connection times out. Since source ports
are chosen in ascending order, the larger the range forwarded, the
sooner this condition will happen, and the longer it will last.
For this reason, ipautofw is considered to be deprecated, and ipportfw
is considered the more useful solution.
> 2) ipportfw - Again, haven't used it. As I understand it, this
> package does things a little differently than ipautofw, in that it
> sets up a permanent forward for the ports in question, not just
> adding them in response to a packet send, and is considered by some
> to be a bit more stable.
Ipportfw is very stable and useful. It is smarter about how packets are
forwarded, and does not have the "collision" problem stated above, so it
will not interfere with the firewall's network connection attempts. It
does not have the flexibility that ipautofw has, though; it can only
forward to one machine behind the firewall for each particular port, and
will not forward port ranges. You must forward each port in the range,
individually. However, since most people don't seem to use that first
mode of ipautofw, this isn't really too bad, and you can always use
both, if you really want to. Ipautofw is deprecated, but doesn't seem
to be going away, yet.
> 3) redir - This is what I use. It only works for TCP connections (I
> think), but if what you need is to redirect one TCP port to another
> machine, it's just the ticket.
The main problem, if you want to call it that, with a program like
'redir', is that it will not masquerade the resulting connection.
Basically, all connections to your internal machine will appear to be
coming from the firewall's IP address. This may not seem like a big
deal, but if you're running a web server, for instance, you won't be
able to tell who's connecting to your web server. Every connection will
appear as coming from your firewall, in your server logs. You'd have to
do the connection logging on the firewall, which I don't think redir
even bothers to do.
> This has the distinct advantage of being very simple to understand,
> and to NOT require kernel patches.
This much is true, however, the kernel patches for these port-forwarders
are quite stable and non-obtrusive (except for the above-mentioned
problem with ipautofw).
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut
sometimes known as David DeSimone || butter quite like unrequited love."
http://www.dallas.net/~fox/ || -- Charlie Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
Delivered-To: mailing list [EMAIL PROTECTED]
Date: Thu, 1 Oct 1998 22:07:48 -0500
From: Fuzzy Fox <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Mail-Followup-To: [EMAIL PROTECTED]
X-Mailer: Mutt 0.93.1i
Subject: Re: [masq] Want to divert one port to one machine.
Kent Quirk <[EMAIL PROTECTED]> wrote:
>
> > [..... ipautofw .....]
>
> Thank you for your assistance; this is good information. Before I saw
> it, I figured out how to use ipautofw and set it up. It seems to be
> running fine at the moment.
If you're only forwarding one port, you might never see a problem. :)
> In my situation, the single port number I'm using was assigned by the
> IANA to the vendor of the server app I'm running; they claim it's
> "unlikely" to cause a conflict.
Well, the conflict issue has to do with "source ports", not "destination
ports", which is what your application uses.
> Under what circumstances (what kinds of apps?) will an application on
> the server "choose" a port number in this way? Are they chosen from
> 65536 possibilities, or only a subset? If the latter, how is the
> subset defined?
Well, this is one of those things I'd like to know better. What I do
know is that any TCP connection must originate from a "source" port, and
point to a "destination" port, which is the port usually defined for a
service. The source port is generally a random number between 1024 and
(I'm guessing) about 40000, something like that.
The source port isn't really chosen at random; every network connection
that's started uses a port one greater than the previous one did. Of
course, if a daemon is listening for connections on a particular port,
that port will be skipped, because it's already in use.
The problem with ipautofw, is that there isn't really anyone "listening"
on that port that it will forward. The port will merely be passed
along, forwarded to the machine behind the firewall. Ipautofw isn't
smart enough to tell the kernel not to use that port for a "source"
port, so if the kernel happens to try it, the resulting connection will
fail, because the kernel will assume that packets can be received on
that source port, but they'll instead get forwarded to a machine that
has no idea what to do with them.
> What happens when it times out? Will it choose another or try again with
> the same one?
The program attempting the connection will simply time out. It is up to
that application to decide what to do next. Maybe it's sendmail trying
to route some mail. If so, it'll try again later. Maybe it's someone
trying to telnet out, and they'll just have to try again. Maybe the DNS
server is trying to get a response from another server. It's hard to
say.
The main thing is that "ipautofw" doesn't have the smarts to keep the
kernel from using the forwarded port, whereas "ipportfw" does. If
you're only forwarding a single port, use ipportfw. It's just as easy
to set up.
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Nothing takes the taste out of peanut
sometimes known as David DeSimone || butter quite like unrequited love."
http://www.dallas.net/~fox/ || -- Charlie Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
.----------------------------------------------------------------------------.
| David A. Ranch - Linux/Networking/PC hardware [EMAIL PROTECTED] |
!---- ----!
`----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch -----'
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
