Connection tracking via RPC transaction ID

["Stephen P. Schaefer" <sschaefer@rfmd.com>]

I'm trying to SNAT an NFS client, but the NFS server (a NetApp) has
two IP addresses, and though DNS advertises it at the first address,
e.g. 192.168.200.10, its answers come back from the other address,
e.g., 192.168.2.150. If I'm not behind the SNAT, there's no problem
because the client kernel ignores the source IP address and just looks
at the RPC transaction ID, but behind the SNAT, the fact that the
answer comes back from a different address than that to which the
request went breaks connection tracking.  I've currently worked around
the problem with a DNAT rule:

iptables -t nat -A PREROUTING -d 192.168.200.10 -i eth1 -j DNAT --to-destination 192.168.2.150

...but I'm woried that this is less than robust.  In particular, I
don't understad why the NetApp uses one address or the other to reply,
and what will keep it from behaving differently tomorrow.  Is there a
connection tracking module that works on RPC transaction ID and can
ignore the source address?  Would it be difficult to write?  Is there
code that does something similar that I should study?

For reference, the rest of the relevant setup is like this:

On the netfiltering box:

eth0: 192.168.111.252/24
eth1: 192.168.111.249/30

SNAT:

iptables -t nat -A POSTROUTING -s 192.168.111.250 -d ! 192.168.111.248/30 -o eth0 -j SNAT --to-source 192.168.111.252