Средства и методы разработки

Мастер выходит в Интернет, вероятно, тоже через NAT. Поэтому пакет мастера: 

From: LocalMasterIP:LocalMasterPort To: PublicSlaveIP:PublicSlavePort

Транслируется в маршрутизаторе ведущего в такой пакет:

From: PublicMasterIP:PublicMasterPort To: PublicSlaveIP:PublicSlavePort.

Маршрутизатор ведомого имеет вручную настроенное правило для PublicSlavePort и транслирует пакет на локальный адрес ведомого так:

From: PublicMasterIP:PublicMasterPort To: LocalSlaveIP:LocalSlavePort.

Ведомый отвечает на публичные IP и порт ведущего:

From: LocalSlaveIP:LocalSlavePort To: PublicMasterIP:PublicMasterPort

И этот пакет, так как имеет назначением публичный адрес, просто маршрутизируется в интернет маршрутизатором с NAT ведомого. Никакого правила на ведомом не нужно, это будет обычный исходящий пакет от ведомого, как любой другой выход в интернет без ранее установленного соединения. Маршрутизатор ведомого транслирует заголовок пакета:

From PublicSlaveIP:PublicSlavePort To: PublicMasterIP:PublicMasterPort (по идее, тут совсем не важно, какой номер исходящего порта использует ведомый и какой номер исходящего порта был у ведущего - могут быть любыми и любые пройдут через маршрутизатор ведомого)

Получается, что проблема с трансляцией адресов UDP, может возникнуть только на стороне ведущего. Когда маршрутизатор с транслятором адресов ведущего, не разбёрётся, кому в локальной сети отправить пакет с портом назначения ведущего.

Исходящий порт ведущего меняется. И тут надо, чтобы NAT ведущего автоматически направлял ответы ведущему, помня, что он только что запрашивал с этого порта кого-то в Интернет. Либо, вариант, жёстко указать ведущему диапазон исходящих портов, чтобы ведущий отправлял запросы только с этих исходящих портов. И у NAT ведущего, направить весь этот диапазон на локальный адрес ведомого.

В случае ТС с AT-комадами и UDP-мостом, хорошо заработает ведомый. Мастер может не получиться, так как нельзя управлять диапазоном исходящих портов.