On Sun, 29 Nov 1998, David A. Ranch wrote:
Hello!
>
>>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.
>
Only parts of it do...inbound file transfers and chat requests, for
example, do not get through. I, too, am interested in how to do this.
UDP Port 4000 might be a key but I have no idea how to set it up....
John Mudge
>
>>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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
For daily digest info, email [EMAIL PROTECTED]
