On Fri, 07 Mar 2014 17:51:11 -0500 Allan Jude <free...@allanjude.com> wrote:
> On 2014-03-07 16:55, O. Hartmann wrote: > > On Fri, 07 Mar 2014 15:33:39 -0500 > > Allan Jude <free...@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@thor: [pciids] setenv FTP_PASSIVE_MODE YES > > > > root@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.
Description: PGP signature