/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */


Fuzzy Fox wrote:
> 
> Gregory Leblanc <[EMAIL PROTECTED]> wrote:
> 
> I'm rather sure that the main reason is that masquerade was designed to
> CO-EXIST with networking on the firewall box itself.  That is, if your
> masq box is not just a masq box, but also, say, an FTP server, or a mail
> server, or a DNS server, then that means that it has its own internal
> socket usage needs, and they must co-exist with the socket usage of
> masqueraded clients.

That sounds reasonable, although it might be nice to have an option in
the kernel to enable more ports that that, with a warning about why it
could cause problems.  I believe that a firewall should be a firewall,
and NOTHING else, because what good does it to do have a firewall if
people can still hack fingerd on that machine, and change your
firewall rules.  But that's just my not-so-humble opinion.

> 
> The range of 61000+ was chosen because there are so few network
> protocols that are likely to attempt to use that range.  The upper limit
> is set by TCP/IP, of which the maximum port is 65534, I think.
> 
> If you were to lower the starting port range, you would increase the
> chances of masqueraded-chosen port numbers colliding with locally-chosen
> port numbers.  FTP, in particular, seems to like to use high-numbered
> ports for its data connections.
> 
> Nevertheless, if you feel that your masqueraded clients *really* have
> the need for more than 4000 *simultaneous* connections, and it's not
> just some mistake that's causing the masq box to keep old connections
> around for longer than they have been useful, you do have access to the
> source code, and can tune these values to your expected needs.  Just be
> aware that you could impact your local firewall box's network usage.

Well, I think I could probably get around that where I'm working now,
but if I was working for someplace like Oregon State University, who
has about 12K clients on their network, I think that it might be a
problem.  :)

> 
> The source lines to change, in kernel 2.2, are in
> 
>     /usr/src/linux/include/net/ip_masq.h
> 
> Here's the relevant section:
> 
>     /*
>      *      Linux ports don't normally get allocated above 32K.
>      *      I used an extra 4K port-space
>      */
> 
>     #define PORT_MASQ_BEGIN 61000
>     #define PORT_MASQ_END   (PORT_MASQ_BEGIN+4096)
> 
> If you increase the number "4096" here, you must also decrease the BEGIN
> number above it, by the same amount.

So if I increase the maximum, I have to increase the minimum
someplace?  That doesn't make sense to me, unless there's some strange
dependancy on this variable someplace.

> > As long as I'm on the topic, how does IP-MASQ handle multiple
> > "outside" or internet-side addresses?
> 
> IP Masq is a "many-to-one" implementation of NAT.  As such, the
> "many-to-many" is not really implemented exactly...  I have heard of
> people playing with it, but don't know what has been the result.
> 
> I think masq *can* support masquerading using multiple outbound IP
> addresses, but you would have to somehow configure your routing
> subsystem to send packets via one or the other interface, according to
> traffic rules.  The typical method involving the "default route" only
> allows one outbound interface to be used.  You should check out the
> alternate routing packages available for Linux, such as "iproute2"
> (which I have yet to investigate, at all).

Actually, I wasn't thinking multiple interfaces, I was thinking
multiple IP addresses.  As in one NIC with two or three IP addresses
on it.  I guess maybe I'll have to peruse the code.
        Greg


_______________________________________________
Masq maillist  -  [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- THIS INCLUDES 
UNSUBSCRIBING!
or email to [EMAIL PROTECTED]

PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.

Reply via email to