DNAT problems using a single interface

[Stephen Satchell <list@satchell.net>]

I have a knotty problem.  I have 31 servers running older versions of 
QMail.  There is proprietary software on those 31 servers that prevents 
me from updating to the latest QMail patches, and even if I could the 
spam control in qmail is, um, sucky.  So I have built a gateway mail 
server, using PostFix, that will "front-end" the 31 QMail servers. 
(There is also a colostomy bag, also running Postfix, to catch and 
retain spam spewing from the servers from things like raped PHP/Perl 
scripts, but that's beside the point.)

The "right" way to do this is to change all the DNS zone files (some 
6,000) of them to point MX records properly, and convince over 100,000 
people to update their mail program configurations...assuming they 
aren't running something like Eudora 5.2, which doesn't allow split 
servers with different authentication.

IPTABLES TO THE RESCUE!  In each of the 31 servers, put a set of 
firewall rules to DNAT up to 200 IP addresses to the gateway server, let 
the TCP communications on port 25 (and other well-known mail ports) 
happen, and put a back-channel using another port for mail that needs to 
go to that server for storage, future pick-up, forwarding, list 
explosion, and autoresponder processing.

I can't get it to work.

-------------Netfilter rules-----------------
# forward mail requests to x; use absolute IP address.
mx11=10.1.2.99
SERVER_IPS="10.1.1.11 10.1.1.12 10.1.1.13 10.1.1.14 10.1.1.15"

for p  in 25:26 465 587; do
  for ip in $SERVER_IPS ; do
   /sbin/iptables -t nat -A PREROUTING -i eth0 -d $ip  \
    -p tcp --dport $p -j DNAT --to-destination $mx11
   done
  done

/sbin/iptables -t filter -A FORWARD -i eth0 -o eth0   \
   -p tcp -d $mx11 --dport $p                           \
   -m state --state NEW -j ACCEPT

/sbin/iptables -t filter -A FORWARD -i eth0 -o eth0   \
   -p tcp -d $mx11 --dport $p                           \
   -m state --state ESTABLISHED,RELATED -j ACCEPT
 


/sbin/iptables -t filter -A FORWARD -i eth0 -o eth0   \
   -p tcp -s $mx11 --sport $p                           \
   -m state --state ESTABLISHED,RELATED -j ACCEPT
 

echo 1 >/proc/sys/net/ipv4/ip_forward
-------------End rules--------------------

Tracing through three sets of TCPDUMP outputs, here is what I saw:

Client send TCP packets SRC=192.168.2.10 (eth0) DST=10.1.1.11 (eth0)
QMbox sends TCP packets SRC=192.168.2.10 (eth0) DST=10.1.2.99 (eth0)
Gateway receives packet
Gateway replies SRC=10.1.2.99 (eth0) DST=192.168.2.10 (eth0) !!!

Client, totally confused by the whole thing, discards the packet it 
doesn't know, because the source address isn't in the conntrack table 
and that's that -- TCP is broken.

The "Host Forwarding" described in [Ziegler, p 277-8] implies that DNAT 
would mangle the source address so that replies would come back to the 
same server, instead of the circle I saw.  This is astonishing based on 
the netfilter documentation I found; I would expect the stuff that works 
with two or more interfaces to work with one interface.  Or is that a 
stretch?

What am I missing here?

More importantly, how can I get the functionality I need without using 
the link capability of xinetd (the QMail management software screws up 
the control files on a distressingly regular basis) and without writing 
a custom link program?

For grins and giggles, I tried to include SNAT, but because there are so 
many input addresses I failed to come up with a suitable set of rules.

I know that I really should just throw out the proprietary product that 
uses QMail, but to solve my mail problems within 15 days I don't think 
that's an option.  I need a suitable bandaid now, that doesn't call for 
a huge hardware investment and that will be proof against proprietary 
software defeating.

Open source.  It works when you have it...

Stephen Satchell
Pattern-bald from tearing hair out.