Shulou(Shulou.com)06/01 Report--

Compared with ScreenOS, SRX is basically consistent in the implementation of NAT functions, but there is a big difference in configuration. The main difference is that NAT of ScreenOS is bound to policy. Whether it is MIP/VIP/DIP or policy-based NAT, NAT content should be reflected in policy (except for the default Souec-NAT mode based on untrust interface). On the other hand, the NAT of SRX is configured independently as the basic content at the network level (independently defining the direction, mapping relationship and address range of address mapping). The Policy no longer contains NAT-related configuration information, which has the advantage of being easy to understand and simplify operation and maintenance. when the network topology and NAT mapping relationship changes, there is no need to adjust the Policy configuration content.

In SRX, the security policy is only responsible for controlling whether the business data is forwarded or not, while the NAT policy only controls the translation rules of the source address and port of the business data, both of which are independent.

The NAT configuration of SRX is divided into source address translation (source NAT), destination address translation (destination NAT) and static address translation (static NAT). The configuration syntax is similar, except that nat rule must be used in rule-set, and only one rule-set is allowed between any two zone or any two network logical interfaces.

Junos provides a complete and integrated NAT function for SRX. NAT is configured at the [security] level and integrates stateful flow processing, but it is logically security policy configuration separation.

A given traffic can match at most one NAT rule and must match a security policy security policy. There is no direct correspondence between NAT and security policy, and a traffic that matches NAT rules can be matched by one or security policy. A traffic that matches a security policy rule can be matched by 0Power1 or more NAT rules. However, once a flow matches the NAT rule, a bi-directional table entry is created in the session table session table.

Figure 5-1 shows the processing in the SRX flow model NAT.

NAT processing flow in SRX

Note that the static NAT and destination NAT rules match before the route lookup / Zone is determined, and before the Policy. The source NAT and the reverse static NAT match after the Policy match.

SRX, a more flexible and precise NAT configuration mode that does not depend on Policy, makes it possible to redesign topology and address translation, while Policy can remain the same.

Because Source NAT must specify both ingress and egress interface, zone, and routinginstance when configuring rule-sets after routing and Zone lookup. Static and Destination NAT are processed before routing and Zone lookup, and rule-sets only needs to configure interface, zone, and routing instance of ingress.

When multiple NAT rule-sets contain contexts that match a given stream, the rule-set with the most specific context is used to determine the translation action. A rule-set containing a matching interface context is preferred to a context with a matching zone, and the context of the matching Zone is better than the context of the routing instance. Within the selected rule-set, the rules is evaluated sequentially, and the first matching process is used to determine the translation action.

The execution order of SRXNAT and Policy is: destination address translation-destination address routing lookup-perform policy check-source address translation. Combined with this execution order, when configuring Policy, we should pay attention to: the source address in Policy should be the source address before translation, and the destination address should be the translated destination address. In other words, the source and destination addresses in Policy should be the real IP addresses of both source and destination, which is different from ScreenOS. Need to pay attention to.

The concepts of MIP/VIP/DIP are no longer used in SRX, where MIP is replaced by Static static address translation, which is functionally identical; DIP is replaced by Source NAT; Policy-based destination address translation and VIP are replaced by Destination NAT. Source address translation based on the Untrust zone interface in ScreenOS is preserved, but it is no longer the default mode in SRX (the Trust Zone interface does not have the concept of NAT mode in SRX) and needs to be configured manually. Similar to ScreenOS,Static belongs to two-way NAT, other types belong to one-way NAT

In addition, SRX also adds a concept of proxy-arp. If the defined IPPool (which can be used for source or destination address translation) is on the same subnet as the interface IP, you need to configure SRX to provide ARP proxy function for the address in this Pool, so that the peer device can resolve to the MAC address of the IPPool address (using the interface MAC address to respond to the other party), so that the return message can be delivered to the SRX.

It is worth noting that SRX does not automatically generate proxy-arp configurations for NAT rules, so if the translated address of the NAT address is different from the outgoing address to the interface but within the same network, the corresponding interface proxy-arp must be manually configured to proxy the ARP query response of the relevant IP address, otherwise the next device will fail to construct a complete layer 2 Ethernet frame header because the MAC address of the NAT address cannot be obtained through ARP.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.