Date: Fri, 11 Aug 2000 12:12:57 -0400 From: Nick Evans <nevans@nextvenue.com> To: 'Damien Tougas' <damien@carroll.com>, freebsd-security@freebsd.org Subject: RE: Strange ipnat behaviour Message-ID: <712384017032D411AD7B0001023D799B33B223@sn1exchmbx.nextvenue.com>
next in thread | raw e-mail | index | archive | help
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C003AF.03592D70 Content-Type: text/plain; charset="iso-8859-1" Did you turn on ip forwarding? -----Original Message----- From: Damien Tougas [mailto:damien@carroll.com] Sent: Wednesday, August 09, 2000 3:39 PM To: freebsd-security@freebsd.org Subject: Strange ipnat behaviour Hello, We are currently 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. The problem that we are seeing is that for some reason unknown to us, nat just stops working. 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 map de0 10.0.0.0/8 -> 0/32 Could that second line be causing the problem? There are currently no ipf rules being used. 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 is non existent. Our first thought was that we might have ran out of ports, but we discovered that there were no more than about 3000 sessions active at the time. Any ideas? Is this a bug, or have we mis-configured something? Thanks for your help. -- Damien Tougas Carroll-Net, Inc. http://www.carroll.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message ------_=_NextPart_001_01C003AF.03592D70 Content-Type: text/html; charset="iso-8859-1" <!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>RE: Strange ipnat behaviour</TITLE> </HEAD> <BODY> <P><FONT SIZE=2>Did you turn on ip forwarding?</FONT> </P> <P><FONT SIZE=2>-----Original Message-----</FONT> <BR><FONT SIZE=2>From: Damien Tougas [<A HREF="mailto:damien@carroll.com">mailto:damien@carroll.com</A>]</FONT> <BR><FONT SIZE=2>Sent: Wednesday, August 09, 2000 3:39 PM</FONT> <BR><FONT SIZE=2>To: freebsd-security@freebsd.org</FONT> <BR><FONT SIZE=2>Subject: Strange ipnat behaviour</FONT> </P> <BR> <P><FONT SIZE=2>Hello,</FONT> </P> <P><FONT SIZE=2>We are currently running ipnat on FreeBSD version 3.4-Stable, I am not</FONT> <BR><FONT SIZE=2>sure exactly what version of ipfilter it is, it is the one that comes</FONT> <BR><FONT SIZE=2>as part of the base OS.</FONT> </P> <P><FONT SIZE=2>The problem that we are seeing is that for some reason unknown to us,</FONT> <BR><FONT SIZE=2>nat just stops working. The only way to get it to work again is to</FONT> <BR><FONT SIZE=2>clear the ipnat tables and rules and re-initialize them using the</FONT> <BR><FONT SIZE=2>following sequence:</FONT> </P> <P><FONT SIZE=2>/usr/sbin/ipnat -CF</FONT> <BR><FONT SIZE=2>/usr/sbin/ipnat -f /etc/rc.nat</FONT> </P> <P><FONT SIZE=2>After that, everything works just fine.</FONT> <BR><FONT SIZE=2>The config file we use (rc.nat) is very simple:</FONT> </P> <P><FONT SIZE=2>map de0 10.0.0.0/8 -> 0/32 portmap tcp/udp 1025:65000</FONT> <BR><FONT SIZE=2>map de0 10.0.0.0/8 -> 0/32</FONT> </P> <P><FONT SIZE=2>Could that second line be causing the problem?</FONT> <BR><FONT SIZE=2>There are currently no ipf rules being used.</FONT> </P> <P><FONT SIZE=2>We ran a tcpdump on the interface while the problem was occurring,</FONT> <BR><FONT SIZE=2>just to see what was going on. What we found was that any new</FONT> <BR><FONT SIZE=2>connections attempted from 10.0.0.0/8 were going through with the ack</FONT> <BR><FONT SIZE=2>bit set only, it is like the initial packet was somehow blocked. As a</FONT> <BR><FONT SIZE=2>result, the server we were trying to contact replied with a tcp reset</FONT> <BR><FONT SIZE=2>since it thought that we were trying to connect to a session that is</FONT> <BR><FONT SIZE=2>non existent. Our first thought was that we might have ran out of</FONT> <BR><FONT SIZE=2>ports, but we discovered that there were no more than about 3000</FONT> <BR><FONT SIZE=2>sessions active at the time.</FONT> </P> <P><FONT SIZE=2>Any ideas? Is this a bug, or have we mis-configured something?</FONT> </P> <P><FONT SIZE=2>Thanks for your help.</FONT> </P> <P><FONT SIZE=2>-- </FONT> <BR><FONT SIZE=2>Damien Tougas</FONT> <BR><FONT SIZE=2>Carroll-Net, Inc.</FONT> <BR><FONT SIZE=2><A HREF="http://www.carroll.com" TARGET="_blank">http://www.carroll.com</A></FONT>; </P> <BR> <BR> <BR> <P><FONT SIZE=2>To Unsubscribe: send mail to majordomo@FreeBSD.org</FONT> <BR><FONT SIZE=2>with "unsubscribe freebsd-security" in the body of the message</FONT> </P> </BODY> </HTML> ------_=_NextPart_001_01C003AF.03592D70-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?712384017032D411AD7B0001023D799B33B223>