ip_nat_expect()

[Kevin Moore]

I'm not clear on how a rule added with ip_nat_expect() differs from a rule
added at the command line other than it is suppossed to take priority and
has a time out.

I have the following situation.  A client on the internet at large sends a
UDP packet to our server address which is really the firewall.  The firewall
sends this to the internal server.   I use a NAT rule to do this. The
internal server sends a UDP response with an ftp port embedded in the reply.
The data is encrypted.  I have a NAT helper that decrypts this outgoing UDP
response, changes the port to an acceptible value (right now I just add
40000, not permanent solution), encrypts it again.  The client gets the UDP
response and starts an ftp session on the port specified in the UDP packet.
The UDP part now works.

In the NAT helper which changes the embedded ftp port, use ip_nat_expect()
so that NAT will have a rule which will handle the client starting an ftp
session on that port.  It doesn't work.  However, if a I know which port the
client will use in a particular instance and add a mapping from the command
line it works (for that one case only of course).

Here's what the output from ipnatctl -L -n looks like:
when using ip_nat_expect() this rule shows up like this
expected [DST] 216.174.192.212/32->216.174.192.214/32 proto=6 dstpt=43725
TO: 10.10.10.4 port 3725

when done at the command line
generic [DST] 216.174.192.212/32->216.174.192.214/32 proto=6 dstpt=43725 TO:
10.10.10.4 port 3725

The command line one works.  Its not a solution because in this case I
anticipated what port would be used.  It varies according to what file is
being transferred (the server, not under my control, (sigh), uses a port per
file, each file being a days worth of data and depends on which ones the
server grabbed when it started up).

Also note that I'm doing nothing with connection tracking.  I'm relying on
the default connection tracking.  I just using a NAT module to catch the one
outgoing UDP packet (always on a known  port) that is the source of all my
woes because it has an embedded port for a subsequent ftp session.

So, in short, my questions are:
    How do I know what port is available on the firewall to have the client
talk to (rather than just doing my +40000 hack)?
    What don't I understand about ip_nat_expect()?

Thanks.

Kevin