/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! */
Alan Baker <[EMAIL PROTECTED]> wrote:
>
> I haven't been able to repeat the outage, but the connection table looks
> something like the following. (Not sure why I couldn't display it
> before.) How many ports would be in use before running out of ports?
In this output, each line is a "port", in the discussion we're talking
about. The maximum number of ports is 4096, so if you're running into a
port-outage, you would type this command and your screen would just
scroll with a huge amount of output.
> Does it cause a problem when ports hang around after they are no
> longer in use?
Every port has an "expire" time which you will see in the second column.
That tells you how long the port will hang around.
> For example the last 3 in this list hung around for a couple of hours.
> If so, what should I do about them?
Well, if they represent an active connection, then you shouldn't do
anything about them. If they represent a dead connection that the
originator has forgotten about, then... well, I don't think there's
anything you can do to remove the connection entry from the table. In
normal usage, there's never a reason to do so. You normally only get
into this situation if a client spams your masq box with thousands of
connection requests in a short span of time.
> IP masquerading entries
> prot expire source destination ports
> UDP 00:03.42 192.168.0.30 168.253.48.19 1115 (61247) -> 53
This is a UDP entry. UDP protocol is "connectionless", meaning that
there is no general way for the masq box to know when your client is
finished talking to the external server. It will simply hold this
connection information for as long as communications continue, and then
drop it after the "expire" time (which you set with "ipchains -M -S").
> TCP 117:39.16 192.168.0.30 207.87.13.16 1117 (61249) -> 80
> TCP 117:31.57 192.168.0.30 207.87.13.16 1119 (61251) -> 80
> TCP 117:36.89 192.168.0.30 207.87.13.16 1118 (61250) -> 80
These are TCP entries. Normally you will want the expire times to be
long for these, because sometimes they represent connections that have a
lot of idle time (such as telnet connections, or ftp control
connections). With TCP entries, however, it can be determined when they
are "finished", so the masq system has two timeouts for these. You set
a long timeout for the "active" portion of the connection, and a short
timeout for the "finished" portion. On my box, I use four hours, and 30
seconds, as my timeouts.
> ICMP 00:58.32 192.168.0.20 204.146.81.99 512 (61258) -> 8
> ICMP 00:44.75 192.168.0.20 209.68.147.66 512 (61256) -> 8
These are ICMP entries; they occur when someone pings an outside host,
and they are set up to route the replies back to the sender. You cannot
change the timeouts on these, without recompiling your kernel.
> TCP 05:08.04 192.168.0.10 207.87.13.16 1085 (61147) -> 80
> TCP 05:08.14 192.168.0.10 207.87.13.16 1087 (61149) -> 80
> TCP 05:08.10 192.168.0.10 207.87.13.16 1086 (61148) -> 80
These are the TCP entries you noted that hung around for a long time.
The timeout given is five minutes, but if the connection continued to
remain active (traffic going back and forth constantly), the timer will
continue to be refreshed back to its maximum value, and thus the
connection entry will stay around... and you want it to, because this is
what makes your masq system do its job!
> UDP 01:31.83 192.168.0.20 192.168.0.255 137 (61252) -> 137
This entry makes me wonder. It looks like you're masquerading traffic
from the same subnet, back to itself? The port number, 137, indicates
NETBIOS traffic.
> UDP 02:07.40 192.168.0.20 168.253.48.19 1122 (61254) -> 53
> UDP 02:21.39 192.168.0.20 168.253.48.19 1123 (61255) -> 53
> UDP 01:33.03 192.168.0.20 168.253.48.19 1120 (61253) -> 53
> UDP 02:34.64 192.168.0.20 168.253.48.19 1124 (61257) -> 53
These indicate DNS traffic. I have heard of cases where the masq
clients get so active with DNS lookups, that they actually overwhelm the
masq server, and fill up the connection table. A simple way to
counteract that effect is to run a caching-only name server on your masq
box. Then configure the masq clients to use the masq box as their DNS
server, and they won't need to masquerade their lookups any more. It'll
probably help speed things up, too.
--
[EMAIL PROTECTED] (Fuzzy Fox) || "Good judgment comes from experience.
sometimes known as David DeSimone || Experience comes from bad judgment."
http://www.dallas.net/~fox/ || -- Life Lessons
_______________________________________________
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.
