conntrack-tools rpc helper

[Richard A Nelson]

I'm having a heck of a time getting this all going ;)

Debian Sid/Experimental
Linux 3.7.1
conntrack toolchain downloded yesterday (stable, not git)

I'm following the doc on conntrack-tools to enable RPC tracking (for NFS
support), and wind up with this state:
# nfct helper list
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 16,
.status = disabled,
};
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = disabled,
};

Why disabled? conntrackd startup went fine, the nfct helper add went fine, what
am I missing ?

And, of course, it doesn't work ;)

I may be royally screwed anyway - due to the bizarre situation I'm trying to
support...
LAN: 192.168/16 - mix of Linux, Windows, and AIX clients
Gateway: 192.168.1.205 (Linux Gateway/Firewall)
OpenConnect VPN to work (CISCO ASA client) - IBM
IBM network - GSA NFS Servers

The sticky point for a statefull firewall seems to be twofold:
1) AIX (at least 5.3) still does RPC mount lookups - even if NFSV4 and port=2049
are specified
Which, it seems, is totally needless

2) The GSA infrastructure is layered, and littered with High Availability & load
balancing - but seems to break
extant rules...
- My LAN client does a RPC GETPORT (MOUNT -V3) to snjgsa.sanjose.ibm.com
- My firewall NATs the request
- The GSA mainline server delegates (forwards, whatever) to a disk sever
- The disk server (snjxgsasd2.sanjose.ibm.com) replies the RCP GETPORT request

At this point, we have two streams, with matching ports, but differing IP sets,
both in UNREPLIED status.

I am not at all sure, that even were I to get the RPC helper going, and it
issues and EXPECT, that things will work, but am willing to hack to make it so :)

[Richard A Nelson]

I left out the end of the scenario :(

As a result, afaict, of the IP missmatch, and both RPC GETPORT streams being
marked UNREPLIED, the Linux gateway box returns an ICMP PORT UNREACHABLE (there
being no such open port on the gateway box).

Post by Richard A Nelson
I'm having a heck of a time getting this all going ;)
Debian Sid/Experimental
Linux 3.7.1
conntrack toolchain downloded yesterday (stable, not git)
I'm following the doc on conntrack-tools to enable RPC tracking (for NFS
# nfct helper list
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 16,
.status = disabled,
};
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = disabled,
};
Why disabled? conntrackd startup went fine, the nfct helper add went fine,
what am I missing ?
And, of course, it doesn't work ;)
I may be royally screwed anyway - due to the bizarre situation I'm trying to
support...
LAN: 192.168/16 - mix of Linux, Windows, and AIX clients
Gateway: 192.168.1.205 (Linux Gateway/Firewall)
OpenConnect VPN to work (CISCO ASA client) - IBM
IBM network - GSA NFS Servers
1) AIX (at least 5.3) still does RPC mount lookups - even if NFSV4 and
port=2049 are specified
Which, it seems, is totally needless
2) The GSA infrastructure is layered, and littered with High Availability &
load balancing - but seems to break
extant rules...
- My LAN client does a RPC GETPORT (MOUNT -V3) to snjgsa.sanjose.ibm.com
- My firewall NATs the request
- The GSA mainline server delegates (forwards, whatever) to a disk sever
- The disk server (snjxgsasd2.sanjose.ibm.com) replies the RCP GETPORT request
At this point, we have two streams, with matching ports, but differing IP
sets, both in UNREPLIED status.
I am not at all sure, that even were I to get the RPC helper going, and it
issues and EXPECT, that things will work, but am willing to hack to make it so :)

[Pablo Neira Ayuso]

Hi Richard,

Post by Richard A Nelson
I'm having a heck of a time getting this all going ;)
Debian Sid/Experimental
Linux 3.7.1
conntrack toolchain downloded yesterday (stable, not git)
I'm following the doc on conntrack-tools to enable RPC tracking (for
# nfct helper list
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 16,
.status = disabled,
};
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = disabled,
};
Why disabled? conntrackd startup went fine, the nfct helper add
went fine, what am I missing ?

That means conntrackd did not configured the helper so far, so it
remains dormant in the kernel.

Did you add the corresponding Helper clause to conntrackd.conf?

It should be something similar to what you can find under
conntrack-tools/doc/helper/conntrackd.conf.

Please, check /var/log/conntrackd.log (or custom path in case you set
it). It should report some information regarding the helper
configuration.

Post by Richard A Nelson
And, of course, it doesn't work ;)
I may be royally screwed anyway - due to the bizarre situation I'm
trying to support...
LAN: 192.168/16 - mix of Linux, Windows, and AIX clients
Gateway: 192.168.1.205 (Linux Gateway/Firewall)
OpenConnect VPN to work (CISCO ASA client) - IBM
IBM network - GSA NFS Servers
1) AIX (at least 5.3) still does RPC mount lookups - even if NFSV4
and port=2049 are specified
Which, it seems, is totally needless
2) The GSA infrastructure is layered, and littered with High
Availability & load balancing - but seems to break
extant rules...
- My LAN client does a RPC GETPORT (MOUNT -V3) to snjgsa.sanjose.ibm.com
- My firewall NATs the request
- The GSA mainline server delegates (forwards, whatever) to a disk sever
- The disk server (snjxgsasd2.sanjose.ibm.com) replies the RCP GETPORT request
At this point, we have two streams, with matching ports, but
differing IP sets, both in UNREPLIED status.
I am not at all sure, that even were I to get the RPC helper going,
and it issues and EXPECT, that things will work, but am willing to
hack to make it so :)

This was tested with NFSv3 running both Linux in the client and the
server sides.

I'd suggest to start by getting that "disabled" issue resolved first,
then, move on to see what other problem you find.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Richard A Nelson]

Post by Pablo Neira Ayuso
Hi Richard,

Thanks for the quick, and on target note !

Post by Pablo Neira Ayuso
{
.name = rpc,
.queuenum = 0,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = disabled,
};
Why disabled? conntrackd startup went fine, the nfct helper add
went fine, what am I missing ?
That means conntrackd did not configured the helper so far, so it
remains dormant in the kernel.
Did you add the corresponding Helper clause to conntrackd.conf?
It should be something similar to what you can find under
conntrack-tools/doc/helper/conntrackd.conf.
Please, check /var/log/conntrackd.log (or custom path in case you set
it). It should report some information regarding the helper
configuration.

My confusion seemed to have been the requisite three part dance - even though
they're pretty well described in the docs.
1) Register helpers via nfct
2) Add iptables rules in -t raw (output & prerouting)
3) (Re)Start conntrackd

I now see:
# nfct helper list
{
.name = rpc,
.queuenum = 2,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 16,
.status = enabled,
};
{
.name = rpc,
.queuenum = 1,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = enabled,
};

I rebooted, and made sure things came back up in the same state... looking good.

Post by Pablo Neira Ayuso
This was tested with NFSv3 running both Linux in the client and the
server sides.

Perfect, then - there is a good chance this'll go... I'm still somewhat worried
about the fact that the RPC call is answered by a different machine than the
request was made to... but trial and error is called for now ;)

Post by Pablo Neira Ayuso
I'd suggest to start by getting that "disabled" issue resolved first,
then, move on to see what other problem you find.

Exactly, one down - and I have removed the old rules allowing arbitrary replies
from port 111, and things are working well on the server side (NFSv3 mounts work
fine).

Now, to see if I can coax the AIX box into booting again - otherwise I'll try
another Linux client behind the server.

Thanks again!