I'm going to answer you here even though we started this conversation over email.  (for the benefit of others)

First off, here was my first response:

Wow  =)  Ok, a couple of blanket statements first.  The IM Gateway plugin explicitly only works with local accounts.  (it uses openfire internals and therefore can't work with external things without major reworkings and ejecting some of the "cleanness" about the implementation)  PyAIMt, PyICQt, PyMSNt, PyYIMt, PyIRCt, PyXMPPt ... all of them should work remotely.  (like you can set up an openfire or whatever server somewhere and they can be used from GTalk)

That said, I'm afraid I don't really know anything about forwarding IMs.  You might be able to do something where you "tie" an openfire account to a gtalk account and somehow log in the openfire account with the gtalk account and forward messages ... but that sounds kinda scarey.  ;D

I don't know if I'll ever implement remote servers being able to connect to the plugin.  It completely destroys any ability to be "smooth" about the whole process.  Like on first registration you'd be back to getting a flood of "will you add me?" from each and every contact.  There's lots of room for things getting out of sync.  It's actually part of the reason why I adored creating a plugin based on internals.  =/

Now to answer your followup:

Thanks for the answer! What do you mean by usable from GTalk. The

Google Talk client? That will only connect to Google's servers. Or you

mean generally an XMPP client?

With the python based transports, they really don't care where you are coming from.  They follow XEP-0100 more or less dead on.  So even if you are on google talk, you can register your google talk account with, say, aim.myserver.org.  The IM gateway plugin can not do this because it uses mechanisms inside of Openfire to tie directly into your roster and such... which means it can't tie into a roster on another server somewhere else which means it can't really be used from an external server.