>How does one specify port ranges using ipportfw?
>From my understanding, IPPORTFW cannot do ranges.
You have to do it a port at a time.
>What would be needed to specify a certain range
>of ports for icq using ipportfw?
You shouldn't need to. ICQ should MASQ fine.
>And what are the major diffs between ipportfw and
>ipautofw? Thanks!
Fuzzy Fox sent this out a while ago which explains is
pretty well..
--
> 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).
--
.----------------------------------------------------------------------------.
| David A. Ranch - Remote Access/Linux/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]
