Racoon: "ignore because do not listen on source address"

Help.. oh help. I once had this nearly working but I have forgotten in
the six months since I last tried it.

Here is what I want to do:
(1) I'm on a Linux box running ipsec-tools-0.5.2 on a local network,
at address 192.168.254.6 with the router at 192.168.254.254.
(2) I want to connect to a remote at XXX.XXX.XXX.XXX such that this
remote, when contacted, will appear as 192.168.30.1 as seen on my
machine.
(3) Remember: MY LINUX BOX IS THE CLIENT. "XXX.XXX.XXX.XXX" is the
public address of the client's Sonicwall router.
(4) The version of racoon that I am using is 0.5.2 and it is
configured to recognize XAUTH.

My setkey file is:
flush; spdflush;
spdadd 192.168.254.0/24 192.168.30.1/32 any -P out ipsec
esp/tunnel/192.168.254.254-XXX.XXX.XXX.XXX/require;
spdadd 192.168.30.1/32 192.168.254.0/24 any -P in ipsec
esp/tunnel/XXX.XXX.XXX.XXX-192.168.254.254/require;

Issuing these commands with racoon running, I "ping 192.168.30.1" and
am told that "resource temporarily unavailable." Meanwhile on the
racoon console:

DEBUG: get pfkey ACQUIRE message
DEBUG: ignore because do not listen on source address :
192.168.254.254.

Remember that this machine is the =client= not the =server= so it
should not be listening to anyone anywhere.

racoon.conf is: (with various secret parts OMITTED):

path include OMITTED;
path pre_shared_key OMITTED;
path certificate OMITTED;

sainfo anonymous
{
pfs_group 1;
encryption_algorithm 3des, des;
authentication_algorithm hmac_sha1;
compression_algorithm deflate;
}
remote XXX.XXX.XXX.XXX
{
exchange_mode aggressive, main;
my_identifier address;
xauth_login OMITTED;

proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
== end of file ==

I am utterly and completely lost, even with the source-code on hand. I
see that the comment in "pfkey.c" reads:
/* ignore, if we do not listen on source address */
/* reasons behind:
* - if we'll contact peer from address we do not
listen -
* we will be unable to complete negotiation;
* - if we'll negotiate using address we're listening -
* remote peer will send packets to address different
* than one in the policy, so kernel will drop them;
* => therefore this acquire is not for us! --Aidas
*/

I am =desperate= for any assistance. Please reply to the newsgroup.

Correction to the above: "XXX.XXX.XXX.XXX" is the Internet public
address of the SonicWall router to which I desire to connect.

The word "client" as used in the original post is therefore ambiguous.
In THAT particular sentence I meant it as "the address of the person
who will pay me money IFF this problem is quickly solved!"

What is so utterly maddening is that I am certain that one simple
command will get me past this roadblock. In my distant memory I simply
do not remember what it is. And I am therefore... show-stopped and the
clock is ticking.