http://www.juniper.net/techpubs/en_US/screenos6.3.

0/information-products/pathway-
pages/screenos/index.html

To configure your Juniper Firewall for a route based LAN to LAN VPN when both sides have static IPs using
pre-shared keys, perform the following steps:

 Configure Juniper Firewall Site A. For more information, go to Configuring Your Juniper Firewall Site A for a
Route Based LAN to LAN VPN When Both Sides Have Static IPs Using Pre-shared Keys.

 Configure Juniper Firewall Site B. For more information, go to Configuring Your Juniper Firewall Site B for a
Route Based LAN to LAN VPN When Both Sides Have Static IPs Using Pre-shared Keys. 
PURPOSE:

SUMMARY:
Route Based VPN - Both Sides have Static IPs using Pre-shared Keys (SSG/ISG/NS)
PROBLEM OR GOAL:

SOLUTION:
This example assumes that the pre-shared secret used is netscreen.
Below shows the settings and proposals that we will use:

NetScreen Site A
 Untrust IP of device 1.1.1.1
 Trust Network 10.1.1.0/24
 Phase 1 Proposal pre-g2-3des-sha
 Phase 2 Proposal g2-esp-3des-sha
NetScreen Site B
 Untrust IP of device 2.2.2.1
 Trust Network 172.16.10.0/24
 Phase 1 Proposal pre-g2-3des-sha
 Phase 2 Proposal g2-esp-3des-sha

++++++++++++++++++++++++++++++++++

SOLUTION:
To configure your Juniper Firewall Site A for a Route Based LAN to LAN VPN when both sides have static IPs
using Pre-shared Keys, perform the following steps:

 Open the WebUI. For more information on accessing the WebUI, go to Accessing Your NetScreen, SSG, or
ISG Firewall Using the WebUI 

 From the Juniper firewall menu, click Network, and then click Interfaces.

 Click New.

 From the Tunnel Interface Name text box, enter a tunnel name.

 For this example, we have entered 1.

 From the Zone drop-down menu, click to choose a Zone.

 For this example, we have selected Untrust (trust-vr).

 Click to select Unnumbered. From the Interface drop-down menu, click to choose an Interface.

 For this example, we have selected ethernet (trust-vr).

 Click OK.

 From the Juniper firewall menu, click VPNs, select AutoKey Advanced, and then click Gateway.

 Click New.
 From the Gateway Name text box, enter a Gateway Name.

 For this example, we have entered Site B GW.

 From Security Level, click to select Custom.

 From Remote Gateway Type, click to select Static IP Address, and enter an IP Address/Hostname.

 For this example, we have entered 2.2.2.1.

 From the Preshared Key text box, enter a Preshared Key.

 The pre-shared keys on Juniper firewall device A and Juniper firewall device B must be identical.
 From the Outgoing Interface drop-down menu, click to choose an Outgoing Interface. Click Advanced.

 For this example, we have selected ethernet3.

 From the Phase 1 Proposal drop-down menu, click to choose a Phase 1 Proposal.

 For this example, we have selected pre-g2-3des-sha.

 Click to select Mode (Initiator). Click Return.

 Click OK.

 From the Juniper firewall options menu, click VPNs, and then click AutoKey IKE.

 Click New.

 From the VPN Name text box, enter a VPN Name. From Security Level, click to select Custom.

 For this example, we have entered Site B VPN.

  From Remote Gateway, click to select Predefined. From the Remote Gateway drop-down menu, click to
selectSite B GW.

 Click Advanced.

 From the Phase 2 Proposal drop-down menu, click to choose a Phase 2 Proposal.

 For this example, we have selected g2-esp-3des-sha.

  From Bind to, click to select Tunnel Interface. From the Tunnel Interface drop-down menu, click to
selecttunnel.1.

 Click to select Proxy-lD. In the Local IP/Netmask text box, enter a Local IP/Netmask, and then in
the Remote IP/Netmask text box, enter a Remote IP/Netmask.

 For this example, we have entered 10.1.1.0/24 for our Local IP/Netmask and 172.16.10.0/24 for the Remote
IP/Netmask.
 From the Service drop-down menu, click to select ANY. Click Return.

 Click OK.

 From the Juniper firewall menu, click Policies.

 In the From drop-down menu, click to select Trust. From the To drop-down menu, click to select Untrust.

 Click New.

 From Source Address, click to select New Address, and enter a New Address.

 For this example, we have entered 10.1.1.0/24.

 From Destination Address, click to select New Address, and enter a New Address.

 For this example, we have entered 172.16.10.0/24.

 In the Service drop-down menu, click to select ANY. From the Action drop-down menu, click to select Permit.

 Click to select Position at Top.

 Click OK.
 From the Juniper firewall menu, click Policies.

 In the From drop-down menu, click to select Untrust. From the To drop-down menu, click to select Trust.

 Click New.

 From Source Address, click to select New Address, and then enter a New Address.

For this example, we have entered 172.16.10.0/24.

 From Destination Address, click to select New Address, and then enter a New Address.

 For this example, we have entered 10.1.1.0/24.

In the Service drop-down menu, click to select ANY. From the Action drop-down menu, click to select Permit.

Click to select Position at Top.

Click OK.
 From the Juniper firewall menu, click Network, select Routing, and then, for 5.2 and below, click Routing
Table;  for 5.3 and above, click Destination.

Click New.

From Virtual Router Name, in the Network Address/Netmask text boxes, enter a Network

Address/Netmask.

 For this example, we have entered 172.16.10.0/255.255.255.0.

 Click to select Gateway. From the Interface drop-down menu, click to select tunnel.1.

Click OK.

To configure the  Route based Site to Site VPN via the CLI, you need to configure the following:
Creating the Gateway:
set ike gateway "Site B GW" address 2.2.2.1 Main outgoing-interface
"ethernet2/4" preshare "3U3SaGSzNyJsLCsZdvCn0/34kLnby3ac/Q==" proposal "pre-
g2-3des-sha"
Creating the AutoKey IKE:
set vpn "Site B VPN" gateway "Site B GW" no-replay tunnel idletime 0 proposal
"g2-esp-des-sha"
set vpn "Site B VPN" id 0x1 bind interface tunnel.1
set vpn "Site B VPN" proxy-id local-ip 10.1.1.0/24 remote-ip 172.16.10.0/24
"ANY"
Creating a tunnel route:
set route 172.16.10.0/24 int tunnel.1
Creating The Policies:
set policy id 2 from "Untrust" to "Trust" "172.16.10.0/24" "10.1.1.0/24" "ANY"
permit
set policy id 1 from "Trust" to "Untrust" "10.1.1.0/24" "172.16.10.0/24" "ANY"
permit
PURPOSE:
 Configuration
Implementation
Troubleshooting
RELATED LINKS: 
 [ScreenOS] Configuring a Policy-Based LAN-to-LAN VPN When Both Sides Have Static IPs Using Pre-
shared Keys

+++++++++++++++++++

ScreenOS] Configuring Your Juniper Firewall Site B for a Route Based

LAN to LAN VPN When Both Sides Have Static IPs Using Pre-shared
Keys

 [KB4143] Show KB Properties

SUMMARY:
Configuring Your Juniper Firewall Site B for a Route Based LAN to LAN VPN When Both Sides Have Static IPs Using
Pre-shared Keys
PROBLEM OR GOAL:

CAUSE:

SOLUTION:
To configure your Juniper Firewall Site B for a Route Based LAN to LAN VPN when both sides have static IPs
using Pre-shared Keys, perform the following steps:

 Open the WebUI. For more information on accessing the WebUI, go to Accessing Your NetScreen, SSG, or
ISG Firewall Using the WebUI 

 From the Juniper firewall menu, click Network, and then click Interfaces.

 Click New.
 From the Tunnel Interface Name text box, enter a tunnel name.

 For this example, we have entered 2.

 From the Zone drop-down menu, click to select a Zone.

 For this example, we have selected Untrust (trust-vr).

 Click to select Unnumbered. From the Interface drop-down menu, click to select an Interface.

 For this example, we have selected ethernet (trust-vr).

 Click OK.

 From the Juniper Firewall menu, click VPNs, select AutoKey Advanced, and then click Gateway.

 Click New.
 From the Gateway Name text box, enter a Gateway Name.

 For this example, we have entered Site A GW.

 From Security Level, click to select Custom.

 From Remote Gateway Type, click to select Static IP Address, and then enter an IP Address/Hostname.

 For this example, we have entered 1.1.1.1.

 From the Preshared Key text box, enter a Preshared Key.

 The pre-shared keys on Juniper Firewall device A and Juniper Firewall device B must be identical.
 From the Outgoing Interface drop-down menu, click to choose an Outgoing Interface. Click Advanced.

 For this example, we have selected ethernet3.

 From the Phase 1 Proposal drop-down menu, click to choose a Phase 1 Proposal.

 For this example, we have selected pre-g2-3des-sha.

 Click to select Mode (Initiator). Click Return.

 Click OK.

 From the Juniper Firewall menu, click VPNs, and then click AutoKey IKE.

 Click New.

 From the VPN Name text box, enter a VPN Name. From Security Level, click to select Custom.

 For this example, we have entered Site A VPN.

  From Remote Gateway, click to select Predefined. From the Remote Gateway drop-down menu, click to
selectSite A GW.

Click Advanced.

 From the Phase 2 Proposal drop-down menu, click to choose a Phase 2 Proposal.

 For this example, we have selected g2-esp-3des-sha.

  From Bind to, click to select Tunnel Interface. From the Tunnel Interface drop-down menu, click to
selecttunnel.2.

 Click to select Proxy-lD. In the Local IP/Netmask text box, enter a Local IP/Netmask, and then in
the Remote IP/Netmask text box, enter a Remote IP/Netmask.

 For this example, we have entered 172.16.10.0/24 for the Local IP/Netmask and 10.1.1.0/24 for the Remote
IP/Netmask.
 From the Service drop-down menu, click to select ANY. Click Return.

 Click OK.

 From the Juniper Firewall menu, click Policies.

 In the From drop-down menu, click to select Trust. From the To drop-down menu, click to select Untrust.

 Click New.

 From Source Address, click to select New Address, and then enter a New Address.

 For this example, we have entered 172.16.10.0/24.

 From Destination Address, click to select New Address, and then enter a New Address.

 For this example, we have entered 10.1.1.0/24.

 In the Service drop-down menu, click to select ANY. From the Action drop-down menu, click to select Permit.

 Click to select Position at Top.

 Click OK.
 From the Juniper Firewall menu, click Policies.

 In the From drop-down menu, click to select Untrust. From the To drop-down menu, click to select Trust.

 Click New.

 From Source Address, click to select New Address, and then enter a New Address.

For this example, we have entered 10.1.1.0/24.

  From Destination Address, click to select New Address, and then enter a New Address.

 For this example, we have entered 172.16.10.0/24

. In the Service drop-down menu, click to select ANY. From the Action drop-down menu, click to select Permit.

Click to select Position at Top.

Click OK.
 From the Juniper Firewall menu, click Network, select Routing, and then, for 5.2 and below, click Routing
Table;  for 5.3 and above, click Destination.

Click New.

From Virtual Router Name, in the Network Address/Netmask text boxes, enter a Network

Address/Netmask.

 For this example, we have entered 10.1.1.0/255.255.255.0.

 Click to select Gateway. From the Interface drop-down menu, click to select tunnel.2.

Click OK.

PURPOSE:
Troubleshooting
RELATED LINKS: 
 Configuration and troubleshooting of all types of VPN
http://kb.juniper.net/kb/documents/public/resolution_path/J_FW_VPN_Config_or_Trblsh.htm

++++++++++++++++++++++++++++++++++++++++++++++++++++++

SUMMARY:
This article provides information on how to configure a NetScreen firewall as a DHCP server.
PROBLEM OR GOAL:
How to configure the NetScreen firewall as a DHCP server.
CAUSE:

SOLUTION:
Note: This article is applicable to ScreenOS 5.0 and higher.   
                This article is not applicable to NS500, ISG1000, ISG2000, NS5200, and NS5400.
            DHCP server is not supported on NS500, ISG1000, ISG2000, NS5200, and NS5400.
To configure your NetScreen as a DHCP server, perform the following steps:
 Open the WebUI. For assistance, refer to KB4060 - Accessing Your NetScreen, SSG, or ISG Firewall Using the
WebUI
From the NetScreen options menu, click Network, and then click DHCP.

From Configure, click Edit.

From the DHCP list, click to select DHCP Server.

 From the DHCP server settings menu, enter the values that your NetScreen will assign to DHCP clients:
 Gateway: This address will be used by the DHCP clients as the default gateway.
 Netmask: This is the subnet mask that will be used by the DHCP clients.
 DNS#1: This address will be used as the primary Domain Name Server by the DHCP clients.
 WINS#1: This address will be used as the primary Windows Internet Naming Server by the DHCP clients.
 Click Apply.

 You will now see three additional options.

From the additional options list, click Addresses.

From the DHCP Server Address List page, click New.

From the IP Address Start text box, enter the beginning IP address of the DHCP range, and from the IP Address
Endtext box, enter the ending IP address of the DHCP range.
 Click OK. 

Configuring the DHCP server settings via the CLI:

set interface ethernet2/4 dhcp server service
set interface ethernet2/4 dhcp server enable
set interface ethernet2/4 dhcp server option lease 1440000
set interface ethernet2/4 dhcp server option gateway 192.168.0.1
set interface ethernet2/4 dhcp server option netmask 255.255.255.0
set interface ethernet2/4 dhcp server option dns1 192.168.0.100
set interface ethernet2/4 dhcp server ip 192.168.0.10 to 192.168.0.100
set interface ethernet2/4 dhcp server config next-server-ip
PURPOSE:
Configuration
Implementation
Troubleshooting
RELATED LINKS: 
 [ScreenOS] Can a NetScreen firewall be used as a DHCP server in a DHCP relay environment?

http://kb.juniper.net/InfoCenter/index?page=content&id=KB3390&actp=search

SUMMARY:
This article provides information about the possibility of using a NetScreen firewall as a DHCP server in a DHCP relay
environment.
PROBLEM OR GOAL:
Environment:

 ScreenOS is configured as DHCP Server 

 DHCP Relay Agent is between DHCP client and DHCP server

Symptoms and errors:

 The NetScreen DHCP server drops the DHCP packets that are received from the DHCP relay agent.

 The DHCP client never receives the IP address from the DHCP server.

The following scenario describes the issue:

In the above setup, FW1 is acting as the DHCP Relay Agent and FW2 is acting as the server .When the packet
reaches FW2, it is dropped. 

The following excerpt is the output of snoop detail and debug flow basic on the firewall (FW2) that is acting as the
server:
 245824.0: ethernet0/0(i) len=346:0017cb402500->0010dbd56200/0800
169.254.79.158 -> 192.168.2.1/17
vhl=45, tos=00, id=7741, frag=0000, ttl=63 tlen=332
udp:ports 67->67, len=312
00 10 db d5 62 00 00 17 cb 40 25 00 08 00 45 00 ....b....@%...E.
01 4c 1e 3d 00 00 3f 11 a0 1e a9 fe 4f 9e c0 a8 .L.=..?.....O...
02 01 00 43 00 43 01 38 d9 c9 01 01 06 01 88 4e ...C.C.8.......N
86 c9 04 00 80 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 a9 fe 4f 9e 00 1f 16 f5 bd 66 00 00 00 00 ....O......f....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 63 82 53 63 35 01 01 74 01 01 ......c.Sc5..t..
3d 07 01 00 1f 16 f5 bd 66 32 04 a9 fe 4f 9e 0c =.......f2...O..
0d 50 55 4e 53 45 5a 31 38 33 37 38 31 44 3c 08 .PUNSEZ183781D<.
4d 53 46 54 20 35 2e 30 37 0b 01 0f 03 06 2c 2e MSFT.5.07.....,.
2f 1f 21 f9 2b 2b 02 dc 00 ff /.!.++.... 

****** 245824.0: <Untrust/ethernet0/0> packet received [332]******

ipid = 7741(1e3d), @2d41e910
packet passed sanity check.
flow_decap_vector IPv4 process
ethernet0/0:169.254.79.158/67->192.168.2.1/67,17<Root>
no session found
flow_first_sanity_check: in <ethernet0/0>, out <N/A>
self check, not for us
chose interface ethernet0/0 as incoming nat if.
packet dropped, packet dropped: for self but not interested
CAUSE:
 When the DHCP request is generated from the host, the source port is initially 68; but when it crosses FW1
(Relay Agent), the source port is changed to 67.

 The firewall that is acting as the DHCP server drops the packet, as it sees the packet coming from
the 67 source port.
SOLUTION:
Currently, the architecture of ScreenOS does not allow NetScreen to be used as a DHCP server in a DHCP relay
environment, as it drops the DHCP request, which is coming from port 67. NetScreen can function as a DHCP relay
agent in this type of environment.   
PURPOSE:
Configuration
Implementation
Troubleshooting
Dynamic Host Configuration Protocol automatizează alocarea parametrilor de rețea la
dispozitive de către unul sau mai multe fault-tolerant servere DHCP. Chiar și în rețele mici,
DHCP este folositor, deoarece simplifica adăugarea unor noi echipamente în rețea.

Când un client configurat (un computer sau orice alt dispozitiv de rețea) se conectează la rețea,
clientul DHCP trimite o broadcast interogare în ce privește informația necesară la serverul DHCP.
Serverul DHCP gestionează o rezervă de adrese IP și informații despre configurarea parametrilor
clientului, ca gateway-ul implicit, numele domeniului, serverul DNS, alte servere ca serverul de timp,
ș.a.m.d. La primirea unei cereri valide, serverul atribuie calculatorului o adresă de IP, un contract de
leasing (perioada de validitate a alocării respective), precum și alți parametri de configurare de IP,
cum ar fi masca de subrețea și gateway-ul implicit . Interogarea este de obicei inițiată imediat
după boot, și trebuie să fie completată, înainte ca clientul să poată iniția comunicarea IP cu alte
gazde.

Funcție de implementare, serverul DHCP poate avea trei metode de alocare a adreselor IP:

 alocare dinamică: Un administrator de rețea atribuie o serie de adrese IP la DHCP, și fiecare

computer din LAN este configurat să ceară o adresa de IP de la serverul DHCP în timpul
inițializării de rețea. Procesul de cerere și aprobare folosește un concept ca un contract de
leasing pe o perioada determinată, permițând serverului DHCP să revendice (și să realoce)
adrese IP disponibile (refolosirea dinamică de adrese de IP).
 alocare automată: Serverul DHCP alocă în permanență o adresă de IP disponibilă, din gama
definită de administrator, către un client. Acest proces este asemănător alocării dinamice, dar
serverul DHCP păstrează un tabel cu alocările de IP anterioare, astfel încât să poată atribui
preferențial pentru un client aceeași adresă de IP pe care acesta a avut-o anterior.
 alocare statică: Serverul DHCP alocă adresa de IP în baza unui tabel cu perechi adresa
MAC/adresa IP, acestea fiind completate manual (probabil de către administratorul rețelei).
Numai clienții care au adresa MAC lisată în acest tabel vor primi o adresă de IP. Această
caracteristică (care nu e suportată de orice router) este denumită Static DHCP
Assignment (by DD-WRT), fixed-address (by the dhcpd documentation), DHCP
reservation or Static DHCP (by Cisco/Linksys), și IP reservation sau MAC/IP binding (de către
diverși alți producători de routere).
Închirierea adreselor DHCP[modificare | modificare sursă]
Închirierea este fundamentală pentru procesul DHCP. Fiecare adresă oferită de un server DHCP are
o perioadă de închiriere asociată, perioadă în care clientul are permisiunea să folosească adresa.
Perioada de închiriere este denumită ”lease time” și poate avea orice valoare, de la câteva minute
 până la câteva luni, ani sau chiar pentru totdeauna. Închirierea pe perioadă nelimitată de timp
transformă adresarea dinamică în adresare statică.

Dacă s-a scurs peste 50% din timpul de închiriere al adresei, clientul trimite serverului care i-a
închiriat adresa, o cerere de prelungire a perioadei de utilizare a adresei (”renew”). Dacă acest client
nu a reușit prelungirea perioadei de închiriere de la serverul de la care a primit inițial închirierea
(”lease-ul”) la scurgerea a 87,5% (7/8) din timp, clientul trimite un ”broadcast packet”, încercând să
închirieze o adresă IP de la orice server existent în rețea. Procesul de închiriere poate fi anulat atât
de client cât și de server înaintea perioadei stabilite inițial. De asemenea, serverul DHCP are
posibilitatea de a trimite mesaje clienților obligându-i să înnoiască contractul de închiriere înainte de
terminarea lui.

Confirmarea cererilor DHCP[modificare | modificare sursă]

Când serverul DHCP primește mesajul DHCPREQUEST de la client, procesele de configurare intră
în faza finală. Faza de confirmare presupune trimiterea unui pachet DHCPACK clientului. Acest
pachet include durata contractului de leasing, precum și orice alte informații de configurare pe care
clientul le-ar putea fi solicitat. În acest moment, procesul de configurare IP este finalizat.

Protocolul așteaptă ca clientul DHCP să-și configureze interfața de rețea cu parametri negociați.

++++++

SUMMARY:
This article provides information on how to configure the DHCP server on a NS or SSG device for a Pre-boot
Execution Environment.
PROBLEM OR GOAL:
 Configuring DHCP server on a ScreenOS device with an option for Pre-boot Execution Environment.

 PXE means to boot computers using a network interface independently of data storage devices (such as
HDD) or installed OS.

 This method is mostly used for installing the OS on a computer, without using a CD/DVD drive. The image of
the OS is stored on a TFTP server.

CAUSE:

SOLUTION:
1. Select DHCP from Network > DHCP:
2. Select the interface on which you want to create the DHCP server and click Edit:

3. From the available options, select DHCP Server. Type the relevant information in the required fields, such
asLease, Gateway, Netmask, DNS# 1, and so on. You can also add a domain name and more DNS servers
inAdvanced options.

4. Click Addresses to add an address range, from which IPs will be assigned to hosts:

Add a range of addresses. Ensure that IPs assigned to the default gateway, firewall, TFTP server, and son are not
included in this range; else it might create conflict.

A normal DHCP server is now configured. To add options for PXE, proceed to step 5.

5. Go to Custom Options:

Here you can add any number of options to be sent with DHCP. For details of each option refer to RFC2132.
6. Four commonly used options for PXE are:

a. 43 – Vendor Specific Identifier: This option is a long hex value and has to be specifically calculated;
as it is vendor specific and then configured.

b. 60 – Vendor Specific Information: This option is entered as a string:

c. 66 – TFTP server IP: This is the IP of the server hosting OS image:

d. 67 – Bootfile name: This is the name of the file (along with path, if file is in a directory) on the TFTP
server. Ensure when providing the path, to type double back-slash (“\\”); as a single back-slash is an escape
character. '\\'will be interpreted as a single '\'

7. Return to the Edit interface of the DHCP list:

8. Check if the Next Server IP option is set to From Option66:

9. Click Apply and Exit.

Via the CLI:

set interface "ethernet0/4" dhcp server service
set interface "ethernet0/4" dhcp server config updatable
set interface "ethernet0/4" dhcp server option gateway 172.27.199.1
set interface "ethernet0/4" dhcp server option netmask 255.255.255.0
set interface "ethernet0/4" dhcp server option dns14.2.2.2
set interface "ethernet0/4" dhcp server option lease 1440000
set interface "ethernet0/4" dhcp server enable
set interface ethernet0/4 dhcp server ip 172.27.199.11 to 172.27.199.100
set interface ethernet0/4 dhcp server option custom60 String PXEClient
set interface ethernet0/4 dhcp server option custom66 IP 172.27.199.7
set interface ethernet0/4 dhcp server option custom67 String
bstrap\\x86\\bstrap.0
set interface "ethernet0/4" dhcp server config next-server-ip option66
save
PURPOSE:
Configuration
Troubleshooting
RELATED LINKS: 
 RFC2132 : DHCP Options and BOOTP Vendor Extensions
 ScreenOS] Configure DNS Proxy in the Juniper firewall

 [KB20555] Show KB Properties

SUMMARY:
How to configure DNS Proxy in the Juniper firewall.
PROBLEM OR GOAL:

Environment:

 DNS server IP address configured on the ScreenOS firewall

 Client PC's points its DNS server at the firewall
 Debug the traffic to see how it is being forwarded

Symptoms & Errors:

 Configure local PCs to use the ScreenOS firewall as its DNS server
 Use the ScreenOS firewall as DNS proxy
SOLUTION:
When the ScreenOS firewall is configured as DNS-Proxy, it redirects the DNS queries to the DNS servers configured
on the ScreenOS firewall.

Configuration on Firewall:

PC--------(eth0/0)Firewall(eth0/2)----------Internet

DNS Lookup:

Firewall is configured as a DNSproxy. For that we need to enable “DNS proxy “feature on the trust interface of the
firewall.
set interface eth0/0 zone trust
set interface eth0/0 ip 10.10.10.1/24
set interface eth0/2 zone untrust
set interface eth0/2 ip 20.20.20.1/24
set dns proxy
set dns proxy enable
set dns server-select domain * outgoing-interface ethernet0/2 primary-server
4.2.2.2 secondary-server 4.1.1.1 failover
set interface eth0/0 proxy dns
set policy id 5 from "Trust" to "Untrust" "Any-IPv4" "Any-IPv4" "DNS" permit
Domain *----you can specify the domain name in the firewall for which you want the firewall to send the query to the
specific dns server. Here “*” symbolizes all entries.

Verifying the setup:

Check the policy logs of the firewall to see if the DNS packets are being sent out. Debug DNS proxy will also show
the firewall proxying the DNS queries.
## 2010-01-26 16:11:02 : Proxy: Processing request from client 192.168.23.2
port 62625
## 2010-01-26 16:11:02 : Proxy: Host name for lookup is www.bluecoat.com type
28
 ## 2010-01-26 16:11:02 : Proxy: Looking up best match
## 2010-01-26 16:11:02 : Proxy: New best match len id 1
## 2010-01-26 16:11:02 : Proxy: Selecting primary
## 2010-01-26 16:11:02 : Proxy: DNS socket send returned 0 for server
195.50.140.114
## 2010-01-26 16:11:02 : Proxy: new socket being set 444 to server
195.50.140.114
## 2010-01-26 16:11:03 : Proxy: DNS socket receive 112 bytes from server
In case the DNS queries are not getting resolved, check the connectivity with the DNS server configured in the
firewall. Another reason can be latency in reply from the DNS server.

Reverse DNS Lookup

The reverse DNS lookup converts an IP address to host name mainly used to identify the domain name of spammer
sending you a spam email. The DNS proxy shall in turn, depending on the configuration, redirect the DNS queries to
the specific DNS servers. A PTR record (sometimes called a "host PTR record" RFC 1035) is what lets someone do
a "reverse" DNS lookup - that is, they have your IP address and want to know what your host/domain is.

Reverse DNS lookup will not happen when the ScreenOS Firewall is acting as a DNS Proxy. It is not supported.

PURPOSE:
Configuration
Troubleshooting
RELATED LINKS: 
 Please follow the below KB which states PTR record lookup fails when the Juniper firewall is configured as
DNS Proxy.

Pot să știu dacă pentru zona Untrust, care modul de interfață i ar trebui să meargă? Care este
impactul și scopului între modul NAT și Route pe interfața?

Mesajul 1 din 2 (2862 vizualizări)

Dacă interfața infiltrării este în modul NAT:

adresă de rețea și de traducere portul (NAPT) se realizează în mod implicit, atunci când dipozitive de la
Trust zona Untrust. Sursa adresa IP este tradus la adresa IP egress. Interfețe legate la zona Trust sunt în
modul NAT implicit.

Dacă interfața infiltrării se află în modul Traseu:

Nicio adresă de traducere se efectuează în mod implicit. NAT poate fi realizată printr-o politică. Interfețe
legate la orice zonă, cu excepția Trust sunt în modul de rută în mod implicit.

În cazul în care cerința dvs. este de a NAT tot traficul de la Trust Untrust atunci puteți plasa interfața
încredere în modul NAT și de trafic se va traduce la interfata adresa IP Untrust automat.

Cu toate acestea, în cazul în care cerința NAT în cazul în care mai complexe, atunci plasarea interfețelor
în modul de rută și configurarea NAT bazate pe politici printr-o politică oferă mai multă flexibilitate și
control.
Salutare tuturor,

Am SSG-550 cu 6.2 screenos, acest dispozitiv este configurat în modul de traseu cu câteva servere din
spatele ei, fiecare server este în zona de securitate proprie, o au diferite id vlan.

Acum trebuie să mă mut o subrețea din spatele SSG-550, dar această subrețea este deja în modul nat,
iar eu nu pot schimba.

Este posibil să-l facă?

Dacă da, care este cel mai bun mod de a face acest lucru?

Aveți posibilitatea să modificați allways NAT sau modul de rută la nivel de interfață. Set int <Ethernet0 /
x traseu ar trebui să-l facă!

Oricum ar fi: sfatul meu ca utilizator experimentat si instructor pe ScreenOS: Allways a pus fiecare
interfață în router-mode și de a face nating în politica. Este atât de mult mai clar ce se întâmplă cu
natting în acest fel!

descriu mai detaliat situația mea.

Zona untrust (IP 1.1.1.1/29) <> încredere zone1 2.2.2.0/28, încredere 3.3.3.0/28 zona 2, încredere, etc ...
zone3 4.4.4.0/27

noua mea subrețea au ext 5.5.5.0/28 și int 172.16.16.0/24 există aproximativ 500 de site-uri web și
toate conexiunile la serverele de baze de date se conectează internaly - thats de ce nu pot schimba IP
addreses pentru servere.

Eu pot crea zone5 încredere cu IP 5.5.5.0/28, dar ceea ce este cel mai bun mod de NAT?

Știu cum să creați VIP, MIP, DIP, dar așa cum am înțeles că nu este modul cum se face în acest caz.

Nu am nici o experiență cu politica de nat, dar dacă îi ajută să-l pot învăța.