[ Charset ISO-8859-15 unsupported, converting... ]
> Hello, I am resending my hard problems cause I was asked not to send
> html emails.
>
> I stumbled upon two strange problems with IPFilter 4.1.9 on Solaris 10
> (any platform).
> It is a self-built ipfilter with gcc, substituting the original Sun's
> version.
>
> 1. when I do "svcadm disable ipfilter", the filter is not actually
> disabled. Nats still run, blocked ports are still blocked. Changing the
> rule file and doing "svcadm disable ipfilter -> svcadm enable ipfilter"
> reloads the changes.
Yes, this is a problem with the file /lib/svc/method/ipfilter(?) that
only kills the ipmon process and does not unload the ipf module. It
is missing this line after "stop)":
[ -n "$ipfid" ] && modunload -i $ipfid
I haven't gone looking to see if there is a bug open about this.
> 2. I have a configuration file that opens just few ports on the public
> machine (itself). Port 80 is one of them.
> All seems to run fine. Then I found 2 customers that cannot reach ONLY
> PORT 80 on any of these public machines running this build of ipfilter.
> These 2 customers remotely use the same Internet connection method: a
> pcmcia UMTS connect card.
> I tried to move apache to port 82 and open up port 82 on ipfilter (the
> same way it was open on port 80): it magically works fine.
> I moved again apache back to port 80 and asked the UMTS/connect-card
> user to do a "telnet www.mymachine.com 80" and try a "GET / HTTP/1.0".
> Once the user types the "G" the connection is broken.
> This does not happen on any other port, and this does not happen at all
> on any other user connection through other methods (works fine on UMTS
> through a nokia-phone used as an usb modem).
> And this did not happen with Sun's version.
Can you use tcpdump/snoop on the network interface in use here and
look at what's happening at the network level ? My bet is that the
webserver is closing the connection...
Darren
