Hello all!
I have an interestingly unique problem that may take a brainiac to help me figgure out:
I have a MaxExchange 7 server that is sitting behind an older Linux Firewall/Router/Email server (500mhz, Slackware 7, Kernel 2.2.16) that we built back in 2002.
We have been able to successfully been able to do MaxExchanges through the IPFWADM/RINETD port forwarding setup we implemented with no problem for all these years: we used ipfwadm to give the server complete outbound access to the outside world (ipfwadm -F -a -m -S [maxexchange-server-ip] -D 0.0.0.0/0), and use rinetd to forward all the required maxexchange ports inwards to the maxexchange server.
We have recently built a replacement server that is much more capable of handling the load of Email that has appeared since 2002 (2ghz, Ubuntu 6.06 server, Kernel 2.6.15).
With this new server, we are now using IPTABLES instead of IPFWADM. RINETD still works the same way, but theres something odd about IPTABLES that does not seem to jive well with MaxExchange:
With the old server, when the FTP test was done, it would successfully connect via Active FTP sessions no problem.
With this New server, however, when the FTP test is done, it gives me an ADDRESS BOOK ID ERROR on the active FTP session, despite the fact that all the forwarding/masquerading is set up essentially the same way: the MaxExchange server has the new server set as its gateway, the Maxexchange server is given complete outbound access to the net via IPTABLES, and RINETD is used to direct all the appropriate maxexchange ports inward to the MaxExchange server.
I've been able to manually check the connectivity of the ports as forwarded by rinetd: My suspicion is that IPTABLES is somehow mangling the outbound packets that are being returned to the client.
Has anyone else ever run into such a dillemma?
Thanks in advance,
Ray Collazo
Systems Admin
Loran Inc.
Original Post