Hans Werner Strube wrote: > Since there has been no reply to my four mails from August 16-19, here > a summary again. > I always liked IPF because of its well-functioning FTP proxy and had > 3.4.x (finally, 3.4.35) running for years on a Solaris 7_x86 PC with > two interfaces (routing). This was replaced by a Solaris 9 SunFire V210 > (64 bit only), with IPF 3.4.35 compiled on it and the same configuration > as on the PC. Then with FTP proxy rules in ipnat.conf, IPF did not pass any > FTP-related packets (not even those of the control connection) to the other > interface, as verified by snoop. But they were not logged as blocked by > any rule, and ipnat -l shows correct mapping. This happens only for > connections *through* the firewall, whereas the FTP proxy works for > connections from the firewall machine itself to the outer net. Also, > no-proxy NAT works correctly through the firewall. > For more details, see my former mails. > Any ideas? Experimenting is difficult for me, since this is a busy > firewall of an institute.
NEWS: I tried the same with the rcmd and raudio proxies - same behaviour: With proxy NAT rule, not even the control connection was visible on the outer interface for connections _through_ the firewall, but it was visible for connections _from_ the firewall itself. Thus, this bug is not FTP specific but seems to concern all builtin proxies! (Version 3.4.35; 4.1.x not tested.) In the failing case, ipnat -lv shows "drop 0/N", N nonzero. Seems to indicate that appr_check in ip_proxy.c (called from ip_natout in ip_nat.c) fails?
