Re: ipfw: fetch doesn't reach ftp://fttp.sites.foo

From: O. Hartmann <ohartman_at_zedat.fu-berlin.de>
Date: Mon, 10 Mar 2014 15:48:08 +0100
On Fri, 07 Mar 2014 17:51:11 -0500
Allan Jude <freebsd_at_allanjude.com> wrote:

> On 2014-03-07 16:55, O. Hartmann wrote:
> > On Fri, 07 Mar 2014 15:33:39 -0500
> > Allan Jude <freebsd_at_allanjude.com> wrote:
> > 
> >> On 2014-03-07 13:57, O. Hartmann wrote:
> >>>
> >>> Recently I swaitched from pf to ipfw on some CURRENT boxes and for convenience 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 through 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 filter, 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 kind.
> >>>
> >>>
> >>> Thanks in adavance,
> >>>
> >>> Oliver 
> >>>
> >>
> >> 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.
> > 
> > Fetch gives the shown "errors" or simple timeouts.  Either manually or via portmaster
> > to update ports like the one shown below.
> > 
> > The very same port has no problems on the system having pf instead of ipfw.
> > 
> > I will switch back to pf on the box in question to check whether the choice of
> > firewall really makes the difference.
> > 
> > This is what I get when seeting passive mode (it doesn't change anything from "active"
> > mode):
> > 
> > root_at_thor: [pciids] setenv FTP_PASSIVE_MODE YES
> > 
> > root_at_thor: [pciids] make fetch
> > ===>  License BSD3CLAUSE GPLv2 GPLv3 accepted by the user
> > ===>   pciids-20140301 depends on file: /usr/local/sbin/pkg - found
> > => pciids-20140301.tar.xz doesn't seem to exist in /usr/ports/distfiles/.
> > => 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 => 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 => Attempting to fetch
> > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz
> > fetch:
> > ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz:
> > No route to host => Attempting to fetch
> > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz
> > fetch:
> > ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz:
> > No route to host => Attempting to fetch
> > ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/sunpoet/pciids-20140301.tar.xz
> > fetch: transfer timed out
> > 
> 
> 'no route to host' suggests it might be trying to do ipv6
> 

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.harvard.edu which I
contact freuently for literature search. Even this specific site can't be reached 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 config revealed)
can.

Received on Mon Mar 10 2014 - 13:48:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:47 UTC