From owner-freebsd-security Fri Aug 11 9:13:57 2000 Delivered-To: freebsd-security@freebsd.org Received: from sn1oexchr02.nextvenue.com (pony.nextvenue.com [209.0.251.199]) by hub.freebsd.org (Postfix) with SMTP id 9EC8B37C099 for ; Fri, 11 Aug 2000 09:13:43 -0700 (PDT) (envelope-from nevans@nextvenue.com) Received: FROM sn1exchmbx.nextvenue.com BY sn1oexchr02.nextvenue.com ; Fri Aug 11 12:13:29 2000 -0400 Received: by sn1exchmbx.nextvenue.com with Internet Mail Service (5.5.2650.21) id ; Fri, 11 Aug 2000 12:13:01 -0400 Message-ID: <712384017032D411AD7B0001023D799B33B223@sn1exchmbx.nextvenue.com> From: Nick Evans To: 'Damien Tougas' , freebsd-security@freebsd.org Subject: RE: Strange ipnat behaviour Date: Fri, 11 Aug 2000 12:12:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C003AF.03592D70" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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" RE: Strange ipnat behaviour

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-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message