Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

NAT-Dst configuration with NAT-Dst IP on same subnet as ingress interface isn't working

0

0

Article ID: KB10174 KB Last Updated: 06 Sep 2011Version: 8.0
Summary:

Configuring NAT-Dst IP in the same subnet as the ingress interface of the firewall isn't working because firewall is not responding to ARP requests for NAT-Dst IP address.  The hidden command 'set arp nat-dst' can be used.

Symptoms:
NAT-Dst configuration with NAT-Dst IP on same subnet as ingress interface isn’t working.  The Juniper firewall device is not responding to the ARP requests for the NAT-Dst IP packets.

Topology:

  Public host
  1.1.1.20/24
      |
      |
      |
      |
  1.1.1.1/24    (NAT-Dst IP 1.1.1.100 -> Internal IP 10.1.1.100)
  Public Zone
     e1
      |
Juniper_firewall
      |
     e2
  Trust Zone
  10.1.1.1/24
      |
      |
      |
      |     
  10.1.1.100/24
  Internal Server

 

In the above example a public host sends traffic to destination IP, 1.1.1.100, and the customer wants the firewall to translate the destination address 1.1.1.00 to 10.1.1.100.  Also, the NAT-Dst IP, 1.1.1.100, is on the same network as the ingress interface, 1.1.1.1/24.

However, the problem is that the firewall is not sending ARP replies to the public host when the public host tries to communicate with the NAT-Dst IP 1.1.1.100.

 

Solution:
There are different solutions to this problem.  Choose one:
  1. Create static ARP entries on upstream devices
    OR
  2. Enable hidden ScreenOS command 'set arp nat-dst'
    OR
  3. For earlier ScreenOS versions, a third option is available - Create a DIP pool on ingress interface. 
    NOTE:  Option 3 is NOT applicable to ScreenOS 5.4.0r12 (and later), 6.0.0r8 (and later), 6.1.0r5 (and later), 6.2.0r2 (and later), and 6.3.0r1 (and later) because the DIP behavior has changed.  (See related KB15607.)

Note: In addition to one of the above solutions, an intra-zone policy is required to trigger the Destination Translation:
set zone name "public"
set address "public" "1.1.1.100" 1.1.1.100 255.255.255.255
set policy from "public" to "public"  "Any" "1.1.1.100" "ANY" nat dst ip 10.1.1.100 permit
 

The solutions are explained further below: 

Solution Option 1
One option is to create permanent static ARP entries on the upstream devices.
For this example, the upstream devices on the same segment as the Juniper Firewall need an ARP entry that maps 1.1.1.100 to the MAC address of the Juniper Firewall e1 interface.  If this is not feasible, perhaps because the upstream devices are managed by another administrative team, then use Solution 2) or 3).
 
Solution Option 2
Enable the hidden ScreenOS command 'set arp nat-dst' on the firewall. The hidden ScreenOS command 'set arp nat-dst' may be enabled on the firewall to trigger ScreenOS to send ARP responses for NAT-DST addresses that are on the same subnet as the device’s interface. The device interface can be in any zone. 


IMPORTANT: Reasons to NOT use Solution Option 2:
  1. The command 'set arp nat-dst' does not work in a VSYS environment.  Therefore, for VSYS environments use Solution 1) or 3).
  2. If more than a few hundred intrazone policies exist, then use solution 1) or 3) to minimize performance degradation.
  3. If the ScreenOS version is below version 5.4, then use solution 1) or 3).

Solution Option 3

(Note:  This option is not applicable to ScreenOS 5.4.0r12 (and later), 6.0.0r8 (and later), 6.1.0r5 (and later), 6.2.0r2 (and later), and 6.3.0r1 (and later).
Create a DIP pool on the ingress interface and this will allow the Juniper firewall to respond to ARP.  In this example, the DIP pool consists of one address, the NAT-Dst IP address. The DIP pool only needs to be created, but not used in a policy. 
 
For this example, when the following command is set on the firewall, the firewall will respond to ARP requests to 1.1.1.100: 
set int eth1 dip 4 1.1.1.100 1.1.1.100

 

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search