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 <freebsd-ipfw@FreeBSD.ORG>; 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" <ari@suutari.iki.fi>
To: "Eric J. Schwertfeger" <ejs@bfd.com>
Cc: <freebsd-ipfw@FreeBSD.ORG>
References: <Pine.BSF.4.21.0007280739190.2119-100000@harlie.bfd.com>
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 <freebsd-ipfw@FreeBSD.ORG>; 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 <freebsd-ipfw@FreeBSD.ORG>; Wed, 2 Aug 2000 16:35:01 -0500 (CDT)
Reply-To: <carock@epctech.com>
From: "Chuck Rock" <carock@epctech.com>
To: "'Freebsd-Ipfw" <freebsd-ipfw@FreeBSD.ORG>
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 <freebsd-ipfw@FreeBSD.ORG>; 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 <freebsd-ipfw@FreeBSD.ORG>; 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 <freebsd-ipfw@FreeBSD.ORG>; 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 <shaun@shamz.net>
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 <CR>)
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 <freebsd-ipfw@FreeBSD.ORG>; 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 <archie@whistle.com>
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" <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
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 <freebsd-ipfw@FreeBSD.ORG>; 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 <archie@whistle.com>
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 <shaun@shamz.net>
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 <freebsd-ipfw@FreeBSD.ORG>; 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" <oleg_y_ivanov@mailru.com>
To: "Shaun Jurrens" <shaun@shamz.net>
Cc: <freebsd-ipfw@FreeBSD.ORG>
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