与ScreenOS相比，SRX在NAT功能实现方面基本保持一致，但在配置上有较大区别，主要差异在于ScreenOS的NAT与policy是绑定的，无论是MIP/VIP/DIP还是基于策略的NAT，在policy中均要体现出NAT内容（除了缺省基于untrust接口的Souec-NAT模式外），而SRX的NAT则作为网络层面基础内容进行独立配置（独立定义地址映射的方向、映射关系及地址范围），Policy中不再包含NAT相关配置信息，这样的好处是易于理解、简化运维，当网络拓朴和NAT映射关系发生改变时，无需调整Policy配置内容。

在SRX中安全策略只负责控制业务数据的转发与否，NAT策略只控制业务数据的源地址和端口的翻译规则，两者各自独立。

SRX的NAT配置分为源地址翻译(source NAT)，目标地址翻译(destination NAT)和静态地址翻译(static NAT)三种，其配置语法都类似，只是nat rule必须被放到rule-set里使用，任意两个zone或任意两个网络逻辑接口之间只允许有一个rule-set。

Junos为SRX提供了一个完整而集成的NAT功能。NAT在【security】层级下配置，集成了有状态流处理，但它在逻辑上是security policy配置分离。

一个给定的流量可以最多匹配一个NAT规则，必须匹配一个安全策略security policy。NAT与security policy之间没有直接的对应关系，一个匹配NAT规则的流量可以被一个或者安全策略匹配。一个匹配security policy规则的流量可以被0,1或者多个NAT规则匹配。但是，一旦一个匹配NAT规则的流，将会在会话表session table建立双向的表项。

图5-1所示为在SRX流模型NAT的处理。

SRX内 NAT处理流程

请注意，静态NAT和目标NAT规则匹配在路由查找/Zone确定之前，也在Policy之前。源NAT和反向静态NAT的匹配在Policy匹配之后。

SRX这种不依赖于Policy的更灵活和精确的NAT配置模式，使得拓扑和地址翻译的重新设计成为可能，而Policy可以保持不变。

因为Source NAT在路由和Zone查找之后，配置rule-sets时必须同时指定ingress和egress interface、zone、routinginstance。Static和Destination NAT在路由和Zone查找之前进行处理，rule-sets只需配置ingress的interface、zone、routing instance。

当多个NAT rule-sets包含的上下文都匹配给定流，具有最具体上下文的rule-set用于确定翻译动作。一个包含匹配接口上下文的rule-set优选于一个具有匹配zone的上下文，而匹配Zone的上下文优于配路由实例的上下文。在所选择的rule-set内，按照顺序评估rules，第一个匹配的用于确定翻译动作的流程。

SRXNAT和Policy执行先后顺序为：目的地址转换－目的地址路由查找－执行策略检查－源地址转换，结合这个执行顺序，在配置Policy时需注意：Policy中源地址应是转换前的源地址，而目的地址应该是转换后的目的地址，换句话说，Policy中的源和目的地址应该是源和目的两端的真实IP地址，这一点和ScreenOS存在区别，需要加以注意。

SRX中不再使用MIP/VIP/DIP这些概念，其中MIP被Static静态地址转换取代，两者在功能上完全一致；DIP被Source NAT取代；基于Policy的目的地址转换及VIP被 Destination NAT取代。ScreenOS中基于Untrust zone接口的源地址转换被保留下来，但在SRX中不再是缺省模式（SRX中Trust Zone接口没有NAT模式概念），需要手工配置。类似ScreenOS，Static属于双向NAT，其他类型均属于单向NAT，

此外，SRX还多了一个proxy-arp概念，如果定义的IPPool（可用于源或目的地址转换）与接口IP在同一子网时，需配置SRX对这个Pool内的地址提供ARP代理功能，这样对端设备能够解析到IPPool地址的MAC地址（使用接口MAC地址响应对方），以便于返回报文能够送达SRX。

值得注意的是SRX不会自动为NAT规则生成proxy-arp配置，因此如果NAT地址翻译之后的地址跟出向接口地址不同但在同一网络内时，必须手工配置相应接口proxy-arp以代理相关IP地址的ARP查询回应，否则下一条设备会由于不能通过ARP得到NAT地址的MAC地址而不能构造完整的二层以太网帧头导致通信失败。