You are on page 1of 151

NETSCREEN JNCIS-FWV STUDY GUIDE

AUTHOR: GARNET NEWTON-WADE NETWORK ENGINEER

Page | 1

CONTENTS
Introduction ........................................................................................................................................................................ 7 Juniper Firewall Product details ................................................................................................................................ 8 SSG 5 ............................................................................................................................................................................. 8 SSG 20 .......................................................................................................................................................................... 9 SSG 140........................................................................................................................................................................ 9 SSG 320M.................................................................................................................................................................... 9 SSG 520M................................................................................................................................................................. 10 SSG 550M................................................................................................................................................................. 10 NetScreen-5200/5400 ....................................................................................................................................... 10 Exam Information..................................................................................................................................................... 12 Current Exam Objectives ....................................................................................................................................... 13 Firewall/VPN Systems................................................................................................................................................. 15 Virtual Private Network.............................................................................................................................................. 16 Phase 1 Proposal ....................................................................................................................................................... 17 Tunnel ..................................................................................................................................................................... 17 Phase 2 Proposal ....................................................................................................................................................... 17 IPSec standard elements........................................................................................................................................ 18 Internet Key Exchange (IKE) ........................................................................................................................... 18 IPSec Packet Flow ..................................................................................................................................................... 18 From the initiator: ............................................................................................................................................... 18 From the recipient:.............................................................................................................................................. 19 From the initiator: ............................................................................................................................................... 20 From the recipient:.............................................................................................................................................. 20 Modes............................................................................................................................................................................. 20 Perfect Forward Secrecy ................................................................................................................................... 21 Security Associations .............................................................................................................................................. 21 Protocols....................................................................................................................................................................... 21 Encapsulation Modes .............................................................................................................................................. 22 Policy/route-based VPN configuration ........................................................................................................... 22 Configuring a Site-to-Site Policy-based VPN ............................................................................................ 22 Route-Based VPNs .................................................................................................................................................... 23 Configuring a Route-based Site-to-Site VPN ............................................................................................. 23 Proxy-IDs...................................................................................................................................................................... 24 Hub/spoke configurations .................................................................................................................................... 25 Back-to-Back VPNs .............................................................................................................................................. 25 Configuring Back-to-Back VPNs..................................................................................................................... 26 Page | 2

Configuring a Hub and Spoke VPN................................................................................................................ 27 NHTB requirements/configurations ................................................................................................................ 29 NEXT-HOP TUNNEL BINDING TABLE .................................................................................................... 29 Creating Entries in the NHTB Table .................................................................................................. 29 Configuring Multiple VPNs through a Single Tunnel Interface using static NHTB ................... 30 Configuring Multiple VPNs through a Single Tunnel Interface using BGP ................................... 32 Auto-Connect VPNs .................................................................................................................................................. 33 PKI ................................................................................................................................................................................... 33 Digital Certificates .................................................................................................................................................... 33 Certificate Authorities ................................................................................................................................ 34 Certificate Revocation ........................................................................................................................................ 34 Configuring Digital Certificates on a NetScreen ........................................................................................... 34 Loading the Digital Certificate ........................................................................................................................ 35 Configuring CRL Settings .................................................................................................................................. 35 Configuring OCSP ................................................................................................................................................. 35 Dynamic Peer VPNs ................................................................................................................................................ 36 Configuring a Site-to-Site VPN with a Dynamic Peer ............................................................................ 36 Transport mode IPsec VPN ................................................................................................................................... 37 Gateway - 1 Configuration .................................................................................................................................... 37 GW-2 Configuration ................................................................................................................................................. 38 Overlapping VPN Networks.................................................................................................................................. 39 Configuring a VPN for Overlapping Networks .............................................................................................. 40 Generic Routing Encapsulation on Tunnel Interfaces ............................................................................... 41 VPN QUESTONS ......................................................................................................................................................... 43 VPN ANSWERS ......................................................................................................................................................... 141 Network Management ................................................................................................................................................. 45 Manage/r IPs .............................................................................................................................................................. 45 Manage IP ................................................................................................................................................................ 45 Manager-IP ............................................................................................................................................................. 46 Management Methods ............................................................................................................................................ 46 The CLI...................................................................................................................................................................... 47 Serial Console ........................................................................................................................................................ 47 THE SERIAL TERMINAL SETTINGS .............................................................................................................. 47 Configuring SSH Management ........................................................................................................................ 48 WebUI ....................................................................................................................................................................... 48 User Privileges ...................................................................................................................................................... 48 Interpret internal counters and logs ................................................................................................................ 50

Page | 3

Self Log ..................................................................................................................................................................... 50 Traffic Log ............................................................................................................................................................... 51 Counters ....................................................................................................................................................................... 52 Flow Counters ....................................................................................................................................................... 52 Configure SYSLOG..................................................................................................................................................... 53 Configuring a Syslog Server ............................................................................................................................. 53 logging levels ......................................................................................................................................................... 54 Configure SNMP .................................................................................................................................................... 55 Configuring SNMP................................................................................................................................................ 56 Troubleshooting with Debug/Snoop..................................................................................................................... 58 Snoop ............................................................................................................................................................................. 58 Filtering Snoop ...................................................................................................................................................... 59 Snoop Output ......................................................................................................................................................... 60 Flow Filters ............................................................................................................................................................. 61 Combining Flow Filters with AND Logic .................................................................................................... 62 Understanding Flow Filter Output................................................................................................................ 63 Juniper Firewall Packet Process .................................................................................................................... 63 Reading a Debug Flow Basic............................................................................................................................ 64 Things to look for when there are problems ............................................................................................ 64 Traffic Management...................................................................................................................................................... 66 Describe the bandwidth allocation process................................................................................................... 66 Policies and Bandwidth Management ......................................................................................................... 67 Queuing functionality.............................................................................................................................................. 67 Bandwidth Management Settings ................................................................................................................. 68 List requirements/steps for configuring traffic management .......................................................... 69 Virtual Systems ............................................................................................................................................................... 74 Define VSYS applications ....................................................................................................................................... 74 Describe root vs. VSYS administration ............................................................................................................ 75 Explain VSYS vs. root assignment of routes/NAT pools/etc .................................................................. 76 Configure interface-based VSYS ......................................................................................................................... 76 How the NetScreen firewall differentiates traffic................................................................................... 77 AN-based Classification ..................................................................................................................................... 79 Configure inter-VSYS communications, including NAT ............................................................................ 80 Routing ..................................................................................................................................................................... 80 Policies ..................................................................................................................................................................... 81 Use show/debug output to identify VSYS usage .......................................................................................... 81 Configure VSYS resource allocation .................................................................................................................. 82

Page | 4

NSRP.................................................................................................................................................................................... 84 Distinguish active/passive and active/active. .............................................................................................. 84 Cluster ID ................................................................................................................................................................. 84 Name a Cluster ...................................................................................................................................................... 85 Describe NSRP operations (HA link, session sync, master election, etc.).......................................... 85 Dual HA Links ........................................................................................................................................................ 86 NSRP States ............................................................................................................................................................ 86 Synchronisation .................................................................................................................................................... 88 Run-Time Objects ................................................................................................................................................ 88 Synchronising Time ............................................................................................................................................ 90 HA Interfaces ......................................................................................................................................................... 90 Configure active/passive and active/active NSRP ...................................................................................... 91 Active/Passive Cluster ....................................................................................................................................... 91 Configuring Active/Passive FAILOVER CLUSTER .................................................................................. 92 Active/Active Cluster ......................................................................................................................................... 93 Configuring an Active/Active Cluster .......................................................................................................... 93 Validate NSRP operations ..................................................................................................................................... 96 check if the Active/Passive NSRP pair configurations are in sync .................................................. 97 Adjust operations (secondary link, failover settings) ............................................................................... 99 Configure redundant interface. ......................................................................................................................... 100 Dynamic Routing/Routing over VPNs ................................................................................................................ 103 Configure RIP over VPNs ..................................................................................................................................... 104 Enabling RIP over VPN .................................................................................................................................... 104 Configure OSPF over VPNs.................................................................................................................................. 105 Configure/verify OSPF routing .................................................................................................................... 106 Configure OSPF options................................................................................................................................... 106 Configure/verify BGP ............................................................................................................................................ 107 CoNFIguration Properties .............................................................................................................................. 109 Configure redistribution/filters/route maps.............................................................................................. 110 Redistributing OSPF and static routes into BGP ................................................................................... 111 Configure static routes incl. floating static routes ................................................................................ 112 Configure/verify source routing.................................................................................................................. 113 Configure/verify policy routing ........................................................................................................................ 115 ATTACK PREVENTION .............................................................................................................................................. 119 SCREEN FUNCTIONS ........................................................................................................................................ 119 Describe/configure anti-virus functionality ........................................................................................... 121 Configure Web Filtering .................................................................................................................................. 123

Page | 5

Multicast .......................................................................................................................................................................... 131 Configure/verify IGMP ......................................................................................................................................... 132 Configure/verify PIM-SM .................................................................................................................................... 132 VERIFYING THE CONFIGURATION ................................................................................................................. 138

Page | 6

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.

Page | 7

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.

Page | 8

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 Page | 9

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 trafficmanagement functionality, in a low-profile modular chassis. Built around Juniper's thirdPage | 10

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 Number of Interfaces Maximum Number of IP Addresses in Trusted Interfaces Maximum Throughput Maximum Number of Sessions Maximum Number of VPN Tunnels Maximum Number of Policies Maximum Number of Virtual Systems Maximum Number of Virtual LANs Maximum Number of Security Zones Maximum Number of Virtual Routers Routing Protocols Supported High-Availability Modes Supported IPS (Deep Inspection FW) Integrated / Redirect Web Filtering

NetScreen-5200 NetScreen-5400 2 XFE 10GigE, or 8 Mini-GBIC, 6 XFE 10GigE, or 24 Mini-GBIC, or 2 Mini-GBIC + 24 10/100 or 6 Mini-GBIC + 72 10/100 Unrestricted 10G FW 5G 3DES/AES VPN 1,000,000 25,000 40,000 0 default, up to 500 additional 4000 16 default, up to 1000 additional 3 default, up to 500 additional OSPF, BGP, RIPv1/v2 Active/Passive Active/Active Active/Active Full Mesh Yes No / Yes Unrestricted 30G FW 15G 3DES/AES VPN 1,000,000 25,000 40,000 0 default, up to 500 additional 4000 16 default, up to 1000 additional 3 default, up to 500 additional OSPF, BGP, RIPv1/v2 Active/Passive Active/Active Active/Active Full Mesh Yes No / Yes

Page | 11

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 http://www.juniper.net/techpubs/software/screenos/screenos6.2.0/index.html

Page | 12

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 Use get commands to validate/troubleshoot VPN setup.

Page | 13

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

Page | 14

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 highperformance 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 Junipers 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.

Page | 15

VIRTUAL PRIVATE NETW ORK


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.

Page | 16

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 protocoleither 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.

Page | 17

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 NetScreens 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 Routebased VPN, The differences for a Policy-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.

Page | 18

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 interfaces IP address as its source IP address and the remote gateways IP address as the destination. The packets 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). 13. The firewall then forwards the packet through the interface to the destination host. Page | 19

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 its 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 isnt 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. Page | 20

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

Page | 21

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 packets 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 modestransport 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 set vpn vpn-name gateway gw-name sec-level p2-proposal

Page | 22

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 its 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:

Page | 23

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-proxyid/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-proxyid/mask service Route-based VPNs 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.

Page | 24

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 number of sites use the formula: [N x (N-1)]/2 where N is the number of sites.

Page | 25

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 siteAnet/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 siteBnet/mask(octet) any Routes: set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr Page | 26

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 Security Zones and Virtual Routers: unset interface interface ip 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 zone untrust 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 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 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 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 0.0.0.0/0 remote-ip 0.0.0.0/0 any

Page | 27

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: Security Zones and Virtual Routers: unset interface interface ip Site A: Security Zones and Virtual Routers: unset interface interface ip 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 zone untrust 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 permit the traffic to and from each other.

Page | 28

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 peers 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 cant view it.

Page | 29

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: 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 0.0.0.0/0 remote-ip 0.0.0.0/0 any

Page | 30

set ike gateway SiteB address siteB-external-IP outgoing-interface interface preshare presharedkey sec-level compatible 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 set vpn HO-VPN proxy-id local-ip 0.0.0.0/0 remote-ip 0.0.0.0/0 any

Page | 31

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 Page | 32

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-toprivate 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. Page | 33

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 certificates 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 CAs 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 * * is a mandatory field

Page | 34

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 Authoritys 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 NetScreens 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: get pki x509 list ca-cert

Page | 35

DYNAMIC PEER VPNS


If a remote site has a dynamically assigned IP address (SOHO sites) it is not possible to define the remote gateways 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 outgoinginterface phy-interface preshare preshared-key proposal p1-proposal Digital Certificates set ike gateway gw-name address remote-gw aggressive local-id local-id outgoinginterface phy-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 Where the peer-id defined on the recipient device is the local-id defined on the initiator device.

Page | 36

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. 2. 3. 4. 5. Build transport mode IPSec VPN between host-1 and GW-1 Build transport or tunnel mode IPSec VPN between GW-1 and GW-2 Build transport mode IPSec VPN between GW -2 and server-1 Do source-NAT and MIP on GW-1 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 Page | 37

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 VPN Configuration on host-1 and host-2

Page | 38

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 srcnat. 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. For the NAT-dst two options are available for permitting inbound traffic:

Page | 39

Policy-based NAT-dst: A policy can apply NAT-dst to translate inbound VPN traffic to an address that is either in the same subnet as the tunnel interface (but not in the same range as the local DIP pool used for outbound VPN traffic) or to an address in another subnet to which the NetScreen device has an entry in its route table. Mapped IP (MIP): A policy can reference a MIP as the destination address. The MIP uses an address in the same subnet as the tunnel interface - but not in the same range as the local DIP pool used for outbound VPN traffic.

CONFIGURING A VPN FOR OVERLAPPING NETWORKS


In this example we have two overlapping networks with Policy-based NAT-src and NAT-dst in order allowing connectivity between servers on each network Site A Interfaces: set interface interface zone untrust set interface interface ip siteA-external-IP/mask(octet) set interface tunnel.1 zone untrust set interface tunnel.1 ip siteA-tunnel-IP/mask(octet) Configure the DIP pool: set interface tunnel.1 dip dip-id dip-start dip-end The DIP pool needs to be configured in the same network range as the tunnel interface IP, but cannot include the tunnel interface IP address itself. Addresses: set address trust SiteA-Net ipaddress/mask(octet) set address trust siteA-NAT-IP ipaddress/mask(octet) This address entry represents the NAT IP address of the server residing on the Site A network that we will use in the Policy NAT-dst. set address untrust SiteB-Net ipaddress/mask(octet) As the Site B network is NAT-src using the DIP configured on Site Bs tunnel interface, this entry uses the IP address of the DIP since that is what Site A sees the source IP address as. set address untrust siteB-NAT-IP ipaddress/mask(octet) This entry represents the NAT IP address that Site B will use for its Policy NAT-dst. Routes: set vrouter untrust-vr route siteB-Net/mask(octet) interface tunnel.1 This route entry represents the entire network assigned to Site Bs tunnel interface. set vrouter trust-vr route siteA-NAT-IP/mask(octet) interface trust-interface This entry is required for NAT-dst to function. set vrouter untrust-vr route 0.0.0.0/0 interface interface gateway default-gw Policies: set policy from trust to untrust SiteA-Net to siteB-NAT-IP any nat src dip-id dip-id permit set policy from untrust to trust SiteB-Net to SiteA-Net any permit

Page | 40

GENERIC ROUTING ENCAPSULATION ON TUNNEL INTERFACES


Encapsulating multicast packets in unicast packets is a common method for transmitting multicast packets across a non-multicast-aware network and through IPsec tunnels, this is also known as tunnelling the protocol but not to be confused with the VPN tunnel. Generic Routing Encapsulation (GRE) version 1 is a mechanism that encapsulates any type of packet within IPv4 unicast packets. Juniper Networks Firewalls support GREv1 for encapsulating IP packets in IPv4 unicast packets. For additional information about GRE, refer to RFC 1701, Generic Routing Encapsulation (GRE). You enable GRE encapsulation on tunnel interfaces and must enable GRE when you transmit multicast packets through an IPsec VPN tunnel between a NetScreen and a third-party Firewall or router. Firewalls have platform-specific limitations on the number of outgoing interfaces through which they can transmit multicast packets. In large hub-and-spoke VPN environments where the Firewall is the hub, you can avoid this limitation by creating a GRE tunnel between the router upstream of the hub-site Firewall to Firewalls at the spokes. Router-A is upstream of Device-A. Router-A has two GRE tunnels which terminate at Device-1 and Device-2. Device-A is connected to Device-1 and Device-2 through VPN tunnels. Before Router-A transmits multicast packets it first encapsulates them in IPv4 unicast packets. Device-A receives these packets as unicast packets and sends them through to Device-1 and Device-2.

In this example, you configure the tunnel interface on Device-1. You perform the following steps: Page | 41

1. 2. 3. 4. CLI

Create the tunnel.1 interface and bind it to ethernet3 and to the Untrust zone on the trust-vr. Enable GRE encapsulation on tunnel.1. Specify the local and remote endpoints of the GRE tunnel.

set interface tunnel.1 zone untrust set interface tunnel.1 ip unnumbered interface ethernet3 set interface tunnel.1 tunnel encap gre set interface tunnel.1 tunnel local-if ethernet3 dst-ip 3.3.3.1 save

Page | 42

VPN QUESTIONS
QUESTION 1 You have created a VPN to a dynamic peer. Which two configured parameters must match? (Choose two.) A. static side peer-id B. dynamic side local-id C. static side IP address D. dynamic side IP address QUESTION 2 What do you need to change in your IPSec VPN configuration to use certificates for authentication? A. Replace the pre-shared key with the certificate name B. Select PFS in Phase 2, then select the certificate to be used. C. Use a custom set of Phase 1 proposals, all beginning with rsaD. Use a custom set of Phase 2 proposals, all beginning with rsaQUESTION 3 You have enabled RIP in a hub and spoke VPN environment using demand circuits. You are not receiving routes from one of your spokes although the VPN is up. When you debug RIP on the spoke device you see regular RIP updates being generated on the tunnel interface. You are receiving and sending routes to the rest of your spokes. What is the problem? A. You did not disable split horizon on the spoke device B. You did not configure demand circuit on the spoke device C. You did not configure passive interface on the spoke device D. You did not configure a RIP neighbor for the spoke device on the hub QUESTION 4 Which two statements regarding NHTB are correct? (Choose two.) A. If the spoke device is not a ScreenOS device, manual configuration of NHTB is required on the hub B. If the spoke device is not a ScreenOS device, manual configuration of NHTB is required on the spoke C. When configuring routing on a spoke device with one tunnel interface, the route to the tunnel interface does not require a routing gateway address D. When configuring routing on a hub device with one tunnel interface terminating multiple VPN spokes, the route to the tunnel interface does not require a routing gateway address

Page | 43

QUESTION 5 In the exhibit, which two must you configure on the SSG 550 to successfully establish a VPN?

A. B. C. D.

default route local-id of 1.1.2.5 peer-id of 1.1.1.10 tunnel interface associated with VLAN1

Page | 44

NETWORK MANAGEMENT
NetScreen firewalls provide two main forms of management: the WebUI and the CLI. NetScreen Security Manager (NSM) is outside of the scope of and not a requirement for the JNCIS-FWV exam. Management of a NetScreen firewall is not only restricted to how it is managed, but also refers to the status of the firewall and the traffic passing through it.

MANAGE/R IPS
Two of the most important concepts in regards to the management of NetScreen firewalls are Manage IPs and Manager IPs (its important not to confuse them). All local and remote management is configured per interface with the exception of direct console access. You can enforce which interfaces will allow management traffic, the type of management methods allowed and the IP address to be used for management.

MANAGE IP
A management interface will generally be configured to use an assigned IP address for management and network connectivity. When NetScreens are configured in clusters, or for increased security the management IP address can be hidden from users by using an IP address assigned to an interface for the sole purpose of management and this is the Manage IP. Configuring a Manage IP In order to configure a Manage IP on an interface, issue the following command: set interface interface manage-ip manage-ip Where manage-ip is the IP address you would like assigned to the interface for management. The Manage IP address must be on the same network as the IP address assigned to the interface. When the Manage IP address is assigned, the interface will respond to ARP requests for its own IP address as well as the Manage IP address. NOTE: When a Manage IP address is assigned to an interface, the IP address of the interface itself can no longer be used to manage the firewall. To view the Manage IP assigned to an interface, simply view the interface properties using the following command: get interface interface Output: Interface ethernet1: number 0, if_info 0, if_index 0, mode route link up, phy-link up/half-duplex vsys Root, zone Trust, vr trust-vr dhcp client disabled PPPoE disabled Page | 45

*ip 10.0.31.1/24 mac 0040.ac24.12f1 *manage ip 10.0.31.2, mac 0040.ac24.12f1 route-deny disable ping enabled, telnet disabled, SSH enabled, SNMP disabled web enabled, ident-reset disabled, SSL enabled webauth disabled, webauth-ip 0.0.0.0 RIP disabled bandwidth: physical 100000kbps, configured 0kbps, current 0kbps total configured gbw 0kbps, total allocated gbw 0kbps DHCP-Relay disabled DHCP-server disabled NOTE: Interface and Manage IP are different

MANAGER-IP
A Manager-IP is the IP address of a host, range of hosts or network address range that can access the NetScreen for management. Manager-IPs are global and once defined apply to all interfaces. However, by default, no Manager-IPs is configured so the NetScreen firewall can be managed from ANY IP address. To increase security you should add the relevant local hosts for local management, and remote hosts for remote management. Add a Manager-IP: set admin manager-ip ip-address subnet-mask To view currently configured Manager-IPs: get admin manager-ip

MANAGEMENT METHODS
The main methods for management are CLI based, WebUI based or through the NetScreen Security Manager (NSM) as discussed above. However, in order to manage a NetScreen firewall using any of the above management methods you must enable it on the relevant interface. To view the management method in use: get interface interface Output: Interface ethernet1: number 0, if_info 0, if_index 0, mode route link up, phy-link up/half-duplex vsys Root, zone Trust, vr trust-vr dhcp client disabled Page | 46

PPPoE disabled *ip 10.0.31.1/24 mac 0040.ac24.12f1 *manage ip 10.0.31.2, mac 0040.ac24.12f1 route-deny disable ping enabled, telnet disabled, SSH enabled, SNMP disabled web enabled, ident-reset disabled, SSL enabled webauth disabled, webauth-ip 0.0.0.0 RIP disabled bandwidth: physical 100000kbps, configured 0kbps, current 0kbps total configured gbw 0kbps, total allocated gbw 0kbps DHCP-Relay disabled DHCP-server disabled NOTE: SSH, web and SSL management methods have been enabled.

THE CLI
The three CLI interfaces are telnet, SSH and console and when using CLI management method remember configurations are not automatically saved. Use the save command after configuration to ensure they are written to memory.

SERIAL CONSOLE
This option gives you CLI access to the firewall Serial Console via a nine-pin female serial connection and is used to initially connect to your device and to conduct out-of band management. There are certain benefits to using a serial console that you do not get from using any other type of connection. The console provides a secure, physical, and dedicated access. Network connectivity issues cannot interrupt this type of connection, and no one can intercept your management traffic. It is completely secure because of its direct connection. When configuring over a serial port, you are not using any network connectivity so when you need to change Internet Protocol (IP) addressing on the firewall and guarantee connectivity using the serial console is the ideal solution. Also only the serial console can allow you to view and interact with the booting process. The details below outline the proper connection settings when connecting with a serial terminal, or serial terminal emulator.

THE SERIAL TERMINAL SETTINGS


Setting Speed Character Size Parity Stop Flow Control Page | 47 Value 9600 bps 8 Bit None Bit 1 None

CONFIGURING SSH MANAGEMENT


To configure SSH management for a given interface, SSH must first be enabled and the RSA key pairs generated. Enable SSH set ssh version v1|v2 set ssh enable The key pairs are generated when ssh is enabled. Once SSH has been enabled configure the SSH management method on the relevant interface. For the relevant interface: set interface interface manage ssh Configuring Telnet Management To configure telnet management: set interface interface manage telnet

WEBUI
The Web User Interface (WebUI) management method is accessed through standard HTTP or more securely through SSL. SSL management requires the loading of a digital certificate. NetScreen firewalls cannot generate their own digital certificate for the purposes of anagement. Configuring HTTP (Web) Management Enable web management for a given interface: set interface interface web Configuring SSL Management Once you obtain a digital certificate you enable web management for a given interface as follows: set interface interface ssl

USER PRIVILEGES
An administrative user should only have enough privilege to perform their given task and NetScreen firewalls provide five categories of administrative users: root, root system write/read, root system read only, virtual system write/read virtual system read only.

Page | 48

Configuring User Privileges To configure an administrative user with privileges: Set admin user username password password privilege all | read-only Root User The root user has the following privileges: Manages the root system of the NetScreen device Adds, removes, and manages all other administrators Establishes and manages virtual systems, and assigns physical or logical interfaces to them Creates, removes, and manages virtual routers (VRs) Adds, removes, and manages security zones Assigns interfaces to security zones Performs asset recovery Sets the device to FIPS mode Resets the device to its default settings Perform debugging (including snoop) Updates the firmware Loads configuration files Clears all active sessions of a specified admin or of all active admins Root System Write/Read Users An administrator with write/read privileges has the same level of privilege as the root administrator but cannot add, modify or remove any other administrative users. Write/read administrators also have the following privileges: Creates virtual systems and assigns a virtual system administrator for each one Monitors any virtual system Tracks statistics Root System Read Only Users The read-only administrator has only viewing privileges using the WebUI and can only issue the get and ping CLI commands. Read-only administrator has the following privileges: Read-only privileges in the root system, using the following four commands: enter, exit, get, and ping Read-only privileges in virtual systems

Page | 49

Virtual System Write/Read Users Virtual system administrators manage virtual systems independently through the CLI or WebUI. On each virtual system, virtual system write/read administrator has the following privileges: Creates and edits auth, IKE, L2TP, XAuth, and Manual Key users Creates and edits services Creates and edits policies Creates and edits addresses Creates and edits VPNs Modifies the virtual system administrator login password Creates and manages security zones Adds and removes virtual system read-only administrators Virtual System Read Only Users A virtual system read-only administrator has the same privileges as a read-only administrator only within their allocated virtual system.

INTERPRET INTERNAL COUNTERS AND LOGS


NetScreen firewalls provide different log files providing information about a different aspect of the firewall.

SELF LOG
Self-log monitors and records all packets terminating at the NetScreen device (e.g. management and VPN traffic). Enable self-logging: set firewall log-self Once enabled the NetScreen firewall will log the traffic in both the self-log and the traffic log. NOTE: Self log entries typically have a source zone of null and a destination zone of self View the self-log: get log self To view the event log: get event Output: 2008-03-11 11:35:47 system notif 00015 Infranet Enforcer could not connect to Infranet Controller VM IC (ip 172.25.69.168). 2008-03-11 11:35:47 system notif 00015 Infranet Enforcer could not connect to the Infranet Controller because the Page | 50

Controller could not be reached on the network. 2008-03-11 11:35:47 system notif 00535 PKI: Failed to obtain CRL for CA issuing cert with subject name CN=vm-ic.testlab.local,O=JTAC,. 2008-03-11 11:35:47 system notif 00535 PKI: Cannot compose HTTP packet to send to URL ca.testlab.local

It is also possible to view specific levels of the event log by issuing the following command: get event level emergency | alert | critical | error | warning | notification | information | debugging

TRAFFIC LOG
If logging is enabled for a particular security policy, log entries are created in the traffic log and the following elements are noted for each session: Date and time that the connection started Source address and port number Translated source address and port number Destination address and port number Translated destination address and port number The duration of the session The service used in the session

NOTE: By viewing the traffic log for a given policy, you can determine the NAT-src and NAT-dst applied to traffic after it has traversed the firewall. Reference a security policy which has the logging option enabled: get log traffic policy policy-id

Page | 51

COUNTERS
Counters provide statistical information about the firewall including traffic flow information, number of Screens and interface details such as the number of packet failures. Counters can be used to monitor a firewall to ensure the traffic is behaving normally, and where to troubleshoot if there is an issue.

FLOW COUNTERS
Flow counters provide information about the traffic received by and sent through an interface or zone. They can be used to determine the amount of bandwidth through an interface or zone and the number of malicious, abnormal or corrupted packets received by an interface or zone e.g. attacks and failed packets including VLAN and VPN packets. Obtaining Flow Counters: Flow counters for all interfaces: get counter flow Flow counters for individual interfaces: get counter flow interface interface Obtain the flow counters for a specific zone: get counter flow zone zone Screen Counters: Screen counters display the number of packets monitored and rejected through a zones Screen options. Obtaining Screen Counters: get counter screen zone zone Hardware Counters: Obtain hardware counters for a given interface: get counter statistics interface interface

Page | 52

Policy Counters: Policy counters display bandwidth utilisation information for a given security policy. To obtain counter statistics for a security policy the count option is required to be configured for the policy. Policy counters can assist in determining bandwidth management settings to be applied to a certain security policy. Obtain policy counter statistics for a given security policy: get counter policy policy-id

CONFIGURE SYSLOG.
NetScreen firewalls have no permanent storage media to store log information. To permanently retained logs a Syslog server can be configured so the firewall can transfer logging information. Up to four Syslog servers can be configured and the NetScreen device can generate different Syslog messages at predefined security levels as well as traffic log information. For each Syslog server, you can specify the following attributes: To include traffic log entries, event log entries, or both To send traffic through a VPN tunnel to the syslog server and which interface to use as the source interface The port to send Syslog messages The security facility, which classifies and sends emergency and alert level messages to the Syslog host; and the regular facility, which classifies and sends all other messages for events unrelated to security

CONFIGURING A SYSLOG SERVER


Configure a NetScreen firewall to use a Syslog server: set syslog config syslog-server-IP port syslog-port Where syslog-port is the port the Syslog server is listening on. set syslog config syslog-server-IP log event | traffic | all set syslog config syslog-server-IP facilities security-facility facility Security-facility and facility can be level0 to level7 (security facility is used to log critical security events where the facility is used to log all other events). set syslog config syslog-server-IP transport protocol Protocol can be TCP if Syslog over TCP is desired set syslog enable

Page | 53

LOGGING LEVELS
The event log monitors and records system level events such as configuration changes and errors. These events can be categorised into a series of levels: Emergency: Alert: More than 3 authentication failures WinNuke attacks IP Spoofing attacks Source Route Option attacks LAND attacks ICMP floods Event Log The event log monitors and records system level events such as configuration changes and errors. These events can be categorised into a series of levels: Emergency. Includes messages such as: SYN attacks Tear Drop attacks Ping of Death attacks Alert. Includes messages such as: More than 3 authentication failures WinNuke attacks IP Spoofing attacks Source Route Option attacks LAND attacks ICMP floods SYN attacks Tear Drop attacks Ping of Death attacks

Critical: Error: SSH negotiation failures AV Scanning issues Bad packet settings Blocked traffic through Screen options Issues with High Availability Low resources VIP connectivity issues SSH failures VPN monitoring status changes Dynamic Routing errors

Page | 54

Warning: SMTP issues Administrative logins/outs/failure (single failure) SYSLOG status and failures Local/External Authentication success/failure

Notification: Configuration changes initiated by an administrator. Failures which do not affect the functioning of the firewall. Debugging: Detailed information used for debugging purposes.

CONFIGURE SNMP
The Simple Network Management Protocol (SNMP) agent for the security device provides network administrators a way to view statistical data about the network and the devices on it and to receive notification of system events of interest. Juniper Networks security devices support the SNMPv1, the SNMPv2c, and the SNMPv3 protocols. SNMPv1 and SNMPv2c Implementation Overview Juniper Networks has implemented SNMP in its devices in the following ways: SNMP administrators are grouped in SNMP communities. A device can support up to three communities, with up to eight members in each community. A community member can be either a single host or a subnet of hosts, depending on the netmask you use when defining the member. By default, the security device assigns an SNMP community member with a 32-bit Netmask (255.255.255.255), which defines it as a single host. If you define an SNMP community member as a subnet, any device on that subnet can poll the security device for SNMP MIB information. However, the security device cannot send an SNMP trap to a subnet, only to an individual host. Each community has either read-only or read/write permission for the MIB II data. Each community can support SNMPv1, SNMPv2c, or both. If a community supports both versions of SNMP, you must specify a trap version for each community member. You can allow or deny receipt of traps for each community. You can access the MIB II data and traps through any physical interface. Each system alarm (a system event classified with a severity level of critical, alert, or emergency) generates a single enterprise SNMP trap to each of the hosts in each community that is set to receive traps. The security device sends Cold Start/Link Up/Link Down traps to all hosts in communities that you set to receive traps. If you specify trap-on for a community, you also have the option to allow traffic alarms. You can send SNMP messages through a route-based or policy-based VPN tunnel.

Page | 55

Juniper Networks has implemented SNMPv3 in its devices in the following ways: An administrator can define a USM user in the SNMPv3 framework. A device can support up to 32 users. The security device administrator can create the view-based access control model (VACM) views. Each view is tagged with an object identifier and mask values. A device can support up to 32 VACM views. The security device administrator can create a VACM access group. For each access group you can define the security model, security level, and the privilege access. A device can support up to 32 VACM access groups. The security device administrator can create a group to map an SNMPv3 USM user, an SNMPv1 community, or an SNMPv2c community, in combination with a VACM access group. The security device administrator can configure an SNMPv1 or SNMPv2c community under an SNMPv3 framework. In an SNMPv3 community, the administrator can enforce access control to SNMPv1 or SNMPv2c requests as well. Each community has a tag name. The administrator can configure the trap details such as filters, target parameters, and target address. The SNMPv3 filters are configured by an administrator. A device can support up to 32 SNMPv3 filters. Each filter is attached to a target (host). The target parameter is used when sending a trap to a target. The administrator can configure a SNMPv3 target parameter and a device can support up to 32 target parameters. Each target has an IPv4 or IPv6 address/netmask. You can enter both the IPv4 and IPv6 addresses. The system sends the trap to the target if the mask is 32 for IPv4 addresses or 128 for IPv6 addresses. Each target has a trap port and a tag. You can specify 8 tags to a target.

CONFIGURING SNMP
Define an SNMP community: set snmp contact admin-contact set snmp location physical-local set snmp auth-trap enable set snmp community community-name privilege trap-on version version Privilege = read-write or read-only and version can be v1, v2c or any set snmp host community-name community-member-IP/32 trap version Version can be v1, v2c or any. Enable SNMP on the relevant interface: set interface interface manage snmp Page | 56

NETWORK MANAGEMENT QUESTONS


QUESTION 1 You are concerned about log entries being overwritten and would like to save this valuable information on an external system. Which three systems will work with ScreenOS devices to accomplish this goal? (Choose three.) A. B. C. D. E. SNMP WebSense WebTrends SYSLOG server NetScreen Security Manager

QUESTION 2 Which two of the following statements regarding SYSLOG are true? (Choose two.) A. B. C. D. You can specify the source address of SYSLOG traffic. You can specify the source interface for SYSLOG traffic. You can encrypt SYSLOG traffic from within the SYSLOG configuration. You can send SYSLOG messages via TCP on a per-SYSLOG server basis.

QUESTION 3 Which of the following is true about the ScreenOS SNMP implementation? A. B. C. D. ScreenOS supports SNMP v1 or v2c on a per-SNMP server basis. You can set traps on a per-community-string basis. ScreenOS supports only two communities: public and private. You can include traffic alarms on a per-SNMP server basis.

Page | 57

TROUBLESHOOTING WITH DEBUG/SNOOP


NetScreen firewalls provide debug and troubleshooting tools to help quickly identify problems. To troubleshoot NetScreen traffic flows the available commands are Snoop and Flow Filter. Debug Buffer: NetScreen firewalls have a debug buffer known as the dbuf used to store debug events so when you enable a particular debug, the events relating to it are recorded into the dbuf. Viewing the dbuf: View the contents of the dbuf: get dbuf stream Clearing the dbuf: it is often necessary to clear the dbuf to obtain the newer events. To clear the contents of the dbuf: clear dbuf Manipulating the dbuf: As the dbuf resides in memory with a dedicated size, the filling of the buffer will result in the event wrapping where newer events will begin overwriting older events. In order to avoid this, the size of the dbuf can be increased (or decreased to save memory). To change the allocated memory amount for the dbuf, issue the command: set dbuf size size Where size is between 32 to 4096 Kilobytes of memory

SNOOP
Snoop allows you to view the traffic flow traversing in and out of a NetScreen firewall. Snoop is used to confirm traffic is reaching the firewall on a particular interface and leaving on the appropriate interface. It can also be used to determine layer 2 issues. All events, including those generated by Snoop, are recorded in dbuf. To enable Snoop: snoop The amount of information that Snoop will display (standard or detailed) can be enabled: snoop detail To change the Snoop mode to standard, issue the command: snoop detail off View configuration of Snoop: Page | 58

snoop info Disabling Snoop: snoop off Or by pressing the ESC key

FILTERING SNOOP
Snoop filter commands require the filter command to be added. For example, snoop filter ip ip Snoop a single host: snoop ip ip ip-address Source Host snoop ip src-ip ip-address Destination Host snoop ip dst-ip ip-address Snooping a Port (a bi-directional filter): snoop ip port port-number Source Port snoop ip src-port port-number Destination Port snoop ip dst-port port-number Snooping an Interface snoop ip interface interface Snooping an IP-Protocol snoop ip ip-proto protocol-number Manipulating Filters with AND Logic snoop ip dst-ip ip-address snoop ip dst-port port-number Snoop will capture packets that contain the destination IP address AND destination port number.

Page | 59

SNOOP OUTPUT
After Snoop captures traffic to retrieve the messages from the dbuf and analyse the output Obtain the events captured by Snoop: get dbuf stream Output: 35455.0 : 4(i):0010db1c5921->0010db1b44b4/0800 10.1.10.5->1.1.70.250/1, tlen=128 vhl=45, tos=00, id=49627, frag=0000, ttl=63 Line 1 contains the following information: timer 35455.0, indicates the time the packet was received interface information 4(i) indicates the physical interface used and the direction of the packet. (Use the formula [n 3] where n is the number displayed by the output. E.g. 4 3 = 1 = Ethernet1. The character in the brackets indicates direction: o (i)= inbound o (o) = outbound The source and destination MAC address - 0010db1c5921->0010db1b44b4 The protocol type in use 0800

Line 2 contains the following information: source and destination IP addresses - 10.1.10.5->1.1.70.250 the IP protocol used - 1 the length of the datagram in bytes - tlen=128

Line 3 contains the following information: the protocol version and header length. IP version 4 header length of 5 32 bit words. vhl=45 the Type of Service - tos=00 the ID of the datagram - id=49627 has the packet been fragmented - frag=0000 the Time To Live for the packet - ttl=62

Other packet types: 05375.0: 0(i):00b0d080b93e->0010db06eeb0/0800 10.1.10.5->2.2.2.222/6, tlen=48 vhl=45, id=7015, frag=4000, ttl=128 ports 2459->21, seq=3821340563, ack=0, flag=7002/SYN 1(o):0010db06eeb1->ffffffffffff/0806 q 0010db06eeb1/2.2.2.10->2.2.2.222 1(i):0010a4a77630->0010db06eeb1/0806 r 0010a4a77630/2.2.2.222->2.2.2.10

05375.0: 05375.0:

Page | 60

A TCP packet /6 has arrived on the Trust interface 0(i) from 10.1.10.5 destined to 2.2.2.222 on port 21. We can tell this packet is a SYN packet as the ACK field is blank ack=0 and the flag is set to SYN /SYN. A SYN/ACK packet would have an acknowledgement ID as well as the SYN flag set. An ACK would simply have an acknowledgement ID and no SYN flag. An ARP request q /0806 being broadcasted ffffffffffff from the MAC address of Untrust interface 0010db06eeb1 for the destination IP 2.2.2.222. The Untrust interface then receives 1(i) an ARP reply r /0806 containing the MAC address of the destination 0010a4a77630.

FLOW FILTERS
Flow Filters are an extremely detailed account of packets arriving at the firewall and how they are processed and are used to determine: if NAT has been applied and which type routing lookups and decisions made policies applied how the packet was delivered

Flow Filters is that they ONLY capture incoming traffic, that is, you will never see a packet leaving the firewall in a Flow Filter capture. As such, the Flow Filter capture will not see traffic initiated from the firewall itself as it is not regarded as incoming traffic. Enabling Flow Filters Flow Filters are filters applied on the firewall to monitor the flows of traffic. To enable a flow filter to monitor traffic, define the following two things: the actual filter the debug command

To enable the debug for Flow Filters: debug flow basic | detail Flow Filter for the Destination Host set ffilter dst-ip ipaddress Flow Filter for the Source Host set ffilter src-ip ipaddress Flow Filter for the Destination Port set ffilter dst-port port-number Flow Filter for the Source Port set ffilter src-port port-number Flow Filter for the Protocol Type set ffilter src-port port-number Page | 61

Viewing Flow Filters get ffilter Output: Flow filter based on: id:0 dst ip 1.1.1.1 id:1 src ip 192.168.1.1 each flow filter has a unique ID Removing Flow Filters unset ffilter id NOTE: Flow filters can only be removed one at a time.

COMBINING FLOW FILTERS WITH AND LOGIC


It is possible to create a flow filter that applies AND logic to the capture but there are some restrictions. It is only possible to combine two arguments together into a single flow filter statement and only certain combinations of filters are allowed to be combined together. To create a flow filter with AND logic: set ffilter 1st-argument 1st-property 2nd-argument 2nd-property Example: set ffilter dst-ip 10.1.1.10 dst-port 80 Output: Flow filter based on: id:0 dst ip 10.1.1.10 dst port 80 It is entered as a single filter with a single ID. Arguments that cannot be combined together: The same argument twice (i.e. src-port src-port) Combine a src-ip and dst-ip If a port/proto filter is used for the first argument, then a port command must also be used for the second argument (the exception being the dst-port as it cannot be added to if it is used as the first argument)

Page | 62

UNDERSTANDING FLOW FILTER OUTPUT


Debug captures are sent to a buffer by default but can be sent the console. Buffer commands: get dbuf info get dbuf stream set dbuf size clear dbuf

- Displays debug buffer size in bytes - Displays the contents of the debug buffer - Allocates system memory for the debug buffer - Clears the contents of the debug buffer

Here are best practices when debug flow basic and how to read the output. Debug Flow basic: get ffilter - see if any filters have been set already, if they have use unset ffilter to remove them set ffilter - limit the traffic you capture using src-ip, src-port, dst-ip, dst-port, ip-proto. This is recommended as debug flow basic is intensive on the firewall. o o filters written on one line use an 'AND' statement. e.g. set ffilter scr-ip 10.1.1.1 dst-ip 2.2.2.2 matches both 10.1.1.1 AND 2.2.2.2 filters on separate lines are 'OR' statements. e.g. set ffilter scr-ip 10.1.1.1, set ffilter dst-ip 2.2.2.2 matches 10.1.1.1 OR 2.2.2.2

debug flow basic - turns on flow debugging with a level of basic logging clear db - make sure there is nothing in the debug buffer from previous debugs Begin the test, do a ping or try to access the resource that you are having problems with. undebug all or press Esc key turns off debug get db str - reads the debug buffer and outputs it to the screen for reading. unset ffilter - removes ffilters when finished

JUNIPER FIREWALL PACKET PROCESS

Page | 63

READING A DEBUG FLOW BASIC


FW-> get dbuf stream ****** 15625.0: <private/ethernet0/5> packet received [60]****** - This is the interface and zone that the packet arrives on ipid = 34344(8628), @02cdf8b0 packet passed sanity check. ethernet0/5:10.1.1.5/17152->1.1.70.250/256,1(8/0)<Root> - This is the packet IP info ports and protocol no session found - Looks for existing sessions on the firewall flow_first_sanity_check: in <ethernet0/5>, out <N/A> chose interface ethernet0/5 as incoming nat if. - There is NAT on the interface flow_first_routing: in <ethernet0/5>, out <N/A> search route to (ethernet0/5, 10.1.1.5->1.1.70.250) in vr trust-vr for vsd-0/flag-0/ifp-null [ Dest] 10.route 1.1.70.250->0.0.0.0, to ethernet0/6 - matches route 10 in the trust-vr routing table routed (x_dst_ip 1.1.70.250) from ethernet0/5 (ethernet0/5 in 0) to ethernet0/6 policy search from zone 104-> zone 103 - Tells you which policy set its going to look at zone to zone derived from routing policy_flow_search policy search nat_crt from zone 104-> zone 103 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 1.1.70.250, port 2396, proto 1) No SW RPC rule match, search HW rule Permitted by policy 2 - Tells you which policy the traffic has hit and what the action is No src xlate choose interface ethernet0/6 as outgoing phy if no loop on ifp ethernet0/6. session application type 0, name None, nas_id 0, timeout 60sec service lookup identified service 0. flow_first_final_check: in <ethernet0/5>, out <ethernet0/6> existing vector list 1-4339cf0. Session (id:8061) created for first pak 1 - session created for future packes in the session flow_first_install_session======> route to 1.1.70.250 arp entry found for 1.1.70.250 - firewall arps for where it is going to route packet to. nsp2 wing prepared, ready cache mac in the session make_nsp_ready_no_resolve() search route to (ethernet0/6, 1.1.70.250->10.1.1.5) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/5 [ Dest] 12.route 10.1.1.5->0.0.0.0, to ethernet0/5 route to 10.1.1.5 flow got session. flow session id 8061 post addr xlation: 10.1.1.5->1.1.70.250. - shows if there has been and address translation and how the packet looks when it is sent out.

THINGS TO LOOK FOR WHEN THERE ARE PROBLEMS


Packet dropped, no route to host - no route has been found in the virtual router that the interface and zone is bound to and that the packet arrived on. Look in the routing table for a route for the destination or source (depending how you are routing). Packet dropped, denied by policy - If a message saying searching global policy is just before this no policy has been matched so it has been dropped by default. Check your policy configuration. Policy match - Check the policy match to ensure it is matching the correct policy and not allowed or denied by another rule Check any NAT is happening that needs to.

Page | 64

TROUBLESHOOTING WITH DEBUG/SNOOP QUESTONS


QUESTION 1 Which command shows the present debugging configuration? A. B. C. D. get conf get dbuf get debug debug info

QUESTION 2 In the output shown, which single command is entered out of order?

A. B. C. D.

set ffilter clear db get dbuf stream debug flow basic

QUESTION 3 You enter the following commands:


snoop filter ip dst-ip 1.1.1.10 snoop filter ip src-ip 2.1.1.10

What is the net result of these settings?


A. Only packets with both a dst-ip of 1.1.1.10 and a src-ip of 2.1.1.10 will be captured B. Packets that have either a dst-ip of 1.1.1.10 or packets with a src-ip of 2.1.1.10 will be captured C. The second command will be ignored since a second filter cannot be added until the first one has been deleted

D. The second command you entered will overwrite the first command you entered so you will
only capture traffic with a src-ip of 2.1.1.10

Page | 65

TRAFFIC MANAGEMENT
One of the inbuilt features of a NetScreen firewall is traffic and bandwidth management capability. As the firewall is often the bottle-neck in a large network environment, deciding which traffic is more important when going out to the MPLS or Internet cloud becomes important.

DESCRIBE THE BANDWIDTH ALLOCATION PROCESS.


Interface Bandwidth Bandwidth refers to the total bandwidth for a given interface path e.g., if the external interface 100Mb is connected to a router with a 10Mb interface which connects to the Internet with a 2Mb connection the total bandwidth for that path is 2Mb. To configure the maximum bandwidth for a given interface: set interface interface bandwidth total-bw (total-bw is the total bandwidth in Kbps) Guaranteed Bandwidth Guaranteed bandwidth is the amount of bandwidth that must be allocated to a security policy when it is demanded e.g., if the total bandwidth available on an interface is 1Mb, and you assign a guaranteed bandwidth of 512Kb for a policy there is only 512Kb remaining if the policy consumes its guaranteed bandwidth. For high priority traffic security policies should all be assigned a guaranteed bandwidth. There is no priority for guaranteed bandwidth, as the bandwidth is guaranteed. Maximum Bandwidth After all guaranteed bandwidth has been allocated the remaining amount is assigned to the maximum bandwidth pool. This is allocated on a priority basis. When configuring bandwidth management for a policy you can specify the maximum bandwidth e.g. the most bandwidth, including the guaranteed bandwidth that the security policy can have allocated to it. An interface has 640Kb bandwidth allocated to it and two security policies each have a guaranteed bandwidth of 256Kb and a maximum bandwidth of 128Kb. In this example the maximum bandwidth that can be allocated if both policies are fully utilising their guaranteed bandwidth is 128Kb. Both policies can then theoretically consume an additional 128Kb of the available 128Kb. So how is 128Kb allocated between two policies each wanting the same amount of remaining bandwidth? The remaining maximum bandwidth is assigned first to the policies with the highest priorities. After the highest level priority policies have been satisfied, the next priority level is allocated bandwidth and this continues until there is no remaining bandwidth in the maximum bandwidth pool or no further policies demand bandwidth.0 So if one policy has the highest priority and the other policy has a priority level of 2nd, all the remaining bandwidth would be consumed by the highest priority policy with none remaining for the other policy. When there is more than one policy on the same priority level vying for maximum bandwidth from the maximum bandwidth pool, the bandwidth is allocated on a round robin basis. Page | 66

POLICIES AND BANDWIDTH MANAGEMENT


Once interface bandwidth is configured bandwidth management controls can be added to security policies. It is recommended to baseline the traffic traversing the firewall to understand which applications are critical and how much bandwidth they consume prior to making configuration changes. Misconfiguring the bandwidth management aspects of security policies can cause traffic to be dropped. NOTE: The firewall does not prevent you from allocating more bandwidth than is available for the interface Despite security policies being stateful they are defined as unidirectional (from one host/network to another host/network). The amount of bandwidth you can allocate to a policy is reserved for this direction (outgoing or incoming).E.g. a policy from host A to host B with a bandwidth allocation of 10Kbps will have 10Kbps allocated for all traffic from host A to host B and will not reserve any bandwidth for the returning traffic from host B to host A (It would have to be configured on another policy for that direction).

QUEUING FUNCTIONALITY
Although the priority feature does not relate to guaranteed bandwidth it is necessary for maximum bandwidth allocation because as bandwidth management is assigned for one security policy, it is automatically enabled for all other security policies, regardless of whether they have bandwidth management configurations or not. If a policy does not have bandwidth management configurations, it is assumed that it has a guaranteed bandwidth of 0, and a maximum bandwidth of as much as it can have but at the lowest priority. Hence, we need to ensure that a policy with bandwidth configurations has a priority, even if that priority is also the default of lowest. The priority levels assignable are: High priority (0) 2nd priority (1) 3rd priority (2) 4th priority (3) 5th priority (4) 6th priority (5) 7th priority (6) Low priority (default) (7)

Unlimited maximum bandwidth is represented with a -1 The closer to 0, the HIGHER the priority

Page | 67

BANDWIDTH MANAGEMENT SETTINGS


There are three modes of traffic shaping for NetScreen Firewalls. Default Mode: In auto mode traffic shaping is turned on for all traffic the first time you configure a policy with traffic shaping. In auto mode when no traffic shaping is turned on traffic shaping is NOT applied. Traffic shaping to be on all the time: Enforces traffic shaping for all traffic even if you have not configured a policy with traffic shaping. The default traffic shaping options will be applied (no guaranteed bandwidth, unlimited maximum bandwidth, and lowest priority) to all traffic. Traffic Shaping always off Sets traffic: The same as when there is no traffic shaping policies configured. Use the CLI to configuration changes as they cannot be made from the WebUI. Traffic shaping Auto Sets traffic-shaping mode to auto. Traffic shaping always on Sets traffic-shaping mode to on. Traffic shaping always off Sets traffic-shaping mode to off.

NS5GT-> get traffic-shaping mode Traffic shaping is set to auto by user Traffic shaping is currently turned off by the system NS5GT-> set traffic-shaping mode on NS5GT-> get traffic-shaping mode Traffic shaping is set to on by user Traffic shaping is currently turned off by the system NS5GT-> set traffic-shaping mode off NS5GT-> get traffic-shaping mode Traffic shaping is set to off by user Traffic shaping is currently turned off by the system NS5GT-> set traffic-shaping mode ? Auto automatically turns on/off traffic shaping Off turn off traffic shaping/On turn on traffic shaping NS5GT-> set traffic-shaping mode auto NS5GT-> get traffic-shaping mode Traffic shaping is set to auto by user Traffic shaping is currently turned off by the system NS5GT->save NOTE: If more than one policy has the same priority level and wants the maximum bandwidth from the maximum bandwidth pool, the bandwidth is allocated on a round robin basis. Page | 68

LIST REQUIREMENTS/STEPS FOR CONFIGURING TRAFFIC MANAGEMENT


To configuring traffic shaping on a policy is straight forward but you need to determine the configuration for each policy. To configure traffic shaping on an existing policy use the following steps via the WebUI: Go to Policies Click Edit link of the policy you want to modify Click the Advanced button at the bottom of the page Enable the Traffic Shaping option Enter the desired Guaranteed Bandwidth (in kbps)

Note: A value of 0 indicates there is no guaranteed bandwidth configured. Enter the desired Maximum Bandwidth (in kbps).

Note: A value of 0 indicates there is no maximum bandwidth configured. Use Traffic Priority drop-down list to select the desired priority. To mark packets with DiffServ Codepoint Marking, enable the DiffServ Codepoint Marking option Click OK

Policy configuration via the CLI: NS5GT-> set policy from trust to untrust any any HTTP permit traffic gbw 100 priority 0 mbw 200 dscp enable policy id = 2 NS5GT-> get policy id 2 name:"none" (id 2), zone Trust -> Untrust,action Permit, status "enabled" src "Any", dst "Any", serv "HTTP" Policies on this vpn tunnel: 0 nat off, url filtering OFF vpn unknown vpn, policy flag 4000, session backup: on traffic shapping on, scheduler n/a, serv flag 00 log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0 total octets 0, counter(session/packet/octet) 0/0/0 priority 0, diffserv marking On tadapter: state on, gbw/mbw 100/200 No Authentication No User, User Group or Group expression set NS5GT-> set policy from trust to untrust any any FTP permit traffic gbw 0 priority 0 mbw 200 dscp enable policy id = 3 NS5GT-> get policy id 3 name:"none" (id 3), zone Trust -> Untrust,action Permit, status "enabled" src "Any", dst "Any", serv "FTP" Policies on this vpn tunnel: 0 nat off, url filtering OFF Page | 69

vpn unknown vpn, policy flag 4000, session backup: on traffic shapping on, scheduler n/a, serv flag 00 log no, log count 0, alert no, counter no(0) byte rate(sec/min) 0/0 total octets 0, counter(session/packet/octet) 0/0/0 priority 0, diffserv marking On tadapter: state on, gbw/mbw 0/200 No Authentication No User, User Group or Group expression set NS5GT-> save Configuring Traffic Shaping on a VPN Policy To shape traffic within a tunnel you must do so on the policy that is acting as the policy for the VPN. A policy-based VPN can be used to shape traffic that is traversing it. Example Parameters: Policy From Zone To Source Address Destination Address Service Action VPN Logging Traffic Shaping Guaranteed Bandwidth Maximum Bandwidth Trust Zone Untrust 10.1.1.10/24 192.168.1.0/24 FTP Tunnel ExampleVPN Enabled Enabled 800Kbps 1000Kbps

set policy from trust to untrust 10.1.1.10/24 192.168.1.0/24 ftp tunnel vpn ExampleVPN log traffic gbw 800 mbw 1000 save Configure Traffic Shaping on a Route-Based VPN The tunnel1.1 interface is bound to the Trust interface so it does not require a policy for traffic in the trust zone (No intrazone blocking in use for the Trust Zone). The VPN has been bound to the Tunnel1.1 Interface and routing created. Enable traffic shaping on the ingress interfaces to ensure the VPN gets appropriate connectivity. Example Parameters: Interface Ingress Maximum Bandwidth Interface Ingress Maximum Bandwidth Trust 100000Kbps Tunnel1.1 (bound to Trust interface) 1544Kbps

set interface Trust bandwidth ingress mbw 100000 set interface tunnel1.1 bandwidth ingress mbw 1544 save Page | 70

WARNING: When applying traffic shaping to encapsulated traffic take care as the firewall either cannot or does not inspect the traffic within the tunnel. As applying traffic shaping to the traffic will actually apply it to the tunnel and not the contents. This is a real issue with latency-sensitive traffic through a VPN. The tunnel will be shaped rather than the traffic within it and you will have significant quality and performance degradation. Enabling DSCP Class Mapping on the Firewall Enabling DSCP Class Selection on the firewall will ensure that traffic set with appropriate ToS (Type of Service) bits by other devices in the network gets the appropriate service. Configure through Juniper CLI: Example Parameters: DSCP Class Selection IP Precedence Set as Mode set traffic-shaping dscp-class-selector save Configuring DSCP Marking in a Policy Example Parameters: Policy From Zone To Zone Source Address Destination Address Service Action Logging Traffic Shaping Diffserv Code Marking DSCP Value Trust Untrust 10.5.0.10/16 192.168.1.0/24 SIP Permit Enabled Enabled Enabled 7 Enabled Defaults Auto

set policy from trust to untrust 10.5.0.10/16 192.168.1.0/24 sip permit log traffic dscp enable value 7 save

Page | 71

TRAFFIC MANAGEMENT QUESTONS


QUESTION 1 You create three policies that will send traffic through an interface configured for 1.544 Mbps. All policies are configured to have 256 Kbps guaranteed bandwidth and 512 Kbps of maximum bandwidth. Each policy has been assigned the following priorities: Policy 1 = priority 4 Policy 2 = priority 5 Policy 3 = priority 3 Each policy receives a constant stream of 1 Mbps. How much bandwidth will be available for Policy 2? A. B. C. D. 256 Kbps 512 Kbps 1.544 Mbps 1 Mbps

QUESTION 2 Which statement defines maximum bandwidth? A. The total amount of bandwidth (configured in Mbps) that can be used by a policy after guaranteed bandwidth has been serviced. B. The total amount of bandwidth (configured in Kbps) that can be used by a policy after all guaranteed bandwidth has been serviced. C. The additional amount of bandwidth over the guaranteed bandwidth amount (configured in Kbps) that can be used by a policy after guaranteed bandwidth has been serviced. D. The additional amount of bandwidth over the guaranteed bandwidth amount (configured in Mbps) that can be used by a policy after guaranteed bandwidth has been serviced.

Page | 72

QUESTION 3 You have four policies configured for the egress interface with 10 Mbps physical bandwidth. The policies are configured as follows: Policy 1 - Highest Priority, 2 Mbps guaranteed, 3 Mbps maximum Policy 2 - 1st Priority, 3 Mbps guaranteed, 4 Mbps maximum Policy 3 - 1st Priority, 3 Mbps guaranteed, 3 Mbps maximum Policy 4 - Highest Priority, 1 Mbps guaranteed, 4 Mbps maximum Assuming the policies are processed in the order shown, which policy will drop traffic first under a full traffic load? A. B. C. D. Policy 1 Policy 2 Policy 3 Policy 4

Page | 73

VIRTUAL SYSTEMS
A virtual system (vsys) is a logical firewall that is contained in a single physical firewall. A NetScreen Systems can be logically partitioned into multiple virtual systems to provide multitenant services. Each vsys is a unique and logically separate security domain, complete with its own set of administrators (virtual system administrators). Internet service providers (ISPs) or large organisations are the main users of virtual systems as satisfy the need for many firewalls in a single location. A virtual system is a unique security domain inside a Juniper firewall. Each virtual system contains its own address book, user lists, custom service definitions, VPNs, and policies. They also have their own virtual system administrators. These administrators are limited to accessing a specific virtual system. This limits the VSYS administrator to their own virtual system and keeps them out of other virtual systems and the root system.

DEFINE VSYS APPLICATIONS


In a vsys the physical firewall is regarded as the root system (rootsys). Virtual systems are only supported on NetScreen firewall Systems and a licence is required to enable this functionality. A vsys can only be created by the root administrator of the physical firewall or any other write/read administrator on that root system. To create a fully functional vsys, the administrator defines the vsys object and makes it functional by configuring its basic properties. Once defined, it creates three zones for its own use: Trust-vsys, Untrust-Tun-vsys Global-vsys.

NOTE: It shares the root systems Untrust zone and uses it as its Untrust zone. Defining a Virtual System You should give the vsys a name, assign a vsys administrator and have a default virtual router assigned to it that it can bind its zones to. The creation of a specific vsys administrator is optional. As a default one will be created with the vsys name as the username and password if one is not defined. It creates its own virtual router. Normally, the vsys will use this virtual router to bind all its zones to but it is possible to assign a root system virtual router (provided the virtual router is shared) for the vsys to bind all its zones to. Define a virtual system: set vsys vsys [ vrouter share vrouter ] set admin name admin-name set admin password password exit Page | 74

vrouter share vrouter - optional command to use a shared root system virtual router NOTE: Once you enter a vsys context, you leave the root system and control the vsys . Changing the Default Virtual Router To change the default virtual router of a virtual system from within the vsys: set vrouter vrouter default-vrouter Entering and Exiting a Virtual System A root or write/read admin of the rootsys can enter any vsys to administer and configure it. Once you enter a vsys, all configurations ONLY affects that particular vsys: enter vsys vsys To exit back to the root system enters the command exit.

DESCRIBE ROOT VS. VSYS ADMINISTRATION


Administration Below are details of the different user privileges and what they can and cant do within a vsys in relation to the Virtual System. Root and write/read administrator from root system: Create a virtual system and assign physical or logical interfaces to them Perform the same administration tasks as a Virtual System write/read administrator

Write/read Virtual System administrator: Create and edit auth, IKE, L2TP, XAuth, and Manual Key users Create and edit services (user defined services only) Create and edit policies Create and edit addresses Create and edit VPNs Modify the virtual system administrator login password Create and manage security zones Add and remove virtual system read-only administrators The vsys also inherits all predefined services from the root system

Read only virtual system administrator: Issue the following two commands: get and ping

NOTE: While sub-interfaces can be created within a vsys, only a root level write/read administrator who has entered the vsys can create them.

Page | 75

EXPLAIN VSYS VS. ROOT ASSIGNMENT OF ROUTES/NAT POOLS/ETC


Sharing allows a vsys to utilise features and functions from the root system and most often the Untrust zone and interface bound to it. A vsys typically needs to share the same Internet access as the root system. By sharing the Untrust zone and interface all the vsys configurations can have Internet access through the root system. Each virtual system has three components that can be either in a shared state or exclusively used. When shared the component is made available to other systems either virtual or root. If the component is exclusive to a virtual system it can only be used by that specific system. However, it is not possible for a vsys to share out its own components. Main components of a virtual system: Virtual Routers - virtual system automatically gain access to all shared virtual routers (VRs) when created. At the same time a new virtual router named <vsys name>-vr is created and is unable to be shared set vrouter vrouter shared Zones - when a VSYS zone is created it has access to all shared zones. And three new zones are automatically created: Trust-<vsys name>, Untrust-Tun-<vsys name>, and Global-<vsys name> set zone zone shared Network Interfaces (Shared) Untrust Zone Interface Types - dedicated physical interface, sub-interface (with virtual local area network [VLAN] tagging), and shared interface (physical, sub-interface, redundant interface, aggregate interface) with the root system only. Network Interfaces (Non-Shared) Trust Zone Interface Types - dedicated physical interface, sub-interface (with VLAN tagging), and shared physical interface with root system (using IP-based traffic classification).

A shared object is an object that can be used by multiple systems within the same physical firewall. They consist of zones, interfaces, and virtual routers sharing the same objects across several virtual systems which allows for efficient distribution of resources.

CONFIGURE INTERFACE-BASED VSYS


Import the physical interface to a virtual system: From the CLI: Ns500-> set vsys Example Ns500(Example)-> set interface ethernet4/2 import Ns500(Example)-> set interface ethernet4/2 zone Trust-Example Ns500(Example)-> set interface ethernet4/2 ip 10.10.10.1/24 Ns500(Example)-> save Ns500(Example)-> exit Ns500-> set vsys Example Page | 76

Ns500(Example)-> unset interface ethernet4/2 ip 10.10.10.1/24 Ns500(Example)-> unset interface ethernet4/2 zone Trust-Example Ns500(Example)-> unset interface ethernet4/2 import Ns500(Example)-> save Ns500(Example)-> exit Ns500->

HOW THE NETSCREEN FIREWALL DIFFERENTIATES TRAFFIC


Self-Traffic Traffic destined to the actual NetScreen firewall (be it rootsys or vsys) is associated to the correct system by determining which system has ownership over the destination object. The destination object can be a configured MIP, VIP, and VPN tunnel or manage IP address. E.g. a MIP configured on vsys1 when traffic arrives destined for the MIP the NetScreen firewall understands that the MIP belongs to vsys1 and processes the traffic as vsys1 accordingly. Through Traffic The NetScreen firewall determines the vsys to use for traffic destined to an IP address beyond the firewall (through traffic) using two different methods: VLAN-based traffic classification, IP-based traffic classification

VLAN-based classification uses the VLAN tagging method and sub-interfaces dedicated to vsys on those VLANs to determine the vsys that should process the traffic. IP-based classification method examines the source and/or destination IP address to determine which network range the traffic belongs to, and which vsys has been configured to handle that network range. This process of determining the Virtual System to process the traffic can be seen in three steps: Ingress Interface/Source IP Traffic Classification The NetScreen device checks if the ingress interface is a dedicated interface or a shared interface. If the ingress interface is dedicated to a vsys (v-i, for example) the firewall associates the traffic with that Virtual System. If the ingress interface is a shared interface the firewall uses IP-based classification to check if the source IP address is associated with a particular vsys. o If the source IP address is not associated with a particular vsys, ingress IP-based classification fails. o If the source IP address is associated with a particular vsys, ingress IP classification succeeds.

Page | 77

Egress Interface/Destination IP Traffic Classification The NetScreen device then checks if the egress interface is shared or dedicated. If the egress interface is dedicated to a vsys (v-e, for example), the firewall associates the traffic with the system the interface is dedicated to. If the egress interface is a shared interface the firewall uses IP-based classification to check if the destination IP address is associated with a particular vsys. o if the destination IP address is not associated with a particular vsys, egress IP classification fails. o If the destination IP address is associated with a particular vsys, egress IP classification succeeds.

Vsys Traffic Assignment Based on the outcome of the ingress interface/source IP (I/S) and egress interface/destination IP (E/D) traffic classifications, the firewall determines the vsys to which traffic belongs. If I/S traffic classification succeeds but E/D traffic classification fails, the firewall uses the policy set and route table for the vsys associated with the ingress interface or source IP address (a vsys named v-i, for example).

I/S traffic classification is particularly useful when permitting outbound traffic from a vsys to a public network such as the Internet. If E/D traffic classification succeeds, but I/S traffic classification fails, the firewall uses the policy set and route table for the vsys associated with the egress interface or destination IP address (a vsys named v-e, for example).

E/D traffic classification is particularly useful when permitting inbound traffic to one or more servers in a vsys from a public network such as the Internet. If both classification attempts succeed and the associated virtual systems are the same, the firewall uses the policy set and route table for that vsys.

You can use both I/S and E/D IP traffic classification to permit traffic from specific addresses in one zone to specific addresses in another zone of the same vsys. If both classification attempts succeed, the associated virtual systems are different, and the interfaces are bound to the same shared security zone, the firewall first uses the policy set and route table for the I/S vsys, and then uses the policy set and route table for the E/D vsys.

NetScreen supports intrazone intervsys traffic when the traffic occurs in the same shared zone. The NetScreen device first applies the v-i policy set and route table, loops the traffic back on the Untrust interface, and then applies the v-e policy set and route table. Such intrazone traffic might be common if a single company uses one shared internal zone with different virtual systems for different internal departments and wants to allow traffic between the different departments.

Page | 78

If both classification attempts succeed, the associated virtual systems are different, and the interfaces are bound to different shared security zones, the firewall drops the packet.

NetScreens do not support interzone intervsys traffic between different shared security zones. If both classification attempts succeed, the associated virtual systems are different, and the ingress and egress interfaces are bound to zones dedicated to different virtual systems, the NetScreen device first applies the v-i policy set and route table. It then loops the traffic back on the Untrust interface and applies the v-e policy set and route table.

NetScreen supports interzone inter-vsys traffic between dedicated security zones. If both classification attempts fail, the firewall drops the packet.

AN-BASED CLASSIFICATION
With VLAN-based traffic classification a firewall uses VLAN tagging to direct traffic to various sub-interfaces bound to different systems. By default a vsys has two security zones - a shared Untrust zone and its own Trust-vsys zone. Both of these zones can have sub-interfaces bound to them so the firewall can determine which vsys should process the traffic. VLAN-based classification has advantages including ease of administration and the ability for different Virtual Systems to have overlapping networks. The association of vsys to traffic is performed using the VLAN tag and not by the source and/or destination IP address but overlapping networks cannot be configured within the same vsys between sub-interfaces. Defining a vsys sub-interface Enter the vsys as root administrator or a write/read administrator from the root: Enter the vsys and import the interface: enter vsys vsys Create the subinterface, assign it to a zone and configure an IP address: set interface interface.subif-id zone zone Where interface is the physical interface, subif-id is the subinterface ID for the new subinterface nd zone is the vsys zone that the subinterface will be assigned to. set interface interface.subif-id ip ipaddress/mask(octet) tag vlan-id Where vlan-id is the VLAN the subinterface will be associated with. Optionally, change the interface to route mode: set interface interface.subif-id ip route Page | 79

IP-based Classification IP-based traffic classification allows traffic to be sorted to Virtual Systems without using a VLAN environment. The firewall uses IP addresses to sort traffic associating a subnet or range of IP addresses with a particular vsys (including the rootsys). When using IP-based classification: Use the untrust-vr and a virtual router specific to the vsys Use the Untrust zone and a zone specific to the vsys (the default Trust-vsys or another vsys defined zone) Use an Untrust zone interface and an interface bound to a zone specific to the vsys

IP-based traffic classification requires the use of a shared security zone so Virtual Systems cannot use overlapping internal IP addresses. When Virtual Systems (including the root system) share the same interface, the operational mode for the interface must be either NAT or Route mode. It is not possible to mix NAT and Route modes for different Virtual Systems. Sharing virtual routers, security zones, and interfaces is less secure than dedicating an internal virtual router, internal security zone, and internal and external interfaces to each vsys. N.B. When all Virtual Systems share the same interfaces, it is possible for a vsys admin in one vsys to use the snoop command to gather information about the traffic activities of another vsys. Because IP spoofing is possible on the internal side, Juniper Networks recommends disabling the IP spoofing SCREEN option on the shared internal interface. Enabling IP-based Classification Before a shared interface can process traffic using IP-based classification it must be configured in the associated shared zone: For an entire network: set zone zone ip-classification net ipaddress/mask(octet) root | vsys vsys For a range of IP addresses: set zone zone ip-classification range iprange_start-iprange_end root | vsys vsys IP-based classification then needs to be enabled on the zone by issuing the following command: set zone zone ip-classification

CONFIGURE INTER-VSYS COMMUNICATIONS, INCLUDING NAT


Even though each vsys is a separated logical entity, it is possible to pass traffic between different vsys and between the rootsys.

ROUTING

Page | 80

NetScreen Systems with Virtual Systems have a single global routing table which is visible by the rootsys and all other vsys. Thus the firewall can determine where traffic has originated and where it needs to go and which vsys needs to process it. Each vsys also has its own routing table that it uses for routing traffic between its own zones and interfaces. These routes are only required for the functioning of the vsys and are entered into this routing table and may not need to be included in the global routing table. A Vsys interface in NAT mode wont import any of its routes into the global route table because it can cause routing and potentially security issues. Vsys interfaces in route mode will always import all their routing information to the global routing table as it is presumed that those routes need to be visible by other Virtual Systems to successfully route traffic to that vsys. Overlapping subnets between different vsys are only possible if the relevant vsys interfaces are in NAT mode and using VLAN-based classification.

POLICIES
A Virtual System is still a firewall so traffic passing in and out of the vsys needs to be permitted by security policies. Virtual Systems can pass traffic between themselves and at times needing to loop this traffic through to the untrust interface providing both Virtual Systems allow traffic to go out, and both of allow the traffic to come in.

USE SHOW/DEBUG OUTPUT TO IDENTIFY VSYS USAGE


Obtaining Session Information Information about sessions created by traffic: get session Output: alloc 176/max 128000, alloc failed 0, di alloc failed 0 id 45/s**,vsys 0,flag 00000040/0000/00,policy 1,time 6, dip 0 0(8801):192.168.1.10/4000->192.168.2.10/1024,1,0010db103040,2,vlan 0,tun 0,vsd 0,route 0 6(2800):192.168.1.10/4000<-192.168.2.10/1024,1,000000000000,3,vlan 0,tun 40000001,vsd 0,route 5 The vsys field determines which vsys the session is applicable (0 represents the Root system). FW-> get dbuf stream ****** 15625.0: <private/ethernet0/5> packet received [60]****** ipid = 34344(8628), @02cdf8b0 packet passed sanity check. Page | 81

ethernet0/5:10.1.1.5/17152->1.1.70.250/256,1(8/0)<Root> no session found flow_first_sanity_check: in <ethernet0/5>, out <N/A> chose interface ethernet0/5 as incoming nat if flow_first_routing: in <ethernet0/5>, out <N/A> search route to (ethernet0/5, 10.1.1.5->1.1.70.250) in vr trust-vr for vsd-0/flag-0/ifp-null [ Dest] 10.route 1.1.70.250->0.0.0.0, to ethernet0/6 routed (x_dst_ip 1.1.70.250) from ethernet0/5 (ethernet0/5 in 0) to ethernet0/6 policy search from zone 104-> zone 103 policy_flow_search policy search nat_crt from zone 104-> zone 103 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 1.1.70.250, port 2396, proto 1) No SW RPC rule match, search HW rule Permitted by policy 2 No src xlate choose interface ethernet0/6 as outgoing phy if no loop on ifp ethernet0/6. session application type 0, name None, nas_id 0, timeout 60sec service lookup identified service 0. flow_first_final_check: in <ethernet0/5>, out <ethernet0/6> existing vector list 1-4339cf0. Session (id:8061) created for first pak 1 flow_first_install_session======> route to 1.1.70.250 arp entry found for 1.1.70.250 nsp2 wing prepared, ready cache mac in the session make_nsp_ready_no_resolve() search route to (ethernet0/6, 1.1.70.250->10.1.1.5) in vr trust-vr for vsd-0/flag-3000/ifpethernet0/5 [ Dest] 12.route 10.1.1.5->0.0.0.0, to ethernet0/5 route to 10.1.1.5 flow got session. flow session id 8061 post addr xlation: 10.1.1.5->1.1.70.250. NOTE: You cannot do debugging from within a virtual system. You must be in the root vsys to be able to run debug commands

CONFIGURE VSYS RESOURCE ALLOCATION


Resource Allocation A profile can be created to allocate resources to the vsys. Set vsys-profile name cpu-weither 20 Set vsys-profile mips max 30 Set vsys-profile dips max 20 reserve 5 Set vsys-profile mpolicies max 5 Set vsys-profile policies max 120 Set vsys-profile sessions max 3000 Save. Page | 82

VIRTUAL SYSTEMS QUESTONS


QUESTION 1 Which three interface types are supported in virtual systems? (Choose three.) A. B. C. D. E. subinterfaces VPN interfaces shared Interfaces limited Interface dedicated Interfaces

QUESTION 2 You are a read/write VSYS administrator. Your configuration requires the use of a DIP. Which statement correctly describes this situation? A. DIP creation can only be done by the root administrator, not a VSYS administrator. B. You can create the DIP on any interface imported into your VSYS, but not on shared interfaces. C. You can create DIPs on any interface you can see in your interface list, including both private and shared interfaces. D. You can create DIPs only on sub-interfaces within your VSYS. All other DIPs need to be created by the root level VSYS admin. QUESTION 3 Which three VSYS features can only be created by the root administrator? (Choose three.) A. B. C. D. E. VPNs policies subinterfaces dedicated interfaces VSYS read/write Admin

Page | 83

NSRP
Juniper NetScreens provide support for the NetScreen Redundancy Protocol (NSRP) which allows the HA options to work, and was originally referred to as HA. With the introduction of NSRP version 2 in the Screen OS 3.1 versions, this changed. HA setups are now commonly referred to as NSRP setups, or just running NSRP.

DISTINGUISH ACTIVE/PASSIVE AND ACTIVE/ACTIVE.


Clustering High Availability (Active/Passive) means that your Firewall application will be available, without interruption, regardless of increased load and/or hardware/software failures. Load Balancing (Active/Active) is a technique implemented either in hardware or software or in both where the incoming requests are spread across the available devices to maintain client response times as the number of concurrent requests grow. Clustering is a fault tolerant environment with two or more firewalls enabled with NSRP in either active/passive or active/active mode. Once formed the configuration of all members of the cluster are synchronised and all future commands issued on one cluster member are propagated to the other cluster members. Exceptions are as follows: Manage IP addresses Cluster ID number User account information IP tracking commands Console settings Hostnames SNMP settings Virtual router settings Interface monitoring Bandwidth management configurations

NetScreen Systems have dedicated physical High Availability (HA) interfaces for the purposes of clustering but for devices without a dedicated HA interface you can take any physical interface and assign it to the HA zone for clustering. Clustered devices connected together using HA interfaces can monitor the status of each other. A secondary path for cluster status traffic to communicate in the instance that the HA connection between the two firewalls becomes inactive can also be configured.

CLUSTER ID
Clustered NetScreen firewalls must share the same cluster ID (A number between 1 and 7). Configure a firewall with a cluster ID: set nsrp cluster id cluster-id

Page | 84

NAME A CLUSTER
Each device has its own hostname so a failover from one firewall to the other can cause issues with SNMP and digital certificate validation. A name for the cluster needs to be assigned which will be used that is independent of which member of the cluster active. In an Active/Active cluster you have more than one VSD group and configure the VSD groups so that normally the first firewall has the master VSD for the first VSD group and the backup VSD for the second VSD group and vice versa. Configure a cluster name: set nsrp cluster name clustername

DESCRIBE NSRP OPERATIONS (HA LINK, SESSION SYNC, MASTER ELECTION, ETC.)
VSD Groups To minimise downtime when the first system in a cluster fails it is important to ensure the second system knows precisely what the first system is doing. It can then pick up without any interruption so you want to shift the entire running firewall onto the backup hardware. NetScreens achieve this by turning the physical firewall into a virtual firewall that has hardware associated with it. This is precisely what is done in NetScreen firewalls. When NSRP is enabled, a Virtual Security When NSRP is enabled a Virtual Security Device (VSD) is created, and the configuration for the physical interfaces changes to apply to virtual interfaces called Virtual Security Interfaces (VSI). So all of the configurations are done on the VSI and NSRP takes care of associating the VSI to the correct physical interface. A firewall cluster member automatically becomes a member of the Virtual Security Device (VSD) group 0. VSD group 0 is the default cluster group for all NetScreen clusters and represents the single group entity of both physical firewalls. Within a VSD group, one VSD is the designated master VSD and is the active VSD processing and forwarding traffic. The other VSD in the group is the backup and is located on the other NetScreen. The backup VSD is not processing traffic so only one of the firewalls is active and processing traffic (Active/Passive). The IP addresses assigned to a VSI follow the master VSD which is different from how Virtual Router Redundancy Protocol (VRRP) works. Security interfaces configured before the firewall became a cluster member convert to Virtual Security Interfaces (VSIs) for the VSD group. When a local interface becomes a VSI it is an interface member in the cluster and can be failed over to another cluster member. It can also be monitored to determine whether it has failed to initiate a potential failover. In NSRP clusters the opposite of a VSI is a local interface and a local interface is one not tied to a VSD and does not move across in case of a failover. It is possible to have local interfaces that do not participate in the VSD. By default, the routing table only includes routes to the local network of all interfaces which become VSIs. For networks beyond the VSIs local network, a static route must be added which refers to the relevant VSI.

Page | 85

DUAL HA LINKS
There are advantages to using dual HA links as the types of packets that are exchanged between the NetScreens in an NSRP cluster are in two categories: Control messages Data packets.

Control messages enable NSRP to function and Data packets are normal user data packets passed on from one firewall to the other for processing. Packet forwarding occurs in certain cases but is not the norm and should be avoided and can occur if an Active/Active setup is used. The control messages consist of various heartbeats and synchronisation messages, such as physical link probes, VSD state information, and session synchronisation information. These messages are always sent via HA link number 1. If you have dual HA interfaces and the first link has the lower interface number e.g. Ethernet7 and ethernet8 are bound to the HA zone ethernet7 would carry the control messages unless it becomes unavailable. In this case the control messages would be sent on ethernet8 instead. Data forwarding is not always available due to bandwidth requirements. NOTE: NetScreens have the option of allowing NSRP traffic to coexist with normal traffic on an interface. Use an interface that is connected to a switch and provides the layer 2 broadcast domain common to both firewalls.

NSRP STATES
At any given time each VSD is in one of six states, which determines the current role of the VSD. The possible states are Master The state of a VSD group member that processes traffic sent to the VSI. Primary Backup The state of a VSD group member that becomes the master should the current master step down. The election process uses device priorities to determine which member to promote. Note that when electing a new master, an RTO peer has precedence over any other VSD group member, even if that member has a better priority rating. Backup The state of a VSD group member that monitors the status of the primary backup and elects one of the backup devices to primary backup if the current one steps down. Initial The transient state of a VSD group member while it joins a VSD group, either when the device boots up or when it is added to the group using the relevant command. Ineligible The state that an administrator purposefully assigns to a VSD group member so that it cannot participate in the election process. Inoperable The state of a VSD group member after a system check determines that the device has an internal problem (such as no processing boards) or a network connection problem (such as when an interface link fails).

You can determine the state of a device by observing the HA LED. The meanings of the various colours - dark, green, yellow, red - are as follows: Dark: The device is not enabled for NSRP.

Page | 86

Green: The device is enabled for NSRP; it is the master in one or more VSD groups; and it is not in inoperable mode. Yellow: The device is enabled for NSRP; it is not the master in any VSD group; and it is not in inoperable mode. Red: The device is enabled for NSRP, but it is currently in inoperable mode.

Changing the Initial State Hold-down Timer The initial state hold-down timer specifies how long a VSD group member stays in the initial state. The default minimum setting is 5. To determine the initial state hold-down time, multiply the init-hold value by the VSD heartbeat-interval (init-hold x hb-interval = initial state hold-down time). E.g. if the init-hold is 5 and the hb-interval is 1000 milliseconds, then the initial state hold-down time is 5,000 milliseconds, or 5 seconds (5 x 1000 = 5000). To change the initial state holddown timer value, issue the following command: set nsrp vsd-group id vsdgroup-id init-hold number Setting a Group Member to Ineligible State To change the state of a group member to ineligible, issue the following command: set nsrp vsd-group id id_num mode ineligible Heartbeat Messages Every VSD group member communicates with its group members by a heartbeat message every second and they allow every member to know the current state of every other member. The heartbeat message includes the following information: Unit ID of the device VSD group ID VSD group member status (master, primary backup, or backup) Device priority RTO peer information

Configuring the Heartbeat Interval The interval for sending VSD heartbeats is configurable and applies globally to all VSD groups. Configure the heartbeat interval: set nsrp vsd-group hb-interval number Where number can be 200, 600, 800, or 1000 milliseconds (1000 milliseconds is the default). Configuring the Heartbeat Threshold The heartbeat threshold is used to determine when a VSD group member has failed and is configurable. To configure the heartbeat threshold: set nsrp vsd hb-threshold number Page | 87

Where number is the number of heartbeats before a device is considered failed (default is 3)

SYNCHRONISATION
For two clustered firewalls to act as a logical entity the configurations, files and state of traffic must be synchronised and kept synchronised. it is then possible to have a seamless failover from one firewall to the other without the loss of traffic. Synchronising Configurations It is possible that a configuration can become unsynchronised. Checking for Synchronisation exec nsrp sync global-config check-sum The output shows whether the configurations of both firewalls are in sync or not and provides a checksum for both. Resynchronising Configurations

To resync without a reboot: exec nsrp sync global-config run Resync requires a reboot: exec nsrp sync global-config save NOTE: When you are attempting to resynchronise the configurations from a master to a target, issue the unset all command first to clear all previous configurations. Otherwise, the resync may cause duplicate entries that can cause issues during the bootup process Synchronising Files To synchronise a single file: exec nsrp sync file name file-name from peer To synchronise all files: exec nsrp sync file from peer

RUN-TIME OBJECTS
Run-time objects (RTOs) are code objects created dynamically in memory during normal operation. E.g. session table entries, ARP cache entries, DHCP leases, and IPSec security associations (SAs). During a failover it is critical the current RTOs are maintained by the new master to avoid service interruption so RTOs are backed up by the members of an NSRP cluster. Page | 88

Each member backs up the RTOs from the other which allows RTOs to be maintained. NSRP cluster members do not synchronise RTOs by default so before enabling RTO synchronisation, you must synchronise the configurations between cluster members. To initiate the RTO mirror relationship between two cluster members goes through two operational states - set and active: 1. After adding the first device to a group its state is set and in the set state the device waits for its peer to join the group. As the receiver of RTOs, it periodically transmits an r-ready message (receiver-ready), announcing its availability. It then waits until it gets an r-ready message from a device with the same cluster ID. 2. After adding the peer correctly cabling for HA then the following occurs: The receiver sends an r-ready message. The sender gets the r-ready message, and immediately sends a group-active message to inform its peer that its state is now active. The receiver then changes its state to active as well. Enabling RTO Synchronisation set nsrp rto-mirror sync Manually Resynchronising RTOs Automatic resync after a reboot occurs if a firewall has RTO synchronisation enabled. But if RTO synchronisation is disabled, then re-enabled, an RTO synchronisation must be performed manually. To manually resync RTOs: exec nsrp sync rto all To resync specific RTO components issue the specific command: exec nsrp sync rto arp | auth-table | dhcp | dns | l2tp | phase1-sa | pki | rm | session | vpn Defining RTO Heartbeats Firewalls send RTO heartbeats at user-defined intervals to communicate their operational tatus. Define the RTO heartbeat interval: set nsrp rto-mirror hb-interval number Define the number of heartbeats (required to deem a peer as down): set nsrp rto-mirror hb-threshold number Disable RTO Synchronisation Disable RTO synchronisation from device acting as the sender in an NSRP cluster: set nsrp rto-mirror session off Page | 89

SYNCHRONISING TIME
NSRP can be used to synchronise time between cluster members but if NTP is also configured it is possible for the time to become unsynchronised. Disable NSRP Time Synchronisation It is recommended to disable the NSRP time synchronisation and allow each host to synchronise its time using NTP as it is more accurate. Disable the NSRP time synchronisation: set ntp no-ha-sync

HA INTERFACES
NetScreen Systems have dedicated HA interfaces for connecting two firewalls together in a cluster. Appliances dont have dedicated HA interfaces so it is possible to specify any physical interface as an HA interface for maximum fault tolerance and to eliminate a single point of failure It is recommended two interfaces be used to provide HA connectivity to cater for interfaces failure. Control Messages Two kinds of control messages are transmitted: Heartbeats HA messages

Three types of heartbeats: VSD group heartbeats (See under NSRP STATES) RTO heartbeats (See under NSRP STATES) HA physical link heartbeats

HA physical link heartbeats - broadcast messages from the HA interfaces of both firewalls to monitor the status of the actual HA interfaces. If one member does not receive 3 consecutive heartbeats from a particular HA interface it fails over all messages to the second HA interface. The two types of HA messages: Configuration messages (Configuration messages are new configuration settings that have been configured on the master which are sent to other peers in the cluster) RTO messages (RTO messages means the RTO synchronisation data sent between firewalls)

Data Messages These are IP packets traversing the firewall that the backup in a VSD group must forward to the device acting as master. When a packet arrives at the interface of a cluster member in an Page | 90

active/active configuration the firewall identifies which VSD group must process the packet. If the firewall that receives the packet is the master of the identified VSD group, it processes the packet itself. If not, the packet is forwarded over the HA link to the master Link Probes Configuring HA with a switch in between the two devices can cause problems. E.g. If the HA1 interface of firewall 1 fails, the HA2 interface will now be carrying the control message (and possibly data) load. However, firewall 2s HA1 interface is still active as its connectivity to the switch is still active and it rejects the new control messages now being received by its HA2 interface as it is still expecting them from interface HA1. Link probes were introduced to solve this problem and by sending out link probes on the HA interfaces to the HA interfaces of the other peer, a firewall can see if a peer interface has failed even in a switched environment. Sending Manual Link Probes Probes are sent every second for a given number of times so if no response is received the peer interface is deemed as inactive. Issue the following command in order to manually send link probes: exec nsrp probe interface peer-MAC count threshold Where interface is the outgoing interface on the probing firewall Peer-MAC is the MAC address of the HA interface of the peer Threshold is the number of probes to be sent Configuring Automatic Link Probes Link probes can also be configured automatically, so that a firewall will continuously monitor its peers HA interface and automatically failover when it deems it as being inactive. Like the manual method, probes are sent every second and if a reply is not received after a given number of probes, the firewall will deem the peer interface as down. With automatic link probing, it is also possible to configure an interval, which is the number of seconds in between probe attempts. To configure automatic link probing, issue the following commands: set nsrp ha-link probe interval interval threshold threshold

CONFIGURE ACTIVE/PASSIVE AND ACTIVE/ACTIVE NSRP


All devices in a new cluster are added to VSD group 0 and a master is elected from the group. If the master fails the backup device becomes active and changes to master state. This is an active/passive configuration or High Availability (HA) cluster. NetScreen firewalls in layer 3 mode (NAT or Route) as well as layer 2 mode (Transparent) can be configured for active/passive failover.

ACTIVE/PASSIVE CLUSTER
Active/passive has advantages over an active/active configuration as it is far easier to configure and manage and simplifies the deployment of fault tolerant networks. Page | 91

NOTE: When the cluster master fails and the backup becomes active as the new master, it sends a gratuitous ARP out of all its interfaces to inform neighbouring network devices that it is active. This forces all connected networking devices to refresh their ARP tables and point relevant IP address to the MAC address of the new master firewall.

CONFIGURING ACTIVE/PASSIVE FAILOVER CLUSTER


Configure active/passive failover for two NetScreen firewalls: Assign the firewall to a particular cluster: set nsrp cluster id cluster-id Optionally, provide authentication and encryption for cluster status traffic: set nsrp auth password clusterpassword set nsrp encrypt password encryptpassword Assign cluster name (avoids issues with digital certificates and SNMP): set nsrp cluster name clustername Select interfaces to monitor: set nsrp monitor interface interface Optionally, configure a secondary path for the cluster status traffic (dedicated HA connection fails). set nsrp secondary-path interface Configure number of gratuitous ARPs: set nsrp arp arpnumber

Page | 92

ACTIVE/ACTIVE CLUSTER
This is a simple matter of setting their priorities correctly

Multiple VSD Groups

VSD Grp 1

VSD Backup

VSD Master

VSD Grp 2

VSD Master

VSD Backup

NetScreen 1

HA Links

NetScreen 2

Each VSD contains its own set of VSIs, so you have multiple IP addresses in each network. Configure the neighbouring network nodes to load-balance between these IP addresses. With routers this can be done by having two routes with identical cost pointing to one of the VSI IP addresses. If the NetScreens are providing the default gateway for a LAN then you can configure half the hosts on the LAN to use the IP address in the first VSD, and the second half to use the other VSDs IP address as their default gateway. When setting up Active/Active configuration you must duplicate the routes. If there are no routes for the second VSD, it is forced to forward all traffic to the first VSD across the HA data link. Also consider the load you are putting on the firewalls may need to be handled by a single firewall e.g. each firewall should run at no more than 50-percent capacity as everything goes through the remaining firewall if a node fails.

CONFIGURING AN ACTIVE/ACTIVE CLUSTER


With active/passive, there is one logical firewall representing both firewalls but in active/active both firewalls are active and the failure of one firewall transfers the entire load to the other firewall. To ensure that both firewalls are properly utilised, half of the devices on the network will connect to one firewall, and half will connect to the other firewall.

Page | 93

On Firewall 1: Assign a cluster ID: set nsrp cluster id cluster-ID Configure the pre-empt options (it will be master for the default VSD Group 0): set nsrp vsd-group id 0 preempt hold-down number Where number is a value from 0 to 600 seconds set nsrp vsd-group id 0 preempt Set the priority of this firewall for the VSD Group set nsrp vsd-group id 0 priority priority Where priority is a value between 1 and 255 The closer the priority is to 0 the higher the priority. As this firewall is the master of this particular VSD group, assign it the highest priority. Configure the other VSD Group required for an active/active configuration: set nsrp vsd-group id 1 Enable RTO Mirror Synchronisation: set nsrp rto-mirror sync On Firewall 2: Join firewall 2 to the cluster: set nsrp cluster id cluster-ID Now both firewalls have been clustered commands issued on one will be propagated to the other. The exceptions commands for priority and preempt options. Assign a cluster name to the cluster: set nsrp cluster name clustername Configure firewall 2 to send RTO synchronisation information: set nsrp rto-mirror sync Firewall 2 is the master for the second VSD group (group 1) so configure the priority and preempt options accordingly: set nsrp vsd-group id 1 priority priority Page | 94

set nsrp vsd-group id 1 preempt hold-down number set nsrp vsd-group id 1 preempt Configure a secondary HA path: set nsrp secondary-path interface Configure gratuitous ARPs: set nsrp arp 5 set arp always-on-dest Configure interfaces for VSD group 0: set interface interface zone zone set interface interface ip ipaddress/mask Manageable interface requires configuration of a manage IP address (different from the actual IP address): set interface interface manage-ip manage-IPaddress Configure monitoring for the interface: set nsrp monitor interface interface Configure the Virtual Security Interfaces for the other VSD group: Set interface interface:vsd-groupID ip ipaddress/mask Configure default gateway both the Internet facing interfaces of both VSD groups: set vrouter vrouter route 0.0.0.0/0 interface interface gateway ipaddress set vrouter vrouter route 0.0.0.0/0 interface interface:vsd-groupID gateway ipaddress

On Firewall1: Firewall 1 now has the configurations that were synchronised but manage IP information is not synchronised so enter the manage IP to be used to manage Firewall1: set interface interface manage-ip manage-IPaddress

Page | 95

VALIDATE NSRP OPERATIONS


Verifying NSRP Active-Active Status When setting up NSRP Active-Active you will need to ensure the cluster is actually operating in Active-Active mode and not Active-Passive or split brain. To check the status of an NSRP active-active cluster: get nsrp nsrp version: 2.0 cluster info: cluster id: 1, no name local unit id: 3513520 active units discovered: index: 0, unit id: 3513520, ctrl mac: 0010db359cba, data mac: 0010db359cbb index: 1, unit id: 3515616, ctrl mac: 0010db35a4ea, data mac: 0010db35a4eb total number of units: 2 VSD group info: init hold time: 5 heartbeat lost threshold: 3 heartbeat interval: 1000(ms) master always exist: disabled group priority preempt holddown inelig master PB other members 0 1 yes 1 no myself 3515616 1 100 no 2 no 3515616 myself total number of vsd groups: 2 Total iteration=23469, time=540006250, max=55388,min=8950,average=23009 RTO mirror info: run time object sync: enabled ping session sync: enabled coldstart sync done nsrp data packet forwarding is enabled nsrp link info: control channel: ethernet7 (ifnum: 10) mac: 0010db359cba state: up data channel: ethernet8 (ifnum: 11) mac: 0010db359cbb state: up ha secondary path link not available NSRP encryption: disabled NSRP authentication: disabled device based nsrp monitoring threshold: 255, weighted sum: 0, not failed device based nsrp monitor interface: device based nsrp monitor zone: device based nsrp track ip: (weight: 255, disabled) number of gratuitous arps: 4 (default) config sync: enabled track ip: disabled Page | 96

For VSD 0 the output states master as 'myself' and for VSD 1 master is 3515616. VSD 0 is configured with priority 1 and VSD 1 is configured for priority 100. This means VSD 0 is the preferred VSD for this device. If the output has VSD 0 and VSD 1 displaying "master for both, and then there is a configuration problem. Under NSRP link info you should see an active control and data channel. If you dont have an active data channel either the link on that interface is bad, or you did not configure 2 interfaces for HA zone. On an NS-208 you will need to bind 2 interfaces to the HA zone in order to make active-active NSRP to work. Otherwise, you may run into a split-brain situation when fail-over occurs and if the HA link between the two devices goes through a switch, you will also need to apply an additional command: set nsrp ha-link probe

CHECK IF THE ACTIVE/PASSIVE NSRP PAIR CONFIGURATIONS ARE IN SYNC


You can check if HA configurations are in sync by the output of checksum command, viewed by 'get log sys'. On either the Master or Backup device enter the following to determine if the configurations for a NSRP pair are in sync: exec nsrp sync global-config check-sum The output is reported on the CONSOLE of the firewall. If no output is returned when you run the command NOTE: If you are not connected to the firewall via the console, i.e. if you are connected via Telnet or SSH, then the output of the command can be viewed in 'get db str' or get log sys': If the configurations are out of sync: enter the following command on the backup Firewall: exec nsrp sync global save The following will be reported but to see the messages you need to be logged in using a console connection: ->load peer system config to save Save global configuration successfully. Continue to save local configurations ... Save local configuration successfully. done Please reset your box to let cluster configuration take effect! -> Then the backup Firewall needs to be reset for the configuration to take effect.

Page | 97

NOTE: If you are prompted to save the configuration after you enter the reset command, answer n (No). Then, proceed with the reboot by answering y (Yes).

-> reset -> Configuration modified. Save? [y] y/n n -> System reset? Are you sure? y/n y When the Backup Firewall boots up the configs will be in sync. Output via TELNET ns5200(B)-> exec nsrp sync global-config check-sum ns5200(B)-> get db str Warning: configuration out of sync Output via CONSOLE ns5200(B)-> exec nsrp sync global-config check-sum ns5200(B)-> Warning: configuration out of sync

nsisg2000(M)-> get log sys ## 2008-03-10 22:47:17 : VSD group (0) change state to Passive ## 2008-03-12 16:00:17 : VSD group (0) change state to Active ## 2008-03-14 15:44:24 : configuration out of sync (local checksum 423391316 != remote checksum 108606823) nsisg2000(M)-> The most recent events are at the bottom of the 'get log sys' output, so to confirm the 'Configuration out of sync' or 'Configuration in sync' output with the date that you ran the command. NOTE: Although the configs are in sync, the sessions and other RTOs (Run Time Objects) may not be in sync. The command set nsrp rto-mirror sync should be configured on each of your firewalls to synchronise RTOs (i.e. session table entries, ARP cache entries, DHCP leases, and IPSec security associations etc.). In the event of a failover, it is critical that the current RTOs be maintained by the new primary device to avoid service interruption. The command get nsrp | inc run time object will report enabled if this command is set.

Page | 98

ADJUST OPERATIONS (SECONDARY LINK, FAILOVER SETTINGS)


Failover There are two types of failover full device failover VSD group failover.

When two firewalls are clustered and a device fails it will become inactive and the backup device will become the master taking over all traffic processing. A VSD group failover is only relevant for active/active configurations. The failure of a single port or interface is not a full device failover. The master of the group with the failure fails-over just that particular VSD group (to the backup). It can then continue to be active and the backup for the other VSD group. Failover Monitoring NSRP provides options for monitoring other things besides NSRP heartbeatsspecifically, interface link status (interface monitoring), zone availability (zone monitoring), and IP address reachability (IP tracking). Objects that can be monitored include: Physical interfaces ensuring that the physical ports are active Zones ensuring that all physical ports as part of a zone are active Specific target IP addresses Up to 16 IP addresses can be monitored to determine whether connectivity beyond the local physical connection is active

The two important settings to configure for failover monitoring are the failover threshold, and the failure weight assigned to each of the monitored objects. Failover threshold - determines when a device or VSD group failover should occur. When a monitored object fails, the weight assigned to it is added to a cumulative weight count. Each monitored group has its own cumulative weight count which also has a weighting value. So when the threshold of the group is exceeded, the weight of the group is also added to the overall weight count. When the threshold of this weight count is exceeded the device on the VSD group fails over. Configuring the Device or VSD Group Threshold Modify the device/VSD group failover: set nsrp monitor threshold threshold Where threshold can be any value between 1 and 255 Configuring Physical Interface Monitoring set nsrp monitor interface interface weight weight Where weight can be any value between 1 and 255

Page | 99

Configuring Zone Monitoring set nsrp monitor zone zone weight weight Where weight can be any value between 1 and 255 Configuring IP Address Monitoring Up to 16 IP addresses can be monitored per cluster: set nsrp track-ip ip ipaddress weight weight Where weight can be any value between 1 and 255 The IP address monitoring threshold is the only threshold that can be modified out of the different monitored group thresholds. To modify the IP address monitoring threshold: set nsrp monitor track-ip threshold threshold Where threshold can be any value between 1 and 255 NOTE: A situation can exist with IP address tracking where both firewalls will not receive a response from a given IP address, and if the threshold is reached, both devices will fail causing a traffic black hole. In this instance, it is possible to force a device to always be a master to handle traffic. Issue the command set nsrp vsd-group master-always-exist to ensure that a device will always be made master.

CONFIGURE REDUNDANT INTERFACE.


Failing over to a different firewall is disruptive and should be avoided but by cabling firewalls so that each one has a redundant interface links to each network segment; interface redundancy means an interface can be failed over failed over to a different interface rather than all traffic failing over to a different firewall. Redundant interfaces are not part of NSRP but are used with NSRP to build full-mesh setups. It is possible to create redundant interfaces without enabling NSRP. If you are using redundant interfaces with NSRP you can bind VSIs to the redundant interfaces. A redundant interface can also be kept as a local interface instead of a VSI. Grouping Physical Interfaces Two or more physical interfaces are grouped together to create a redundant interface. One interface is considered the primary interface and will be used for sending and receiving traffic unless its link goes down in a redundant interface group. The secondary interface has its link up at all times but is not active; traffic sent to it is discarded. Once the redundant interface has been created, it can be configured like any other interface. It is assigned to a zone, given an IP address, and can be referred to in unnumbered VPN tunnels.

Page | 100

NOTE: physical interfaces do not need to be assigned to the same zone as the redundant interface.

Internet

Eth 1
Prim ary Path

NetScreen Firewall

Eth 2
Ethernet 1 & 2 of the NetScreen Firewall are grouped together into interface redundant 1 IP Address 192.168.41.1

In the above configuration all traffic normally passes over ethernet1. If that link fails, traffic is instantly moved to ethernet2. set interface redundant1 zone inside set interface redundant1 ip 192.168.41.1/24 set interface ethernet1 group redundant1 set interface ethernet2 group redundant1 The first physical interface added to the redundant interface group becomes the primary interface. This can be changed if desired. E.g. Interface redundant1 consists of physical interfaces ethernet1 and ethernet2, and ethernet1 is currently the primary interface. To change the primary interface to ethernet2: set interface redundant1 phy primary ethernet2

Page | 101

NSRP QUESTIONS
QUESTION 1 You have configured NSRP Active/Passive using the default vsd-group. You are using BGP to learn routes from adjacent network devices. You want each firewall to establish a BGP peer to different upstream routers. You also want the backup device to learn dynamic routes. Which configuration would ensure you can establish a BGP peer to two different routers? A. Configure two BGP peers on the same VSI interface, but use a different virtual router on each device. B. Use the unset vr <vr-name> nsrp-config-sync command and configure BGP peers on the VSI interface. C. Use the unset nsrp vsd-group id 0 and set nsrp vsd-group id 1 commands for VSI interfaces, then configure BGP peers on the local interfaces, then unset vr untrust-vr nsrp-config-sync. D. Use the unset nsrp vsd-group id 0 and set nsrp vsd-group id 1 commands for the VSI interfaces, then configure BGP peers on the local interfaces, then unset vr <vr-name> nsrp-config-sync. QUESTION 2 Which three steps comprise the basic NSRP configuration? (Choose three.) A. B. C. D. E. Adjust VSD settings Configure interfaces Establish the HA link Activate NSRP protocol Configure cluster settings.

QUESTION 3 You have configured set nsrp vsd-group master-always-exist on your ScreenOS device. What does this do? A. B. C. D. The NSRP protocol will not initialize without a master This device will always be master in the NSRP cluster There will always be a master device in the NSRP cluste The vsd-group will always be homed to the master in the NSRP cluster.

Page | 102

DYNAMIC ROUTING/ROUTING OVER VPNS


Juniper firewalls can support five different route types in each virtual router. Each route type has a specific method for learning its routes. Directly Connected Routes - These routes are automatically generated and placed into the routing table based upon the subnet an interface is attached to. For instance, if you have an interface 192.168.1.1/24, then the route 192.168.1.0/24 will be placed into the routing table. These routes cannot be modified, and will only be removed when the interface is removed or the address changes. Host Routes - The term Host Route refers to a route that is automatically generated for an interface on the box. The firewall will automatically generate a route for the interface and place it in the routing table. For instance, if you have an interface 192.168.1.1/24, a route 192.168.1.1/32 will be placed in the routing table. This route cannot be modified, and will only be deleted if the interface is removed or the IP address is changed. Static Routes - Static routes are manually created and direct the firewall to the next routing device, which then routes the traffic to its ultimate destination. Static routes are created by the user. For example, a static route might route traffic to a remote destination network 10.1.1.0/24 and to the next hop 192.168.2.254/24. Dynamic Routes - These routes are learned by a dynamic routing protocol such e.g. Routing Information Protocol (RIP), Open Shortest Path First (OSPF), or Border Gateway Protocol (BGP). Routes to remote networks are calculated by the protocol and the best route calculated will then be injected into the routing table. Routes to Other VRs - A route that passes traffic to another VR located on the firewall. For instance, you might say to route traffic to 10.1.2.0/24 to the Untrust-VR instead of another network. Of course, the Untrust-VR must have some sort of routing knowledge to be able to forward the traffic further. Route-maps and Access-lists Access-lists - Access-lists instruct which traffic the NetScreen is allowed to query the subsequent routing table for. Each access-list is assigned to a VR and actioned by order of sequence. Allowing an action of either permit or deny. From the CLI: set vrouter "VR-Trust" access-list 1 set vrouter "VR-Trust" access-list 1 deny 10.1.1.0/24 1 set vrouter "VR-Trust" access-list 1 permit ip 192.168.1.0/24 2 save

Page | 103

Route-maps - Route-maps are designed to filter routes that are advertised to the firewall inbound or advertised from the firewall outbound. They also allow changes to various values on routes. The route map matches the IP (via an access-list) then sets an action to this route. From the CLI: set vrouter "VR-Trust" set route-map name "Route-map 1" permit 1 set match ip 1 set metric 150 exit exit save

CONFIGURE RIP OVER VPNS


Before getting into the fine detail of how to configure Routing Information Protocol (RIP) on the Juniper firewalls, here is a bit of a RIP overview of the concepts, components, and terminology. RIP is a dynamic, distance vector routing protocol based around the Berkely BSD application routed and was developed for smaller IP based networks. RIP uses UDP port 520 for route updates. RIP calculates the best route based on hop count. Like all distance vector routing protocols, RIP takes some time to converge. While RIP requires less CPU power and RAM than some other routing protocols, RIP does have some limitations: Metric: Hop Count - RIP prefers paths with the shortest hop count Hop Count Limit - RIP cannot handle more than 15 hops Classful Routing Only - RIP cannot handle classless routing

Routers running IP RIP broadcast the full list of all the routes they know every 30 seconds. When a router running RIP hears a broadcast it runs the distance vector algorithm to create a list of best routes.

ENABLING RIP OVER VPN


From the CLI: set vrouter trust-vr protocol rip set vrouter trust-vr protocol rip enable set interface tunnel.1 protocol rip enable set interface trust protocol rip enable set vrouter trust-vr access-list 10 permit ip 10.10.0.0/16 10 set vrouter trust-vr route-map name abcd permit 10 set vrouter trust-vr route-map abcd 10 match ip 10 set vrouter trust-vr protocol rip route-map abcd out Show Commands: get vrouter trust-vr protocol rip database get vrouter trust-vr protocol rip Page | 104

get vrouter trust-vr protocol rip neighbors

CONFIGURE OSPF OVER VPNS


Open Shortest Path First (OSPF) is a link-state or shortest path first routing algorithm and allows routes to be selected dynamically based on the current state of the network and not just a static picture of how routers are connected. OSPF is capable of working with tunnel interfaces to bring dynamic routing capabilities over VPNs. In the example OSPF to works over tunnel interface Tunnel.1 and is part of area 0.0.0.0 and advertise routes on to, and from, the remote ofce connected to this interface. Assume you have already congured OSPF on the Trust-VR with Area 0.0.0.0, as well as created the Tunnel.1 interface and the VPN associated with it. Go to Network | Interfaces and click the Edit hyperlink next to the interface to be congured for OSPF At the top of the screen click the OSPF hyperlink. Check the Bind to Area box and select the appropriate Area. Uncheck the Demand Circuit checkbox. Specify Authentication for OSPF instances by using MD5 authentication. Specify an MD5 Key, Key-ID, and if Preferred. Congure the link as Point-To-Point for going over a WAN interface Alter the default timing and cost values if required Click Apply. Go back to the top of the screen and check the Protocol Enabled checkbox to enable it. Click OK. Example Conguration: Virtual Router Trust-VR Interface Tunnel.1 Protocol OSPF Bind to Area 0.0.0.0 Protocol Enabled Yes, after initial apply Demand Circuit No Authentication MD5 MD5 Key 8JFoa+[] Key-ID 1 Preferred Yes Link Type Point-to-Point Cost 50 From CLI: set interface tunnel.1 protocol ospf area 0.0.0.0 set interface tunnel.1 protocol ospf enable set interface tunnel.1 protocol ospf retransmit-interval 5 set interface tunnel.1 protocol ospf cost 50 set interface tunnel.1 protocol ospf authentication md5 "8JFoa+[]" key-id 1 set interface tunnel.1 protocol ospf authentication active-md5-key-id 1 save NOTE: Routing protocols can only function with route based VPNs, since policy-based VPNs do not use a tunnel interface. Page | 105

CONFIGURE/VERIFY OSPF ROUTING


You should familiar with a few OSPF commands on the Juniper rewalls as these commands will help determine the state of the routing table, OSPF relationships, OSPF congurations and other OSPF statistics. A summarised output of the OSPF conguration on the rewall - get vrouter <vroutername> protocol ospf To capture OSPF specific conguration - get vrouter <vroutername> protocol ospf cong. To display the current state of interfaces participating in OSPF - get vrouter <vroutername> protocol ospf interface To print out a list of all of the OSPF routers with established neighbor relationship with the rewall - get vrouter <vroutername> protocol ospf neighbor To list LSAs received and their age - get vrouter <vroutername> protocol ospf database Display the entire routing table - get route View routes learned by OSPF - get vrouter <vroutername> protocol ospf routes

CONFIGURE OSPF OPTIONS


Configuration Example: Bind to Area Protocol OSPF Reduce Flooding Authentication MD5 Key Key ID Preferred Link Type Passive Mode From WebUI: Select Network >Interfaces and click the Edit hyperlink next to the interface to be congure for OSPF At the top of the screen click the OSPF hyperlink and enter the interface-specic conguration Check the Bind to Area checkbox and select the appropriate Area to congure from the dropdown menu. Check the Protocol Enable checkbox to enable OSPF Leave the Reduce Flooding box unchecked Dene MD5 Authentication for the interface to make sure your OSPF trafc is authenticated with a secure hash. Dene an MD5 Key which is a string of alphanumeric and non-alphanumeric values and a Key ID for the key. You may also specify that this key is Preferred. If this interface is on Ethernet, you should leave it in Broadcast mode if over point-to-point WAN link set it to Point-to-Point. Leave the priority values costs and timing values as default 9.9.9.9 Enabled Disabled MD5 jun1p3r 5 Yes Broadcast Disabled

Page | 106

From CLI: set interface ethernet1 protocol ospf area 9.9.9.9 set interface ethernet1 protocol ospf enable set interface ethernet1 protocol ospf authentication md5 "jf8*jfkal" key-id 5 set interface ethernet1 protocol ospf authentication active-md5-key-id 5 save

CONFIGURE/VERIFY BGP
Border Gateway Protocol (BGP) is a protocol that allows additional routing variables to help add customisability to routing decisions. BGP is a Path Vector routing protocol because of its reliance on paths to determine routes. The current version of BGP in is BGP version 4 and is the de facto exterior routing protocol BGP uses techniques include using autonomous systems to represent entire networks incremental update and classless inter-domain routing (CIDR). BGP peers use TCP port 179 to communicate routing updates between themselves. Autonomous Systems An autonomous system (AS) is a network under administrative control by a single organisation. A series of autonomous systems used for routing decisions describes a path so the AS number must be unique and be assigned to an organisation participating in BGP though there are private AS numbers which can be used for internal purposes. IANA distributes AS numbers to organisations which need their own AS BGP Peers Routers participating in BGP must be connected to at least one other BGP router which is known as a BGP peer. The BGP peers communicate over TCP port 179 and updates are sent incrementally to their peers as new route data becomes available. Peers must be congured to talk to their neighbour or else the BGP session wont be established. BGP Attributes Attributes commonly used by the Juniper rewalls: AS Path - Denes the AS numbers the route has traversed and determines the best path and avoids routing loops. Route decisions can be enforced based upon the ASs the route has traversed. The attribute is passed to other routers that the route is announced to with the AS number of each AS appended to the path as it passes through the respective AS (mandatory) Next-Hop - Next-hop IP address that the router will take to reach the destination (mandatory) Origin - How the route was learned e.g. from an internal gateway protocol (IGP) such as OSPF an exterior gateway protocol EGP or incomplete (mandatory) Local Preference - The preferred exit point for an AS for routes that travel through it (optional) Atomic Aggregate - lets the BGP neighbor know the route was summarised and the original path was lost (optional) Aggregator the BGP peer specifies the router ID and AS number used for the aggregation (optional) Page | 107

Community - used to group routes together based on their attributes (optional) Multiple Exit Discriminator - Advertised to BGP peers to indicating the preferred value when multiple paths exist into the AS (optional) Cluster List - Dened for iBGP and used to determine the route reector the route has gone through. BGP communicates on TCP port 179 and within that communication channel BGP uses several different control messages to perform BGP tasks. IBGP IBGP is used when BGP AS Path information must be maintained within an AS to other BGP peers and must be fully meshed or have equivalent behaviour with route reectors or confederations which is important to help maintain a loop-free topology. Route Reection IBGP can employ route reectors to reduce the complexity of a BGP internal network. The complexity of fully meshed networks grows with every peer added to the domain so Route reectors help to subdivide an iBGP domain into a more manageable topology. Route reectors work similarly to designated routers in OSPF. All iBGP routers within a route reector group send the routes to the route reector which then distribute them to other directly connected route reector peers. Route reector properties: Route Reector - Species whether the BGP instance should act as a route reector or not Cluster ID - Species what the cluster ID should be for this route reector instance Open Message - rst message exchanged between two BGP peers after the TCP session on port 179 has been initiated and formally establishes the BGP connection between the peers. Update Message - BGP announcement to withdraw routes done with information contained in the update message. Notication Message - exchanged when an error is detected by BGP and contains the reason for the message, then closes the BGP session Keep-Alive Message - exchanged between BGP peers to keep TCP sessions established and let each know the other peer is still active

Confederations Confederations allow you to make sub-ASs which are ASs that are further segmented so you dont have to mesh an entire iBGP network and can mesh within sub-ASs. Those can then be meshed together with the other ASs and can greatly reduce the number of links to be maintained and reduce complexity. Confederations properties: Confederation - species whether confederations are enabled or disabled. ID - the AS number of the confederation. Peer Member Area ID - the AS number of the sub-AS which is part of the confederation

Page | 108

CONFIGURATION PROPERTIES
Properties of BGP can be congured both at the virtual router and interface level. A single BGP instance can be congured per VR and the number of routes you can have on the rewall is dependent on what rewall platform. BGP protocol requires a large routing table. . VR Properties congured per VR: AS Number - required for each BGP instance and should be the AS number you have been assigned by IANA unless using a private AS number. Keep Alive - the value set for how often a keep-alive message is sent to a peer o Use Node Default Uses the default value o Custom dene a custom value in seconds. Always Compare MED State - used to always compare the MED values of routes to determine the best way into a network. Route Flap Dampening State - enables Route Flap Dampening. Ignore Default Route from Peer Enabling - blocks a default route from being imported from a BGP peer. Advertise Default Route - automatically advertise the default route to other BGP peers. Hold Time - denes the value used to determine how long to wait between message transmissions to a peer Disable - disable the hold-time functionality for this example. Enable - congure a hold-time to be employed Value - time in seconds that will be used for the hold time Default Local Preference - default local preference value to apply to a route. Default MED - default MED that will be advertised to another BGP peer. Route Reector - congure a BGP instance to be a route reector and which cluster ID for the cluster group it will be a part of: Disable - disables instance as a route reector. Enable Set - enable route reection on this VR instance Cluster ID - set a Cluster ID for the route reector to reect for if route reection is enabled Synchronize with IGP - enables BGP to synchronize routing information with IGP. BGP Enabled - enable this BGP instance.

Conguring a BGP Instance in a VR The first step to take before conguring BGP on individual interface: 1. 2. 3. 4. 5. Go to Network > Routing > Virtual Routers Click the Edit button (next to the VR to create a BGP instance in) Scroll to the bottom and click the Create BGP Instance hyperlink. Dene the AS Number for communications within BGP Dene a custom Keep-Alive value, or leave it at the Node Default.

Each BGP instance supports several options e.g. to enable Route Flap Damping and Ignore Default Route from Peer. 6 7 8 Dene the Hold Time BGP uses for this routing instance, or disable the hold time. Dene the Local Preference and MED Values to be used or alter these on a route-byroute basis with Route Maps If participating in iBGP enable it as a Route Reector and dene the Cluster ID

Page | 109

If participating in iBGP you can synchronise with IGP to ensure routing protocols exchange any advertised routing information. 10 Enable BGP in the VR you have congured 11 Click OK. Using the following Properties: Virtual Router AS Number Keep Alive Always Compare MED Route Flap Damping State Ignore Default Route from Peer Advertise Default Route Hold Time Default Local Preference Default MED Route Reector Synchronize with IGP BGP Enabled From the CLI: To congure this example via the Juniper CLI: set vrouter trust-vr protocol bgp 65512 set vrouter trust-vr bgp enable unset vrouter trust-vr protocol bgp synchronization save Trust-VR 65512 Use Node Default Disabled Enabled Enabled Disabled Enabled (180 Seconds) 100 0 Disabled Disabled Checked (Enabled)

CONFIGURE REDISTRIBUTION/FILTERS/ROUTE MAPS


Route redistribution pulls routes out of the routing table from one protocol, and then advertises them out on another protocol and Juniper rewalls use route maps to select which routes and which protocols to pull from the routing table and which routes to advertise. Route maps can match routes by route prex or properties of the route e.g. metrics, and protocol-specic attributes. Route maps are congured within VRs so make sure you create the route map in the appropriate VR. There are several caveats to be aware of before implementing route redistribution: Route redistribution can cause routing loops if routes are not carefully ltered. Routes may take undesirable paths that are not optimum. Routing metrics may not be equivalent between two different protocols If you are not careful to lter what routes you want to advertise, you may inadvertently advertise routes to trafc you dont want to advertise to others.

Page | 110

Redistributing Routes into BGP If running BGP in a multihomed environment using iBGP you will need route redistribution as you may need to announce BGP routes within your autonomous system as well as advertise routes from within your autonomous system to other systems. With BGP you usually need to lter what routes are being advertised and/or imported and wouldnt want to announce the entire Internet BGP routing table into your internal routing structure, nor announce certain routes to the Internet via BGP e.g. private networks. Redistributing routes into BGP requires care regarding which routes will be imported and to make ensure the internal routing infrastructure is not overwhelmed.

REDISTRIBUTING OSPF AND STATIC ROUTES INTO BGP


Filtering out the private IP address ranges and set the metric the next hop and the AS path. From WebUI : Create an access list to deny private ranges but allow anything else. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Go to Network > Routing > Virtual Routers and click the number hyperlink in the Access List column and row for the VR. Click New Dene a Name, Sequence No, IP Address/Netmask, and an Action and do this once for each of the private address ranges to be denied, and again to allow any other range. Create a route map referencing the access list Go back to the Network > Routing > Virtual Routers page and click the number under the Route Map column, and on the row of your VR. Click New Dene a Name, Sequence Number, and Action Match the routes based upon an Access-List and Access List ID and dene set properties to set on any route that matches the map including setting the metric, AS path, and Next Hop for the route. Apply the route map to the OSPF instance by going to Network > Routing > Virtual Routers, and then clicking Edit next to the VR you would like to edit. Scroll to the bottom and click Edit OSPF Instance hyperlink. At the top click Redistribute Rules hyperlink. From the Route Map drop-down menu select the route map just congured To select the routes to import In the Protocol eld, choose OSPF and Static (requires two different statements) Click Add

Congured the following properties: Virtual Router Access-List Sequence No. IP / Netmask Action Sequence No. IP / Netmask Action Page | 111 VR-1025 60 1 192.168.0.0/16 Deny 2 172.16.0.0/12 Deny

Sequence No. IP / Netmask Action Sequence IP / Netmask Action Route Map Sequence No. Action Access-List Access-List (ID Chosen) Set Metric AS Path Next-Hop Origin Redistribute Redistribute From CLI:

3 10.0.0.0/8 Deny No. 4 0.0.0.0/0 Permit BGP-Match 1 Permit Checked 60 500 1 1.1.1.1 IGP OSPF to BGP Static to BGP

set vrouter VR-1025 access-list 60 set vrouter VR-1025 access-list 60 deny ip 192.168.0.0/16 1 set vrouter VR-1025 access-list 60 deny ip 172.16.0.0/12 2 set vrouter VR-1025 access-list 60 deny ip 10.0.0.0/8 3 set vrouter VR-1025 access-list 60 permit ip 0.0.0.0/0 4 set vrouter VR-1025 as-path-access-list 1 permit "$655" set vrouter VR-1025 set route-map name "BGP-Match" permit 1 set route-map name "BGP-Match" 1 set match ip 60 set metric 500 set next-hop 1.1.1.1 set as-path 1 set origin igp exit exit set vrouter VR-1025 protocol bgp redistribute route-map "BGP-Match" protocol ospf set vrouter VR-1025 protocol bgp redistribute route-map "BGP-Match" protocol static save

CONFIGURE STATIC ROUTES INCL. FLOATING STATIC ROUTES


Creating a Static Route To add a static route to a virtual router: set vrouter vrouter route ip-address/mask(octet) interface interface gateway gw-ipaddress metric metric The interface is the outgoing interface for traffic and how the traffic will reach the nexthop gateway IP address (gw-ip-address). Sometimes a destination will be on an Page | 112

interface even though its network is different (see NAT-dst and route-based VPNs) so the gateway portion and the metric portion of the command is optional. Sometimes, it is necessary to create the static route from one virtual router to the other. set vrouter vrouter route ip-address/mask(octet) vrouter dst-vrouter Where dst-vrouter is the virtual router responsible for passing the traffic to the nexthop gateway To configure a default route use 0.0.0.0/0 as the network IP address and Sometimes static routes are added in this way: set route ip-address/mask(octet) gateway gw-ip-address This command is valid because of the default virtual router setting as a NetScreen can be configured with a default virtual router. So all routes added using the above short-cut command is added to the default virtual router.

CONFIGURE/VERIFY SOURCE ROUTING


Conguring Source-Based Static Routes: Before you can perform source-based routing you must enable it in the VR Go to Network > Routing > Source to view the source-based routing table Select the appropriate VR in the drop-down menu Click New The route you enter in the IP Address/Netmask is the source IP address or subnet you would like to route for. Select to forward to a VR or Gateway for the next hop (we use a Gateway and dene a Gateway IP Address) Click OK Using the following values: Virtual Router Route Type IP Address/Netmask Next Hop Gateway IP Address From CLI: Set vrouter VR-1025 route source 10.1.5.0/24 interface null gateway 172.16.2.1 preference 20 save Listing the Routing Table VR-1025 Source Based 10.1.50/24 Gateway 172.16.2.1

Page | 113

When troubleshooting routing issues and validating configurations to ensure youre routing has been configured correctly it is useful to list the routing table. get route Output: C - Connected, S - Static, A - Auto-Exported, I - Imported, R - RIP untrust-vr (2 entries) --------------------------------------------------------------------------------------------------------------------ID IP-Prefix Interface Gateway P Pref Mtr Vsys --------------------------------------------------------------------------------------------------------------------* 2 0.0.0.0/0 eth3 100.100.100.1 S 20 1 Root * 1 100.100.100.0/24 eth3 0.0.0.0 C 0 0 Root trust-vr (7 entries) --------------------------------------------------------------------------------------------------------------------ID IP-Prefix Interface Gateway P Pref Mtr Vsys --------------------------------------------------------------------------------------------------------------------* 4 0.0.0.0/0 n/a untrust-vr S 20 0 Root * 7 1.1.1.1/32 eth2 10.2.6.100 S 20 1 Root * 6 10.1.0.0/16 eth2 10.2.6.2 S 20 1 Root * 2 10.2.6.0/24 eth2 0.0.0.0 C 0 0 Root * 1 10.3.1.0/24 eth1 0.0.0.0 C 0 0 Root * 8 192.168.1.0/24 eth4 0.0.0.0 C 0 0 Root * 5 10.5.0.0/16 eth1 10.3.1.9 S 20 1 Root Specific Route Information Route IDs provide allow a detailed look up on a configured route. get route id id Output: route in vr trust-vr: -------------------------Configure/verify policy routing id: IP address/mask: next hop (gateway): preference: metric: outgoing interface: vsys name/id: tag: flag: type: status:

7 1.1.1.1/32 10.2.6.100 20 1 ethernet2 Root/0 0 00000040/00000008 static active (for 7 days 7 hours 1 minutes 9 seconds)

Page | 114

Determine which route selected traffic is taking get route ip ip-address Output: Destination Routes for 1.1.1.1 --------------------trust-vr : => 1.1.1.1/32 (id=7) via 10.2.6.100 (vr: trust-vr) Interface ethernet2 , metric 1 potential routes in other vrouters: untrust-vr : => 0.0.0.0/0 (id=2) via 202.65.22.1 (vr: untrust-vr)

Interface ethernet3 , metric 1

You can determine which routes in the routing table the firewall is attempting to use and the alternative routes which may be possible. Attack Prevention

CONFIGURE/VERIFY POLICY ROUTING


PBR (Policy Based Routing) Policy Based routing allows traffic routing based on Extended ACLs. This gives greater control on how traffic is routed and allows route based traffic on source IP, source port, destination Port, Destination IP, Protocol etc. The basic framework of configuring policy based routing is as follows, Create an Extended ACL Create a Match Group (aggregate one or more access lists) Create an Action Group (define where the traffic is routed) Create a Policy (combines Match group and Action group) Configure Policy Binding to bind this new policy to a zone. Extended Access-Lists Extended access-lists list match criteria you define for PBR policies. PBR match criteria determine the path of a particular data traffic flow. Match criteria include the following: Source IP address Destination IP address Source port Destination port

Page | 115

Protocol, such as HTTP Quality of Service (QoS) priority (optional)

Match Groups Match groups provide a way to organise extended access lists by group, name and priority and associate an extended access-list ID number with a unique match group name and a match group ID number. This match-group ID number defines the order in which you want the security device to process the extended ACL lists. You can assign multiple extended access-lists to the same match-group. Action Groups Action groups specify the route you want a packet to take. You specify the action for the route by defining the next interface, next-hop, or both. Each configured action entry is monitored for reachability as follows: Next-Interface Only Reachability - If you associate the action entry with only a next-interface, link state determines reachability so if the next-interface is up, the action entry is reachable. Any interfaces including all the logical interfaces, such as tunnel, aggregate, or redundant, that are visible in the VR in which the policy resides are candidates for next-interface. For example, if you configure the action entry with a NULL interface, the action entry is reachable all the time. With a NULL interface as the next interface, PBR lookup always succeeds; so, ScreenOS stops the route lookup and discards the packet(s). Next-Hop Only Reachability - If you associate the action group with a next-hop only, that nexthop must be reachable through a route entry in the destination routes routing table. The configured next-hop is reachable as long as a valid route exists in the destination routes routing table to resolve the next-hop. Next-Interface and Next-Hop Reachability - If you configure next-interface and next-hop reachability, the configured next-hop must be reachable through the configured next-interface. If the next-hop is reachable through the next-interface, the action entry is reachable. Any interfaces including all the logical interfaces, such as tunnel, aggregate, or redundant, that are visible in the VR in which the policy resides are candidates to be a next-interface. If the next hop is reachable but the next interface is a NULL interface, ScreenOS drops the packet. If you configure the action entry with a NULL interface as the next interface and the next hop as a static route, ScreenOS passes the packet(s) to the static route. At the time of configuration, you also assign a sequence number to specify the order in which you want the action group entry processed. Policy Based Routing set vrouter trust-vr Create an Extended ACL set access-list extended 100 src-ip 10.1.1.7/24 dst-ip 10.2.2.2/32 dest-port 22-22 protocol tcp entry 1 set access-list extended 100 src-ip 10.1.1.7/24 dst-ip 10.2.2.2/32 dest-port 443-443 protocol tcp entry 2 Create a Match Group Page | 116

set match-group name PBR_GROUP set match-group PRB_ROUTE ext-acl 10 match-entry 1 set match-group PRB_ROUTE ext-acl 10 match-entry 2 Create an Action Group set action-group name Action_PBR_ROUTE set action-group Action_PBR_ROUTE next-hop 10.1.2.7 action-entry 1 set action-group Action_PBR_ROUTE next-interface ethernet2 action-entry 2 Create a Policy set pbr policy Redirect_PBR_ROUTE match-group PBR_GROUP action-group Action_PBR_ROUTE 1 exit set interface ethernet4 pbr Redirect_PBR_GROUP set vrouter trust-vr pbr Redirect_PBR_ROUTE

Page | 117

DYNAMIC ROUTING/ROUTING OVER VPNS QUESTONS


QUESTION 1 You want to configure routing redundancy over your VPN network, but do not want to deploy a dynamic routing protocol. What should you do? A. Configure multiple static routes, setting tags to designate primary and backup routes. Configure multiple static routes, adjusting the cost to determine primary and backup routes. B. Configure multiple static routes, adjusting the metric to determine primary and backup routes. C. Configure multiple static routes, adjusting the preference to create floating static routes as backups. QUESTION 2 To which three ScreenOS components can a policy-based routing policy be bound? (Choose three.) A. B. C. D. E. zone policy interface virtual router virtual system

QUESTION 3 Which two of the following statements regarding ScreenOS antivirus functionality are true? (Choose two.) A. B. C. D. ICAP-based external scanning requires an AV profile. External scanning requires a Trend Micro antivirus scanner. Embedded scanning can be based on file extension and content type. You can use policy-based routing to implement AV in a high-performance environment.

Page | 118

ATTACK PREVENTION
Deep Inspection takes network security all the way up the stack to the application layer, inspecting trafc as it would be interpreted by the end-host application. This answers the problem; how do I defend from attacks when I need to leave port 80 open? DI examines all incoming packets and assigns them a session or in the case of stateless protocols such as UDP or ICMP, a pseudo-session. It reassembles fragments, rearranges out-of-order frames, and creates data streams from these packets so errors from overlapping fragments are handled by IP layer protocol anomaly inspectors. These streams are then handed off to protocol-specic inspection engines, called Q modules, which further inspect and parse the stream into protocol-specic elements called contexts, for signature matching. Protocol-specic anomalies are also detected at this stage. E.g. DNS requests are matched to DNS replies to ensure the answer matches the questionthis prevents DNS poisoning.

SCREEN FUNCTIONS
These are the steps to configure deep inspection on firewalls using CLI.

Downloading the signature database


If the firewall has internet access, the signatures can be downloaded from the console using the command exec attack update. To work, the firewall must be configured with a reachable DNS server IP address. The command to configure DNS server is: set dns host dns1 <ip_address> SSG150> exec attack update Loading attack database. Done. Done. Switching attack databaseDone Saving attack database to flashDone. SSG150> If the firewall does not have internet access, the signature update can be done by manually downloading the attack signature file to a PC and uploading it to the firewall. To download the signature file the following information is required Major software version Hardware platform Device serial number

There are also four different groups of attack database available for download Base Client protection Server protection Worm protection

The attack-db can be then uploaded to the firewall from a TFTP server: Page | 119

save attack-db from tftp <ip_address> attacks.bin to flash

Viewing the attack objects


Attacks are grouped by 1. Severity 2. Protocol To view all the attack groups get attack group Using the filter to view specific protocol get attack group | inc http Using the filter to view specific severity get attack group | inc high Using the filter to view specific severity and protocol get attack group | inc critical:http Viewing the signature within a group Note: The group name in the command is case sensitive get attack group HIGH:DNS:ANOM

Creating Deep Inspection Policies


Only signature or anomaly groups can be used in security policies. The following example shows how to create security policy inspecting FTP traffic set policy id 4 from untrust to trust any any http permit set policy id 2 attack HIGH:HTTP:SIGS action close Adding another group of signature sets to the existing DI policy is done from policy context mode. set policy id 4 set attack HIGH:WORM:SIGS action drop The attack logs can be seen in the event log where Event type 601 corresponds to deep inspection logs. get eve type 601

Page | 120

DESCRIBE/CONFIGURE ANTI-VIRUS FUNCTIONALITY


The anti-virus functionality can be split into two main parts, the application protocol engine, found in the rmware, and the pattern/signature updates, updated from the network. The application protocol engine decodes the content le types, as well as the le transfer protocols. Antivirus provides engines for the following le transfer application protocols: HTTP (downloads, server-to-client ows) ICAP FTP (downloads, server-to-client ows) POP3 (download, server-to-client ows) IMAP (downloads, server-to-client ows) SMTP (uploads, client-to-server ows) ICAP

These decode the le transfer application protocol, and scan for les. Finding a le, they then decode le formats, unpacking and decompressing as needed, checking for virus signatures. These engines cover the typical le transfer applications and there are ways to transfer les, particularly larger les that are not scanned. As the protocol engine has to buffer the le and this buffer must t in memory, scanning is limited to small and medium-sized les. Content must be buffered and then reassembled before scanning, which might increase delay. This may be perceptible for interactive applications like HTTP. Viruses typically piggyback on executable les so a potential for optimisation is not to scan data content le types e.g. Application/x-director, application/pdf, audio/*, image/*, text/css, test/html, video/*. But this is not recommended.

Antivirus Engines on Juniper Firewall Models based on Juniper Networks rewalls running ScreenOS 5.4

Page | 121

ScreenOS supports internal and external antivirus scanning on selected platforms and ScreenOS 5.0 includes the embedded antivirus functionality for the NetScreen-5GT and support for the Trend Micro CSP protocol on the NetScreen-25/-50/-204/-208/-500. The NetScreen-5GT, with ScreenOS 5.0, has the ability to do inline antivirus scanning via an embedded scanning engine from Trend Micro. This capability is licensed, requiring a software key to activate. It includes automatic pattern updates from Trend Micro for 1 year, with additional purchase of annual update subscriptions available. Conguring Global Antivirus Parameters Access Screening > Antivirus > Global and display the ScreenOS 5.4.0 screen. The options to congure include the following: Fail Mode Trafc Permit - If enabled and the AV scan fails the trafc is still permitted. If the scan is successful, and no virus is found, the trafc is permitted regardless of this setting. If the scan detects a virus, the trafc is dropped, regardless of this setting. Maximum AV Resources Allowed per AV Client - Enforces limiting of the memory resource per AV client. Keep Alive - If enabled it keeps the HTTP session open to the server with a keep-alive request after the le arrives on the NetScreen device, but before it has nished scanning the le. Decreases overall latency of the connection but less secure Trickling - Sends a small portion of the le to the requesting client to prevent the clients browser timeout. The three options for this are Disable, Default (if the received le is larger than 3MB it will trickle 500 bytes for every 1MB of data scanned), or Custom, you can set your own trickling settings: Minimum Length - Sets the minimum le size to start trickling. Files smaller than this will not be trickled and files of this size or larger are trickled according to the following settings. Trickle Size - sets the trickle packet size. Trickle for Every - sets the amount of trafc sent before a single packet is sent.

Antivirus Rules Antivirus protection is activated by associating an Antivirus prole with each rule. Select the AV prole object from the drop-down list. Do this for each policy that needs antivirus scanning on any of the supported protocols. Antivirus Policy Listing

Verify Antivirus Protection A harmless standard pattern for every Antivirus product can be found at the European Institute for Computer Antivirus Research (EICAR). To get the EICAR test les, see www.eicar.com/. Your Web browser should display the flowing:

Page | 122

VIRUS WARNING 10.252.3.237:1273->83.246.65.3:80 Download contaminated le: www.eicar.com/download/eicar.com/ with virus EICARTest-File. And your logs should contain the entry: AV: VIRUS FOUND: 10.252.3.237:1283->83.246.65.3:80, http url: http://www.eicar.com/download/eicar.com, le www.eicar.com/download/eicar.com/ virus EICAR-Test-File. You can test whether the test pattern is correctly blocked for executable (.com), data les (.txt), and archives (.zip) depending on your conguration. Configure Anti-Virus AV, Web filtering, anti-spam, or deep inspection (DI) subscriptions can be added to your new or existing Juniper Networks security device to activate the services as shown: You should receive an authorization code, via email, from Juniper Networks or your authorised dealer after purchase. The code contains information you to register the subscription. Register the subscription authorisation code to the device at http://tools.juniper.net/subreg Ensure your device has Internet connectivity. Retrieve the subscription key on the device.

You can do this in one of two ways: WebUI - click Retrieve Subscriptions Now from Configuration >Update > ScreenOS/Keys. CLI - run the following command: exec license-key update

Reset the device after the key has been loaded. The device can be configured to automatically or manually retrieve the signature services.

CONFIGURE WEB FILTERING


Web filtering or URL filtering allows management of Internet access to prevent access to inappropriate Web content. ScreenOS provides two Web-filtering solutions; Integrated and Redirect. Integrated Web filtering can permit or block access to a requested site by binding a Webfiltering profile to the firewall policy. A Web-filtering profile specifies URL categories and the action the security device takes when it receives a request to access a URL in each category. The URL categories are predefined or user-defined. In redirect Web filtering the device sends HTTP requests in TCP connections to a Websense or SurfControl server to block or permit access to different sites based on their URLs domain names and IP addresses. Perform the following to configure either of the Web-filtering solutions:

Page | 123

Select the protocol set url protocol type { sc-cpa | scfp | websense } command selects the protocol. Initiate the Web-filtering mode set url protocol { sc-cpa | scfp | websense } command puts the CLI in the Web-filtering context. Once initiated, all subsequent command executions apply to that Web-filtering mode. Entering and Exiting Web-Filtering Modes

Configuring Integrated Web Filtering To configure a security device for Web filtering, perform the following steps: Set Up a Domain Name Server Enable Web Filtering Define URL Categories (Optional) Define Web-Filtering Profiles (Optional) Prioritise User Groups Enable Web-Filtering Profile and Policy ENABLE WEB FILTERING WebUI or CLI commands can be used to enable integrated Web filtering on a Juniper Firewall but if using CLI you must enter the Web-filtering context before entering the commands specific to integrated Web filtering. From WebUI Security > Web Filtering > Protocol Selection: Select Integrated (SurfControl), then click Apply. Then select Enable Web Filtering via CPA Server, and click Apply again. From CLI device-> set url protocol type sc-cpa device-> set url protocol sc-cpa device(url:sc-cpa)-> set enable device(url:sc-cpa)-> exit Page | 124

To view the list of SurfControl predefined URL categories: From WebUI Security > Web Filtering > Profiles > Predefined category From CLI device-> set url protocol type sc-cpa device-> set url protocol sc-cpa device(url:sc-cpa)-> get category pre The URL category list is than displayed:

DEFINE URL CATEGORIES (OPTIONAL) To create a category named Competitors and add the following URLs: www.games1.com and www.games2.com. From WebUI Security > Web Filtering > Profiles > Custom > New: Enter the following, and click Apply: Category Name: Competitors URL: www.games1.com Enter the following, and click OK: URL: www.games2.com From CLI device-> set url protocol sc-cpa device(url:sc-cpa)-> set category competitors url www.games1.com device(url:sc-cpa)-> set category competitors url www.games2.com device(url:sc-cpa)-> exit device-> save

Page | 125

DEFINE WEB-FILTERING PROFILES (OPTIONAL) A Web-filtering profile consists of a group of URL categories assigned with permit or block (it displays a message in the browser indicating the URL category) as an action. You can edit an existing message or create a new message (up to 500 characters) to be sent from the security device. From WebUI Security > Web Filtering > Protocol > Selection Select Integrated (SurfControl). Enter the message in the Web Filter Deny Message text area and click Apply. The default message is: Your page is blocked due to a security policy that prohibits access to $URL-CATEGORY From CLI device-> set deny-message deny-message-str Define Web-Filtering Profiles (Optional) If the device is unable to determine the category of the requested URL, it blocks or permits access based on the default configuration in the profile. Web-Filtering Profiles and Policies Flowchart

If the URL is in a permitted category and AV scanning enabled for that policy, the device scans the contents for viruses. If the URL is in a blocked category, it closes the TCP connection and sends a message alerting the user. It does not perform AV scanning. From WebUI Security > Web Filtering > Profile > Custom Profile > New Enter the following and click Apply: Profile Name: my-profile Default Action: Permit Category Name: Competitors (select) Action: Block (select) Configure: Add (select)

Page | 126

From CLI device(url:sc-cpa)-> set profile my-profile other permit device(url:sc-cpa)-> set profile my-profile competitors block device(url:sc-cpa)-> exit PRIORITISE USER GROUPS User groups are created to manage authentication users collectively and a user can belong to more than one user group. So, user groups must be prioritised. This ensures the UF Manager selects the highest priority user group and blocks or permits the HTTP/HTTPS request according to the profile bound to the user-group. The priority can be set to a value between 1 and 65535 and no two user groups can have the same priority. User groups and priorities can be created the WebUI or the CLI. From WebUI Security > Web Filtering > User Group Binding Enter the following and click Apply: User Group: (select) Priority: 4 Profile: (select) From CLI device-> set url protocol sc-cpa device(url:sc-cpa)-> set user-group group_name priority priority_number device(url:sc-cpa)-> set user-group group_name profile profile_name ENABLE WEB-FILTERING PROFILE AND POLICY Antivirus (AV) scanning and integrated Web filtering can be enabled in a policy. If usergroup based filtering is enabled the UF Manager extracts the URL from the request and identifies the profile assigned to the user. If the user belongs to multiple user groups the UF Manager selects the user group that has highest priority. The UF Manager identifies the category of the URL and permits or blocks the request according to the group-based profile. If the user group or profile related to the user is not found, the device intercepts all HTTP requests. If there is a profile bound to the policy the device matches the URL in the incoming HTTP request to the categories in the profile in the following sequence: Blacklist Whitelist User-defined categories SurfControl predefined URL categories

If the device is unable to determine the category of the requested URL, it blocks or permits access based on the default configuration in the profile. Page | 127

Perform the following steps to enable integrated Web filtering on the security device and block access to competitor sites Create a category called Competitors. Add the following URLS to the category: www.comp1.com and www.comp2.com. Create a profile called my-profile, and add the Competitors category. Apply my-profile to a firewall policy

To determine whether the groupbased filtering is enabled, use the get url CLI command. The following output appears: device-> get url UF Key Expire Date: 11/21/2009 00:00:00 SC-CPA Web filtering: enabled Primary: america usi.SurfCPA.com port:9020 Secondary: asia Asiai.SurfCPA.com port:9020 Cache: enabled Cache Size: 500(K) Cache Timeout: 24 Hour(s) Cache Host Count: 0 Cache URL Count: 0 Category list query interval: 2 Week(s) Fail Mode: Fail-Block Log: blocked Group-based filtering: disabled

From WebUI Web Filtering Security > Web Filtering > Protocol > Select Integrated (SurfControl) Click Apply Select Enable Web Filtering via CPA Server Select User Group Based Filtering Click User Group Binding to set the priority Click Apply URL Category Security > Web Filtering > Profile > Custom List > New: Enter the following: Category Name: Competitors URL: www.comp1.com Enter the following and click OK: URL: www.comp2.com Click Apply

Page | 128

Web-Filtering Profile Security > Web Filtering > Profile > Custom Profile > New: Enter the following, Profile Name: my-profile Default Action: Permit Category Name: Competitors (select) Action: Block (select) Configure: Add (select) Click Apply From CLI Web Filtering get url device->set url protocol sc-cpa device(url:sc-cpa)-> set enable device(url:sc-cpa)-> set group-based-filtering device(url:sc-cpa)-> get user-group group_name | all URL Category device(url:sc-cpa)-> set category competitors url www.comp1.com device(url:sc-cpa)-> set category competitors url www.comp2.com Web-Filtering Profile device(url:sc-cpa)-> set profile my-profile other permit device(url:sc-cpa)-> set profile my-profile competitors block device(url:sc-cpa)-> exit Firewall Policy device-> set policy id 23 from trust to untrust any any http permit url-filter device-> set policy id 23 device(policy:23)-> set url protocol sc-cpa profile my-profile device(policy:23)-> exit device-> save

Page | 129

ATTACK PREVENTION QUESTONS


QUESTION 1 Which three events would cause ScreenOS devices to generate SNMP traps? (Choose three.) A. B. C. D. E. cold starts traffic alarms warm reboots self log events traffic log events

QUESTION 2 Which three HTTP components can a ScreenOS device inspect and selectively block? (Choose three.) gz files zip files exe files Java applets JavaScript applets

QUESTION 3 Which policy action is needed to add deep inspection to a policy? A. B. C. D. reject detect permit inspect

Page | 130

MULTICAST
NetScreen and SSG series firewalls support a range of routing protocols and multicast and IPv6 traffic and these functions have been integrated within a single device. A separate routing table for multicast traffic is held on Juniper Firewalls. A multicast traffic source can be directed out of a specific interface based upon a combination of: Source IP Multicast group Incoming interface.

The firewall can translate the multicast group based on this route and multicast routes can be dynamically defined based upon the Protocol Independent Multicast (PIM). Juniper supports this protocol. Multicast Routing Here is how to create multicast static routes in the Multicast Routing table. The properties of multicast routes: Source IP - source IP address of the multicast host transmitting the traffic to traffic via multicast. MGroup - multicast IP group address being sent. Incoming Interface- interface the traffic will arrive on but potentially multicast can arrive on multiple interfaces. Outgoing Interface - interface multicast traffic is forwarded out of. Translated MGroup - translates the multicast group address

Configuring Static Multicast Routes To configure a static multicast route on the firewall your network must be configured to support multicast routing to be truly effective. From the WebUI: Go to Network > Routing > MCast Routing Select the VR to configure Click New Define the Source IP of the multicast host Define the MGroup, (multicast group address) the multicast destination address, such as 224.0.0.18. Define Interface the multicast traffic arrives on (Incoming Interface) Note. And it is important to define this since the traffic could arrive on more than one interface. Define the Outgoing Interface from the drop-down menu (Interface the traffic will be forwarded out from)

Page | 131

CONFIGURE/VERIFY IGMP
The, Internet Group Management Protocol (IGMP); can multicasts messages and information among members of an IP multicast group. IGMP runs between hosts and routers and exchanges multicast group membership information. Traffic is sent to a single MAC address but forwarded out via the local multicast router to multiple hosts using multicast. Enterprises use multicast routing to transmit traffic, such as data or video streams, from one source to a group of receivers simultaneously. Any host can be a source, and the receivers can be anywhere on the Internet. Configuring Access List for Accepted Groups set vrouter trust-vr access-list 1 permit ip 224.4.4.1/32 1 set interface ethernet1 protocol igmp accept groups 1 Enabling IGMP on interface set interface ethernet1 protocol igmp router set interface ethernet1 protocol igmp accept groups 1 set interface ethernet1 protocol igmp enable set interface ethernet2 protocol igmp router set interface ethernet2 protocol igmp accept groups 1 set interface ethernet2 protocol igmp enable Verify IGMP Configuration The following commands can be used to verify an IGMP configuration: exec igmp interface ethernet2 query exec igmp interface ethernet2 query 224.4.4.1 exec igmp interface ethernet2 report 224.4.4.1 get igmp interface get igmp group To forward the multicast traffic you need to configure multicast routing protocol.

CONFIGURE/VERIFY PIM-SM
PIM (Protocol Independent Multicast) PIM runs between routers to forward the multicast traffic to multicast group members in the network. PIM-SM (Protocol Independent Multicast-Sparse Mode) is a routing protocol that forwards multicast traffic to interested receivers and can use either a shared distribution tree or the shortest path tree (SPT) to forward multicast traffic through the network. By default, PIMSM uses the shared distribution tree with a rendezvous point (RP) at the root of the tree and is generally a core router. All sources in a group send their packets to the RP, and the RP sends data down the shared distribution tree to all receivers in a network. When a configured threshold is reached, the receivers can form an SPT to the source, decreasing the time it takes the receivers to receive the multicast data. A DR (Designated Router) is elected when there are multiple multicast routers and this DR is sends the multicast packets to the RP and the rest of the other multicast routers. Page | 132

A NetScreen device can function as a rendezvous point (RP), source designated router (DR), receiver DR, and intermediate router. It cannot function as a bootstrap router. You can configure PIM-SM on one virtual router (VR) or across two VRs. Configure PIM-SM on one virtual router: 1. Configure zones and interfaces. 2. Configure either static routes or a dynamic routing protocol such as Routing Information Protocol (RIP), Border Gateway Protocol (BGP) or Open Shortest Path First (OSPF) on a specific virtual router on the NetScreen device. 3. Create a firewall policy to pass unicast and multicast data traffic between zones. 4. Create and enable a PIM-SM routing instance on the same virtual router on which you configured the static routes or a dynamic routing protocol. 5. Enable PIM-SM on interfaces forwarding traffic upstream towards the source or RP, and downstream towards the receivers. 6. Enable IGMP on interfaces connected to hosts. 7. Configure a multicast policy to permit PIM-SM messages between zones. When you configure PIM-SM across two VRs, you must configure the RP in the zone of the VR in which the RP is located. Then, configure a multicast group policy allowing join-prune and BSRstatic-RP messages between the zones in each VR. You must also export unicast routes between the two VRs to ensure the accuracy of the reverse path forwarding (RPF) information. Some NetScreen devices support multiple virtual systems. For information on virtual systems, see the Virtual Systems volume in the NetScreen Concepts & Examples ScreenOS Reference Guide. When you configure PIM-SM in a virtual system, it is the same as configuring PIM-SM in the root system. When you configure PIM-SM on two virtual routers that are each in a different virtual system, then you must configure a proxy RP. PIM-SM Configuration You want hosts in the Trust zone to receive multicast traffic for the multicast group 24.4.4.1/32. Configure RIP as the unicast routing protocol in the trust-vr Create a firewall policy to pass data traffic between the Trust and Untrust zones. Create a PIM-SM instance in the Trust-vr and enable PIM-SM on ethernet1 and ethernet2 in the Trust zone, and on ethernet3 in the Untrust zone. Ensure all interfaces are in route mode Configure IGMP on ethernet 1 and ethernet2 (which are connected to receivers). Create a multicast policy permitting static-RP-BSR and join-prune messages between the zones.

Page | 133

From WebUI 1. Zones and Interfaces Network > Interfaces > Edit (for ethernet1): Enter the following, and then click Apply: Zone Name: Static IP: IP Address/Netmask: Select the following, and then click OK: Interface Mode: Network > Interfaces > Edit (for ethernet2): Enter the following, and then click OK: Zone Name: Static IP: IP Address/Netmask: Select the following, and then click OK: Interface Mode: NAT Trust (select this option when present) 10.1.1.1/24 NAT Trust (select this option when present) 10.1.1.1/24

Page | 134

Network > Interfaces > Edit (for ethernet3): Enter the following, and then click OK: Zone Name: IP Address/Netmask: 2. Addresses Objects > Addresses > List > New: Enter the following information, and then click OK: Address Name: IP Address/Domain Name: IP/Netmask: Zone: Objects > Addresses > List > New: Enter the following information, and then click OK: Address Name: IP Address/Domain Name: IP/Netmask: Zone: 3. IGMP Network > Interfaces > Edit (for ethernet1) > IGMP: Enter the following, and then click OK: IGMP Mode: Protocol IGMP: Router (select) Enable (select) source-dr (select), 6.6.6.1/24 Untrust mgroup1 (select), 224.4.4.1/32 Trust Untrust 1.1.1.1/24

Network > Interfaces > Edit (for ethernet2) > IGMP: Enter the following, and then click OK: IGMP Mode: Protocol IGMP: 4. RIP Network > Routing > Virtual Router (trust-vr) > Edit > Create RIP Instance: Select Enable RIP, and then click OK. Network > Interfaces > Edit (for ethernet3) > RIP: Enter the following, and then click Apply: RIP Instance: Protocol RIP: (select) Enable (select) Router (select) Enable (select)

Page | 135

5. PIM-SM Network > Routing > Virtual Router (trust-vr) > Edit > Create PIM Instance: Select the following, and then click OK. Protocol PIM: Network > Interfaces > Edit (for ethernet1) > PIM: Enter the following, and then click Apply: PIM Instance: Protocol PIM: Network > Interfaces > Edit (for ethernet2) > PIM: Enter the following, and then click Apply: PIM Instance: Protocol PIM: Network > Interfaces > Edit (for ethernet3) > PIM: Enter the following, and then click Apply: PIM Instance: Protocol PIM: 6. Policy Policies > (From: Untrust, To: Trust) > New: Enter the following, and then click OK: Source Address: Address Book Entry: Destination Address: Address Book Entry: Service: Action: Multicast Policy MCast Policies (From: Trust, To: Untrust) > New: Enter the following and click OK: MGroup Address: Bidirectional: PIM Message: BSR Static RP: Join/Prune: IP/Netmask (select) 224.4.4.1/32 (select) (select) (select) (select) (select), source-dr (select), mgroup1 any Permit (select) Enable (select) (select) Enable (select) (select) Enable (select) Enable (select)

Page | 136

From CLI 1. Zones and Interfaces set interface ethernet 1 zone trust set interface ethernet 1 ip 10.1.1.1/24 set interface ethernet1 nat set interface ethernet 2 zone trust set interface ethernet 2 ip 10.1.2.1/24 set interface ethernet2 nat set interface ethernet 3 zone untrust set interface ethernet 3 ip 1.1.1.1/24 2. Addresses set address trust mgroup1 224.4.4.1/32 set address untrust source-dr 6.6.6.1/24 3. IGMP set interface ethernet 1 protocol igmp router set interface ethernet 1 protocol igmp enable set interface ethernet 2 protocol igmp router set interface ethernet 2 protocol igmp enable RIP set vrouter trust-vr protocol rip set vrouter trust-vr protocol rip enable set interface ethernet3 protocol rip enable 4. PIM-SM set vrouter trust-vr protocol pim set vrouter trust-vr protocol pim enable set interface ethernet1 protocol pim set interface ethernet1 protocol pim enable set interface ethernet2 protocol pim set interface ethernet2 protocol pim enable set interface ethernet3 protocol pim set interface ethernet3 protocol pim enable 5. Policy set policy from untrust to trust source-dr mgroup1 any permit 6. Multicast Policy 7. set multicast-group-policy from trust mgroup 224.4.4.1/32 any to untrust pim-message bsr-static-rp join bi-directional save

Page | 137

VERIFYING THE CONFIGURATION


To verify the PIM-SM configuration, execute the following command:

To view the multicast route entries, execute the following command: You can verify the following in each route entry: The (S, G) state or (*, G) forwarding state If the forwarding state is (*, G), the RP IP address; If the forwarding state is (S, G), the source IP address Zone that owns the route The join status and the incoming and outgoing interfaces Timer values

Page | 138

MULTICAST QUESTONS QUESTION 1 Review the exhibit. Based on the exhibit, which of the following statements is true about this OSPF configuration?

A. B. C. D.

The neighbor device has been selected as the DR. The OSPF neighbor's IP address is 10.50.1.1. OSPF hellos are going to the wrong multicast address. The neighbor relationship between the two devices cannot be established.

QUESTION 2 Review the exhibit. Which two of the following elements must be configured on the ScreenOS device in order to support PIM-SM? (Choose two)

A. A multicast control policy B. A bootstrap router process


Page | 139

C. A unicast routing protocol D. A static RP QUESTION 3 Which CLI command identifies the multicast sources visible to your ScreenOS device? A. B. C. D. get route pim get igmp source all exec pim interface all query get vrouter trust-vr protocol pim

Page | 140

APPENDIX
VPN ANSWERS QUESTION 1 Answer: AB Explanation/Reference: Sites without a static IP address (typically home or small office sites) cannot be defined with a remote gateway IP address. NetScreen Firewalls overcome this through the use of a local and peer ID. Therefore A & B are correct. QUESTION 2 Answer: C Explanation/Reference: Since the peer will be identified by a certificate generated with RSA keys, all phase 1 proposals for this gateway must begin with RSA and not Pre (pre-shared). You cannot specify both types within the same proposal set. Also be sure to specify the correct outgoing interface which should be the Internet facing interface. QUESTION 3 Answer: A Explanation/Reference: POINT-TO-MULTIPOINT TUNNEL INTERFACE RIP point-to-multipoint is supported on numbered tunnel interfaces for RIP versions 1 and 2. You must disable split horizon on a point-to-multipoint interface tunnel that you configure with or without demand circuits so that messages reach all remote sites. RIP dynamically learns about neighbors. RIP sends all transmitted messages to the multicast address 224.0.0.9 and reduplicates them to all tunnels as appropriate. If you want to set up RIP as a point-to-multipoint tunnel with demand circuits, you must design your network in a hub and spoke configuration. QUESTION 4 Answer: AC Explanation/Reference: To make the population of both NHTB and route tables automatic the following conditions must apply: 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

Page | 141

QUESTION 5 Answer: AC Explanation/Reference: Setting up the AutoKey IKE tunnel using AutoKey IKE, with either a pre-shared secret or certificates, involves the following steps: A. Define security zone interface IP addresses B. Make address book entries for the local and remote end entities.(Local end, ssg550 needs to know about peer-id of 1.1.1.10) C. Define the remote gateway and key exchange mode, and specify either a preshared secret or a certificate. D. Create the AutoKey IKE VPN. E. Set a default route to the external router F. Configure policies.

Page | 142

NETWORK MANAGEMENT ANSWERS QUESTION 1 Answer: CDE Explanation/Reference: NetScreen Logging Juniper firewalls have the capability to log network traffic, and studying these logs can help your troubleshooting efforts immensely. Logs can be distributed via the following methods: Console Some log messages are sent to the console (serial, SSH, or Telnet). Internal The firewall can store a limited amount of logs for real-time troubleshooting. QUESTION 2 Answer: BD Explanation/Reference: Select Syslog from the Report Settings sub-menu: On the Source interface drop-down list, select the interface from which syslog packets are sent, e.g. you might select trust, if you wish to send syslog messages to a system behind the firewall. Syslog Host Name / Port: enter the IP Address of the Syslog host and the port number that the Syslog UDP packets will be sent on. The default is 514. QUESTION 3 Answer: A Explanation/Reference: SNMPv1 and SNMPv2c Implementation Overview Juniper Networks has implemented SNMP in its devices in the following ways: SNMP administrators are grouped in SNMP communities. A device can support up to three communities, with up to eight members in each community. A community member can be either a single host or a subnet of hosts, depending on the netmask you use when defining the member. By default, the security device assigns an SNMP community member with a 32-bit netmask (255.255.255.255), which defines it as a single host. If you define an SNMP community member as a subnet, any device on that subnet can poll the security device for SNMP MIB information. However, the security device cannot send an SNMP trap to a subnet, only to an individual host. Each community has either read-only or read/write permission for the MIB II data. Each community can support SNMPv1, SNMPv2c, or both. If a community supports both versions of SNMP, you must specify a trap version for each community member. You can allow or deny receipt of traps for each community.
Page | 143

You can access the MIB II data and traps through any physical interface. Each system alarm (a system event classified with a severity level of critical, alert, or emergency) generates a single enterprise SNMP trap to each of the hosts in each community that is set to receive traps. The security device sends Cold Start/Link Up/Link Down traps to all hosts in communities that you set to receive traps. If you specify trap-on for a community, you also have the option to allow traffic alarms. You can send SNMP messages through a route-based or policy-based VPN tunnel.

Page | 144

TROUBLESHOOTING WITH DEBUG/SNOOP ANSWERS QUESTION 1 Answer: C Explanation/Reference: Current Settings / Values get debug - get currently enabled debug level QUESTION 2 Answer: B Explanation/Reference: Order should be: ns5gt-> clear db ns5gt-> get ffilter ns5gt-> set ffilter dst-port 27900 filter added ns5gt-> get ffilter Flow filter based on: id:0 dst port 27900 ns5gt-> debug flow basic ns5gt-> undebug all ns5gt-> get db str QUESTION 3 Answer: B Explanation/Reference: Filters that are written on one line are and 'AND' statement. E.g. set ffilter scr-ip 10.1.1.1 dst-ip 2.2.2.2 will match 10.1.1.1 AND 2.2.2.2 Filters that are on separate lines are 'OR' statements. E.g. set ffilter scr-ip 10.1.1.1, set ffilter dst-ip 2.2.2.2 will match 10.1.1.1 OR2.2.2.2

Page | 145

TROUBLESHOOTING WITH DEBUG/SNOOP ANSWERS QUESTION 1 Answer: B Explanation/Reference: All policies are configured to have 256 Kbps guaranteed bandwidth and 512 Kbps of maximum. Therefore each policy can utilise a third of the overall bandwidth which is 512 Kbs. QUESTION 2 Answer: B Explanation/Reference: Maximum Bandwidth: Secured bandwidth available to the type of connection in kilobits per second (kbps). QUESTION 3 Answer: A

Page | 146

VIRTUAL SYSTEMS ANSWERS QUESTION 1 Answer: ACE Explanation/Reference: Interfaces A vsys can support the following three kinds of interfaces for their Untrust and Trust zones: Untrust Zone Interface Types Dedicated Physical Interface Subinterface (with VLAN tagging as a means for trunking* inbound and outbound traffic) Shared Interface (physical, subinterface, redundant interface, aggregate interface) with Root System Trust Zone Interface Types Dedicated Physical Interface Subinterface (with VLAN tagging) Shared Physical Interface with Root System

QUESTION 2 Answer: A Explanation/Reference: Virtual System Write/Read Users Virtual system administrators independently manage virtual systems through the CLI or WebUI. On each virtual system, the virtual system write/read administrator has the following privileges: Creates and edits auth, IKE, L2TP, XAuth, and Manual Key users Creates and edits services Creates and edits policies Creates and edits addresses Creates and edits VPNs Modifies the virtual system administrator login password Creates and manages security zones Adds and removes virtual system read-only administrator

Therefore DIP creation can only be done by the root administrator, not a VSYS administrator.

Page | 147

QUESTION 3 Answer: CDE Explanation/Reference: In relation to Virtual Systems, only the root and write/read administrator from a root system can: Create a virtual system and assign physical or logical interfaces to them Perform the same administration tasks as a Virtual System write/read administrator

Page | 148

DYNAMIC ROUTING/ROUTING OVER VPNS ANSWERS QUESTION 1 Answer: C Explanation/Reference: VPN Routing Considerations When the primary link is up, we want all traffic to route through the primary interface. We only want traffic to go through the secondary when the primary link goes down. Therefore, we separate these by setting a lower metric on the backup route for both default route and for tunnel routes. Also, avoid using permanent routes, as this would prevent route failovers to work. QUESTION 2 Answer: ACD Explanation/Reference: Binding a Policy-Based Routing Policy You can bind a PBR policy to an interface, a zone, or a virtual router with the WebUI or the CLI from within a virtual router context. QUESTION 3 Answer: CD Explanation/Reference: In this release of the AV scan engine, you can:

Enable/disable scanning based on file extension and content type.


Policy-based routing (PBR) provides a flexible mechanism for forwarding data packets based on polices configured by a network administrator. PBR enables you to implement policies that selectively cause packets to take different paths. PBR provides a routing mechanism for networks that rely on Application Layer support, such as antivirus (AV), deep inspection (DI), or anti-spam, Web filtering, and/or that require an automatic way to specific applications

Page | 149

ATTACK PREVENTION ANSWERS QUESTION 1 Answer: ABC Explanation/Reference: KB7990 Trap Enterprise ID Description 100 Hardware problems 200 Firewall problems 300 Software problems 400 Traffic problems 500 VPN problems 600 NSRP problems 800 DRP problems 900 Interface failover problems 1000 Firewall attacks QUESTION 2 Answer: BCD Explanation/Reference: Attack Protection Overview for ScreenOS 5.0 Granular Blocking of HTTP Components - You can selectively choose which HTTP components ActiveX controls, Java applets, .exe files, and .zip files that you want the NetScreen device to block. QUESTION 3 Answer: C Explanation/Reference: All security entries on the security device are policies. Policies are comprised of addresses (source and destination), services, actions, and options. Policies allow you to permit, deny, encrypt, authenticate, prioritize, schedule, and monitor the traffic attempting to cross from one security zone to another. You decide which users and what information can enter and leave, and when and where they can go .Alternatively, your policies can define connections that must be encrypted, thus forming a Virtual Private Network (VPN).

Page | 150

MULTICAST ANSWERS
QUESTION 1 Answer: A Explanation/Reference: Designated Router / Backup Designated Router Routers form an adjacency with a DR and BDR only. The DR/BDR election process is based on priorities (configurable), router ID, and/or (in case of the same priorities for multiple routers/interfaces) who answers first during the election phase Note the lines above: ospf: Elect BDR 1.1.1.1 10.50.10.100 (Id), DR 1.1.1.1 10.50.10.100 (Id) ospf: Adjacency needs to be established with 10.50.10.100 on ethernet0/0 This shows the neighbor device is the DR QUESTION 2 Answer: AC Explanation/Reference: Multicast policies permit multicast control traffic, such as IGMP or PIM messages, to cross NetScreen devices. Unlike firewall policies where you can specify either deny or permit as an action, the action in multicast policies is always permit. PIM-SM Allows a router to use any unicast routing protocol and performs RPF checks using the unicast routing table. However, PIM-SM has an explicit join message, so routers determine where the interested receivers are and send join messages upstream to their neighbors, building trees from receivers to RP. PIM-SM uses an RP router as the initial source of multicast group traffic and therefore builds distribution trees in the form (*,G), as do all sparse-mode protocols. However, PIM-SM migrates to an (S,G) source-based tree if that path is shorter than through the RP for a particular multicast group's traffic. QUESTION 3 Answer: D Explanation/Reference: IGMP get vrouter trust-vr protocol pim - get the multicast sources visible to your ScreenOS device

Page | 151

You might also like