From owner-freebsd-ipfw Sun Jul 30 22: 0:58 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 5F74A37B6CC for ; Sun, 30 Jul 2000 22:00:16 -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 IAA09826; Mon, 31 Jul 2000 08:00:09 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <003f01bffaac$5cfd3440$0e05a8c0@intranet.syncrontech.com> From: "Ari Suutari" To: "Eric J. Schwertfeger" Cc: References: Subject: Re: IPSEC tunnel mode & ipfw Date: Mon, 31 Jul 2000 08:01:17 +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, > 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. Yes, I think this would be nice. However, when having multiple IPsec tunnels, one might also be interested in from which tunnel the packet originated. This would require some changes in KAME also. > > 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. I think I would prefer the first approach provided that there would be some kind of 'tunnel-id'... > 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. I wonder how many different IPsec implementations there have been. I had also my own (which ran very well for many years, but I lost source code for it!). Well, luckily the pipsecd is now around so I can use it for the time being. Ari S. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Aug 2 14:35:18 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from kira.epconline.net (kira.epconline.net [209.83.132.2]) by hub.freebsd.org (Postfix) with ESMTP id 65C0137BA44 for ; Wed, 2 Aug 2000 14:35:08 -0700 (PDT) (envelope-from carock@epctech.com) Received: from therock (guardian.epconline.net [216.178.14.38]) by kira.epconline.net (8.9.3/8.9.3) with SMTP id QAA73725 for ; Wed, 2 Aug 2000 16:35:01 -0500 (CDT) Reply-To: From: "Chuck Rock" To: "'Freebsd-Ipfw" Subject: divert connection logging?? Date: Wed, 2 Aug 2000 16:37:42 -0500 Message-ID: <003801bffcc9$e3803700$1805010a@epconline.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I have a FreeBSD 4.0 box running ipfw and ipdivert. We are diverting telnet from this box to another box on the other network card. This is working fine, but we also do extensive logging on this machine, and we would like to "see" the connections to the divert port. netstat is not showing the telnet sessions, but iplog will, so the information is there somewhere, but we are looking for a better solution. Is there a way to see the connections to the divert port? Thanks, Chuck Rock EPC To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Aug 2 16:45:55 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from mta01.chello.no (mta01.chello.no [212.186.255.12]) by hub.freebsd.org (Postfix) with ESMTP id A81C637B635 for ; Wed, 2 Aug 2000 16:45:48 -0700 (PDT) (envelope-from shaun@shamz.net) Received: from johnny.priv.shamz.net ([213.46.212.80]) by mta01.chello.no (InterMail vK.4.02.00.00 201-232-116 license 77df2db80a2bdce4d335ff4839618d42) with ESMTP id <20000802234615.HJVR27441.mta01@johnny.priv.shamz.net> for ; Thu, 3 Aug 2000 01:46:15 +0200 Received: from dakota.priv.shamz.net (dakota.priv.shamz.net [192.168.0.24]) by johnny.priv.shamz.net (8.9.3/8.9.3) with ESMTP id BAA24002 for ; Thu, 3 Aug 2000 01:45:44 +0200 (CEST) (envelope-from shaun@dakota.priv.shamz.net) Received: (from shaun@localhost) by dakota.priv.shamz.net (8.9.3/8.9.3) id BAA03653 for freebsd-ipfw@FreeBSD.ORG; Thu, 3 Aug 2000 01:45:44 +0200 (CEST) (envelope-from shaun) Date: Tue, 1 Aug 2000 01:17:09 +0200 From: Shaun Jurrens To: freebsd-ipfw@FreeBSD.ORG Subject: connections via natd dying in natd Message-ID: <20000801011709.B4159@dakota.priv.shamz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Mailer: Mutt 1.0.1i Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi all, I have been struggling with this problem for a number of months, actually. I had it using 3-STABLE boxes and now with one 4-STABLE through the 3(.5)-STABLE natd gateway, the same problem occurs. The problem: connections via natd suddenly drop and similtaneously, I get errors on the console for the gateway box that natd has "failed to write the packet back (Permission denied)". This is almost exclusively with ssh connections (mostly because they are the most constant long time connections I have to notice this behavior) I have searched the lists and done the arp -s to set a permanent arp setting on all interfaces. I am also on a cable modem (chello). Even stranger, if I don't wait for the session to time out and kill the xterm, the connection stays up on the foreign host for _days_ (there are currently zombie sessions alive that are more than a week old). I do _not_ have the same behavior if I log to/from the gateway box to/from a foreign host. I find this more than a little disturbing. Well, down to the OS specifics: FreeBSD johnny 3.5-STABLE FreeBSD 3.5-STABLE #0: Sat Jun 24 23:35:28 CEST 2000 natd_flags="-f /etc/natd.conf" /etc/natd.conf log yes unregistered_only yes use_sockets yes dynamic yes interface xl0 some relevant sysctl's: net.inet.ip.fw.enable: 1 net.inet.ip.fw.one_pass: 1 net.inet.ip.fw.debug: 1 net.inet.ip.fw.verbose: 1 net.inet.ip.fw.verbose_limit: 100 net.inet.ip.fw.dyn_buckets: 256 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_count: 230 net.inet.ip.fw.dyn_max: 1000 net.inet.ip.fw.dyn_ack_lifetime: 1320 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_fin_lifetime: 20 net.inet.ip.fw.dyn_rst_lifetime: 5 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.tcp.rfc1323: 1 net.inet.tcp.rfc1644: 0 net.inet.tcp.mssdflt: 512 net.inet.tcp.rttdflt: 3 net.inet.tcp.keepidle: 1200 net.inet.tcp.keepintvl: 150 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.tcp.keepinit: 150 net.inet.tcp.log_in_vain: 1 net.inet.tcp.delayed_ack: 1 net.inet.tcp.restrict_rst: 1 net.inet.tcp.pcbcount: 23 net.inet.tcp.always_keepalive: 1 An additional and perhaps related problem is one with passive ftp. I should probably take an entire mail for it alone, but suffice it to say, active ftp works if I open the ports, but passive ftp causes the same failed packet errors. I know how passive ftp works and if I open ports from > 1024 to those (at least for fbsd ftpd's) on the server 49152-65535, I should be able to initiate a data channel. Well, I have had no success. The rule that I propose should work, looks like this: $fwcmd add 10202 allow tcp from ${intnet}:${intmask} 1025-65535 to any 49152-65535 setup keep-state (wrapped here with ) I've tried to tcpdump the connections, but it's a little difficult to watch so many things at the same time: natd aliases, two tcpdumps, and fw rules. I don't see anything hitting a rule either. The first problem is more aggrevating. The second one I have a awkward hack for. Guess I could use some suggestions from people more knowledgeable than I.... A final plea as long as I'm begging anyway: Could someone fix the mailing list search engine? If I can help with it let me know. I use it often, and it is a constant source of frustration, because it is so broken. I'd appreciate a CC as well, because I prefer to track the lists via web. Thanks in advance for any assistance. -- Yours truly, Shaun D. Jurrens shaun@shamz.net shamz@freenix.no IRCNET nick: shamz #chillout #unix #FreeBSD To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Wed Aug 2 16:50:44 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 37C4137B75F for ; Wed, 2 Aug 2000 16:50:42 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id QAA28133; Wed, 2 Aug 2000 16:50:06 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008022350.QAA28133@bubba.whistle.com> Subject: Re: divert connection logging?? In-Reply-To: <003801bffcc9$e3803700$1805010a@epconline.net> from Chuck Rock at "Aug 2, 2000 04:37:42 pm" To: carock@epctech.com Date: Wed, 2 Aug 2000 16:50:06 -0700 (PDT) Cc: "'Freebsd-Ipfw" X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Chuck Rock writes: > I have a FreeBSD 4.0 box running ipfw and ipdivert. We are diverting telnet > from this box to another box on the other network card. This is working > fine, but we also do extensive logging on this machine, and we would like to > "see" the connections to the divert port. > > netstat is not showing the telnet sessions, but iplog will, so the > information is there somewhere, but we are looking for a better solution. > > Is there a way to see the connections to the divert port? sockstat(1) should show the connected divert sockets... it needs to be updated to show the ports though. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 3 11:57:39 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 3022837B528 for ; Thu, 3 Aug 2000 11:57:36 -0700 (PDT) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.3/8.9.3) id LAA42218; Thu, 3 Aug 2000 11:56:57 -0700 (PDT) (envelope-from archie) From: Archie Cobbs Message-Id: <200008031856.LAA42218@bubba.whistle.com> Subject: Re: connections via natd dying in natd In-Reply-To: <20000801011709.B4159@dakota.priv.shamz.net> from Shaun Jurrens at "Aug 1, 2000 01:17:09 am" To: Shaun Jurrens Date: Thu, 3 Aug 2000 11:56:57 -0700 (PDT) Cc: freebsd-ipfw@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL68 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Shaun Jurrens writes: > I have been struggling with this problem for a number of months, actually. I > had it using 3-STABLE boxes and now with one 4-STABLE through the 3(.5)-STABLE > natd gateway, the same problem occurs. The problem: connections via natd > suddenly drop and similtaneously, I get errors on the console for the gateway > box that natd has "failed to write the packet back (Permission denied)". This > is almost exclusively with ssh connections (mostly because they are the most > constant long time connections I have to notice this behavior) Don't know if this is much help, but.. "failed to write the packet back (Permission denied)" almost definitely indicates that the packet being written back hit an 'ipfw deny' packet filtering rule. This is the only way that a write to a socket can generate an EPERM error. So I'd start by turining on ipfw logging for all deny rules to see which one is being triggered. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Thu Aug 3 13:26:48 2000 Delivered-To: freebsd-ipfw@freebsd.org Received: from pinochet.cityline.ru (pinochet.cityline.ru [195.46.160.34]) by hub.freebsd.org (Postfix) with ESMTP id 41D3037B789 for ; Thu, 3 Aug 2000 13:26:39 -0700 (PDT) (envelope-from oleg_y_ivanov@mailru.com) Received: from admin (140.166.fx.dialup.cityline.ru [195.46.166.140]) by pinochet.cityline.ru (8.10.2/t/08-Oct-1998) with SMTP id e73KLug22196; Fri, 4 Aug 2000 00:21:56 +0400 (MSD) Message-ID: <003c01bffd88$a2df8380$0801a8c0@admin.uzdw-centre.ru> From: "Oleg Y. Ivanov" To: "Shaun Jurrens" Cc: Subject: Re: connections via natd dying in natd Date: Fri, 4 Aug 2000 00:22:53 +0400 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 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hey , I also have this problem =8-((( In my case this message usually appears when ipfw is used in stateful mode & rule with "keep-state" addendum expires.Packet written by natd hits default (or any other ;) "deny" rule. Is this scenario enough realistic ? >>Shaun Jurrens writes: >> I have been struggling with this problem for a number of months, actually. I >> had it using 3-STABLE boxes and now with one 4-STABLE through the 3(.5)-STABLE >> natd gateway, the same problem occurs. The problem: connections via natd >> suddenly drop and similtaneously, I get errors on the console for the gateway >> box that natd has "failed to write the packet back (Permission denied)". This >> is almost exclusively with ssh connections (mostly because they are the most >> constant long time connections I have to notice this behavior) > >Don't know if this is much help, but.. > >"failed to write the packet back (Permission denied)" almost definitely >indicates that the packet being written back hit an 'ipfw deny' packet >filtering rule. This is the only way that a write to a socket can >generate an EPERM error. > >So I'd start by turining on ipfw logging for all deny rules to see >which one is being triggered. > --------------------------------- Sincerely Yours , Oleg Y. Ivanov : sysadmin & DBA of UzDaewoo Centre , Moscow To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message