From owner-freebsd-ipfw Mon Jul 24 8:26:41 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from c014.sfo.cp.net (c014-h001.c014.sfo.cp.net [209.228.12.65]) by hub.freebsd.org (Postfix) with SMTP id 6941E37BB3C for ; Mon, 24 Jul 2000 08:26:12 -0700 (PDT) (envelope-from dchance@valuedata.net) Received: (cpmta 126 invoked from network); 24 Jul 2000 08:26:08 -0700 Received: from m12hRs4n205.midsouth.rr.com (HELO development1) (24.95.125.205) by smtp.valuedata.net with SMTP; 24 Jul 2000 08:26:08 -0700 X-Sent: 24 Jul 2000 15:26:08 GMT Message-ID: <001b01bff583$6c8464c0$0200000a@development1> From: "Daryl Chance" To: "FreeBSD IPFW" Subject: Thanks and a Question Date: Mon, 24 Jul 2000 10:25:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hello, Thanks for the help on the firewall rules last friday, I wound up following a link from someones .sig and modified the FW rules on www.mostgraveconcern.com, thanks whoever (sorry, don't have the email anymore). Now, onto the question. I came in this morning and checked my security file and noticed the following entry: Jul 23 05:36:53 xxxx /kernel: ipfw: 400 Deny UDP 10.0.0.7:137 24.95.125.205:137 in via rl0 Jul 23 05:36:55 xxxx /kernel: ipfw: 400 Deny UDP 10.0.0.7:137 24.95.125.205:137 in via rl0 Jul 23 05:36:56 xxxx /kernel: ipfw: 400 Deny UDP 10.0.0.7:137 24.95.125.205:137 in via rl0 this someone trying to "forge" or "spoof" (sorry, not familiar with the terminology) an internal packet from an outside interface?. Is there anyway to log the actual ip, or not since it's been spoofed :). btw, whats special about 137? I know it's something specific to windows (at least IIRC). Thanks, Daryl Chance To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jul 28 0:15:57 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from osku.suutari.iki.fi (osku.syncrontech.com [213.28.98.4]) by hub.freebsd.org (Postfix) with ESMTP id 3F5F337B803 for ; Fri, 28 Jul 2000 00:15:53 -0700 (PDT) (envelope-from ari@suutari.iki.fi) Received: from coffee (adsl-nat.syncrontech.com [213.28.98.3]) by osku.suutari.iki.fi (8.9.3/8.9.3) with SMTP id KAA03510 for ; Fri, 28 Jul 2000 10:15:50 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <004101bff863$d169b600$0e05a8c0@intranet.syncrontech.com> From: "Ari Suutari" To: Subject: IPSEC tunnel mode & ipfw Date: Fri, 28 Jul 2000 10:16:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, I would like to run IPsec in tunnel mode between two offices connected by internet. Works OK otherwise, but I cannot figure out how to use ipfw in this situation so that to result is secure. Assume a packet going from office A (192.168.1.xxx) to office B (192.168.2.xxx). Host in A (192.168.1.2) | Gateway/Firewall (192.168.1.1) | Internet | Gateway/Firewall (192.168.2.1) | Host in B (192.168.2.2) The gateway machines run FreeBSD 4.0 currently. When packet comes to firewall in office A, it is tunneled by IPsec and sent to gateway at office B via internet. No problem here. At office B i have ipfw rule, which allows IPsec AH packets to come from A's gateway. Firewall at B de-tunnels the packet and it hits firewall rules again. Now, for this to work I have to have a ipfw rule allowing packets from 192.168.1.xxx to 192.168.2.xxx, otherwise the de-tunneled packet is dropped by ipfw. When I add this rule, everything works fine. However, I'm a little bit worried, since this last rule would also allow packets through if someone pretends to be 192.168.1.xxx since there is no way to tell ipfw that the rule is valid only if the packet being examined has arrived through IPsec tunnel. I solved this temporarily by using pipsecd - now I can trust that packets coming from interface tun0 have gone through IPsec checks. However, I would like to use the functionality available in kernel. Any ideas anyone ? Ari S. -- Ari Suutari Lemi, Finland To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Fri Jul 28 7:46: 8 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from horst.bfd.com (horst.bfd.com [12.9.219.10]) by hub.freebsd.org (Postfix) with ESMTP id 3D98537B9BD for ; Fri, 28 Jul 2000 07:46:05 -0700 (PDT) (envelope-from ejs@bfd.com) Received: from HARLIE.bfd.com (bastion.bfd.com [12.9.219.14]) by horst.bfd.com (8.10.0/8.10.0) with ESMTP id e6SEjvi47656; Fri, 28 Jul 2000 07:45:58 -0700 (PDT) Date: Fri, 28 Jul 2000 07:45:57 -0700 (PDT) From: "Eric J. Schwertfeger" To: Ari Suutari Cc: freebsd-ipfw@FreeBSD.ORG Subject: Re: IPSEC tunnel mode & ipfw In-Reply-To: <004101bff863$d169b600$0e05a8c0@intranet.syncrontech.com> 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 Fri, 28 Jul 2000, Ari Suutari wrote: > However, I'm a little bit worried, since this last rule > would also allow packets through if someone pretends > to be 192.168.1.xxx since there is no way to tell ipfw > that the rule is valid only if the packet being examined > has arrived through IPsec tunnel. > > I solved this temporarily by using pipsecd - now I can > trust that packets coming from interface tun0 have > gone through IPsec checks. However, I would like > to use the functionality available in kernel. I've tackled that problem as well, and came up with two possible solutions. 1) KAME sets a bitflag in the memory buffer of the packet. If IPFW had the ability to branch on that flag, then you could tell if the packet had gone through KAME or not. Having the ability to set that flag as well could allow IPSEC/natd on the same box, even to the same target. This could be done by changing only ipfw and its kernel module. 2) change the way KAME works, so that there's an ipfw rule that states "apply KAME now" and then continues with the next rule, rather than having KAME reinject the packet as if it had just come in. I like this idea better on a theoretical level, but the problem is that it would be a major divergence from KAME, so we would probably loose any future KAME improvements. In fact, I wrote a user-land IPSECd that used ipfw and divert sockets, but it had too many other problems. It did solve the IPSEC/ipfw problem quite nicely, however. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message