From owner-freebsd-current@FreeBSD.ORG Mon Mar 10 14:48:22 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39C2E50A for ; Mon, 10 Mar 2014 14:48:22 +0000 (UTC) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E8B321AA for ; Mon, 10 Mar 2014 14:48:21 +0000 (UTC) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.82) with esmtp (envelope-from ) id <1WN1Uy-002Rds-Vx>; Mon, 10 Mar 2014 15:48:13 +0100 Received: from f052070002.adsl.alicedsl.de ([78.52.70.2] helo=thor.walstatt.dyndns.org) by inpost2.zedat.fu-berlin.de (Exim 4.82) with esmtpsa (envelope-from ) id <1WN1Uy-003wUw-Rf>; Mon, 10 Mar 2014 15:48:12 +0100 Date: Mon, 10 Mar 2014 15:48:08 +0100 From: "O. Hartmann" To: Allan Jude Subject: Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo Message-ID: <20140310154808.3c778b85.ohartman@zedat.fu-berlin.de> In-Reply-To: <531A4D5F.9080401@allanjude.com> References: <20140307195719.654653c9.ohartman@zedat.fu-berlin.de> <531A2D23.30907@allanjude.com> <20140307225537.3c672d34.ohartman@zedat.fu-berlin.de> <531A4D5F.9080401@allanjude.com> Organization: FU Berlin X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/pKPYJJIT5w7lfo76ErFdKjq"; protocol="application/pgp-signature" X-Originating-IP: 78.52.70.2 X-ZEDAT-Hint: A Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:48:22 -0000 --Sig_/pKPYJJIT5w7lfo76ErFdKjq Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 07 Mar 2014 17:51:11 -0500 Allan Jude wrote: > On 2014-03-07 16:55, O. Hartmann wrote: > > On Fri, 07 Mar 2014 15:33:39 -0500 > > Allan Jude wrote: > >=20 > >> On 2014-03-07 13:57, O. Hartmann wrote: > >>> > >>> Recently I swaitched from pf to ipfw on some CURRENT boxes and for co= nvenience I > >>> used the "workstation" predefinition of FreeBSD. But with that change= , all access > >>> of ports via fetch located at ftp-sites stopped passing the filter. > >>> > >>> Even switching to "open" doesn't help and this is confusing me. > >>> > >>> The CURRENT box in question is passing its traffic within a LAN throu= gh a gateway > >>> running also FreeBSD CURRENT, but with pf. The gateway is performing = NAT. As long as > >>> the failing client behind the gateway system is using pf as the filte= r, the traffic > >>> for ftp seems to pass through. On the gateway with pf as the default = filter, the > >>> ports fetching via ftp-site their sources perform without problems. > >>> > >>> What is up with IPFW? > >>> > >>> Is their a solution? I tried to search google for "freebsd ipfw ftp" = but I didn't > >>> find anything suitable targeting my problem or any problem of that ki= nd. > >>> > >>> > >>> Thanks in adavance, > >>> > >>> Oliver=20 > >>> > >> > >> What error does fetch give? Is it having problems with DNS, connection > >> to the FTP site, or just making the FTP DATA connection? Have you tried > >> with 'passive' mode on/off? > >> > > The box doesn't have problems contacting any DNS. > >=20 > > Fetch gives the shown "errors" or simple timeouts. Either manually or = via portmaster > > to update ports like the one shown below. > >=20 > > The very same port has no problems on the system having pf instead of i= pfw. > >=20 > > I will switch back to pf on the box in question to check whether the ch= oice of > > firewall really makes the difference. > >=20 > > This is what I get when seeting passive mode (it doesn't change anythin= g from "active" > > mode): > >=20 > > root@thor: [pciids] setenv FTP_PASSIVE_MODE YES > >=20 > > root@thor: [pciids] make fetch > > =3D=3D=3D> License BSD3CLAUSE GPLv2 GPLv3 accepted by the user > > =3D=3D=3D> pciids-20140301 depends on file: /usr/local/sbin/pkg - fou= nd > > =3D> pciids-20140301.tar.xz doesn't seem to exist in /usr/ports/distfil= es/. > > =3D> Attempting to fetch > > http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids= -20140301.tar.xz > > fetch: > > http://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids= -20140301.tar.xz: > > Not Found =3D> Attempting to fetch > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-= 20140301.tar.xz > > fetch: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-= 20140301.tar.xz: > > No route to host =3D> Attempting to fetch > > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pcii= ds-20140301.tar.xz > > fetch: > > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pcii= ds-20140301.tar.xz: > > No route to host =3D> Attempting to fetch > > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pcii= ds-20140301.tar.xz > > fetch: > > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pcii= ds-20140301.tar.xz: > > No route to host =3D> Attempting to fetch > > ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pcii= ds-20140301.tar.xz > > fetch: transfer timed out > >=20 >=20 > 'no route to host' suggests it might be trying to do ipv6 >=20 This phenomenon is "funny". Days ago, that was around this net/route.c (-r262780) issue reported here, = I could reach from the specific box in question FTP sites as well as http://adswww.harvar= d.edu which I contact freuently for literature search. Even this specific site can't be r= eached via browser, nor traceroute, nor ping. The gateway (also FreeBSD, same CURRENT,= but with "pf" instead "ipfw", but that doesn't matter as a change to the once-working con= fig revealed) can. --Sig_/pKPYJJIT5w7lfo76ErFdKjq Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTHdCsAAoJEOgBcD7A/5N8T7UH/02+YuhoMMy+yQdVtGcOoQzv hhajDfHHTc5vby6r6WDXoG0EvYVIoPLX0gFBPLAAKDPT0VSxnE9W10NVDN2WpOqa Fb6xPlYpripj7SOVEJDgB4iq6TfQQ0Pg07hSqqWwkYiJqD3jmOaHLsj99a0EVbBY pLFhpFkHid5O7G3fuMCLNrEqaa1s9ADU6rryoUKheXCBbjTebT1IgZFdrnmefqhQ Kkj5Jt9wHcJwQ0VWdXC153Q60R4XsZS7pUdLQjcGXurJbk5DQ+n+8BCQngQvWsTa h2+wyW0H/I0Vmni7sgnQBZMSqlkOiiEBeBe9D+9EMb8/twGlD8JFTWg9fMfe2+A= =/4SB -----END PGP SIGNATURE----- --Sig_/pKPYJJIT5w7lfo76ErFdKjq--