Существует возможность спроектировать и внедрить NAT-модули, способные функционировать совместно с IPsec-архитектурой, но весьма дифференцированно и в зависимости от конкретного случая, причем ценою ограничений на модель обеспечения надежности. Со всеми этими ограничениями, накладываемыми на системы обеспечения безопасности, NAT-модули представляют собой весьма существенное препятствие для интеграции систем защиты, которая имеет место в настоящее время в Internet-сети.
Как определено в стандарте RFC-2694, DNS-ALG-субмодуль способен обеспечить безопасность DNS-серверов в коропоративных сетевых сегментах. Внутризональные процедуры информационного обмена между DNSSEC-серверами, обеспечивающие необходимую модификацию данных в DNS-БД (база данных DNS-системы), потерпят провал. Это относится и к тем случаям, когда DNS-ALG-субмодуль «искажает» любые подписанные ответные DNS-сообщения, содержащие измененные DNS-данные. Например, это может быть случай, когда все DNS-запросы относительно объектов в сети общего пользования, направляются корпоративными IP-узлами, а DNS-сервер расположен внутри корпоративной сети. Все сказанное выше справедливо и в случае, когда все DNS-запросы относительно объектов корпоративной сети, направляются корпоративными IP-узлами, а DNS-сервер расположен в сети общего пользования. Любой DNS-ALG-субмодуль может только тогда модифицировать RR-записи с ЭЦП (подписанные DNS-данные), когда он имеет доступ к ключу, аутентифицированному источником DNS-данных. Группа DNSSEC-протоколов была специально разработана для того, чтобы исключить процедуру распределения этого ключа по сети, и для проведения процедуры аутентификации источника DNS-данных. Очевидно, что NAT-модули, которые используют DNS-ALG-субмодули для исправления DNS-имен объектов в DNS-запросах относительно IP-адресов, будут:
нарушать безопасность при изменении RR-записей в DNS-БД;
требовать доступа к ключам всех источников DNS-данных при получении на обработку DNS-запросов относительно IP-адресов.
Те способы обеспечения безопасности, которые не защищают или не транслируют IP-адреса в качестве идентификаторов (такие как TLS, SSL и SSH), могут функционировать в обслуживаемых NAT-модулями сетевых сегментах. Если прикладные службы способны формировать и использовать такого типа соединения, то тогда NAT-модули не будут создавать дополнительных проблем для их функционирования. Такие способы обеспечения безопасности не способны эффективно защитить все прикладные службы, так как IP-заголовок полностью открыт (не защищен), и они не запрещают проведение «губительных» управляющих процедур, подобных переходу на новый ТСР-сеанс связи.
Аргументы в пользу того, что NAT-модули могут функционировать в защищенном режиме, искажают смысл обеспечения безопасности сквозного соединения, так как NAT-модуль берет на себя роль оконечного объекта безопасности в сквозном соединении. С функциониальной точки зрения, NAT-модуль должен быть управляемым, как элемент защищаемого сетевого сегмента, и в этом режиме IP-пакеты, циркулирующие с незащищенной стороны NAT-модуля, полностью открыты (не защищены).