Похоже проблема в том что вы путаете между собой proxi , NAT и Firewall.
Это все разные вещи.

В случае когда оба конца за NAT-ом даю идею:

Исходные данные:
Оба дивайса имеют в памяти по два публичных адреса. Один считают своим, другой считают присвоенным удаленному дивайсу. Адреса эти им никто может официально не выдавать, они их используют как бы нелегально, но они должны быть публичными.
Также дивайсам известно с каких портов они будут выходить на связь.

Начало обмена:
Каждый из дивайсов с известного порта посылает UDP по фиктивному адресу своего удаленного партнера.
Эти UDP не доходят понятно до адресата, но дело сделано, с тем адресатом пробит UDP канал в NAT-е
После того как каналы пробиты на обих NAT-ах c двух концов дивайсы начинают в свои пакеты в поле адреса отправителя ставить свои фиктивные публичные адреса.
И эти пакеты уже дойдут к каждому
Есть NAT-ы где канал пробивается еще легче, просто можно послать пакет по любому адресу.
Тогда и TCP можно использовать.

Интересная идея, только вот если не ошибаюсь NAT на публичном интерфейсе совершенно не обязательно будет передавать от такого же порта, какой с которого получил от компа с внутреннего интерфейса.

В любом случае для данной задачи, а я так понял, необходимо ее решить в общем смысле - такой вариант не пройдет. Да и швыряться UDP трафом налево и направо через GPRS - тоже не очень хорошая мысль.

Оказывается возможно реализовать соединение между двумя компами.

Делается сервер в интернете. На который заходят участники сети. Получают пути друг для друга. Потом уже связываются между собой, используя эти пути. Т.е. происходить соединение между ПК и сервером. Далее, скажем, другой инициатор сети, зная путь, прикидывается сервером и работает.

вами, судя по всему, описана схема поиска друг друга хостами с динамическим ip.
если оба участника находятся за nat (как обычно это происходит в случае gprs), то такая схема работать не будет.

Да вот говорят за MTC-овским NAT-ом это работает.
Так у них и SIM карты до сих пор клонируют.
Видать левая контора с устаревшим оборудованием.

За нормальным NAT-ом конечно работать не будет.
Но вот схема с подстановкой публичного IP работать должна за любым NAT-ом
http://electronix.ru/forum/index.php?showt...mp;#entry411267

Как будет время, я конечно же проверю ваш вариант - но очень сильно сомневаюсь, что будет работать, а уж в нестабильности точно уверен.

лень расписывать подробно, вкратце.
предоположим вы "пробили" nat.
вы написали, с какого адреса и порта вы будете слать пакеты. а на какой адрес?
с портами вам уже указали - при прохождении nat порты обычно не сохраняются.
и напоследок: вы посылаете пакет с "левым" src ip. скорее всего он будет отброшен, но даже если и нет - nat подменяет src ip.

Нас это не остановит, ;-)
Хотя в каком-то моменте, стормозил вроде.

Тогда технология несколько меняется

Идея такая:
Усложним задачу предположив, что дивайсы не знают какой внешний IP или из какого пула внешних IP им присваивает оператор.
Тогда каждый дивайс узнает свой внешний IP адрес через какой-нибудь публичный STUN сервер.
Потом оставляет запись о себе где нить на публичном POP3 сервере или на HTTP майл сервере.

Найдя в общем каталоге через отдельный TCP коннект адрес своего партнера дивайс уже шлет ему пакеты. Но на какой порт? После сессии со STUN порт уже мог поменяться.
Тогда делаем ход конем.
NAT-ы не должны следить за сессиями они работают на уровне IP поэтому тупо шлем FTP команду PORT с запросом на активное FTP DATA соединение своему партнеру например на 21-й порт.
Команда не дойдет ясно, но как замечено NAT-ы не мапируют порт передаваеммый в этой команде.
Договорившись заранее о номере этого порта партнеры после обнаружения IP друг друга просто начинают что-то слать друг другу используя этот номер порта.

ключевое слово - пул

ничего не понял