The error means that NAT was trying to do a layer 4 fix up on the address in an FTP open, and couldn't find the ip addresses it needed to translate in the packet.
The reason the message talks about tokens is that we find the ip addresses in the packet by looking for a token, or a set of symbols, in the ip packet, to find
the stuff we need to translate.
When an FTP session is initiated, it negotiates 2 channels, a command channel and a data channel. These are both IP addresses with different port numbers. FTP client and server will negotiate a second data channel to transfer files.
The packet exchanged via control channel has the format "PORT,i,i,i,i,p,p,i,i,i,i are the four bytes of an IP address, p,p specify the port. NAT tries to
match this pattern and translate address/port if necessary.
NAT must translate both channels' addressing schemes. NAT scans for numbers in the command stream until it thinks it has found a port command that requires translation. It tries to parse out the translation, which it calculates using the pattern we discussed above. If the packet is corrupt or the ftp server or client are malforming commands, NAT cannot properly calculate the translation and it generates that error.
If you want to pursue this, it would help to have sniffer traces on the segments from the FTP server to the router and from the router to the FTP client. More than likely the FTP client is the culprit.
A suggestion is to set the FTP client to "passive" so that it initiates both channels. This sometimes helps with FTP through NAT.
