From owner-freebsd-security Tue Jun 12 13:53:18 2001 Delivered-To: freebsd-security@freebsd.org Received: from fwnl.nextleft.com (ns1.nextleft.com [207.67.140.66]) by hub.freebsd.org (Postfix) with ESMTP id 5BF3F37B405 for ; Tue, 12 Jun 2001 13:53:06 -0700 (PDT) (envelope-from jkeck@NextLeft.COM) Received: from durban.sea.com (NextLeft.COM [172.19.4.20]) by fwnl.nextleft.com (8.9.3/8.9.3) with ESMTP id NAA74358; Tue, 12 Jun 2001 13:53:02 -0700 (PDT) (envelope-from jkeck@nextleft.com) Received: by durban.sea.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 13:57:11 -0700 Message-ID: <40B05F13113ED411A91E00D0B71A7DAC127369@durban.sea.com> From: John Keck To: "'Robin Huiser'" , freebsd-security@FreeBSD.ORG Subject: RE: ipfw, natd and routing question Date: Tue, 12 Jun 2001 13:57:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F382.3B477250" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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_01C0F382.3B477250 Content-Type: text/plain; charset="iso-8859-1" The first case diverts incoming packets for the DMZ, which you don't want. The second case fails to divert response packets for the inside, which you do want. Try: ${fwcmd} add divert natd all from not x.x.242.48:255.255.255.240 to not x.x.242.48:255.255.255.240 via ${natd_interface} Hope this helps... J. Keck NextLeft, Inc. San Diego, CA USA jkeck@nextleft.com -----Original Message----- From: Robin Huiser [mailto:robin@bequbed.com] Sent: Monday, June 11, 2001 7:47 AM To: freebsd-security@FreeBSD.ORG Subject: FW: ipfw, natd and routing question Hi all, I hope someone can help me with this problem I'm trying to solve. I think the answer is trivial, but so far I 'm stuck. Our FreeBSD 4.2-STABLE firewall has three network cards as shown below: -- DMZ / EXT--FIREWALL--- \ -- LAN -The EXT interface: connected to the Internet, IP subnet x.x.242.32/240 -The DMZ interface: connected to our DMZ subnet, IP subnet x.x.242.48/240 -The LAN interface: connected to our LAN subnet, IP subnet 192.168.1.0/24 I use NAT to 'route' traffic from the LAN to the Internet I use ipfw rules to ROUTE traffic from the Internet to the DMZ subnet So far, so good. But... how do I prevent the NAT to 'translate' the IP addresses when a session is set up from the DMZ segment to a host somewhere on the Internet? I want all traffic to be routed from the DMZ subnet to the Internet... I've tried to alter the natd rule, without any success. The rules I tried didn't work or had bad side effects, so I moved back to the standard natd rule, but everything gets NAT-ed now... Some examples I tried: # # The rule below works, but the it causes TCP/IP timeouts and a *very* slow # connection between the DMZ and EXT subnets... # ${fwcmd} add divert natd all from not x.x.242.48:255.255.255.240 to any via ${natd_interface} # # The rule below doesn't work at all (?) Don't know why... # ${fwcmd} add divert natd all from 192.168.1.0:255.255.255.0 to any via ${natd_interface} Please advise... Cheers -- Robin __________________________________________________________________ Robin Huiser robin@bequbed.com BeQubed N.V. http://www.bequbed.com Veenwal 130 tel: +31 (30) 6023 626 (OFFICE) 3432 ZE +31 (6) 2061 9842 (MOBILE) Nieuwegein fax: +31 (30) 6586 090 The Netherlands __________________________________________________________________ ======================Confidential Disclaimer===================== The information contained in this communication is confidential and is intended solely for the use of the individual or entity to whom it is addressed. You should not copy, disclose or distribute this communication without the authority of BeQubed N.V. BeQubed is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. BeQubed does not guarantee that the integrity of this communication has been maintained nor that the communication is free of viruses, interceptions or interference. If you are not the intended recipient of this communication please return the communication to the sender and delete and destroy all copies. In carrying out its engagements, BeQubed applies general terms and conditions, which contain a clause that limits its liability. A copy of these terms and conditions is available on request free of charge. ================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message ------_=_NextPart_001_01C0F382.3B477250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: ipfw, natd and routing question

The first case diverts incoming packets for the DMZ, = which you don't want.  The second case fails to divert response = packets for the inside, which you do want.  Try:

 ${fwcmd} add divert natd all from not = x.x.242.48:255.255.255.240 to not x.x.242.48:255.255.255.240
via ${natd_interface}

Hope this helps...
J. Keck
NextLeft, Inc.
San Diego, CA  USA
jkeck@nextleft.com


-----Original Message-----
From: Robin Huiser [mailto:robin@bequbed.com]
Sent: Monday, June 11, 2001 7:47 AM
To: freebsd-security@FreeBSD.ORG
Subject: FW: ipfw, natd and routing question


Hi all,

I hope someone can help me with this problem I'm = trying to solve. I think
the answer is trivial, but so far I 'm stuck.

Our FreeBSD 4.2-STABLE firewall has three network = cards as shown below:

          &nb= sp;           &nb= sp;         -- DMZ
          &nb= sp;           &nb= sp;        /
          &nb= sp;    EXT--FIREWALL---
          &nb= sp;           &nb= sp;        \
          &nb= sp;           &nb= sp;         -- LAN

-The EXT interface: connected to the Internet, IP = subnet x.x.242.32/240
-The DMZ interface: connected to our DMZ subnet, IP = subnet x.x.242.48/240
-The LAN interface: connected to our LAN subnet, IP = subnet 192.168.1.0/24

I use NAT to 'route' traffic from the LAN to the = Internet
I use ipfw rules to ROUTE traffic from the Internet = to the DMZ subnet

So far, so good.

But... how do I prevent the NAT to 'translate' the IP = addresses when a
session is set up from the DMZ segment to a host = somewhere on the Internet?
I want all traffic to be routed from the DMZ subnet = to the Internet...

I've tried to alter the natd rule, without any = success.
The rules I tried didn't work or had bad side = effects, so I moved back to
the standard natd rule, but everything gets NAT-ed = now...

Some examples I tried:

#
# The rule below works, but the it causes TCP/IP = timeouts and a *very* slow
# connection between the DMZ and EXT = subnets...
#
${fwcmd} add divert natd all from not = x.x.242.48:255.255.255.240 to any
via ${natd_interface}

#
# The rule below doesn't work at all (?) Don't know = why...
#
${fwcmd} add divert natd all from = 192.168.1.0:255.255.255.0 to any via
${natd_interface}


Please advise...

Cheers -- Robin

_______________________________________________________________= ___

Robin = Huiser           =          = robin@bequbed.com
BeQubed = N.V.           &n= bsp;        http://www.bequbed.com

Veenwal = 130           &nb= sp;         tel:   = +31 (30) 6023 626 (OFFICE)
3432 = ZE           &nbs= p;           &nbs= p;        +31 (6) 2061 9842 = (MOBILE)
Nieuwegein         = ;            = ; fax:   +31 (30) 6586 090
The Netherlands
_______________________________________________________________= ___


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3DConfidential = Disclaimer=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

The information contained in this communication is = confidential and is
intended solely for the use of the individual or = entity to whom it is
addressed. You should not copy, disclose or = distribute this communication
without the authority of BeQubed N.V. BeQubed is = neither liable for the
proper and complete transmission of the information = contained in this
communication nor for any delay in its = receipt.
BeQubed does not guarantee that the integrity of = this communication has been
maintained nor that the communication is free of = viruses, interceptions or
interference.

If you are not the intended recipient of this = communication please return
the communication to the sender and delete and = destroy all copies.

In carrying out its engagements, BeQubed applies = general terms and
conditions, which contain a clause that limits its = liability. A copy of
these terms and conditions is available on request = free of charge.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



To Unsubscribe: send mail to = majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the = body of the message

------_=_NextPart_001_01C0F382.3B477250-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message