Connection tracking via RPC transaction ID

Connection tracking via RPC transaction ID

[Stephen P. Schaefer]

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

Re: Connection tracking via RPC transaction ID

[Jason Opperisano]

On Wed, Apr 20, 2005 at 02:42:13PM -0400, Stephen P. Schaefer wrote:
> 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?

there's an RPC conntrack module in PoM:

  http://svn.netfilter.org/netfilter/trunk/patch-o-matic-ng/rpc/

it's 2.4-only, and i have no clue if it helps with this specific
situation.

-j

--
"Quagmire: Tuesdays in the '80s I was always in bed by 8... and home
 by 11."
        --Family Guy