archive.today webpage capture | Saved from | ||
| Original | no other snapshots from this url | ||
| All snapshots | from host archive.org from host kb.juniper.net | ||
| WebpageScreenshot | |||
 share download .zip report bug or abuse Buy me a coffee | |||
short link
long link
markdown
html code
wiki code
Can You Chip In?
Please don't scroll past this—the Wayback Machine is fighting for universal access to quality information. The Internet Archive, which runs this project, relies on online donations averaging $15.27 to help us keep the record straight. We'd be deeply grateful if you'd join the one in a thousand users that support us financially.
We understand that not everyone can donate right now, but if you can afford to contribute this Friday, we promise it will be put to good use. Our resources are crucial for knowledge lovers everywhere—so if you find all these bits and bytes useful, please pitch in.
Please don't scroll past this—the Wayback Machine is fighting for universal access to quality information. The Internet Archive, which runs this project, relies on online donations averaging $15.27 to help us keep the record straight. We'd be deeply grateful if you'd join the one in a thousand users that support us financially.
We understand that not everyone can donate right now, but if you can afford to contribute this Friday, we promise it will be put to good use. Our resources are crucial for knowledge lovers everywhere—so if you find all these bits and bytes useful, please pitch in.
Can You Chip In? Please don't scroll past this. The nonprofit which runs this project relies on online donations averaging $15.27. If you find our archive useful, please pitch in.
COLLECTED BY
Organization: Alexa Crawls
Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
Collection: Alexa Crawls
Starting in 1996, Alexa Internet has been donating their crawl data to the Internet Archive. Flowing in every day, these data are added to the Wayback Machine after an embargo period.
TIMESTAMPS
The Wayback Machine - https://web.archive.org/web/20111111024458/http://kb.juniper.net:80/InfoCenter/index?page=content&id=KB10174
Knowledge Base
NAT-Dst configuration with NAT-Dst IP on same subnet as ingress interface isn't working
|
|
||||||||
[KB10174] Show KB Properties
[KB10174] Hide KB Properties
Summary:
Problem or Goal:
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.
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:
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: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 ServerIn 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.
There are different solutions to this problem. Choose one:
Note: In addition to one of the above solutions, an intra-zone policy is required to trigger the Destination Translation:
The solutions are explained further below:
Solution Option 1
Solution Option 2
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).
Purpose:- Create static ARP entries on upstream devices
OR - Enable hidden ScreenOS command '
set arp nat-dst'
OR - 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:
- The command '
set arp nat-dst' does not work in a VSYS environment. Therefore, for VSYS environments use Solution 1) or 3).- If more than a few hundred intrazone policies exist, then use solution 1) or 3) to minimize performance degradation.
- 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
Configuration
Related Links: ASK THE KB
Question or KB ID:RELATED TOPICS
Copyright© 1999-2010 Juniper Networks, Inc.