Асимметричная маршрутизация с двумя межсетевыми экранами ForeFront TMG 2010

У меня странная проблема с сетью.

Есть сеть, одна IP-подсеть: 192.168.60.0/24.

Сеть имеет два подключенных к Интернету брандмауэра (работает ForeFront TMG 2010), 192.168.60.253 (производство) и 192.168.60.240 (разработка); это необходимо, потому что есть две среды, и каждая из них нуждается в своих собственных правилах интернет-публикации; однако по историческим причинам они используют одну и ту же IP-подсеть, и это не может быть легко изменено. Таким образом, рабочие компьютеры используют 192.168.60.253 в качестве шлюза по умолчанию, в то время как компьютеры для разработки используют 192.168.60.240. Все работает, пока никакие другие сети не вовлечены.

Но, конечно, есть другая сеть (на самом деле больше, чем одна, но давайте все упростим), подключенная к третьей сетевой плате на рабочем брандмауэре, а именно 192.168.100.0/24. Компьютеры в этой сети используют этот брандмауэр в качестве шлюза по умолчанию. Они могут общаться с производственными компьютерами в основной сети и наоборот.

Когда компьютеры в сети 192.168.100.0/24 пытаются общаться с компьютерами-разработчиками в основной сети, это не работает, потому что их шлюз по умолчанию (межсетевой экран develompent) не знает, как отправлять пакеты обратно. Это ожидается. Поэтому я добавил постоянный статический маршрут к брандмауэру разработки, чтобы сказать ему "когда вам нужно отправить пакет на 192.168.100.0/24, отправьте его на 192.168.60.253"; Я также определил сеть в сетевой конфигурации TMG и разрешил весь трафик между двумя сетями.

Теперь действительно странная часть: пинг между двумя сетями работает, но любой другой протокол - нет. HTTP, RDP, SMB... ничего не проходит, хотя маршрутизация работает и политики брандмауэра открыты для всех.

Что происходит, почему и как я могу это исправить (кроме ручного добавления статических маршрутов на каждый сервер разработки, чего я бы хотел избежать)?

Обновить:

Я проверил журналы трафика в брандмауэре разработки, и похоже, что TCP-пакеты отбрасываются, потому что, с точки зрения этого брандмауэра, они не связаны с каким-либо открытым соединением. На самом деле это имеет смысл, потому что при запуске соединения начальный пакет TCP-рукопожатия проходит через рабочий брандмауэр, а ответ пытается вернуться через брандмауэр разработки... и TMG отбрасывает его, потому что он никогда не видел первый пакет совсем. Это также объясняет, почему TCP не работает, в то время как ICMP (и предположительно UDP) работает.

Но все же: как я могу это исправить и заставить эту асимметричную маршрутизацию работать, если это вообще возможно сделать?