[prev in list] [next in list] [prev in thread] [next in thread]
List: ipfilter
Subject: FW: Ipnat fails under load?
From: Nick Evans <nevans () nextvenue ! com>
Date: 2000-08-25 3:54:06
[Download RAW message or body]
-----Original Message-----
From: Greg Rumple [mailto:grumple@zaphon.llamas.net]
Sent: Thursday, August 24, 2000 7:21 PM
To: Damien Tougas
Cc: freebsd-questions@freebsd.org; freebsd-stable@freebsd.org
Subject: Re: Ipnat fails under load?
I am experiencing very similar issues. I am running ipnat on FreeBSD
4.1-STABLE as of 8 days ago. I am running a tiny bit more sophisticated
set of rules than you, but in reality not much different. I have a
class C of machines (about 100 in total) run through the box (collapsed
to a single IP). At any one time we have anywhere from 300-1000
connections through the nat, but this box is a P3-700 with 256 megs of
ram. This is not an issue, were not experiencing any lag. What instead
we are seeing is we just flat out lose connections to some machines
until I as well do a full flush/reload. And today even that didn't fix
it, I truly had to reboot the box. For example, I had a machine outside
the nat, that I connect to regularly. I could not telnet to it, I could
not ping it, or anything through the nat. I even tried from the nat
directly, and couldn't do any of those items (this machine is in another
facility). I could reach other machines 1 ip address above or below it
though (which is what's weird). So I even brought up tcpdump on the
external interface, and could see the echo requests and echo replies
when pinging. Just the kernel wasn't picking them up. This is the
third or fourth time I have reached such a state, and this time it could
only be fixed via a reboot. Unfortunately I accidently killed the X
term that I had all the tcpdump captures, and information in so I don't
have that readily available. But I am seeing similar issues. This is a
pretty heavy load for a nat, and we realize it, but it's our only option
right now. And I really don't wanna use natd, since I would have to
deal with ftp proxy/passive issues.
* Damien Tougas (damien@carroll.com) [000824 20:44]:
> Hello,
>
> After some period of time (anywhere from days to weeks), ipnat stops
> working properly. We ran a tcpdump on the interface while the problem
> was occurring, just to see what was going on. What we found was that
> any new connections attempted from 10.0.0.0/8 were going through with
> the ack bit set only, it is like the initial packet was somehow
> blocked. As a result, the server we were trying to contact replied
> with a tcp reset since it thought that we were trying to connect to a
> session that did not exist. Our first thought was that we might have
> ran out of ports, but we have since found that there are typically no
> more than about 3000 sessions active when this occurrs.
>
> The only way to get it to work again is to clear the ipnat tables and
> rules and re-initialize them using the following sequence:
>
> /usr/sbin/ipnat -CF /usr/sbin/ipnat -f /etc/rc.nat
>
> After that, everything works just fine. The config file we use
> (rc.nat) is very simple:
>
> map de0 10.0.0.0/8 -> 0/32 portmap tcp/udp 1025:65000
>
> There are currently no other firewall rules being used. All IP
> addresses on the machine are static. The reason we use the 0/32
> designation is to maintain configuration file consistancy across all
> servers.
>
> We are running ipnat on FreeBSD version 3.4-Stable, I am not sure
> exactly what version of ipfilter it is, it is the one that comes as
> part of the base OS.
>
> Any ideas?
>
> Thanks for your help.
>
> -- Damien Tougas Carroll-Net, Inc. http://www.carroll.com
>
>
>
>
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe
> freebsd-stable" in the body of the message
--
Greg Rumple
grumple@zaphon.llamas.net
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>FW: Ipnat fails under load?</TITLE>
</HEAD>
<BODY>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Greg Rumple [<A \
HREF="mailto:grumple@zaphon.llamas.net">mailto:grumple@zaphon.llamas.net</A>]</FONT> \
<BR><FONT SIZE=2>Sent: Thursday, August 24, 2000 7:21 PM</FONT> <BR><FONT SIZE=2>To: \
Damien Tougas</FONT> <BR><FONT SIZE=2>Cc: freebsd-questions@freebsd.org; \
freebsd-stable@freebsd.org</FONT> <BR><FONT SIZE=2>Subject: Re: Ipnat fails under \
load?</FONT> </P>
<BR>
<P><FONT SIZE=2>I am experiencing very similar issues. I am running ipnat on \
FreeBSD</FONT> <BR><FONT SIZE=2>4.1-STABLE as of 8 days ago. I am running a \
tiny bit more sophisticated</FONT> <BR><FONT SIZE=2>set of rules than you, but in \
reality not much different. I have a</FONT> <BR><FONT SIZE=2>class C of \
machines (about 100 in total) run through the box (collapsed</FONT> <BR><FONT \
SIZE=2>to a single IP). At any one time we have anywhere from 300-1000</FONT> \
<BR><FONT SIZE=2>connections through the nat, but this box is a P3-700 with 256 megs \
of</FONT> <BR><FONT SIZE=2>ram. This is not an issue, were not experiencing any \
lag. What instead</FONT> <BR><FONT SIZE=2>we are seeing is we just flat out \
lose connections to some machines</FONT> <BR><FONT SIZE=2>until I as well do a full \
flush/reload. And today even that didn't fix</FONT> <BR><FONT SIZE=2>it, I \
truly had to reboot the box. For example, I had a machine outside</FONT> \
<BR><FONT SIZE=2>the nat, that I connect to regularly. I could not telnet to \
it, I could</FONT> <BR><FONT SIZE=2>not ping it, or anything through the nat. I \
even tried from the nat</FONT> <BR><FONT SIZE=2>directly, and couldn't do any of \
those items (this machine is in another</FONT> <BR><FONT SIZE=2>facility). I \
could reach other machines 1 ip address above or below it</FONT> <BR><FONT \
SIZE=2>though (which is what's weird). So I even brought up tcpdump on \
the</FONT> <BR><FONT SIZE=2>external interface, and could see the echo requests and \
echo replies</FONT> <BR><FONT SIZE=2>when pinging. Just the kernel wasn't \
picking them up. This is the</FONT> <BR><FONT SIZE=2>third or fourth time I \
have reached such a state, and this time it could</FONT> <BR><FONT SIZE=2>only be \
fixed via a reboot. Unfortunately I accidently killed the X</FONT> <BR><FONT \
SIZE=2>term that I had all the tcpdump captures, and information in so I don't</FONT> \
<BR><FONT SIZE=2>have that readily available. But I am seeing similar \
issues. This is a</FONT> <BR><FONT SIZE=2>pretty heavy load for a nat, and we \
realize it, but it's our only option</FONT> <BR><FONT SIZE=2>right now. And I \
really don't wanna use natd, since I would have to</FONT> <BR><FONT SIZE=2>deal with \
ftp proxy/passive issues.</FONT> </P>
<P><FONT SIZE=2>* Damien Tougas (damien@carroll.com) [000824 20:44]:</FONT>
<BR><FONT SIZE=2>> Hello,</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> After some period of time (anywhere from days to weeks), ipnat \
stops</FONT> <BR><FONT SIZE=2>> working properly. We ran a tcpdump on the \
interface while the problem</FONT> <BR><FONT SIZE=2>> was occurring, just to see \
what was going on. What we found was that</FONT> <BR><FONT SIZE=2>> any new \
connections attempted from 10.0.0.0/8 were going through with</FONT> <BR><FONT \
SIZE=2>> the ack bit set only, it is like the initial packet was somehow</FONT> \
<BR><FONT SIZE=2>> blocked. As a result, the server we were trying to \
contact replied</FONT> <BR><FONT SIZE=2>> with a tcp reset since it thought that \
we were trying to connect to a</FONT> <BR><FONT SIZE=2>> session that did not \
exist. Our first thought was that we might have</FONT> <BR><FONT SIZE=2>> ran out \
of ports, but we have since found that there are typically no</FONT> <BR><FONT \
SIZE=2>> more than about 3000 sessions active when this occurrs.</FONT> <BR><FONT \
SIZE=2>> </FONT> <BR><FONT SIZE=2>> The only way to get it to work again is to \
clear the ipnat tables and</FONT> <BR><FONT SIZE=2>> rules and re-initialize them \
using the following sequence:</FONT> <BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> /usr/sbin/ipnat -CF /usr/sbin/ipnat -f /etc/rc.nat</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> After that, everything works just fine. The config file \
we use</FONT> <BR><FONT SIZE=2>> (rc.nat) is very simple:</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> map de0 10.0.0.0/8 -> 0/32 portmap tcp/udp 1025:65000</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> There are currently no other firewall rules being used. \
All IP</FONT> <BR><FONT SIZE=2>> addresses on the machine are static. The reason \
we use the 0/32</FONT> <BR><FONT SIZE=2>> designation is to maintain configuration \
file consistancy across all</FONT> <BR><FONT SIZE=2>> servers.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> We are running ipnat on FreeBSD version 3.4-Stable, I am not \
sure</FONT> <BR><FONT SIZE=2>> exactly what version of ipfilter it is, it is the \
one that comes as</FONT> <BR><FONT SIZE=2>> part of the base OS.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Any ideas?</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> Thanks for your help.</FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> -- Damien Tougas Carroll-Net, Inc. <A \
HREF="http://www.carroll.com" TARGET="_blank">http://www.carroll.com</A></FONT> \
<BR><FONT SIZE=2>> </FONT> <BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> </FONT>
<BR><FONT SIZE=2>> To Unsubscribe: send mail to majordomo@FreeBSD.org with \
"unsubscribe</FONT> <BR><FONT SIZE=2>> freebsd-stable" in the body of \
the message</FONT> </P>
<P><FONT SIZE=2>-- </FONT>
<BR><FONT SIZE=2>Greg Rumple</FONT>
<BR><FONT SIZE=2>grumple@zaphon.llamas.net</FONT>
</P>
<BR>
<P><FONT SIZE=2>To Unsubscribe: send mail to majordomo@FreeBSD.org</FONT>
<BR><FONT SIZE=2>with "unsubscribe freebsd-questions" in the body of the \
message</FONT> </P>
</BODY>
</HTML>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic