We've been using IP Filter V3.4.31 on Solaris 9 (SPARC, 64-bit; compiled
with Sun's C compiler) for a year or two on some of our servers, and it was
working fine except for an obscure problem [1] that came to light fairly
recently, which prompted me to try a current version to see if that would
cure the problem.
I found that V4.1.13 cured *that* problem but introduced a new one (with
absolutely no changes to the ipf configuration or anything else relevant,
other than ipf itself). I've done some investigation (details below), but
it's left me mystified - so any suggestions or solutions would be welcome.
FTP mirroring (using the mirror script from
http://sunsite.org.uk/packages/mirror/ + some local fixes, e.g. Y2K
issues) between the Sun as client and a Macintosh system using the
NetPresenz FTP server had been working fine with the old ipf version, but
the upgrade broke it (reproduceably).
This is with ipf used simply to protect the Sun system itself, the
system's not acting as a firewall/router.
While mirror is looking around (changing directory and collecting
directory listings; the FTP server doesn't support doing recursive
listings), before trying to retrieve any new/updated files, it's
successful for the first few tens of directories but then hangs for
several minutes and eventually times out (with nothing logged by ipf, and
nothing meaningful logged on the Mac, just "connection aborted" or
similar). I've checked that the mirroring still "just works" on another
system that's still using the older ipf version, so it looks like the ipf
upgrade is the critical factor, not something external.
That was using passive FTP, which had always "just worked" with the older
ipf version, and it consistently hung while scanning a particular
directory. Running FTP manually, in passive mode had no problem accessing
that directory.
The failure is for approx the 32nd (or 33rd) directory listing that the
mirror script would have tried to collect, which may be significant. That
makes me wonder if one end or the other has a limit of 32-ish connections
(power of 2...) that can be set up in quick succession, with the earlier
(completed) connections stuck in the mandatory wait states before they can
be reused. However, with no change to the FTP server I cannot see how there
could be such a limit without it being a problem previously, and ipf itself
isn't acting as a connection end-point ("merely" filtering connections set
up by other software).
Changing to using active-mode client FTP (as the ipf ftp proxy was already
set up so that could work) it "just worked". Passive-mode FTP mirroring
still works just fine with a different server (locally written, running on
a Netware server, so it's not a general passive FTP issue. However, the
Netware server has more Unix-like directory listing facilities, which can
do a single, recursive directory listing rather than needing to get a
separate listing for each directory (of which there are several hundred in
the Mac scenario - though not a problem until the ipf upgrade).
The tail end of a failing mirror run shows a successful directory listing
followed by multiple "150 ASCII transfer started" response packets from the
Mac on the control channel (no ACK received?) then a long (several
minutes) timeout followed by a "TYPE I" command from the Sun and an
immediate (and broken, no response code prefix) "No TCP" response from the
Mac. That doesn't make much sense, and suggests that both systems were
waiting for the other to do something.
Does this sound like a known ipf problem, or a scenario that's likely to
cause problems for ipf? Does hanging after around 32 connections in quick
succession fit with anything in ipf's inner workings, or is it
(as I suspect), more likely a bug or "feature" in the Mac FTP server - wouldn't
be the first? Any ideas about why the problem should show up only after the
ipf upgrade, even if it's a problem with the FTP server, would also be of
interest.
It's difficult to investigate (no meaningful logging on the Mac and the
Sun systems are servers in 24x7 production use), and the FTP mirroring is
a means to an end rather than something that is important in itself, so I
can't justify spending much time making passive mode work again - but it
seemed worth asking in case it was a known/fixable problem or hinted at
more serious ipf isses. The specific (FTP mirroring) problem is ignorable
since we have a workaround; the question is whether there's an underlying
problem that may bite later, without a viable workaround.
The ipf.conf (edited to omit the rules relating to new inbound connections;
none relate to FTP) and ipfnat.conf are:
===== (trimmed) ipf.conf
pass out quick proto tcp all flags S keep state keep frags
pass out quick proto udp all keep state
pass out quick proto icmp all keep state
pass out quick all
pass in quick on bge0 proto icmp from any to 131.111.8.0/24 icmp-type echo
keep state
pass in quick on bge0 proto icmp from any to 131.111.8.0/24 icmp-type squench
keep state
pass in quick on bge0 proto icmp from any to 131.111.8.0/24 icmp-type redir
keep state
pass in quick on bge0 proto icmp from any to 131.111.8.0/24 icmp-type unreach
keep state
pass in quick on bge0 proto icmp from any to 131.111.8.0/24 icmp-type timex
keep state
block in quick on bge0 from any to 131.111.8.255/32
block in quick on bge0 from any to 131.111.255.255/32
block in quick on bge0 from any to 0.0.0.0/32
block in quick on bge0 from any to 255.255.255.255/32
block in quick on bge0 from any to 224.0.0.0/4
block in quick on bge3 from any to 10.111.222.255/32
block in quick on bge3 from any to 0.0.0.0/32
block in quick on bge3 from any to 255.255.255.255/32
block in quick on bge3 from any to 224.0.0.0/4
block return-rst in log quick proto tcp all flags S
block in log quick proto tcp all
block return-icmp(port-unr) in log quick proto udp all
block in log quick all
=====
===== ipnat.conf (to allow active-mode client FTP, no actual NATing)
map bge0 0/0 -> 0/32 proxy port 21 ftp/tcp
map bge3 0/0 -> 0/32 proxy port 21 ftp/tcp
=====
Any ideas would be welcome.
John Line
[1] The problem which prompted me to upgrade ipf was something that I saw
when connecting to the system from home, after upgrading from dialup to
broadband, with a VPDN tunnel to the network containing the Sun system.
Downloads from any of several Sun systems (all Solaris 9, with the same old
ipf version) would hang "forever" after around 120-150KB had been fetched.
That happened for both scp and http downloads, but not for uploads, and
downloads to other client systems appeared to be fine. Packet traces
suggested that it got stuck after a trivial issue such as a lost or out of
sequence packet (apparently arising consistently at about the same point in
transfers - VPDN "feature"?), at which point ipf reported it was blocking
the connection,
I couldn't see any specific relevant-sounding issues mentioned anywhere
(on the web or the mailing list) of such a problem, and the ipf version
was old enough that it seemed best to try upgrading before querying it if
the upgrade didn't fix it. It fixed that - but broke passive-mode FTP
mirroring. :-(
--
John Line - web & news development, University of Cambridge Computing Service
