From owner-freebsd-net@FreeBSD.ORG Tue Jun 29 23:12:45 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D42D416A4CE for ; Tue, 29 Jun 2004 23:12:45 +0000 (GMT) Received: from beelzebubba.sysabend.org (alcatraz.inna.net [209.201.74.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 430BF43D2F for ; Tue, 29 Jun 2004 23:12:45 +0000 (GMT) (envelope-from xyzzy@moo.sysabend.org) Received: from moo.sysabend.org (moo.sysabend.org [66.111.41.70]) by beelzebubba.sysabend.org (Postfix) with SMTP id 2CB1A14F23 for ; Tue, 29 Jun 2004 19:12:34 -0400 (EDT) Received: (nullmailer pid 51432 invoked by uid 14); Tue, 29 Jun 2004 23:12:15 -0000 Date: Tue, 29 Jun 2004 16:12:15 -0700 From: Tom Arnold To: freebsd-net@freebsd.org Message-ID: <20040629231215.GL94504@moo.sysabend.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Organization: The Sysabend Dump X-Operating-System: CPM2.2 X-Bucket-Brigade-Devices: Rah! X-8-Bit-Samples-And-Analog-Filters: Rah! Subject: ipnat/ipf state problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: xyzzy@sysabend.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2004 23:12:46 -0000 I'm having a weird ipnat/ipf problem. I think its more ipnat related then ipf. First, the ipf rules : # block anything to our netblock but allow further processing block in on fxp0 from any to 64.74.133.224/27 block in on fxp0 from any to 192.168.0.0/16 # allow everything out and keep state pass out quick on fxp0 proto udp from any to any keep state pass out log quick on fxp0 proto tcp from any to any flags S keep state # see what slips through pass in log quick on fxp0 from any to any Now for ipnat : ( there are far more translations that this, but they are all the same so I'm only showing the machine I did my testing from ) # sc-app1 map fxp0 192.168.19.201/32 -> 64.74.133.242/32 age 30 The machine: The machine has three ethernets, fxp0-2. fxp0 is to the outside world. fxp1 is the inside network. fxp2 is to another set of firewalls. There are several RFC1918 internal networks that use this firewall as their gateway. Now, the problem. IPNat seems to be translating at both fxp0 and fxp1. A packet from the outside in gets translated to its RFC1918 equiv at fxp0 which is expected, but internal machines seem to be translated to their external IPs at fxp1 which I didnt expect. The main result of this is state is never kept. Heres the start of an ssh connection from the above mentioned sc-app1 to a colo box of mine : 29/06/2004 15:11:32.304448 fxp0 @0:2 p 64.74.133.242,4238 -> 66.111.41.70,22 PR tcp len 20 60 -S K-S OUT 29/06/2004 15:11:32.368570 fxp0 @0:20 p 66.111.41.70,22 -> 192.168.19.201,4238 PR tcp len 20 60 -AS IN 29/06/2004 15:11:32.435935 fxp0 @0:20 p 66.111.41.70,22 -> 192.168.19.201,4238 PR tcp len 20 92 -AP IN You can see in the first line the outbound connection has already been NATed before it hit ipf, which puzzles me. Is this a bug or a feature? If this is a feature, how can I convince ipf to keep state when the IPs will never match? -- ------------------------------------------------------------------------ - Tom Arnold - When I was small, I was in love, - - Sysabend - In love with everything. - - CareTaker - And now there's only you... - -------------- -- Thomas Dolby, "Cloudburst At Shingle Street" -