Gdnw Jncis-fwv Study Guide

(1)

Page | 1

NETSCREEN JNCIS -FWV STU DY GUIDE

A U T H O R : G A R N E T N E W T O N - W A D E

(2)

Page | 2

INTRODUCTION

The Juniper Networks Technical Certification Program (JNTCP) Firewall/VPN certification track is a two-tiered program that allows participants to demonstrate competence with Juniper Networks Firewall with VPN products and the ScreenOS software. The "FWV, Specialist (JNCIS -FWV)", also known as JN0-532 exam is designed for networking professionals with advanced knowledge of, and experience with, Juniper Firewall/VPN products and ScreenOS software. The exam tests for a wider and deeper level of knowledge than does the JNCIA-FWV exam and focuses on advanced configuration and troubleshooting of NetScreen firewall Appliances and Systems.

The JNCIS-FWV certification is valid for two years. Recertification is achieved by passing the current version of the JNCIS-FWV exams and exam topics include:

 VPNs

 Network Management,

 Troubleshooting with Debug & Snoop

 Traffic Management

 Virtual Systems

 NSRP

 Dynamic Routing/Routing over VPNs

 Attack Prevention, Multicast

This study guide attempts to provide the necessary theoretical and practical training to obtain the JNCIS-FWV certification.

(8)

Page | 8

JUNIPER FIREWALL PRODUCT DETAILS

Product Lines and Purpose:

Data Center NetScreen-5200 NetScreen-5400 Campus NetScreen-5200 NetScreen-5400 SOHO SSG5 SSG20 SSG140 SSG320M SSG350M SSG520M SSG550M

SSG 5

The SSG-5 entry level firewall in the series a SOHO, or branch office firewall. It has 7 Ethernet interfaces. 1 WAN interface, 1 DMZ interface, and 5 bgroup or "trust" interfaces. It supports up to 8000 sessions and 16,000 with an extended license key and is available with 128MB or 256MB or memory and there is also a wireless model. Deep inspection and spam filtering is optional but requires a license and 256MB or memory. Total firewall throughput is around 90 Mbps conservatively and 40 Mbps for VPN traffic. Other options include an AUX interface for a serial connection, an ISDN port, or V.92 modem.

High availability (HA) pairs can be configured in active/active or active/passive modes by providing correct licensing. A rack mount shelf is available that allows 2 SSG-5 firewalls mounted side by side to occupy 1U of rack space.

(9)

Page | 9

SSG 20

The SSG 20 has 2 less interfaces but this device has the same performance numbers and two "mini-PIM" slots allowing for modular installation of ADSL, T1, ISDN, or serial interfaces. The mini-PIM cards are expensive and this device also comes in a wireless model. Personally, I have never seen an SSG20 in use. I doubt Juniper sold many of these as they just didn't have enough features to seem a step above the SSG 5.

SSG 140

The replacement for the NetScreen 25/50 and contains a total of 10 interfaces (8 10/100 ports and 2 10/100/1000 ports). Conservative throughput is 300 Mbps with 100 Mbps for VPN traffic. Total concurrent sessions is 48,000 and the SSG 140 also has (4) rear PIM slots. These are different from the mini-PIM slots used in the other models, but provide the same

functionality. The SSG 140 is well-suited for small data centres and medium-sized corporate offices.

SSG 320M

The M suffix stands for modular and these models have front PIM slots allowing the addition of both WAN and LAN interfaces. The SSG 320 is a 1U modular chassis which provides the ability

(10)

Page | 10

to add up to 3 cards to the PIM slots. These can be WAN or LAN interface or a mix of the two. The SSG 320 can be "upgraded" to JunOS e.g. it can be transformed into a J-series router. Conservative throughput is 400 Mbps with 175 Mbps for VPN traffic. Total concurrent sessions are listed at 64,000. The SSG 320 is comparable to the NetScreen 100 series without the

modular chassis.

SSG 520M

The SSG 520 is a 3U modular chassis with a total of 6 PIM slots; 4 PIM and 2 ePIM. The ePIM slots are enhanced slots and will accommodate copper or SFP gigabit ports. Conservative throughput is 600 Mbps with 300 Mbps for VPN traffic and a total concurrent sessions limit of 128,000. The 520 model has redundant power supplies.

SSG 550M

The 550 model is identical to the 520 although conservative throughput of 1000 Mbps with 600 Mbps for VPN traffic and total concurrent sessions limit of 256,000 and also has redundant power supplies. The SSG 520 and 550 are capable of doing spam filtering, deep inspection (DI), and configuration with another device as an HA pair.

NETSCREEN-5200/5400

The Juniper Networks NetScreen-5000 series is a line of purpose-built, high-performance firewall/VPN security systems designed to deliver high-performance capabilities for large enterprise, carrier, and data centre networks. The NetScreen-5000 series consists of two products: the 2-slot NetScreen-5200 system and the 4-slot NetScreen-5400 system.

NetScreen-5000 security systems integrate firewall, VPN, DoS and DDoS protection, and traffic-management functionality, in a low-profile modular chassis. Built around Juniper's

(11)

third-Page | 11

generation security ASIC and distributed system architecture, the NetScreen-5000 series offers scalability and flexibility provides a high level security system through NetScreen ScreenOS custom operating system.

Both products employ a switch fabric for data exchange and separate multibus channel for control information, delivering scalable performance for the most demanding environments. Specifications

Features/Functionality

NetScreen-5200

NetScreen-5400

Number of Interfaces

2 XFE 10GigE, or 8 Mini-GBIC,

or 2 Mini-GBIC + 24 10/100

6 XFE 10GigE, or 24 Mini-GBIC,

or 6 Mini-GBIC + 72 10/100

Maximum Number of IP

Addresses in Trusted Interfaces

Unrestricted

Maximum Throughput

10G FW

5G 3DES/AES VPN

30G FW

15G 3DES/AES VPN

Maximum Number of Sessions

1,000,000

Maximum Number of VPN

Tunnels

25,000

Maximum Number of Policies

40,000

Maximum Number of Virtual

Systems

0 default, up to 500 additional

Maximum Number of Virtual

LANs

4000

Maximum Number of Security

Zones

16 default, up to 1000 additional 16 default, up to 1000 additional

Maximum Number of Virtual

Routers

3 default, up to 500 additional

Routing Protocols Supported

OSPF, BGP, RIPv1/v2

High-Availability Modes

Supported

Active/Passive

Active/Active

Active/Active Full Mesh

Active/Passive

Active/Active

Active/Active Full Mesh

IPS (Deep Inspection FW)

Yes

Integrated / Redirect Web

(12)

Page | 12

EXAM INFORMATION

The exam is structured around:

• 75 multiple choice questions • 90 minutes completion time • Passing grade: 80%

• Prerequisite certification: none

• Written exam administered at Prometric testing centres worldwide

All questions relating to configuration examples and command syntax are based around the Command Line Interface (CLI). There are no questions, or multiple choice answers based on the Web User Interface (WebUI).

The exam is based on the ScreenOS version 6.0.x firmware.

Additional resources are available to supplement this guide and help in your studies:

Concepts & Examples Guide documentation (free and enough to pass) - Determine which features are applicable to you use the sample concepts and examples in these guides

(13)

Page | 13

CURRENT EXAM OBJECTIVES

This list is intended to provide a general view of the skill set required to successfully complete the specified certification exam. Topics listed are subject to change.

VPNs

Network Management

Troubleshooting with Debug & Snoop Traffic Management

Virtual Systems NSRP

Dynamic Routing/Routing over VPNs Attack Prevention

Multicast VPNs

Identify IKE Phase 1/Phase2 negotiation sequence and proposals

Identify/differentiate IPSec standard elements (encapsulations, SA, SPI, etc.) List steps for policy-based/route-based VPN configuration

Relate proxy-ID to VPN setup

Identify proper configuration for various hub/spoke configurations (policy, int. placement, etc.)

Identify NHTB requirements/configurations Configure/verify AC-VPNs

Identify PKI components (certificates, CDL, etc.) List steps for PKI implementation w/ VPNs VPN Variations

Configure Dynamic Peer VPNs Configure Transparent mode VPNs Configure Overlapping Networks

Describe GRE applications/Configure GRE Network Management

Configure local management (SSL, SSH, management restrictions). Interpret internal counters and logs.

Configure SYSLOG. Discuss logging levels. Configure SNMP.

Troubleshooting with Debug/Snoop Enable debug/snoop.

Set debug filters. Set snoop filters.

Use get commands to validates/troubleshoot routing and policies. Use debug output to identify routing and policy problems.

Use get commands to validate/troubleshoot address translation. Use debug output to identify problems

(14)

Page | 14

Traffic Management

Describe the bandwidth allocation process. Describe queuing functionality.

List requirements/steps for configuring traffic management Virtual Systems

Define VSYS applications

Describe root vs. VSYS administration

Explain VSYS vs. root assignment of routes/NAT pools/etc. Configure interface-based VSYS

Configure inter-VSYS communications, including NAT. Use show/debug output to identify VSYS usage. Configure VSYS resource allocation

NSRP

Distinguish active/passive and active/active.

Describe NSRP operations (HA link, session sync, master election, etc.) Configure active/passive and active/active NSRP.

Validate NSRP operations.

Adjust operations (secondary link, failover settings). Configure redundant interface.

Dynamic Routing/Routing over VPNs Configure RIP over VPNs

Configure OSPF over VPNs Configure/verify OSPF routing Configure OSPF options Configure/verify BGP

Configure redistribution/filters/route maps Configure static routes incl. floating static routes Configure/verify source routing

Configure/verify policy routing Attack Prevention

Describe SCREEN functions

Describe/configure Deep Inspection Describe/configure anti-virus functionality Configure web filtering

Multicast

Configure/verify IGMP Configure/verify PIM-SM

(15)

Page | 15

FIREWALL/VPN SYSTEMS

Juniper Networks’ security platform is the NetScreen firewall product line and provides integrated firewall and Internet Protocol Security (IPSec) VPN solutions in a single box. The firewall is based on the tried and trusted stateful inspection technology. It provides a

connection-oriented security model by verifying the validity of every connection within high-performance architecture. The firewall hardware is based on a custom-built architecture consisting of application-specific integrated circuit (ASIC) technology which performs at a higher performance level than a general-purpose processor and connects over a high-speed bus fabric to the core processor of the firewall unit. This is a reduced instruction set computer (RISC) CPU.

1. The Juniper firewall appliance is Juniper’s firewall/VPN solution.

2. The NetScreen IDP product protects against network attacks and can alert, log events, and capture attacks as they occur. It can also prevent against worms, viruses, and Trojans.

3. The SSL VPN (NetScreen Secure Access SSL VPN) allows for clientless access into your network.

4. The UAC product provides network access control to client systems. You can use the firewalls to provide enforcement or you can also use switches that are 802.1x compatible to provide access management to clients as well.

ScreenOS software is used on the SSG range and was used to power the earlier NetScreens; version 6 was designed to run specifically on the SSG range. However, Juniper has recently released version 6 for the NetScreen 5GT which is the only model of the older series to get a version 6 release.

Screen OS can be managed in three ways:

Command-Line Interface (CLI) The CLI provides granular control over the firewall operating system through straightforward interaction with ScreenOS

Web User Interface (WebUI) A Web-based application with a user-friendly interface allowing management of the NetScreen appliance

NetScreen Security Manager (NSM) A centralised enterprise-class solution that allows

management off the entire NetScreen firewall infrastructure. The NSM also consolidates logging and reporting.

The web interface allows admins to do 90-95% of tasks through an easy to use web GUI but the CLI is the preferred method. There are a total of 7 models in the SSG series. Two of them offer a wireless option. The following information provides an overview each model.

(16)

Page | 16

VIRTUAL PRIVATE NETWORK

Definition: A Virtual Private Network (VPN) allows two sites to communicate securely over an insecure medium such as the Internet.

NetScreen firewalls support the IPSec protocol standard for site-to-site and client-to-site VPN connections. There are two types of tunnel negotiation methods, Manual Key and AutoKey. In a Manual Key IPSec VPN all Security Association (SA) parameters are predefined so the authentication and security properties of the tunnel are already set. Therefore it is possible for one device to simply encrypt the traffic and forward it to the other device. When a Firewall/VPN is required to establish many tunnels the Manual Key method becomes labour intensive and is inherently less secure because parties on both ends of the VPN need to agree and share the SA parameters.

NOTE: A Security Association is a unidirectional agreement between both VPN end points

regarding the methods and parameters to use in order to secure the communication channel.

AutoKey IKE IPSec VPN automates most of the negotiation process and can be divided into two distinct phases.

• Phase 1 (IKE phase) negotiates how the VPN tunnel will be authenticated and secured • Phase 2 (IPSec phase) determines how traffic will be secured through the tunnel.

(17)

Page | 17

PHASE 1 PROPOSAL

Phase 1 of an AutoKey IKE tunnel negotiation consists of the exchange of proposals for how to authenticate and secure the channel. The exchange can be in one of two modes: aggressive or main. Using either mode, the participants exchange proposals for acceptable security services. Tunnel

Both end points need to agree on the same proposal for Phase 1 and four possible Phase 1 proposal types are defined:

• Method: indicates a preshared key (“pre”) or digital certificate (using “RSA”-Sig or “DSA”-Sig) used as the authentication method

• DH Group: Indicates the Diffie-Hellman group used for the key generation or exchange (“g1”, “g2” or “g5”)

• Encrypt/Auth: Indicates the encryption algorithm (“3DES”, “DES” or “AES”) and hash algorithm (“MD5” or “SHA-1”) used

Examples of Phase 1 proposals i: • pre-g2-3des-sha1

• pre-g1-des-md5 • dsa-g2-3des-sha1 • rsa-g5-aes128-md5

Once IKE has been used to establish a tunnel to provide a secure channel of communication, IPSec is used to provide a means of securing the actual data that will traverse the tunnel. Key lifetime indicates the life of the key (how often the key should be changed) and can be configured in terms of seconds, minutes hours or days. A Phase 1 tunnel may still be established when both ends use different key lifetimes but when one end decides to change its key the tunnel will fail.

PHASE 2 PROPOSAL

Once the tunnel has been established (Phase 1), the SAs to secure the data to be transmitted through the IPsec tunnel are negotiated (Phase 2).

Proposals are exchanged to determine the security parameters to be used for the SA. Phase 2 proposals also include a security protocol—either Encapsulating Security Payload (ESP) or Authentication Header (AH)—and selected encryption and authentication algorithms. The proposal can also specify a DH group and if Perfect Forward Secrecy (PFS) is desired.

Regardless of the mode used in Phase 1, Phase 2 always operates in quick mode and involves the exchange of three messages. Juniper Networks Firewalls support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a range of tunnel parameters you will accept. ScreenOS also provides a replay protection feature but use of this feature does not require negotiation because packets are always sent with sequence numbers, so you have the option of checking or not checking the sequence numbers.

• PFS: “nopfs” indicates PFS is not used, “g1”, “g2” or “g5” indicates which DH group is being applied.

(18)

Page | 18

• Encapsulation: ESP (“esp”) or AH (“ah”) protocol is being used for encryption and authentication.

• Encryption/Authentication: encryption (“DES”, “3DES” or “AES”) and/or the hash algorithm (“MD5” or “SHA1”) used.

Examples of a Phase 2 proposal: • g2-esp-3des-sha1 • nopfs-esp-des-md5 • g1-ah-null-sha1

IPSEC STANDARD ELEMENTS

Internet Key Exchange (IKE)

The Internet Key Exchange (IKE) protocol a separate protocol and used to automatically generate and negotiate keys and Security Associations. A preshared key or a digital certificate can be used to secure communication between two end points through a VPN tunnel. IKE uses the preshared or public key bound to the certificate to automatically change keys at

predetermined intervals. IKE uses the Diffie-Hellman (DH) key exchange algorithm to allow the secure key exchange. There are five different groups and NetScreen’s supports the following three:

• DH Group 1: 768-bit Modulus • DH Group 2: 1024-bit Modulus • DH Group 5: 1536-bit Modulus

The larger the modulus, the more secure the generated key is considered to be.

IPSEC PACKET FLOW

The following shows the packet flow sequence from the initiator to the recipient for a Route-based VPN, The differences for a Policy-Route-based VPN are discussed later

FROM THE INITIATOR:

1. Host attempts to send a packet destined for an IP address on the recipient network via its default gateway.

2. Packet arrives at the egress interface which is bound to one of the zones (Trust zone for this example).

3. With SCREEN options enabled for the zone the NetScreen firewall activates the SCREEN module.

4. The session module then performs a session lookup trying to match the packet with an existing session.

5. The address-mapping module checks if a Mapped IP (MIP) configuration uses the destination IP address.

6. The route module performs a route lookup for the destination IP address and sees that the traffic needs to be routed through a tunnel interface. The tunnel interface is bound to a VPN tunnel and from the ingress and egress interfaces the firewall works out the source and destination zones and can now do a policy lookup.

(19)

Page | 19

7. The policy engine performs a policy lookup between the two zones. From the policy match, the policy engine performs the policy action (“permit “for this example).

8. The IPSec module checks if an active Phase 2 security association (SA) with the remote gateway exists and if so the process skips to step 10. If not, the next step is initiated. 9. The IKE module checks if an active Phase 1 SA exists with the remote peer and if so the

IPSec module attempts to establish a Phase 2 negotiation. The process continues to the next step on successful completion of Phase 2 negotiation. If Phase 1 negotiations fail, traffic will fail at this point.

10. The IPSec module encapsulates the packet using the appropriate protocols (tunnel mode using ESP in this example). The packet is appended with a new header which includes the outgoing interface’s IP address as its source IP address and the remote gateway’s IP address as the destination. The packet’s payload is then encrypted to the next header field in the original IP header and authenticated from the ESP trailer to the ESP header. 11. The firewall sends the encrypted and authenticated packet destined for the remote

gateway through the outgoing interface to the next-hop-gateway.

FROM THE RECIPIENT:

1. Packet arrives at the external interface bound to a particular zone (Untrust zone for this example).

2. Using the SPI, destination IP address, and IPSec protocol contained in the outer packet header, the IPSec module attempts to locate an active Phase 2 SA with the initiating peer along with the keys to authenticate and decrypt the packet. If successful, the firewall moves onto step 4. If an active Phase

3. SA cannot be found, the NetScreen moves onto the next step.

4. IKE module checks if an active Phase 1 SA exists with the remote peer. If a Phase 1 SA does not exist, the NetScreen attempts to establish a Phase 1 tunnel with the remote gateway.

5. IPSec module performs an anti-replay check. 6. IPSec module attempts to authenticate the packet.

7. Using the Phase 2 SA and keys, the IPSec module decrypts the packet, uncovering its original source address (the original host that send the packet) and its ultimate

destination (the original destination of the packet). The firewall determines which VPN the packet came through, and as a result, which tunnel interface the VPN was bound to. From this point forward, the firewall treats the packet as if its ingress interface is the tunnel interface. It also adjusts the anti-replay sliding window at this point.

8. If SCREEN options have been enabled for the zone, the firewall activates the SCREEN module at this point.

9. The session module performs a session lookup, attempting to match the packet with an existing session. It then either performs First Packet Processing or Fast Processing. 10. The address-mapping module checks if a mapped IP (MIP) or virtual IP (VIP)

configuration uses the original destination IP address.

11. The route module first uses the ingress interface to determine the virtual router to use for the route lookup. It then performs a route lookup for the destination and determines which interface it needs to send the packets out from. By determining the ingress interface and the egress interface, the NetScreen can thereby determine the source and destination zones. It is now possible to perform a policy lookup on the respective zones. 12. The policy engine checks its policy list from the source zone to the destination zone and

finds a policy that grants access (or possibly denies access).

(20)

Page | 20

The packet flow for a Policy-based VPN is the same apart from the following points:

FROM THE INITIATOR:

Route Lookup: To determine the destination zone, the route module does a route lookup for the destination IP address. As there is more than likely not a route for that particular IP address, the NetScreen uses the default gateway and the zone associated with the ultimate outgoing interface (let us assume it’s the Untrust zone). By determining the ingress and egress interfaces, the firewall has thereby determined the source and destination zones, and can now perform a policy lookup.

Policy Lookup: The policy engine does a policy lookup between the two zones. The lookup matches the source address and zone, destination address and zone, and service and finds a policy that references a VPN tunnel.

The NetScreen device then forwards the packet through to the destination using the VPN tunnel configured in the policy.

FROM THE RECIPIENT:

The inbound packet flow on the recipient end is the same for both route-based and policy-based VPN configurations except that the tunnel is not bound to tunnel zone. The NetScreen device learns that the packet came through vpn1 which is bound to the Untrust-Tun tunnel zone whose carrier zone is the Untrust zone. Unlike route-based VPNs the firewall considers ethernet3 to be the ingress interface of the decrypted packet - not tunnel.1.

Route Lookup: The route module performs a route lookup for destination IP address and discovers the relevant interface and zone for the delivery of the packet. By learning the source zone and determining the destination zone based on the egress interface, the firewall can now check for a policy from the respective zones that references the VPN tunnel.

Policy Lookup: The policy engine checks its policy list from the source zone to the destination zone and finds a policy that references the VPN tunnel.

The NetScreen then forwards the packet to its destination.

NOTE: Unlike a Route-based VPN a Policy-based VPN isn’t reliant on a tunnel interface. Instead, all VPNs are bound to a tunnel zone (the Untrust-tunnel-zone). The tunnel zone relies on the carrier zone (Untrust zone in our example) to determine which zones it should use for policy lookup. The

physical interface the packet arrives on is used as the ingress interface as opposed to the tunnel interface in a Route-based VPN situation.

MODES

IKE supports two modes of negotiation, Main mode and Aggressive mode. Main mode is the standard method used for site-to-site VPNs with static peers and Aggressive mode is used for VPN clients and sites with dynamic IP addresses.

The VPN tunnel initiator and the recipient send three two-way exchanges, six messages in Main mode.

(21)

Page | 21

1. Messages 1 and 2: Propose and accept the encryption and authentication algorithms 2. Messages 3 and 4: Diffie-Hellman exchange with initiator and recipient providing a

nonce (randomly generated number)

3. Messages 5 and 6: Send and verify identities

Exchanging identity information after Messages 3 and 4, after an encryption method has been established ensures the identity information remains secure.

Aggressive mode establishes a secure tunnel but requires two exchanges with a total of three messages.

1. Message 1: The VPN tunnel initiator proposes the SA, initiates Diffie-Hellman key exchange, sends a nonce and its IKE identity

2. Message 2: The recipient accepts the SA, authenticates the initiator, sends a nonce, its IKE identity and its digital certificate (if digital certificates are in use)

3. Message 3: The initiator authenticates the recipient, confirms the exchange and sends its digital certificate (if digital certificates are in use)

Identities of both parties are sent in the clear so Aggressive mode does not provide identity protection.

PERFECT FORWARD SECRECY

Phase 2 can use this same key for the purposes of its encryption when no Perfect Forward Secrecy (PFS) is enabled. PFS requires another separate key to be generated using DH for Phase 2 usage. This increases security as a compromise in Phase 1 keys does not equate to a

compromise in Phase 2 keys.

SECURITY ASSOCIATIONS

A security association (SA) is a unidirectional agreement between the VPN participants regarding the methods and parameters to use in securing a communication channel. Full bidirectional communication requires at least two SAs, one for each direction.

An SA groups together the following components for securing communications:

 Security algorithms and keys

 Protocol mode (transport or tunnel)

 Key-management method (manual key or AutoKey IKE)

 SA lifetime

For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel. For inbound traffic, the Firewall looks up the SA by using the following triplet:

• Destination IP

• Security protocol (AH or ESP)

 Security parameter index (SPI) value

PROTOCOLS

To secure packets destined for a VPN tunnel there are two protocols:

 Authentication Header (AH) provides authenticity and integrity of the content and origin of a packet. This is achieved with either an MD5 or SHA-1 hash algorithm. AH

(22)

Page | 22

leaves the packet payload in its original form with an AH header appended to the packet header.

 Encapsulation Security Payload (ESP) provides security of data by encrypting the packet’s payload. ESP supports the DES, 3DES and AES protocols for encryption and an ESP header is appended to the packet.

ENCAPSULATION MODES

IPsec operates in one of two modes—transport or tunnel. When both ends of the tunnel are hosts, you can use either mode but when at least one of the endpoints is a security gateway (router or firewall) you must use tunnel mode. Juniper Networks Firewalls always operate in tunnel mode for IPsec tunnels and transport mode for L2TP-over-IPsec tunnels.

 Transport mode retains the original header, the newly appended header (either AH or ESP) and the payload.

 Tunnel mode encapsulates the whole packet (including the original header) into a new packet and appends a new header to the packet.

POLICY/ROUTE-BASED VPN CONFIGURATION

A Policy Based VPN is a configuration in which a specific VPN tunnel is referenced in a policy whose action is set as Tunnel. The tunnel icon appears as either a Lock or as a Lock with directional arrows as shown in the sample below. The icon below indicates the policy is configured for a Bi-Directional Tunnel.

Common Reasons to use a Policy-based VPN:  Remote VPN device is a non-Juniper device

 Need to access only one subnet or one network at the remote site, across the VPN

CONFIGURING A SITE-TO-SITE POLICY-BASED VPN

In order to configure a Policy-based VPN, complete the following steps: Preshared Keys:

set ike gateway gw-name address remote-gw main outgoing-interface phy-interface preshare preshared-key proposal p1-proposal

(23)

Page | 23

Digital Certificates:

set ike gateway gw-name address remote-gw main outgoing-interface phy-interface proposal p1-proposal

set ike gateway gw-name cert peer-ca CA

set ike gateway gw-name cert peer-cert-type ca-type set vpn vpn-name gateway gw-name sec-level p2-proposal Bi-directional policies referring to the tunnel:

set policy top name “policy-name” from src-zone to dst-zone source-net remote-net any tunnel vpn vpn-name

set policy top name “policy-name” from src-zone to dst-zone remote-net source-net any tunnel vpn vpn-name

ROUTE-BASED VPNS

With Route Based VPNs the network topology configuration is removed from the VPN policy configuration. The VPN policy creates a Tunnel Interface between two end points. Static routes can be added to the Tunnel Interface.

The Route Based VPN moves network configuration from the VPN policy configuration to Static Route configuration. This requires changes only to the Static Route when network topology changes.

Route Based VPNs must include the following configuration information: • Tunnel Interface

• Phase I VPN Gateway configuration (listed under VPNs > AutoKey Advanced > Gateway on the WebUI)

• Phase II VPN configuration (listed under VPNs > AutoKey IKE on the WebUI); including: o Local and Remote Proxy ID

o VPN configuration bound to tunnel interface • Route for remote network pointing to tunnel interface • Policy specifying action of "Permit" to allow traffic

CONFIGURING A ROUTE-BASED SITE-TO-SITE VPN

The configuration for a Route-based VPN requires additional steps. Firstly, create and define the tunnel interface:

set interface tunnel-int-name zone zone

set interface tunnel-int-name ip unnumbered interface phy-interface

NOTE: For a standard Site-to-Site Route-based VPN, the tunnel interface can be configured as

unnumbered so it will take on the IP address of the physical interface it’s bound to. In advanced Route-based VPN configurations, you can assign the tunnel interface an IP address for NATing.

The creation of the VPN is quite similar to that of a Policy-based VPN but with one difference. The tunnel interface must be bound to the VPN tunnel and a proxy-ID must be manually configured:

(24)

Page | 24

Preshared Key:

set ike gateway gw-name address remote-gw main outgoing-interface phy-interface preshare preshared-key proposal p1-proposal

set vpn vpn-name gateway gw-name sec-level p2-proposal set vpn vpn-name bind interface tunnel-int-name

set vpn vpn-name proxy-id local-ip local-proxy-id/mask remote-ip remote-proxy-id/mask service

Digital Certification:

set ike gateway gw-name address remote-gw main outgoing-interface phy-interface proposal p1-proposal

set ike gateway gw-name cert peer-ca CA

set ike gateway gw-name cert peer-cert-type ca-type set vpn vpn-name gateway gw-name sec-level p2-proposal set vpn vpn-name bind interface tunnel-int-name

set vpn vpn-name proxy-id local-ip local-proxy-id/mask remote-ip remote-proxy-id/mask service

Route-based VPN’s are instigated through the routing of traffic to a particular destination, and as such, a static route needs to be added:

set vrouter vrouter route remote-net interface tunnel-int-name

A security policy can be used to control traffic outbound to and inbound from the tunnel:

set policy top name “policy-name” from src-zone to dst-zone source-net remote-net any permit

set policy top name “policy-name” from src-zone to dst-zone remote-net source-net any permit

NOTE: If the tunnel interface is bound to the same zone as the destination zone and Intrazone blocking is disabled, a security policy is not required to permit the traffic. It is assumed that all traffic is permitted by default. Binding the tunnel interface to a different zone requires the use of a security policy to explicitly permit traffic.

PROXY-IDS

The proxy-ID determines which networks and services are permitted through the VPN and is made up of the local network, remote network and service. Both end points of the VPN exchange their proxy-ID which needs to match for the Phase 2 negotiation to be complete.

If a Policy-based VPN is being used, the necessary proxy-ID information resides in the policy e.g. source, destination and service.

If Route-based VPN is being used, a policy may not be necessary, and if so, may not contain the correct information to create the proxy-ID. In this case the proxy-ID must be manually entered when configuring Route-based VPNs.

(25)

Page | 25

NOTE: By manually specifying a proxy-ID in a Policy-based VPN scenario, it will overwrite the proxy-ID automatically obtained from the security policy.

HUB/SPOKE CONFIGURATIONS

If two VPN tunnels terminating at the Firewall are set up, it is possible to have routes so that the Firewall directs traffic exiting one tunnel to the other tunnel. Tunnel interfaces assigned to the same security zone do not require policies for traffic to route between them (Intrazone blocking must be disabled).

NOTE: Hub and Spoke VPNs are easiest to configure using Route-based VPNs. It is possible to

achieve this functionality through Policy-based VPNs but only through the Trust and Untrust zones.

If more granular access controls are required then tunnel interfaces can be assigned to different zones to provide control over the traffic through security policies. This type of Hub and Spoke VPN is known as a Back-to-Back VPN.

BACK-TO-BACK VPNS

Back-to-back VPNs enforce interzone policies between two spoke sites through the hub site. There are several advantages to using back-to-back VPNs. Using back-to-back VPNs reduces the number of tunnels you need to create. So it is especially useful in cases were a limited number of tunnels are supported e.g. NetScreen 5XP supports only 10 tunnels. Enforcing policies between spoke sites can be accomplished by placing each of the sites into different zones. Since each site is located in a different zone Firewalls must perform a policy lookup before routing the traffic to the destination site so you can control which traffic is allowed between your spoke sites.

• Enable intrazone blocking

• Define policies between the tunnel interfaces.

The administrator of the hub site can control the flow of all traffic from the remote sites by defining a policy at each spoke site that passes all traffic from the trusted network destined for the outside world across the VPN to the hub site. The administrator can use policies at the hub site to filter traffic.

NOTE: To calculate the total number of VPN tunnels required in a fully meshed VPN for a given

(26)

Page | 26

CONFIGURING BACK-TO-BACK VPNS

Configuration for Back-to-Back VPNs is the same as standard Hub and Spoke so using the same example as previously showing the configuration changes required at the Head Office.

Head Office:

Security Zones and Virtual Routers: unset interface interface ip

unset interface interface zone set zone untrust vrouter untrust-vr set zone untrust block

set zone name x1

set zone x1 vrouter trust-vr set zone x1 block

set zone name x2

set zone x2 vrouter trust-vr set zone x2 block

Where interface is the interface bound to the Untrust zone Interfaces:

set interface interface zone untrust

set interface interface ip HO-external-IP/mask(octet) set interface tunnel.1 zone x1

set interface tunnel.1 ip tunnel1-ip/mask(octet) set interface tunnel.2 zone x2

set interface tunnel.2 ip tunnel2-ip/mask(octet)

The tunnel1-ip should be an IP address that resides on the local area network of Site A and the tunnel2-ip should be an IP address that resides on the local area network of Site B.

Site A:

set ike gateway SiteA address siteA-external-IP outgoing-interface interface preshare presharedkey sec-level compatible

set vpn SiteA-VPN gateway SiteA sec-level compatible set vpn SiteA-VPN bind interface tunnel.1

set vpn SiteA-VPN proxy-id local-ip siteB-net/mask(octet) remote-ip siteA-net/mask(octet) any

Again t is possible to use other Phase 1 & 2 proposals apart from compatible. Granular

restrictions of what can be routed between the spokes; proxy-ID is enforced to be the local area networks of both spokes. Simplifying the configuration, configure a 0.0.0.0/0 proxy-ID.

Site B:

set ike gateway SiteB address siteB-external-IP outgoing-interface interface preshare presharedkey sec-level compatible

set vpn SiteB-VPN gateway SiteB sec-level compatible set vpn SiteB-VPN bind interface tunnel.2

set vpn SiteB-VPN proxy-id local-ip siteA-net/mask(octet) remote-ip siteB-net/mask(octet) any

Routes:

(27)

Page | 27

set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw

A static route addition to the spoke sites is not required as each tunnel interface resides on the same network, and as such, the routing table knows of the route because of this “direct” connection.

Addresses:

set address x1 “SiteA LAN” siteA-net/mask(octet) set address x2 “SiteB LAN” siteB-net/mask(octet) Policies:

set policy top from x1 to x2 “SiteA LAN” “SiteB LAN” any permit set policy top from x2 to x1 “SiteB LAN” “SiteA LAN” any permit

CONFIGURING A HUB AND SPOKE VPN

This example is of a Head Office which is acting as the hub and two remote sites called Site A and Site B acting as the spokes.

Head Office

unset interface interface zone set zone untrust vrouter untrust-vr unset zone untrust block

Where interface is the interface bound to the Untrust zone. Interfaces:

set interface interface ip HO-external-IP/mask(octet) set interface tunnel.1 zone untrust

set interface tunnel.1 ip unnumbered interface interface set interface tunnel.2 zone untrust

set interface tunnel.2 ip unnumbered interface interface Where interface is the interface bound to the Untrust zone. VPN for Site A:

set vpn SiteA-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any It is possible to use other Phase 1 & 2 proposals apart from compatible. VPN for Site B:

set vpn SiteB-VPN gateway SiteB sec-level compatible set vpn SiteB-VPN bind interface tunnel.2

(28)

Page | 28 Routes:

set vrouter untrust-vr route siteA-net/mask(octet) interface tunnel.1 set vrouter untrust-vr route siteB-net/mask(octet) interface tunnel.2

set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw For Site A:

Site A:

unset interface interface zone set zone untrust vrouter untrust-vr

Where interface is the interface bound to the Untrust zone. Interfaces:

set interface interface-trust zone trust

set interface interface-trust ip trust-ip/mask(octet) set interface interface-trust nat

set interface interface ip siteA-external-IP/mask(octet) set interface tunnel.1 zone untrust

set interface tunnel.1 ip unnumbered interface interface Address:

set address untrust SiteB siteB-net/mask(octet) VPN:

set ike gateway HeadOffice address HO-external-IP outgoing-interface interface preshare presharedkey sec-level compatible

set vpn HO-VPN gateway HeadOffice sec-level compatible set vpn HO-VPN bind interface tunnel.1

set vpn HO-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any Routes:

set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr

set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw set vrouter untrust-vr route SiteB-net/mask(octet) interface tunnel.1

Policies:

set policy from trust to untrust any SiteB any permit set policy from untrust to trust SiteB any any permit Site B is as Site A. but with configuration details relevant to Site B.

NOTE: Although a policy is not required at Head Office a policy is still required at both sites to

(29)

Page | 29

NHTB REQUIREMENTS/CONFIGURATIONS

You can bind multiple IPSec VPN tunnels to a single tunnel interface. To link a specific destination to one of a number of VPN tunnels bound to the same tunnel interface, the

NetScreen device uses two tables: the route table and the next-hop tunnel binding (NHTB). The NetScreen device maps the next-hop gateway IP address specified in the route table entry to a particular VPN tunnel specified in the NHTB table.

NEXT-HOP TUNNEL BINDING TABLE

Creating Entries in the NHTB Table

Once you have learnt the IP address of the remote peer’s tunnel interface, you can issue the following command to manually create an entry into the NHTB table:

set interface tunnel-interface nhtb peer-tunnel-interface-ip vpn vpn-name NOTE: You can add entries into the NHTB table but can’t view it.

(30)

Page | 30

To make the populating of both the NHTB and route tables automatic, the following conditions must be met:

• The remote peers for all VPN tunnels bound to a single local tunnel interface must be NetScreen devices running ScreenOS 5.0.x or above.

• Each remote peer must bind its tunnel to a tunnel interface, and that interface must have an IP address unique among all peer tunnel interface addresses.

• At both ends of each VPN tunnel, VPN monitoring with the rekey option must be enabled, or, the IKE heartbeat reconnect option for each remote gateway must be enabled.

• The local and remote peers must have an instance of Border Gateway Protocol (BGP) enabled on their connecting tunnel interfaces.

CONFIGURING MULTIPLE VPNS THROUGH A SINGLE TUNNEL INTERFACE USING

STATIC NHTB

In this example, we will bind 3 AutoKey IKE VPNs to a single tunnel interface at Head Office, showing the configurations for Head Office and one of the spoke sites.

Head Office:

Security Zones and Virtual Routers: unset interface untrust-interface ip unset interface untrust-interface zone set zone untrust vrouter untrust-vr Interfaces:

set interface trust-interface zone trust

set interface trust-interface ip ipaddress/mask(octet) set interface untrust-interface zone untrust

set interface untrust-interface ip HO-external-IP/mask(octet) set interface tunnel.1 zone untrust

set interface tunnel.1 ip HO-tunnel-IP/mask(octet) Addresses:

set address trust HO-Net ipaddress/mask(octet) set address untrust SiteA-Net ipaddress/mask(octet) set address untrust SiteB-Net ipaddress/mask(octet) set address untrust SiteC-Net ipaddress/mask(octet) set group address untrust RemoteSites + SiteA-Net set group address untrust RemoteSites + SiteB-Net set group address untrust RemoteSites + SiteC-Net VPNs:

(31)

Page | 31

set vpn SiteB-VPN gateway SiteA sec-level compatible set vpn SiteB-VPN bind interface tunnel.1

set vpn SiteB-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any

set ike gateway SiteC address siteC-external-IP outgoing-interface interface preshare presharedkey sec-level compatible

set vpn SiteC-VPN gateway SiteA sec-level compatible set vpn SiteC-VPN bind interface tunnel.1

set vpn SiteC-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any It is possible to use other Phase 1 & 2 proposals apart from compatible. Routes:

set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw set vrouter untrust-vr route siteA-Net interface tunnel.1 gateway siteA-tunnel-IP set vrouter untrust-vr route siteB-Net interface tunnel.1 gateway siteB-tunnel-IP set vrouter untrust-vr route siteC-Net interface tunnel.1 gateway siteC-tunnel-IP set interface tunnel.1 nhtb siteA-tunnel-IP vpn SiteA-VPN

set interface tunnel.1 nhtb siteB-tunnel-IP vpn SiteB-VPN set interface tunnel.1 nhtb siteC-tunnel-IP vpn SiteC-VPN Policies:

set policy from trust to untrust HO-Net RemoteSites any permit set policy from untrust to trust RemoteSites HO-Net any permit Site A:

Security Zones and Virtual Routers: unset interface untrust-interface ip unset interface untrust-interface zone set zone untrust vrouter untrust-vr Interfaces:

set interface trust-interface zone trust

set interface trust-interface ip ipaddress/mask(octet) set interface untrust-interface zone untrust

set interface untrust-interface ip HO-external-IP/mask(octet) set interface tunnel.1 zone untrust

set interface tunnel.1 ip siteA-tunnel-IP/mask(octet) Addresses:

set address trust SiteA-Net ipaddress/mask(octet) set address untrust HO-Net ipaddress/mask(octet) VPN to Head Office:

set ike gateway HO address HO-external-IP outgoing-interface interface preshare presharedkey sec-level compatible

set vpn HO-VPN gateway HO sec-level compatible set vpn HO-VPN bind interface tunnel.1

(32)

Page | 32 Routes:

set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw set vrouter untrust-vr route HO-Net interface tunnel.1 gateway HO-tunnel-IP Policies:

set policy from trust to untrust SiteA-Net to HO-Net any permit set policy from untrust to trust HO-Net to SiteA-Net any permit

CONFIGURING MULTIPLE VPNS THROUGH A SINGLE TUNNEL INTERFACE USING BGP

Configure the binding of 3 AutoKey IKE VPNs to a single tunnel interface with BGP for automatic route entry;

Using the previous example with the following modified commands: For Head Office:

VPNs:

set vpn SiteA-VPN monitor rekey set vpn SiteB-VPN monitor rekey set vpn SiteC-VPN monitor rekey

NOTE: VPN monitoring must be turned on at the hub site when using automatic configuration

Dynamic Routing:

When configuring dynamic routing the dynamic routing protocol must be enabled on both the virtual router and the interface.

ns-> set vrouter untrust-vr protocol bgp AS-Number ns-> set vrouter untrust-vr protocol bgp enable ns-> set interface tunnel.1 protocol bgp

ns-> set vrouter untrust-vr ns(untrust-vr)-> set protocol bgp

ns(untrust-vr/bgp)-> set neighbor siteA-tunnel-IP remote-as AS-Number outgoing interface tunnel.1

ns(untrust-vr/bgp)-> set neighbor siteA-tunnel-IP enable

ns(untrust-vr/bgp)-> set neighbor siteB-tunnel-IP remote-as AS-Number outgoing interface tunnel.1

ns(untrust-vr/bgp)-> set neighbor siteB-tunnel-IP enable

ns(untrust-vr/bgp)-> set neighbor siteC-tunnel-IP remote-as AS-Number outgoing interface tunnel.1

ns(untrust-vr/bgp)-> set neighbor siteC-tunnel-IP enable ns(untrust-vr/bgp)-> exit

ns(untrust-vr)-> exit For Site A:

Dynamic Routing:

ns-> set vrouter untrust-vr protocol bgp AS-Number ns-> set vrouter untrust-vr protocol bgp enable ns-> set interface tunnel.1 protocol bgp

ns-> set vrouter untrust-vr ns(trust-vr)-> set protocol bgp

ns(untrust-vr/bgp)-> set neighbor HO-tunnel-IP remote-as AS-Number outgoing interface tunnel.1

(33)

Page | 33

ns(untrust-vr/bgp)-> set neighbor HO-tunnel-IP enable ns(untrust-vr/bgp)-> exit

ns(untrust-vr)-> exit

AUTO-CONNECT VPNS

AC-VPN is designed to be implemented in a hub-and-spoke network in which all spokes are connected to the hub by VPN tunnels. After you set up a static VPN tunnel between the hub and each of the spokes, you configure AC-VPN on the hub and the spokes and then enable the Next Hop Resolution Protocol (NHRP).

The hub uses NHRP to obtain a range of information about each spoke, including its public-to-private address mappings, subnet mask length, and routing and hop count information, which the hub caches. Then, when any spoke begins communicating with another spoke (through the hub), the hub uses this information, in combination with information obtained from the AC-VPN configuration on the spokes, to enable the spokes to set up an AC-VPN tunnel between

themselves.

While the tunnel is being negotiated communication continues to flow between the two spokes through the hub. When the dynamic tunnel becomes active, the hub drops out of the link and traffic flows directly between the two spokes. When traffic ceases to flow through the dynamic tunnel the tunnel will time out.

PKI

PKI is a security architecture introduced to provide an increased level of confidence for exchanging information over an increasingly insecure Internet. Its fundamental components include:

• Certificate Authority (CA) • Registration Authority (RA) • Certificate Revocation List (CRL).

DIGITAL CERTIFICATES

The purpose of digital certificates is to ensure that the public key contained in the certificate belongs to the entity to which the certificate was issued. Encryption techniques using public and private keys require a public-key infrastructure (PKI) to support the distribution and identification of public keys.

Digital certificates package public keys, information about the algorithms used, owner or subject data, the digital signature of a Certificate Authority that has verified the subject data, and a date range during which the certificate can be considered valid.

Users and devices can exchange digital certificates in order to prove their identity, allowing a circle of trust to form. This is on the proviso that all the users and devices trust the validation of the Certificate Authority.

As a digital certificate contains the public encryption key for a particular user or device, the other party receiving the digital certificate (having trusted the digital certificate), can use the public key for the purpose of encrypting data and traffic back to the owner of the digital certificate.

(34)

Page | 34

Certificate Authorities

A certificate authority (CA) is an authority in a network that issues and manages security credentials and public keys for message encryption. As part of a public key infrastructure (PKI), a CA checks with a registration authority (RA) to verify information provided by the requestor of a digital certificate. If the RA verifies the requestor's information, the CA can then issue a certificate.

Depending on the public key infrastructure implementation, the certificate includes the owner's public key, the expiration date of the certificate, the owner's name, and other information about

the public key owner.

CERTIFICATE REVOCATION

Revoking a certificate makes it no longer valid for use. Once a certificate is revoked, visitors to your website may get warning messages telling them that the certificate is no longer valid and should not be trusted.

A Certificate Revocation List (CRL) can be referenced when validating a digital certificate to ensure that the certificate has not been revoked. This is a manual processes where the CRL is downloaded periodically. When the validator does not have the latest CRL a presented certificate may still be trusted even though it may have been revoked and added to a more recent CRL. To address +this OCSP (Online Certificate Status Protocol) was developed for online real-time verification of a digital certificate’s status.

NOTE: When a NetScreen uses OCSP, it is referred to as the OCSP client (or requester). The server

which receives the verification request is known as the OCSP responder.

CONFIGURING DIGITAL CERTIFICATES ON A NETSCREEN

Generate a certificate request and forward it to an appropriate CA to be signed. Issue the commands below to generate the certificate request and have it forwarded to the CA’s email address:

set pki x509 dn country-name country * set pki x509 dn email your-email-address * set pki x509 dn ip NetScreen-ip-address set pki x509 dn local-name location set pki x509 dn name hostname *

set pki x509 dn org-name company-name set pki x509 dn org-unit-name department set pki x509 phone phone-number

set pki x509 dn state-name state

set pki x509 default send-to ca-email-address * exec pki rsa new-key 1024 *

(35)

Page | 35

LOADING THE DIGITAL CERTIFICATE

Once you receive the digital certificate it is saved to a tftp server and can be uploaded to the NetScreen. Three items are required for the Digital Certificate to function:

• digital certificate assigned to the NetScreen (typically called local.cer) • signing Certificate Authority’s digital certificate (typically called auth.cer) • CRL (usually *.crl).

Load the three items to the NetScreen with the following commands: exec pki x509 tftp tftp-ip-address cert-name auth.cer

exec pki x509 tftp tftp-ip-address cert-name local.cer exec pki x509 tftp tftp-ip-address crl-name filename.crl

CONFIGURING CRL SETTINGS

NetScreen firewalls check the status of certificates received against a CRL to ensure their validity during the Phase 1 negotiations. If no CRL is loaded to the NetScreen’s database the firewall attempts to retrieve the CRL defined on the CA certificate through LDAP or HTTP but if no CRL is defined on the CA certificate it attempts to use the URL defined for the CRL.

set pki authority default cert-path full

set pki authority default cert-status crl url “URL”

set pki authority default cert-status crl server-name CA-server-IP-address set pki authority default cert-status crl refresh daily|weekly|monthly

CONFIGURING OCSP

NetScreen can use OCSP for certificate validation as opposed to a CRL and to configure the NetScreen for OCSP, issue the following commands:

Configure the NetScreen to use OCSP for the relevant CA:

set pki authority CA-ID cert-status revocation-check OCSP Configure the OCSP Responder:

set pki authority CA-ID cert-status ocsp url URL

CA-ID is the identification number assigned to the configured CA by the NetScreen firewall. To view the list of configured CAs and IDs, issue the command:

(36)

Page | 36

DYNAMIC PEER VPN’S

If a remote site has a dynamically assigned IP address (SOHO sites) it is not possible to define the remote gateway’s IP address and establish a VPN tunnel. However NetScreen firewalls overcome this through the use of local and peer IDs.

By configuring a local ID on the initiating device with a dynamic IP address it presents this information to the recipient firewall when attempting to establish Phase 1 negotiations. The recipient device can be configured to recognise this through a peer ID and can accept the initiators current IP address.

CONFIGURING A SITE-TO-SITE VPN WITH A DYNAMIC PEER

The configuration is the same with the following exceptions when defining the gateway. Initiating device:

Preshared Key

set ike gateway gw-name address remote-gw aggressive local-id local-id outgoing-interface phy-outgoing-interface preshare preshared-key proposal p1-proposal

Digital Certificates

set ike gateway gw-name address remote-gw aggressive local-id local-id outgoing-interface phy-outgoing-interface proposal p1-proposal

Recipient device:

Preshared Key

set ike gateway gw-name dynamic peer-id aggressive outgoing-interface phy-interface preshare preshared-key proposal p1-proposal

Digital Certificates

set ike gateway gw-name dynamic peer-id aggressive outgoing-interface phy-interface proposal p1-proposal

(37)

Page | 37

TRANSPORT MODE IPSEC VPN

In order to support transport mode IPsec for traffic between gateways the security gateway needs to meet the RFC standard that the source address for outgoing packets and the destination address for incoming packets is an address belonging to the security gateway.

In the above the two hosts (h-1 and h-2) are in one trust zone and the two servers (s-1 and s-2) are in another trust zone. GW -1 and GW -2 are in an untrust zone.

To configure NAT transport mode in the above scenario, perform the following steps: 1. Build transport mode IPSec VPN between host-1 and GW-1

2. Build transport or tunnel mode IPSec VPN between GW-1 and GW-2 3. Build transport mode IPSec VPN between GW -2 and server-1 4. Do source-NAT and MIP on GW-1

5. Do MIP (MIP and reversed MIP) on GW-2.

The following section explains the steps involved in configuring a transport mode IPsec VPN. GW-1 uses src-NAT when h-1 is accessing s-1, and GW-2 uses MIP when h-2 is accessing s-2.

GATEWAY - 1 CONFIGURATION

IKE Configuration on host-1 and host-2

set ike gateway gateway1 address 1.1.1.1 aggressive outgoing-interface loopback.1 preshare test1 sec-level standard

set ike gateway gateway2 address 1.1.1.10 aggressive outgoing-interface loopback.2 preshare test1 sec-level standard

VPN Configuration on host-1 and host-2

set vpn v1 gateway gateway1 transport sec-level standard set vpn v2 gateway gateway2 transport sec-level standard MIP Configuration

set interface loopback.1 mip 3.3.3.3 host 6.6.6.6 set interface loopback.2 mip 3.3.3.4 host 6.6.6.7 IKE Configuration for GW-2

set ike gateway s1 address 6.6.6.6 aggressive outgoing-interface loopback.3 preshare test1 sec-level standard

set ike gateway s2 address 6.6.6.7 aggressive outgoing-interface loopback.4 preshare test1 sec-level standard

(38)

Page | 38

VPN Configuration for s1 and s2

set vpn v3 gateway s1 transport sec-level standard set vpn v4 gateway s2 transport sec-level standard DIP Configuration

set interface eth2 ext ip 4.4.4.4 255.255.255.255 dip 10 4.4.4.4 4.4.4.4 set interface eth2 ext ip 4.4.4.5 255.255.255.255 dip 11 4.4.4.5 4.4.4.5 Policy Setup

Outgoing policy:

set policy id 3 from trust to untrust "1.1.1.1" "3.3.3.3" any nat src dip-id 10 tunnel vpn v3

set policy id 4 from trust to untrust "1.1.1.10" "3.3.3.4" any nat src dip-id 11 tunnel vpn v4

Incoming policy:

set policy id 1 from trust to untrust "1.1.1.1" "(MIP)3.3.3.3" any tunnel vpn v1 set policy id 2 from trust to untrust "1.1.1.10" "(MIP)3.3.3.4" any tunnel vpn v2

GW-2 CONFIGURATION

IKE and VPN Configuration to Server-PC

set ike gateway gateway1 address 5.0.0.1 aggressive outgoing-interface lo.3 preshare test sec-level standard

set ike gateway gateway2 address 5.0.0.2 aggressive outgoing-interface lo.4 preshare test sec-level standard

VPN Configuration on server-1 and server-2

set vpn v3 gateway gateway1 transport sec-level standard set vpn v4 gateway gateway2 transport sec-level standard Reversed MIP (Traffic Is from Untrust to Trust)

set interface lo.3 mip 7.7.7.7 host 4.4.4.4 set interface lo.4 mip 7.7.7.8 host 4.4.4.5 IKE and VPN configuration to GW-1 (Client-PC)

set ike gateway h1 address 4.4.4.4 aggressive outgoing-interface lo.1 preshare test sec-level standard

set ike gateway h2 address 4.4.4.5 aggressive outgoing-interface lo.2 preshare test sec-level standard

(39)

Page | 39

set vpn v1 gateway h1 transport sec-level standard set vpn v2 gateway h2 transport sec-level standard MIP

set interface lo.1 mip 6.6.6.6 host 5.0.0.1 set interface lo.2 mip 6.6.6.7 host 5.0.0.2 Policy Setup

Outgoing policy:

set policy id 7 from untrust to trust "4.4.4.4" "6.6.6.6" any tunnel vpn v3 set policy id 8 from untrust to trust "4.4.4.5" "6.6.6.7" any tunnel vpn v4 Incoming policy

set policy id 5 from untrust to trust "4.4.4.4" "(MIP)6.6.6.6" any tunnel vpn v1 set policy id 6 from untrust to trust "4.4.4.5" "(MIP)6.6.6.7" any tunnel vpn v2 1. When a packet from h-1 arrives at GW-1, the GW-1 decrypts the packet and finds the

destination MIP for the packet.

2. GW-1 matches the packet against the policy (policy 1) that defines the host VPN. It does a policy search again and finds the policy (policy 3) that defines the server VPN and src-nat.

3. GW-1 then does a destination MIP, which changes the destination IP address from 3.3.3.3 to 6.6.6.6 and the source NAT, which changes the source IP address from 1.1.1.1 to 4.4.4.4.

4. GW-2 decrypts the packet and finds the destination MIP for the packet.

It matches the decrypted packet with the policy (policy 5) that defines the host VPN. It does a policy search again and finds the policy (policy 7) that defines the server VPN. 5. Before sending the packet out, GW-2 finds the reversed-MIP on lo.3 for packet's src-IP

4.4.4.4, so the src-ip is changed from 4.4.4.4 to 7.7.7.7 6. GW-2 forwards the packet to s-1 through interface 7.7.7.7

7. S-1 (5.0.0.1) processes the packet and sends it to GW-2 (6.6.6.6) through interface 7.7.7.7.

8. GW-2 identifies the reversed MIP (7.7.7.7 -> 4.4.4.4) and sends the packet to GW-1 (4.4.4.4). From GW-1, the packet is sent to h-1.

OVERLAPPING VPN NETWORKS

There often situations where you face the local area networks of both VPN end points using the same IP address. This is an Overlapping of VPN Networks but through the use of NetScreen firewalls it can be overcome and still allow traffic to communicate between the networks by performing both NAT-src and NAT-dst for both networks.

For the NAT-src the interfaces at both ends of the tunnel need to be in mutually exclusive IP address ranges and have a DIP pool configured so Policy-based NAT-src can be applied to outgoing traffic.

Gdnw Jncis-fwv Study Guide

NETSCREEN JNCIS -FWV STU DY GUIDE

CONTENTS

INTRODUCTION

JUNIPER FIREWALL PRODUCT DETAILS

SSG 5

SSG 20

SSG 140

SSG 320M

SSG 520M

SSG 550M

NETSCREEN-5200/5400

Features/Functionality

NetScreen-5200

NetScreen-5400

Number of Interfaces

2 XFE 10GigE, or 8 Mini-GBIC,

or 2 Mini-GBIC + 24 10/100

6 XFE 10GigE, or 24 Mini-GBIC,

or 6 Mini-GBIC + 72 10/100

Maximum Number of IP

Addresses in Trusted Interfaces

Unrestricted

Unrestricted

Maximum Throughput

10G FW

5G 3DES/AES VPN

30G FW

15G 3DES/AES VPN

Maximum Number of Sessions

1,000,000

1,000,000

Maximum Number of VPN

Tunnels

25,000

25,000

Maximum Number of Policies

40,000

40,000

Maximum Number of Virtual

Systems

0 default, up to 500 additional

0 default, up to 500 additional

Maximum Number of Virtual

LANs

4000

4000

Maximum Number of Security

Zones

16 default, up to 1000 additional 16 default, up to 1000 additional

Maximum Number of Virtual

Routers

3 default, up to 500 additional

3 default, up to 500 additional

Routing Protocols Supported

OSPF, BGP, RIPv1/v2

OSPF, BGP, RIPv1/v2

High-Availability Modes

Supported

Active/Passive

Active/Active

Active/Active Full Mesh

Active/Passive

Active/Active

Active/Active Full Mesh

IPS (Deep Inspection FW)

Yes

Yes

Integrated / Redirect Web

EXAM INFORMATION

CURRENT EXAM OBJECTIVES

FIREWALL/VPN SYSTEMS

VIRTUAL PRIVATE NETWORK

PHASE 1 PROPOSAL

PHASE 2 PROPOSAL

IPSEC STANDARD ELEMENTS

Internet Key Exchange (IKE)

IPSEC PACKET FLOW

FROM THE INITIATOR:

FROM THE RECIPIENT: