NAT-Dst configuration with NAT-Dst IP . same subnet as ingress interface isn
Knowledge Base ID: KB10174
Version: 4.0
Published: 07 Oct 2008
Updated: 07 Oct 2008
Categories: . Firewall/IPSec_***
. NS-204
. NS-208
. ISG-1000
. ScreenOS
Synopsis:
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.
Problem:
NAT-Dst configuration with NAT-Dst IP . 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 . 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 3 different solutions to this problem.  Choose .e:

1) Create static ARP entries . upstream devices
OR
2) Enable hidden ScreenOS command 'set arp nat-dst'
OR
3) Create DIP pool . ingress interface

Note: In addition to .e 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 1
--------------
One option is to create permanent static ARP entries . the upstream devices.
For this example, the upstream devices . 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 2
---------------
Enable the hidden ScreenOS command 'set arp nat-dst' . the firewall. The hidden ScreenOS command 'set arp nat-dst' may be enabled . the firewall to trigger ScreenOS to send ARP responses for NAT-DST addresses that are . the same subnet as the device’s interface. The device interface can be in any zone. 

IMPORTANT Reasons to NOT use Solution 2:

a. The command 'set arp nat-dst' does not work in a VSYS environment.  Therefore, for VSYS environments use Solution 1) or 3).
b. If more than a few hundred intrazone policies exist, then use solution 1) or 3) to minimize performance degradation.
c. If the ScreenOS version is below version 5.4, then use solution 1) or 3).
 
Solution 3
--------------
Create a DIP pool . the ingress interface and this will allow the Juniper firewall to respond to ARP.  In this example, the DIP pool consists of .e address, the NAT-Dst IP address. The DIP pool .ly needs to be created, but not used in a policy. 
 
For this example, when the following command is set . 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

 
Purpose:
Configuration