From owner-freebsd-ipfw Sun Mar 11 23:47:44 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 081C637B722 for ; Sun, 11 Mar 2001 23:47:20 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id JAA31313 for ; Mon, 12 Mar 2001 09:47:13 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: Subject: RE: interface specification extension for ipfw Date: Mon, 12 Mar 2001 09:47:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Patrick, I have just caught up with my mail this morning - I have read this thread with interest. My experience with ipfw is purely as a user, but my understanding is as follows: When firewalling is enabled, the kernel will pass any packet which is entering or leaving a network interface to the ipfw ruleset for evaluation. For gateways (as firewalls usually are) this means that the packet will be processed twice, inbound and outbound. When the packet is from or to the local host it will only be evaluated once! The man page says: ------------------- Each packet that has been received or is about to be sent goes through the ipfw rules. In the case of a host acting as a gateway, packets that are forwarded by the host are processed by ipfw twice (once when entering, and once when leaving). ... The in keyword indicates the rule should only match incoming packets. The out keyword indicates the rule should only match outgoing packets. ... The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in invalid) whenever xmit is used. Specifying via to- gether with xmit or recv is invalid. A packet may not have a receive or transmit interface: packets originat- ing from the local host have no receive interface. while packets destined for the local host have no transmit interface. ------------------- As I understand all this, it is impossible to set up an 'in' rule to handle packets originating on the localhost because they never come 'in', they only go 'out'. Likewise, it is impossible to set up an 'out' rule to handle packets destined for the localhost, since they only come 'in'. This would explain the discrepancy between your rules #7 and #11. #7 counts all packets going 'out', but #11 only counts packets going 'out' which originally came 'in' from somewhere else. So #7 includes traffic from the localhost, but #11 does not. I cannot comment on the ideas you have about using '!any' or 'null' or 'me' instead of the usual interface names ('cos I am not intimate with the source code). But whatever changes might be made in the way ipfw evaluates the interface information in the packets, I suspect that the kernel will still hand packets to ipfw on the same basis, namely when the packet will be passing through an interface, and NOT when it is to/from the local machine. In summary, in one of your messages you said you want to achieve something like: ------------------ 10 skipto 1000 ip from any to any in recv ed0 20 skipto 2000 ip from any to any in recv xl0 30 skipto 3000 ip from any to any in recv local 40 deny ip from any to any ------------------ In this example Rule #30 is impossible because a local packet will never be evaluated on the way 'in'. Even if you find a way of identifying the 'local' interface ('!any' or whatever), the kernel is not going to process that packet. Likewise, Rod Grimes suggested: ------------------ No, but it should be trivial to patch the code to allow your !any, if you consider that !any is the same as =null: ipfw count ip from any to any in recv null Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be null for packets originated on the local machine. ------------------ Again, I don't believe his rule will work, because ipfw will not get an opportunity to look at an 'in' packet which is from the local machine. If you change his rule to "ipfw count ip from any to any out recv null" then ipfw will handle the packet, but obviously this is on the way 'out' already. The only thing I think you can do is try to catch the packets on the way 'out' and do whatever needs doing there. In those outbound rules you should have success with one of your new keywords ('!any' or 'null' or whatever you choose). Please forgive me if I am wrong, but that is the way I have understood ipfw. If you do make these changes to the ipfw processor I certainly hope they will make it into a future release of -STABLE because it could be very useful! Have fun, Patrick O'Reilly. -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Patrick Bihan-Faou Sent: 10 March 2001 19:30 To: freebsd-ipfw@FreeBSD.ORG Subject: RE: interface specification extension for ipfw OK, I have done a couple of experiments, and now I am confused. The statement in the manpage (regarding whether or not the interface information is set) seems to be incorrect. 00001 483 113807 count ip from any to any 00002 245 17088 count ip from any to any in 00003 25 3887 count ip from any to any in recv rl0 00004 218 12895 count ip from any to any in recv rl1 00005 2 306 count ip from any to any in recv lo0 00006 245 17088 count ip from any to any in recv any 00007 238 96719 count ip from any to any out 00008 22 3536 count ip from any to any out recv rl0 00009 23 1166 count ip from any to any out recv rl1 00010 0 0 count ip from any to any out recv lo0 00011 45 4702 count ip from any to any out recv any 00012 25 1309 count ip from any to any out xmit rl0 00013 211 95104 count ip from any to any out xmit rl1 00014 2 306 count ip from any to any out xmit lo0 00015 238 96719 count ip from any to any out xmit any 00016 0 0 count ip from any to any out recv rl0 xmit rl0 00017 22 3536 count ip from any to any out recv rl0 xmit rl1 00018 0 0 count ip from any to any out recv rl0 xmit lo0 00019 22 3536 count ip from any to any out recv rl0 xmit any 00020 23 1166 count ip from any to any out recv rl1 xmit rl0 00021 0 0 count ip from any to any out recv rl1 xmit rl1 00022 0 0 count ip from any to any out recv rl1 xmit lo0 00023 23 1166 count ip from any to any out recv rl1 xmit any 00024 0 0 count ip from any to any out recv lo0 xmit rl0 00025 0 0 count ip from any to any out recv lo0 xmit rl1 00026 0 0 count ip from any to any out recv lo0 xmit lo0 00027 0 0 count ip from any to any out recv lo0 xmit any 00028 23 1166 count ip from any to any out recv any xmit rl0 00029 22 3536 count ip from any to any out recv any xmit rl1 00030 0 0 count ip from any to any out recv any xmit lo0 00031 45 4702 count ip from any to any out recv any xmit any These traces seem to suggest that no packets are ever passed to the firewall rules without proper interface information. I certainly cannot confirm that the following statement is valid in a reliable way: A packet may not have a receive or transmit interface: packets originating from the local host have no receive interface, while packets destined for the local host have no transmit interface. For rules with the "in" keyword, I cannot find any packet that don't have the "recv" interface information set (count for rule #2 == #6 == #3 + #4 + #5). For rules with the "out" keyword, the xmit interface is also always indicated (#7 == #15 == #12 + #13 + #14). However rules with the "out" keyword may loose the "recv" interface information (#7 != #11). I first thought that maybe the diversion to natd was causing this (not shown in the above snippet), but the number of packets that have been diverted is equal to the number of packets that have "recv" interface information with the "out" keyword (rule #11). The test traffic included pings from the host, going through the host (this is my router to the internet), from the host to the host itself. I am getting increasingly confused with all of this, and any word of wisdom would be greatly appreciated. Specifically: - is it possible to have no "recv" interface with the "in" keyword ? - what makes the "recv" interface information unavailable for "out" rules ? Could it be that locally generated packets are never subjected to the "in" rules ? Thanks in advance! Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 13 4:40: 9 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from hq1.tyfon.net (hq1.tyfon.net [217.27.162.35]) by hub.freebsd.org (Postfix) with ESMTP id 3B97437B726 for ; Tue, 13 Mar 2001 04:40:07 -0800 (PST) (envelope-from dl@tyfon.net) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 497B01C844 for ; Tue, 13 Mar 2001 13:40:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by hq1.tyfon.net (Postfix) with ESMTP id 558241C85E for ; Tue, 13 Mar 2001 13:40:02 +0100 (CET) Date: Tue, 13 Mar 2001 13:40:02 +0100 (CET) From: Dan Larsson To: Subject: Ethernet Firewall? Message-ID: Organization: Tyfon Svenska AB X-NCC-NIC: DL1999-RIPE X-NCC-RegID: se.tyfon MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by hq1.tyfon.net Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi! What ever happend to this patch? http://www.freebsd.org/cgi/getmsg.cgi?fetch=1578366+0+/usr/local/www/db/text/2000/freebsd-questions/20000227.freebsd-questions Anyone working on an ethernet address filter addition to ipfw? Regards +------ Dan Larsson | Tel: +46 8 550 120 21 Tyfon Svenska AB | Fax: +46 8 550 120 02 GPG and PGP keys | finger dl@hq1.tyfon.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 13 7:25:48 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from apollo.ocsny.com (apollo.ocsny.com [204.107.76.2]) by hub.freebsd.org (Postfix) with ESMTP id EED5C37B718 for ; Tue, 13 Mar 2001 07:25:36 -0800 (PST) (envelope-from mikel@ocsinternet.com) Received: from ocsinternet.com (thoth.upan.org [204.107.76.16]) by apollo.ocsny.com (8.9.2/8.9.3) with ESMTP id KAA99736; Tue, 13 Mar 2001 10:23:24 -0500 (EST) Message-ID: <3AAE3D3F.33A84CC4@ocsinternet.com> Date: Tue, 13 Mar 2001 10:31:11 -0500 From: Mikel X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en,it MIME-Version: 1.0 To: Dan Larsson Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: Ethernet Firewall? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Last I knew it was here. I don't know trhe status of it being added to bsd as a whole though... Cheers, Mikel http://spe.kakito.com/ Dan Larsson wrote: > Hi! > > What ever happend to this patch? > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1578366+0+/usr/local/www/db/text/2000/freebsd-questions/20000227.freebsd-questions > > Anyone working on an ethernet address filter addition to ipfw? > > Regards > +------ > Dan Larsson | Tel: +46 8 550 120 21 > Tyfon Svenska AB | Fax: +46 8 550 120 02 > GPG and PGP keys | finger dl@hq1.tyfon.net > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 13 8:33:29 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mail.ibizcorp.com (internal-office.ibizcorp.com [63.110.128.74]) by hub.freebsd.org (Postfix) with ESMTP id 9C91B37B721 for ; Tue, 13 Mar 2001 08:33:25 -0800 (PST) (envelope-from brad@iBizcorp.com) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 13 Mar 2001 09:37:33 -0700 Message-ID: <40DFA2708D54D41193F20001025665B61ABBFF@MAIL> From: Bradley Senff To: "'freebsd-ipfw@freebsd.org'" Subject: RE: IPFW and forwarding from one interface to another (LONG) Date: Tue, 13 Mar 2001 09:37:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nick, et al. I didn't see that the fwd was for outbound only. I have adjusted my filters to reflect that concept, and all is well. To summarize: To make this work, I went to the uplink port (fxp0), and put in a filter that was basically "add xxxx fwd 5.5.5.5 ip from 1.1.1.0/24 to any out fxp0" ... The only curiousity I have left is whether that forces the packets back through the firewall, since it will be going "out" a different port after that rule... Thoughts? Thank you for the kick in the head. :-) -brad -----Original Message----- From: Nick Rogness [mailto:nick@rogness.net] Sent: Tuesday, March 06, 2001 12:27 PM To: Bradley Senff Cc: 'freebsd-ipfw@freebsd.org' Subject: Re: IPFW and forwarding from one interface to another (LONG) On Tue, 6 Mar 2001, Bradley Senff wrote: [snip] > # HERE IS what should be FORCING the traffic back through dc0 > # but it isn't! > # I have also tried to use 5.5.5.6/30 as well, but no dice. > add 11000 fwd 5.5.5.5 ip from 1.1.1.0/24 to any via in dc1 ipfw fwd only works on outbound traffic. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 13 11:53:14 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 4B6F437B726 for ; Tue, 13 Mar 2001 11:53:08 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2DKMfL12880; Tue, 13 Mar 2001 14:22:42 -0600 (CST) (envelope-from nick@rogness.net) Date: Tue, 13 Mar 2001 14:22:41 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: Bradley Senff Cc: "'freebsd-ipfw@freebsd.org'" Subject: RE: IPFW and forwarding from one interface to another (LONG) In-Reply-To: <40DFA2708D54D41193F20001025665B61ABBFF@MAIL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 13 Mar 2001, Bradley Senff wrote: > Nick, et al. > I didn't see that the fwd was for outbound only. I have adjusted my > filters to reflect that concept, and all is well. > > To summarize: > To make this work, I went to the uplink port (fxp0), and put in a > filter that was basically "add xxxx fwd 5.5.5.5 ip from 1.1.1.0/24 to any > out fxp0" ... > > The only curiousity I have left is whether that forces the packets > back through the firewall, since it will be going "out" a different port > after that rule... Thoughts? Yes, it will be filtered on the way out the other interface. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Mar 13 13:59:19 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id AF69837B71B for ; Tue, 13 Mar 2001 13:59:15 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 6871381D03; Tue, 13 Mar 2001 15:59:15 -0600 (CST) Date: Tue, 13 Mar 2001 15:59:15 -0600 From: Bill Fumerola To: Mikel Cc: Dan Larsson , freebsd-ipfw@FreeBSD.ORG Subject: Re: Ethernet Firewall? Message-ID: <20010313155915.K31752@elvis.mu.org> References: <3AAE3D3F.33A84CC4@ocsinternet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3AAE3D3F.33A84CC4@ocsinternet.com>; from mikel@ocsinternet.com on Tue, Mar 13, 2001 at 10:31:11AM -0500 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Mar 13, 2001 at 10:31:11AM -0500, Mikel wrote: > Last I knew it was here. I don't know trhe status of it being added to bsd as a whole though... [..] > > http://spe.kakito.com/ > > Dan Larsson wrote: > > > http://www.freebsd.org/cgi/getmsg.cgi?fetch=1578366+0+/usr/local/www/db/text/2000/freebsd-questions/20000227.freebsd-questions > > > > Anyone working on an ethernet address filter addition to ipfw? I really don't think ipfw's charter is to poke around in the ethernet header. That being said, if I can integrate this in a way that won't hurt performance for the rest of ipfw (and I'm pretty sure I can) I will add it to ipfw, rather then introducing another program and subsystem to maintain. I'll try and integrate it into my local ipfw trees sometime this week. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 10: 6:13 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from johnnydang.net (cp160443-a.mtgmry1.md.home.com [65.1.242.45]) by hub.freebsd.org (Postfix) with ESMTP id 2E0CD37B718 for ; Wed, 14 Mar 2001 10:06:10 -0800 (PST) (envelope-from johnny.dang@johnnydang.net) Received: from localhost (johnny_dang@localhost) by johnnydang.net (8.11.1/8.11.1) with ESMTP id f2EI7MF01236 for ; Wed, 14 Mar 2001 13:07:23 -0500 (EST) (envelope-from johnny.dang@johnnydang.net) X-Authentication-Warning: johnnydang.net: johnny_dang owned process doing -bs Date: Wed, 14 Mar 2001 13:07:22 -0500 (EST) From: Johnny Dang X-Sender: johnny_dang@johnnydang.net To: FreeBSD IpFW Subject: Any good book or source about the IPFW? Message-ID: Organization: JOHNNYDANG.NET MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As I am done with the natd, I need to know more about setting up the rules. Any good book and examples of the IPFW commands? I need to have a better security... Any web sites with good examples of IPFW? Thanks. ++++++++++++++++++++++++++++++++++++++++++++++++++ "The instructions said to use Windows 98 or better, so I installed FreeBSD...It is working now!..." ++++++++++++++++++++++++++++++++++++++++++++++++++ Johnny Dang To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 16: 7:59 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from vorrix.com (ns1.vorrix.com [205.214.90.212]) by hub.freebsd.org (Postfix) with ESMTP id 84EC437B718 for ; Wed, 14 Mar 2001 16:07:55 -0800 (PST) (envelope-from steffen@vorrix.com) Received: from ws001 [208.60.70.194] by vorrix.com [192.168.0.1] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 14 Mar 2001 19:09:23 -0500 Message-ID: <001701c0ace3$f860eff0$fd03a8c0@ws001> From: "Steffen Vorrix" To: Subject: SSH Forwarding Date: Wed, 14 Mar 2001 19:07:48 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C0ACBA.0EF844E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDRemoteIP: 208.60.70.194 X-Return-Path: steffen@vorrix.com X-MDaemon-Deliver-To: freebsd-ipfw@freebsd.org Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_0014_01C0ACBA.0EF844E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to forward SSH to another FreeBSD box behind my FreeBSD = Firewall. My FreeBSD Firewall answers to 3 public IP addresses. I can = get all redirects working properly, from web to mail traffic, and I can = connect to the firewall with SSH, but I can't get through the firewall = back to my internal machine from an external source. I have setup the = redirect in my natd.conf, checked for typos, etc, and have setup my = firewall for testing purposes to type open, and I still am not having = any luck. Can anyone think of anything that I am missing? All web = traffic and mail traffic flow just fine. It is only SSH redirection = that doesn't work. Any help would be appreciated. Chris Schremser ------=_NextPart_000_0014_01C0ACBA.0EF844E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am trying to forward SSH to another = FreeBSD box=20 behind my FreeBSD Firewall.  My FreeBSD Firewall answers to 3 = public IP=20 addresses.  I can get all redirects working properly, from web to = mail=20 traffic, and I can connect to the firewall with SSH, but I can't get = through the=20 firewall back to my internal machine from an external source.  I = have setup=20 the redirect in my natd.conf, checked for typos, etc, and have setup my = firewall=20 for testing purposes to type open, and I still am not having any = luck.  Can=20 anyone think of anything that I am missing?  All web traffic and = mail=20 traffic flow just fine.  It is only SSH redirection that doesn't=20 work.
 
Any help would be = appreciated.
 
Chris = Schremser
------=_NextPart_000_0014_01C0ACBA.0EF844E0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 20: 1:29 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mailx.info.com.ph (mailx.info.com.ph [203.172.11.23]) by hub.freebsd.org (Postfix) with ESMTP id 6D6CC37B718 for ; Wed, 14 Mar 2001 20:01:20 -0800 (PST) (envelope-from nitronarc@foresightone.com) Received: from it_manager.foresightone.com ([202.163.209.16]) by mailx.info.com.ph (8.11.2/8.11.2) with ESMTP id f2F3tsX19954 for ; Thu, 15 Mar 2001 11:56:09 +0800 (HKT) Message-Id: <5.0.2.1.2.20010315113100.009f19a0@localhost> X-Sender: f1si@pop.info.com.ph (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Mar 2001 12:00:44 +0800 To: freebsd-ipfw@freebsd.org From: "Ramoncito P. Puyat" Subject: help with ipfw Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG greetings! We have a small company using a cable connection for our internet. Recently, due to some nuisance hacking we installed a freebsd box with ipfw/natd. Everything went fine until two of our employees complained that we were not able to use the pc-to-phone facility of MSN Messenger and the ftp facility of ICQ. When we needed to call, we had to bring the firewall to open-mode and only closed it up after the phone call. My security logs points to many probe/scan attempts from the outside especially in the 137-139 port range. We tried to make the rules as per the suggestion of MSN and ICQ but to no avail. Could someone help me out on this. I want to allow the use of MSN and ICQ with out necessarily removing my protection. Below is a copy of my ipfw rules. TIA Ramon ----- ipfw.rules ----- # Suck in the configuration variables. if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi if [ -n "${1}" ]; then firewall_type="${1}" fi # Flush previous rules /sbin/ipfw -f flush # Allow loopbacks, deny imposters /sbin/ipfw add 100 pass all from any to any via lo0 /sbin/ipfw add 200 deny all from any to 127.0.0.0/8 # Stop spoofing /sbin/ipfw add deny all from 192.168.0.0/16 to any in via ed0 /sbin/ipfw add deny all from not 192.168.0.0/16 to any in via rl0 # Stop RFC1918 nets on the outside interface /sbin/ipfw add deny all from any to 10.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 172.16.0.0/12 via ed0 /sbin/ipfw add deny all from any to 192.168.0.0/16 via ed0 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface /sbin/ipfw add deny all from any to 0.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 169.254.0.0/16 via ed0 /sbin/ipfw add deny all from any to 192.0.2.0/24 via ed0 /sbin/ipfw add deny all from any to 224.0.0.0/4 via ed0 /sbin/ipfw add deny all from any to 240.0.0.0/4 via ed0 /sbin/ipfw add deny all from 0.0.0.0/8 to any via ed0 /sbin/ipfw add deny all from 169.254.0.0/16 to any via ed0 /sbin/ipfw add deny all from 192.0.2.0/24 to any via ed0 /sbin/ipfw add deny all from 224.0.0.0/4 to any via ed0 /sbin/ipfw add deny all from 240.0.0.0/4 to any via ed0 # Stop Scour /sbin/ipfw add deny all from 209.249.159.0/24 to any via ed0 /sbin/ipfw add deny all from 216.52.208.0/24 to any via ed0 /sbin/ipfw add deny all from any to 209.249.159.0/24 via ed0 /sbin/ipfw add deny all from any to 216.52.208.0/24 via ed0 # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP # address set to 192.0.2.1 then an incoming packet for it after being # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. /sbin/ipfw add divert 8668 ip from any to any via ed0 # Allow established connections with minimal overhead /sbin/ipfw add allow tcp from any to any established # Allow IP fragments to pass through /sbin/ipfw add allow all from any to any frag ### TCP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow tcp from any to 203.172.11.21 53 /sbin/ipfw add allow tcp from any to 203.172.11.25 53 /sbin/ipfw add allow tcp from 203.172.11.21 53 to any /sbin/ipfw add allow tcp from 203.172.11.25 53 to any # HTTP - Allow access to our web server /sbin/ipfw add allow tcp from any to any 80 setup # HTTPS - Allow access to our secure server /sbin/ipfw add allow tcp from any to any 443 setup # POP - Allow access to our POP3 server /sbin/ipfw add allow tcp from any to any 110 setup # SMTP - Allow access to sendmail for incoming e-mail /sbin/ipfw add allow tcp from any to any 25 setup # FTP - Allow incoming data channel for outgoing connections, # reject & log all incoming control connections /sbin/ipfw add allow tcp from any 20 to any 1024-65535 setup /sbin/ipfw add deny log tcp from any to any 21 in via ed0 setup # SSH Login - Allow & Log all incoming /sbin/ipfw add allow log tcp from any to any 22 in via ed0 setup # IDENT - Reset incoming connections /sbin/ipfw add reset tcp from any to any 113 in via ed0 setup # NFS /sbin/ipfw add deny log tcp from any to any 2049 in recv ed0 # ICQ /sbin/ipfw add allow tcp from any 5190 to any via ed0 /sbin/ipfw add allow tcp from any to any 5190 via ed0 # MSN Messenger /sbin/ipfw add allow tcp from any 6901 to any via ed0 /sbin/ipfw add allow tcp from any to any 6901 via ed0 /sbin/ipfw add allow tcp from any to any 7801-7825 via ed0 /sbin/ipfw add allow tcp from any 6891-6900 to any via ed0 /sbin/ipfw add allow tcp from any to any 6891-6900 via ed0 # X Servers /sbin/ipfw add deny log tcp from any to any 6000-6010 in recv ed0 # Reject&Log all setup of incoming connections from the outside /sbin/ipfw add deny log tcp from any to any in via ed0 setup # Allow setup of any other TCP connection /sbin/ipfw add allow tcp from any to any setup ### UDP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow udp from any to 203.172.11.21 53 /sbin/ipfw add allow udp from any to 203.172.11.25 53 /sbin/ipfw add allow udp from 203.172.11.21 53 to any /sbin/ipfw add allow udp from 203.172.11.25 53 to any # SMB - Allow local traffic /sbin/ipfw add allow udp from any to any 137-139 via rl0 # SYSLOG - Allow machines on inside net to log to us. /sbin/ipfw add allow log udp from any to any 514 via rl0 # NTP - Allow queries out in the world /sbin/ipfw add allow udp from any 123 to any 123 via ed0 /sbin/ipfw add allow udp from any 123 to any via rl0 /sbin/ipfw add allow udp from any to any 123 via rl0 # MSN Messenger /sbin/ipfw add allow udp from any to any 6801 via ed0 /sbin/ipfw add allow udp from any to any 6901 via ed0 /sbin/ipfw add allow udp from any to any 2001-2120 via ed0 /sbin/ipfw add allow udp from any 6801 to any via ed0 /sbin/ipfw add allow udp from any 6901 to any via ed0 /sbin/ipfw add allow udp from any 2001-2120 to any via ed0 # NFS /sbin/ipfw add deny log udp from any to any 2049 in recv ed0 # TRACEROUTE - Allow outgoing /sbin/ipfw add allow udp from any to any 33434-33523 out via ed0 ### ICMP RULES # ICMP packets # Allow all ICMP packets on internal interface /sbin/ipfw add allow icmp from any to any via rl0 # Allow outgoing pings /sbin/ipfw add allow icmp from any to any icmptypes 8 out via ed0 /sbin/ipfw add allow icmp from any to any icmptypes 0 in via ed0 # Allow Destination Unreachable, Source Quench, Time Exceeded, and Bad Header /sbin/ipfw add allow icmp from any to any icmptypes 3,4,11,12 via ed0 # Deny the rest of them /sbin/ipfw add deny icmp from any to any ### MISCELLANEOUS REJECT RULES # Reject broadcasts from outside interface /sbin/ipfw add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ed0 # Reject&Log SMB connections on outside interface /sbin/ipfw add 64000 deny log udp from any to any 137-139 via ed0 # Reject&Log all other connections from outside interface /sbin/ipfw add 65000 deny log ip from any to any via ed0 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 20:41: 9 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mail3.info.com.ph (mail3.info.com.ph [203.172.11.152]) by hub.freebsd.org (Postfix) with ESMTP id 43A0137B719 for ; Wed, 14 Mar 2001 20:41:02 -0800 (PST) (envelope-from nitronarc@iname.com) Received: from it_manager.iname.com ([202.163.209.16]) by mail3.info.com.ph (8.9.3/8.9.3) with ESMTP id MAA10638 for ; Thu, 15 Mar 2001 12:28:43 +0800 Message-Id: <5.0.2.1.2.20010315124042.009f4850@pop.info.com.ph> X-Sender: ajpuyat/mail.globe.com.ph@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Mar 2001 12:40:49 +0800 To: freebsd-ipfw@freebsd.org From: "Ramoncito P. Puyat" Subject: help with ipfw Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG greetings! We have a small company using a cable connection for our internet. Recently, due to some nuisance hacking we installed a freebsd box with ipfw/natd. Everything went fine until two of our employees complained that we were not able to use the pc-to-phone facility of MSN Messenger and the ftp facility of ICQ. When we needed to call, we had to bring the firewall to open-mode and only closed it up after the phone call. My security logs points to many probe/scan attempts from the outside especially in the 137-139 port range. We tried to make the rules as per the suggestion of MSN and ICQ but to no avail. Could someone help me out on this. I want to allow the use of MSN and ICQ with out necessarily removing my protection. Below is a copy of my ipfw rules. TIA Ramon ----- ipfw.rules ----- # Suck in the configuration variables. if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi if [ -n "${1}" ]; then firewall_type="${1}" fi # Flush previous rules /sbin/ipfw -f flush # Allow loopbacks, deny imposters /sbin/ipfw add 100 pass all from any to any via lo0 /sbin/ipfw add 200 deny all from any to 127.0.0.0/8 # Stop spoofing /sbin/ipfw add deny all from 192.168.0.0/16 to any in via ed0 /sbin/ipfw add deny all from not 192.168.0.0/16 to any in via rl0 # Stop RFC1918 nets on the outside interface /sbin/ipfw add deny all from any to 10.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 172.16.0.0/12 via ed0 /sbin/ipfw add deny all from any to 192.168.0.0/16 via ed0 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface /sbin/ipfw add deny all from any to 0.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 169.254.0.0/16 via ed0 /sbin/ipfw add deny all from any to 192.0.2.0/24 via ed0 /sbin/ipfw add deny all from any to 224.0.0.0/4 via ed0 /sbin/ipfw add deny all from any to 240.0.0.0/4 via ed0 /sbin/ipfw add deny all from 0.0.0.0/8 to any via ed0 /sbin/ipfw add deny all from 169.254.0.0/16 to any via ed0 /sbin/ipfw add deny all from 192.0.2.0/24 to any via ed0 /sbin/ipfw add deny all from 224.0.0.0/4 to any via ed0 /sbin/ipfw add deny all from 240.0.0.0/4 to any via ed0 # Stop Scour /sbin/ipfw add deny all from 209.249.159.0/24 to any via ed0 /sbin/ipfw add deny all from 216.52.208.0/24 to any via ed0 /sbin/ipfw add deny all from any to 209.249.159.0/24 via ed0 /sbin/ipfw add deny all from any to 216.52.208.0/24 via ed0 # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP # address set to 192.0.2.1 then an incoming packet for it after being # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. /sbin/ipfw add divert 8668 ip from any to any via ed0 # Allow established connections with minimal overhead /sbin/ipfw add allow tcp from any to any established # Allow IP fragments to pass through /sbin/ipfw add allow all from any to any frag ### TCP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow tcp from any to 203.172.11.21 53 /sbin/ipfw add allow tcp from any to 203.172.11.25 53 /sbin/ipfw add allow tcp from 203.172.11.21 53 to any /sbin/ipfw add allow tcp from 203.172.11.25 53 to any # HTTP - Allow access to our web server /sbin/ipfw add allow tcp from any to any 80 setup # HTTPS - Allow access to our secure server /sbin/ipfw add allow tcp from any to any 443 setup # POP - Allow access to our POP3 server /sbin/ipfw add allow tcp from any to any 110 setup # SMTP - Allow access to sendmail for incoming e-mail /sbin/ipfw add allow tcp from any to any 25 setup # FTP - Allow incoming data channel for outgoing connections, # reject & log all incoming control connections /sbin/ipfw add allow tcp from any 20 to any 1024-65535 setup /sbin/ipfw add deny log tcp from any to any 21 in via ed0 setup # SSH Login - Allow & Log all incoming /sbin/ipfw add allow log tcp from any to any 22 in via ed0 setup # IDENT - Reset incoming connections /sbin/ipfw add reset tcp from any to any 113 in via ed0 setup # NFS /sbin/ipfw add deny log tcp from any to any 2049 in recv ed0 # ICQ /sbin/ipfw add allow tcp from any 5190 to any via ed0 /sbin/ipfw add allow tcp from any to any 5190 via ed0 # MSN Messenger /sbin/ipfw add allow tcp from any 6901 to any via ed0 /sbin/ipfw add allow tcp from any to any 6901 via ed0 /sbin/ipfw add allow tcp from any to any 7801-7825 via ed0 /sbin/ipfw add allow tcp from any 6891-6900 to any via ed0 /sbin/ipfw add allow tcp from any to any 6891-6900 via ed0 # X Servers /sbin/ipfw add deny log tcp from any to any 6000-6010 in recv ed0 # Reject&Log all setup of incoming connections from the outside /sbin/ipfw add deny log tcp from any to any in via ed0 setup # Allow setup of any other TCP connection /sbin/ipfw add allow tcp from any to any setup ### UDP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow udp from any to 203.172.11.21 53 /sbin/ipfw add allow udp from any to 203.172.11.25 53 /sbin/ipfw add allow udp from 203.172.11.21 53 to any /sbin/ipfw add allow udp from 203.172.11.25 53 to any # SMB - Allow local traffic /sbin/ipfw add allow udp from any to any 137-139 via rl0 # SYSLOG - Allow machines on inside net to log to us. /sbin/ipfw add allow log udp from any to any 514 via rl0 # NTP - Allow queries out in the world /sbin/ipfw add allow udp from any 123 to any 123 via ed0 /sbin/ipfw add allow udp from any 123 to any via rl0 /sbin/ipfw add allow udp from any to any 123 via rl0 # MSN Messenger /sbin/ipfw add allow udp from any to any 6801 via ed0 /sbin/ipfw add allow udp from any to any 6901 via ed0 /sbin/ipfw add allow udp from any to any 2001-2120 via ed0 /sbin/ipfw add allow udp from any 6801 to any via ed0 /sbin/ipfw add allow udp from any 6901 to any via ed0 /sbin/ipfw add allow udp from any 2001-2120 to any via ed0 # NFS /sbin/ipfw add deny log udp from any to any 2049 in recv ed0 # TRACEROUTE - Allow outgoing /sbin/ipfw add allow udp from any to any 33434-33523 out via ed0 ### ICMP RULES # ICMP packets # Allow all ICMP packets on internal interface /sbin/ipfw add allow icmp from any to any via rl0 # Allow outgoing pings /sbin/ipfw add allow icmp from any to any icmptypes 8 out via ed0 /sbin/ipfw add allow icmp from any to any icmptypes 0 in via ed0 # Allow Destination Unreachable, Source Quench, Time Exceeded, and Bad Header /sbin/ipfw add allow icmp from any to any icmptypes 3,4,11,12 via ed0 # Deny the rest of them /sbin/ipfw add deny icmp from any to any ### MISCELLANEOUS REJECT RULES # Reject broadcasts from outside interface /sbin/ipfw add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ed0 # Reject&Log SMB connections on outside interface /sbin/ipfw add 64000 deny log udp from any to any 137-139 via ed0 # Reject&Log all other connections from outside interface /sbin/ipfw add 65000 deny log ip from any to any via ed0 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 22: 4:33 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id 7FFA437B71C for ; Wed, 14 Mar 2001 22:04:24 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id IAA80669; Thu, 15 Mar 2001 08:04:11 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "Steffen Vorrix" , Subject: RE: SSH Forwarding Date: Thu, 15 Mar 2001 08:04:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C0AD26.848EFDE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <001701c0ace3$f860eff0$fd03a8c0@ws001> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C0AD26.848EFDE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Steffen, It seems strange that your rules work for HTTP and SMTP, but not for SSH. You will need to supply more info before anyone can help. Please list the pertinent parts of your ipfw rules (rc.firewall), and your natd.conf. Regards, Patrick O'Reilly --- "I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use." -- Galileo Galilei -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Steffen Vorrix Sent: 15 March 2001 02:08 To: freebsd-ipfw@FreeBSD.ORG Subject: SSH Forwarding I am trying to forward SSH to another FreeBSD box behind my FreeBSD Firewall. My FreeBSD Firewall answers to 3 public IP addresses. I can get all redirects working properly, from web to mail traffic, and I can connect to the firewall with SSH, but I can't get through the firewall back to my internal machine from an external source. I have setup the redirect in my natd.conf, checked for typos, etc, and have setup my firewall for testing purposes to type open, and I still am not having any luck. Can anyone think of anything that I am missing? All web traffic and mail traffic flow just fine. It is only SSH redirection that doesn't work. Any help would be appreciated. Chris Schremser ------=_NextPart_000_00A5_01C0AD26.848EFDE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Steffen,
 
It=20 seems strange that your rules work for HTTP and SMTP, but not for=20 SSH.
 
You=20 will need to supply more info before anyone can help.  Please list = the=20 pertinent parts of your ipfw rules (rc.firewall), and your=20 natd.conf.

Regards,
Patrick O'Reilly
---
"I do not feel = obliged to=20 believe that the same God who has endowed us with sense, reason, and = intellect=20 has intended us to forego their use." -- Galileo Galilei=20

-----Original Message-----
From:=20 owner-freebsd-ipfw@FreeBSD.ORG = [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On=20 Behalf Of Steffen Vorrix
Sent: 15 March 2001 = 02:08
To:=20 freebsd-ipfw@FreeBSD.ORG
Subject: SSH=20 Forwarding

I am trying to forward SSH to another = FreeBSD box=20 behind my FreeBSD Firewall.  My FreeBSD Firewall answers to 3 = public IP=20 addresses.  I can get all redirects working properly, from web to = mail=20 traffic, and I can connect to the firewall with SSH, but I can't get = through=20 the firewall back to my internal machine from an external = source.  I have=20 setup the redirect in my natd.conf, checked for typos, etc, and have = setup my=20 firewall for testing purposes to type open, and I still am not having = any=20 luck.  Can anyone think of anything that I am missing?  All = web=20 traffic and mail traffic flow just fine.  It is only SSH = redirection that=20 doesn't work.
 
Any help would be = appreciated.
 
Chris=20 Schremser
------=_NextPart_000_00A5_01C0AD26.848EFDE0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Mar 14 22:31: 5 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id EE29837B719 for ; Wed, 14 Mar 2001 22:30:50 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id IAA80980; Thu, 15 Mar 2001 08:30:30 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: "Ramoncito P. Puyat" , Subject: RE: help with ipfw Date: Thu, 15 Mar 2001 08:30:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.2.1.2.20010315124042.009f4850@pop.info.com.ph> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ramon, Here is the procedure I follow when trying to determine what needs to be 'open' for a specific set of comms to work. This is a highly technical method which should be used by trained professionals only!!! Do not try this at home or without professional supervision!!! ;-) Yeah, just kidding - this is trial and error development at its best! In your rc.firewall, add two rules directly after the divert to natd and the established and fragment rules something like this (X.X.X.X is the IP of the server on the Internet that you are trying to reach): -------- /sbin/ipfw add divert 8668 ip from any to any via ed0 /sbin/ipfw add allow tcp from any to any established /sbin/ipfw add allow all from any to any frag /sbin/ipfw add allow log ip from any to X.X.X.X <--- new rule /sbin/ipfw add allow log ip from X.X.X.X to any <--- new rule -------- Now, try the connections you need. They should work as the firewall is now 'open' for all traffic to/from the specific destination IP address. If it still does not work then you will need to temporarily add logging to the deny rules earlier in your rc.firewall to see which ones are stopping your comms. Read your /var/log/ipfw.log and learn what comms are happening. Then you can built more specific rules to match exactly what is needed to make it work generically. (And don't forget to remove these test rules once you are done!) Regards, Patrick O'Reilly --- "I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forego their use." -- Galileo Galilei -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of Ramoncito P. Puyat Sent: 15 March 2001 06:41 To: freebsd-ipfw@FreeBSD.ORG Subject: help with ipfw greetings! We have a small company using a cable connection for our internet. Recently, due to some nuisance hacking we installed a freebsd box with ipfw/natd. Everything went fine until two of our employees complained that we were not able to use the pc-to-phone facility of MSN Messenger and the ftp facility of ICQ. When we needed to call, we had to bring the firewall to open-mode and only closed it up after the phone call. My security logs points to many probe/scan attempts from the outside especially in the 137-139 port range. We tried to make the rules as per the suggestion of MSN and ICQ but to no avail. Could someone help me out on this. I want to allow the use of MSN and ICQ with out necessarily removing my protection. Below is a copy of my ipfw rules. TIA Ramon ----- ipfw.rules ----- # Suck in the configuration variables. if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi if [ -n "${1}" ]; then firewall_type="${1}" fi # Flush previous rules /sbin/ipfw -f flush # Allow loopbacks, deny imposters /sbin/ipfw add 100 pass all from any to any via lo0 /sbin/ipfw add 200 deny all from any to 127.0.0.0/8 # Stop spoofing /sbin/ipfw add deny all from 192.168.0.0/16 to any in via ed0 /sbin/ipfw add deny all from not 192.168.0.0/16 to any in via rl0 # Stop RFC1918 nets on the outside interface /sbin/ipfw add deny all from any to 10.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 172.16.0.0/12 via ed0 /sbin/ipfw add deny all from any to 192.168.0.0/16 via ed0 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes RESERVED-1, # DHCP auto-configuration, NET-TEST, MULTICAST (class D), and class E) # on the outside interface /sbin/ipfw add deny all from any to 0.0.0.0/8 via ed0 /sbin/ipfw add deny all from any to 169.254.0.0/16 via ed0 /sbin/ipfw add deny all from any to 192.0.2.0/24 via ed0 /sbin/ipfw add deny all from any to 224.0.0.0/4 via ed0 /sbin/ipfw add deny all from any to 240.0.0.0/4 via ed0 /sbin/ipfw add deny all from 0.0.0.0/8 to any via ed0 /sbin/ipfw add deny all from 169.254.0.0/16 to any via ed0 /sbin/ipfw add deny all from 192.0.2.0/24 to any via ed0 /sbin/ipfw add deny all from 224.0.0.0/4 to any via ed0 /sbin/ipfw add deny all from 240.0.0.0/4 to any via ed0 # Stop Scour /sbin/ipfw add deny all from 209.249.159.0/24 to any via ed0 /sbin/ipfw add deny all from 216.52.208.0/24 to any via ed0 /sbin/ipfw add deny all from any to 209.249.159.0/24 via ed0 /sbin/ipfw add deny all from any to 216.52.208.0/24 via ed0 # Network Address Translation. This rule is placed here deliberately # so that it does not interfere with the surrounding address-checking # rules. If for example one of your internal LAN machines had its IP # address set to 192.0.2.1 then an incoming packet for it after being # translated by natd(8) would match the `deny' rule above. Similarly # an outgoing packet originated from it before being translated would # match the `deny' rule below. /sbin/ipfw add divert 8668 ip from any to any via ed0 # Allow established connections with minimal overhead /sbin/ipfw add allow tcp from any to any established # Allow IP fragments to pass through /sbin/ipfw add allow all from any to any frag ### TCP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow tcp from any to 203.172.11.21 53 /sbin/ipfw add allow tcp from any to 203.172.11.25 53 /sbin/ipfw add allow tcp from 203.172.11.21 53 to any /sbin/ipfw add allow tcp from 203.172.11.25 53 to any # HTTP - Allow access to our web server /sbin/ipfw add allow tcp from any to any 80 setup # HTTPS - Allow access to our secure server /sbin/ipfw add allow tcp from any to any 443 setup # POP - Allow access to our POP3 server /sbin/ipfw add allow tcp from any to any 110 setup # SMTP - Allow access to sendmail for incoming e-mail /sbin/ipfw add allow tcp from any to any 25 setup # FTP - Allow incoming data channel for outgoing connections, # reject & log all incoming control connections /sbin/ipfw add allow tcp from any 20 to any 1024-65535 setup /sbin/ipfw add deny log tcp from any to any 21 in via ed0 setup # SSH Login - Allow & Log all incoming /sbin/ipfw add allow log tcp from any to any 22 in via ed0 setup # IDENT - Reset incoming connections /sbin/ipfw add reset tcp from any to any 113 in via ed0 setup # NFS /sbin/ipfw add deny log tcp from any to any 2049 in recv ed0 # ICQ /sbin/ipfw add allow tcp from any 5190 to any via ed0 /sbin/ipfw add allow tcp from any to any 5190 via ed0 # MSN Messenger /sbin/ipfw add allow tcp from any 6901 to any via ed0 /sbin/ipfw add allow tcp from any to any 6901 via ed0 /sbin/ipfw add allow tcp from any to any 7801-7825 via ed0 /sbin/ipfw add allow tcp from any 6891-6900 to any via ed0 /sbin/ipfw add allow tcp from any to any 6891-6900 via ed0 # X Servers /sbin/ipfw add deny log tcp from any to any 6000-6010 in recv ed0 # Reject&Log all setup of incoming connections from the outside /sbin/ipfw add deny log tcp from any to any in via ed0 setup # Allow setup of any other TCP connection /sbin/ipfw add allow tcp from any to any setup ### UDP RULES # DNS - Allow queries out in the world /sbin/ipfw add allow udp from any to 203.172.11.21 53 /sbin/ipfw add allow udp from any to 203.172.11.25 53 /sbin/ipfw add allow udp from 203.172.11.21 53 to any /sbin/ipfw add allow udp from 203.172.11.25 53 to any # SMB - Allow local traffic /sbin/ipfw add allow udp from any to any 137-139 via rl0 # SYSLOG - Allow machines on inside net to log to us. /sbin/ipfw add allow log udp from any to any 514 via rl0 # NTP - Allow queries out in the world /sbin/ipfw add allow udp from any 123 to any 123 via ed0 /sbin/ipfw add allow udp from any 123 to any via rl0 /sbin/ipfw add allow udp from any to any 123 via rl0 # MSN Messenger /sbin/ipfw add allow udp from any to any 6801 via ed0 /sbin/ipfw add allow udp from any to any 6901 via ed0 /sbin/ipfw add allow udp from any to any 2001-2120 via ed0 /sbin/ipfw add allow udp from any 6801 to any via ed0 /sbin/ipfw add allow udp from any 6901 to any via ed0 /sbin/ipfw add allow udp from any 2001-2120 to any via ed0 # NFS /sbin/ipfw add deny log udp from any to any 2049 in recv ed0 # TRACEROUTE - Allow outgoing /sbin/ipfw add allow udp from any to any 33434-33523 out via ed0 ### ICMP RULES # ICMP packets # Allow all ICMP packets on internal interface /sbin/ipfw add allow icmp from any to any via rl0 # Allow outgoing pings /sbin/ipfw add allow icmp from any to any icmptypes 8 out via ed0 /sbin/ipfw add allow icmp from any to any icmptypes 0 in via ed0 # Allow Destination Unreachable, Source Quench, Time Exceeded, and Bad Header /sbin/ipfw add allow icmp from any to any icmptypes 3,4,11,12 via ed0 # Deny the rest of them /sbin/ipfw add deny icmp from any to any ### MISCELLANEOUS REJECT RULES # Reject broadcasts from outside interface /sbin/ipfw add 63000 deny ip from any to 0.0.0.255:0.0.0.255 in via ed0 # Reject&Log SMB connections on outside interface /sbin/ipfw add 64000 deny log udp from any to any 137-139 via ed0 # Reject&Log all other connections from outside interface /sbin/ipfw add 65000 deny log ip from any to any via ed0 # Everything else is denied by default, unless the # IPFIREWALL_DEFAULT_TO_ACCEPT option is set in your kernel # config file. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Mar 15 2:25:30 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from smtp2.vol.cz (smtp2.vol.cz [195.250.128.42]) by hub.freebsd.org (Postfix) with ESMTP id 839E337B71A for ; Thu, 15 Mar 2001 02:25:26 -0800 (PST) (envelope-from michal.kutnohorsky@asp1000.com) Received: from server.asp1000.cz (mail.asp1000.cz [212.27.223.156]) by smtp2.vol.cz (8.11.1/8.11.1) with ESMTP id f2FAPMf91912 for ; Thu, 15 Mar 2001 11:25:23 +0100 (CET) Received: by server.asp1000.cz with Internet Mail Service (5.5.2650.21) id ; Thu, 15 Mar 2001 11:22:48 +0100 Message-ID: <381F2A6B1CC4C449B19CA48BA7A2A87B0E1CB9@server.asp1000.cz> From: michal.kutnohorsky@asp1000.com To: freebsd-ipfw@FreeBSD.ORG Subject: ipfw rulez Date: Thu, 15 Mar 2001 11:22:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-2" Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, Im newbie in ipfw/natd , im trying to set up my firewall at home. I read natd and ipfw manual, i exactly know what i want to allow and what to deny. I make rules as you can see bellow (now im just testing firewall from internal net 192.168.0.0 xl0 for this time i dont forwarding packtes between second interface yet...) count ip from any to any allow log tcp from any to any 22 in recv xl0 allow log tcp from any to any 22 out xmit xl0 allow log tcp from any to any 1024-65535 in recv xl0 allow log tcp from any to any 1024-65535 out xmit xl0 allow log tcp from any to any 80 out xmit xl0 allow log tcp from any to any 80 in recv xl0 allow tcp from any to 192.168.0.22 139 out xl0 allow tcp from any to 192.168.0.22 139 in xl0 80, 22 works ok but I cant connect to Samba server 192.168.0.22.139 Allways it writes me error message that port 139 at 192.168.0.22 cant be open... Can you advice me how to correct it? Does Samba needs any icmp or UDP packets? Samba is on xl0 - 192.168.0.22:139 Kernel configuration is IPFIREWALL_VERBOSE , IPDIVERT Thanky you very much michal x--------------------------x |-- Michal Kutnohorsky -- | |-- michalk@asp1000.com -- | |-- icq 24864416 -- | | \_/ -- dej si taky -- | x--------------------------x To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Mar 15 7: 9:34 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from mip.co.za (puck.mip.co.za [209.212.106.44]) by hub.freebsd.org (Postfix) with ESMTP id F280337B71A for ; Thu, 15 Mar 2001 07:09:23 -0800 (PST) (envelope-from patrick@mip.co.za) Received: from patrick (patrick.mip.co.za [10.3.13.181]) by mip.co.za (8.9.3/8.9.3) with SMTP id RAA94325; Thu, 15 Mar 2001 17:08:43 +0200 (SAST) (envelope-from patrick@mip.co.za) From: "Patrick O'Reilly" To: , "FreeBSD IPFW List" Subject: RE: ipfw rulez Date: Thu, 15 Mar 2001 17:08:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <381F2A6B1CC4C449B19CA48BA7A2A87B0E1CB9@server.asp1000.cz> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Michal, Where are these ipfw rules? I am not sure if the samba server and the firewall are the same server. 1) if ipfw is on 192.168.0.x and samba server is 192.168.0.22 then: -------- allow tcp from any to 192.168.0.22 139 out xl0 allow tcp from 192.168.0.22 139 to any in xl0 -------- 2) if ipfw is on 192.168.0.22 (same server as samba server) then: -------- allow tcp from any to 192.168.0.22 139 in xl0 allow tcp from 192.168.0.22 139 to any out xl0 -------- I do not think you need UDP for Samba ??? Your other rules should also be structured in a similar manner for HTTP, etc. I hope this helps. Patrick. -----Original Message----- From: owner-freebsd-ipfw@FreeBSD.ORG [mailto:owner-freebsd-ipfw@FreeBSD.ORG]On Behalf Of michal.kutnohorsky@asp1000.com Sent: 15 March 2001 12:23 To: freebsd-ipfw@FreeBSD.ORG Subject: ipfw rulez hi, Im newbie in ipfw/natd , im trying to set up my firewall at home. I read natd and ipfw manual, i exactly know what i want to allow and what to deny. I make rules as you can see bellow (now im just testing firewall from internal net 192.168.0.0 xl0 for this time i dont forwarding packtes between second interface yet...) count ip from any to any allow log tcp from any to any 22 in recv xl0 allow log tcp from any to any 22 out xmit xl0 allow log tcp from any to any 1024-65535 in recv xl0 allow log tcp from any to any 1024-65535 out xmit xl0 allow log tcp from any to any 80 out xmit xl0 allow log tcp from any to any 80 in recv xl0 allow tcp from any to 192.168.0.22 139 out xl0 allow tcp from any to 192.168.0.22 139 in xl0 80, 22 works ok but I cant connect to Samba server 192.168.0.22.139 Allways it writes me error message that port 139 at 192.168.0.22 cant be open... Can you advice me how to correct it? Does Samba needs any icmp or UDP packets? Samba is on xl0 - 192.168.0.22:139 Kernel configuration is IPFIREWALL_VERBOSE , IPDIVERT Thanky you very much michal x--------------------------x |-- Michal Kutnohorsky -- | |-- michalk@asp1000.com -- | |-- icq 24864416 -- | | \_/ -- dej si taky -- | x--------------------------x To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Mar 15 14:20:57 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 6305937B718 for ; Thu, 15 Mar 2001 14:20:55 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2FMOta06485 for ; Thu, 15 Mar 2001 16:24:55 -0600 (CST) (envelope-from nick@rogness.net) Date: Thu, 15 Mar 2001 16:24:55 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: freebsd-ipfw@freebsd.org Subject: natd divert injecting clarifications Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Just to be sure I have it right. When the kernel diverts the packet to natd, via ipfw: 1) kernel sends packet to natd 2) natd read() the packet 3) natd screws with it 4) natd write() the packet 5) kernel reinjects the packet back into the firewall That's what I could get out of divert(4) and some of the natd source. Bare with me...I'm still a novice programmer. Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 16 21: 0: 1 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from smtp2.info.com.ph (smtp2.info.com.ph [203.172.11.24]) by hub.freebsd.org (Postfix) with ESMTP id 1626337B719 for ; Fri, 16 Mar 2001 20:59:58 -0800 (PST) (envelope-from nitronarc@iname.com) Received: from it_manager.iname.com ([202.163.209.16]) by smtp2.info.com.ph (8.11.2/8.11.2) with ESMTP id f2H4kgA23786 for ; Sat, 17 Mar 2001 12:46:46 +0800 (HKT) Message-Id: <5.0.2.1.2.20010317125238.009e9990@localhost> X-Sender: ajpuyat/mail.globe.com.ph@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Sat, 17 Mar 2001 12:59:31 +0800 To: freebsd-ipfw@freebsd.org From: "Ramoncito P. Puyat" Subject: firewall with DMZ setup Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi all!!! Our company wants to serve web pages from our local location. We would like to set-up a ipfw/natd with a DMZ deature. Our server has three NICs (ed0 - outside if, rl0 - inside if and dc0 - DMZ if). We use the 192.168.0.0/24 address range for rl0. We want to use the 192.168.1.0/24 address range for our DMZ. How do we go about this? What rules can we use to divert ip traffic to our WWW, POP3, SMTP and other servers in the DMZ. TIA Ramon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 16 22:39:21 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from cody.jharris.com (cody.jharris.com [205.238.128.83]) by hub.freebsd.org (Postfix) with ESMTP id 2625937B718 for ; Fri, 16 Mar 2001 22:39:19 -0800 (PST) (envelope-from nick@rogness.net) Received: from localhost (nick@localhost) by cody.jharris.com (8.11.1/8.9.3) with ESMTP id f2H6cx113156; Sat, 17 Mar 2001 00:39:00 -0600 (CST) (envelope-from nick@rogness.net) Date: Sat, 17 Mar 2001 00:38:59 -0600 (CST) From: Nick Rogness X-Sender: nick@cody.jharris.com To: "Ramoncito P. Puyat" Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: firewall with DMZ setup In-Reply-To: <5.0.2.1.2.20010317125238.009e9990@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 17 Mar 2001, Ramoncito P. Puyat wrote: > hi all!!! > > Our company wants to serve web pages from our local location. We would like > to set-up a ipfw/natd with a DMZ deature. Our server has three NICs (ed0 - > outside if, rl0 - inside if and dc0 - DMZ if). We use the 192.168.0.0/24 > address range for rl0. We want to use the 192.168.1.0/24 address range for > our DMZ. How do we go about this? What rules can we use to divert ip > traffic to our WWW, POP3, SMTP and other servers in the DMZ. How many IP's (public) do you have? Just 1? Nick Rogness - Keep on routing in a Free World... "FreeBSD: The Power to Serve!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Mar 16 22:40:54 2001 Delivered-To: freebsd-ipfw@freebsd.org Received: from elvis.mu.org (elvis.mu.org [207.154.226.10]) by hub.freebsd.org (Postfix) with ESMTP id 672C437B71A for ; Fri, 16 Mar 2001 22:40:52 -0800 (PST) (envelope-from billf@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1098) id 94A7781D03; Sat, 17 Mar 2001 00:40:51 -0600 (CST) Date: Sat, 17 Mar 2001 00:40:51 -0600 From: Bill Fumerola To: "Ramoncito P. Puyat" Cc: freebsd-ipfw@freebsd.org Subject: Re: firewall with DMZ setup Message-ID: <20010317004051.J362@elvis.mu.org> References: <5.0.2.1.2.20010317125238.009e9990@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.2.1.2.20010317125238.009e9990@localhost>; from nitronarc@iname.com on Sat, Mar 17, 2001 at 12:59:31PM +0800 X-Operating-System: FreeBSD 4.2-FEARSOME-20010209 i386 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, Mar 17, 2001 at 12:59:31PM +0800, Ramoncito P. Puyat wrote: > Our company wants to serve web pages from our local location. We would like > to set-up a ipfw/natd with a DMZ deature. Our server has three NICs (ed0 - > outside if, rl0 - inside if and dc0 - DMZ if). We use the 192.168.0.0/24 > address range for rl0. We want to use the 192.168.1.0/24 address range for > our DMZ. How do we go about this? What rules can we use to divert ip > traffic to our WWW, POP3, SMTP and other servers in the DMZ. step 1: read 'man natd', specifically the parts on installation/setup step 2: read /etc/rc.firewall. twice. step 3: read 'man natd', specifically the parts on -redirect_{port,address} step 4: adapt the 'simple' firewall type in /etc/rc.firewall to your network. add 'dif/dnet/dmask/dip' for your dmz. keep in mind the difference between public ip space and private ip space when writing rules. -- Bill Fumerola - security yahoo / Yahoo! inc. - fumerola@yahoo-inc.com / billf@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message