Netscreen Ce VPN

1HW6FUHHQ&RQFHSW
([DPSOHV
6FUHHQ265HIHUHQFH*XLGH
9HUVLRQ
31
5HY%
1HW6FUHHQ&RQFHSWV ([DPSOHV

&RS\ULJKW1RWLFH Caution: Changes or modifications to this product could void the

user's warranty and authority to operate this device.
Copyright © 1998-2002 NetScreen Technologies, Inc. NetScreen
Technologies, Inc., the NetScreen logo, NetScreen-5, 'LVFODLPHU
NetScreen-5XP, NetScreen-10, NetScreen-25, NetScreen-50,
NetScreen-100, NetScreen-204, NetSreen-208, NetScreen-500, THE SPECIFICATIONS REGARDING THE PRODUCTS IN THIS
NetScreen-1000, NetScreen-Global Manager, NetScreen-Global MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
PRO, NetScreen-Global PRO Express, NetScreen-Remote, STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS
GigaScreen ASIC, and NetScreen ScreenOS are trademarks and MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE
NetScreen is a registered trademark of NetScreen Technologies, PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
Inc. All other trademarks and registered trademarks are the IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR
property of their respective companies. APPLICATION OF ANY PRODUCTS. NO PART OF THIS
DOCUMENT MAY BE REPRODUCED OR TRANSMITTED IN ANY
NetScreen Technologies, Inc. FORM OR BY ANY MEANS, ELECTRONIC OR MECHANICAL, FOR
350 Oakmead Parkway, Suite 500 ANY PURPOSE, WITHOUT RECEIVING WRITTEN PERMISSION
Sunnyvale, CA 94085 U.S.A. FROM NETSCREEN TECHNOLOGIES INC.
www.netscreen.com
3URGXFW/LFHQVH$JUHHPHQW
)&&6WDWHPHQW
PLEASE READ THIS LICENSE AGREEMENT (“AGREEMENTS”)
This equipment has been tested and found to comply with the CAREFULLY BEFORE USING THIS PRODUCT. BY INSTALLING
limits for a Class A digital device, pursuant to part 15 of the FCC AND OPERATING, YOU INDICATE YOUR ACCEPTANCE OF THE
rules. These limits are designed to provide reasonable protection TERMS OF THIS LEGAL AND BINDING AGREEMENT AND ARE
against harmful interference in a light commercial installation. CONSENTING TO BE BOUND BY AND ARE BECOMING A PART TO
This equipment generates, uses and can radiate radio frequency THIS AGREEMENT. IF YOU DO NOT AGREE TO ALL OF THE
energy, and, if not installed and used in accordance with the TERMS OF THIS AGREEMENT, DO NOT START THE
instruction, may cause harmful interference to radio INSTALLATION PROCESS.
communications. However, there is no guarantee that interference
will not occur in a particular installation. If this equipment does 1. License Grant. This is a license, not a sales agreement, between
cause harmful interference to radio or television reception, which you, the end user, and NetScreen Technologies, Inc.
can be determined by turning the equipment off and on, the user is (“NetScreen”). The term “Software” includes all NetScreen and
encouraged to try to correct the interference by one or more of the third party Software provided to you with the NetScreen product,
following measures: and includes any accompanying documentation, any updates and
enhancements of the Software provided to you by NetScreen, at
• Reorient or relocate the receiving antenna. its option. NetScreen grants to you a non-transferable (except as
• Increase the separation between the equipment and receiver. provided in section 3 (“Transfer”) below), non-exclusive license to
use the Software in accordance with the terms set forth in this
• Consult the dealer or an experienced radio/TV technician for License Agreement. The Software is “in use” on the product when
help. it is loaded into temporary memory (i.e. RAM).
• Connect the equipment to an outlet on a circuit different from 2. Limitation on Use. You may not attempt and if you are a
that to which the receiver is connected. corporation, you will use best efforts to prevent your employees
and contractors from attempting to, (a) modify, translate, reverse
engineer, decompile, disassemble, create, derivative works based
1HW6FUHHQ&RQFHSWV ([DPSOHV LL

on, sublicense, or distribute the Software or the accompanying unit. Defects in the product will be reported to NetScreen in a form
documentation; (b) rent or lease any rights in the Software or and with supporting information reasonably requested by
accompanying documentation in any form to any person; or (c) NetScreen to enable it to verify, diagnose, and correct the defect.
remove any proprietary notice, labels, or marks on the Software, For returned product, the customer shall notify NetScreen of any
documentation, and containers. nonconforming product during the warranty period, obtain a
return authorization for the nonconforming product, from
3. Transfer. You may transfer (not rent or lease) the Software to NetScreen, and return the nonconforming product to NetScreen’s
the end user on a permanent basis, provided that: (i) the end user factory of origin with a statement describing the nonconformance.
receives a copy of this Agreement and agrees in writing to be
bound by its terms and conditions, and (ii) you at all times comply NOTWITHSTANDING ANYTHING HEREIN TO THE CONTRARY, THE
with all applicable United States export control laws and FOREGOING IS CUSTOMER’S SOLE AND EXCLUSIVE REMEDY
regulations. FOR BREACH OF WARRANTY BY NETSCREEN WITH RESPECT
TO THE PRODUCT.
4. Proprietary Rights. All rights and title and interest in and to, and
all intellectual property rights, including copyrights, to the The warranties set forth above shall not apply to any Product or
software, and documentation, remain with NetScreen. You Hardware which has been modified, repaired or altered, except by
acknowledge that no title to the intellectual property in the NetScreen, or which has not been maintained in accordance with
Software is transferred to you and you will not acquire any rights any handling or operating instructions supplied by NetScreen, or
to the Software except for the license as specifically set forth which has been subjected to unusual physical or electrical stress,
herein. misuse, abuse, negligence or accidents.
5. Term and Termination. The term of the license is for the duration THE FOREGOING WARRANTIES ARE THE SOLE AND EXCLUSIVE
of NetScreen’s copyright in the Software. NetScreen may WARRANTIES EXPRESS OR IMPLIED GIVEN BY NETSCREEN IN
terminate this Agreement immediately without notice if you breach CONNECTION WITH THE PRODUCT AND HARDWARE, AND
or fail to comply with any of the terms and conditions of this NETSCREEN DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING
Agreement. You agree that, upon such termination, you will either IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
destroy all copies of the documentation or return all materials to PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD
NetScreen. The provisions of this Agreement, other than the PARTY RIGHTS. NETSCREEN DOES NOT PROMISE THAT THE
license granted in Section 1 (“License Grant”) shall survive PRODUCT IS ERROR-FREE OR WILL OPERATE WITHOUT
termination. INTERRUPTION.
6. Limited Warranty. For a period of ninety (90) days after delivery 7. Limitation of Liability. IN NO EVENT SHALL NETSCREEN OR ITS
to Customer, NetScreen will repair or replace any defective LICENSORS BE LIABLE UNDER ANY THEORY FOR ANY
software product shipped to Customer, provided it is returned to INDIRECT, INCIDENTAL, COLLATERAL, EXEMPLARY,
NetScreen at Customer’s expense within that period. NetScreen CONSEQUENTIAL OR SPECIAL DAMAGES OR LOSSES
warrants to Customer that such product will substantially conform SUFFERED BY YOU OR ANY THIRD PARTY, INCLUDING WITHOUT
with NetScreen’s published specifications for that product if LIMITATION LOSS OF USE, PROFITS, GOODWILL, SAVINGS,
properly used in accordance with the procedures described in LOSS OF DATA, DATA FILES OR PROGRAMS THAT MAY HAVE
documentation supplied by NetScreen. NetScreen’s exclusive BEEN STORED BY ANY USER OF THE SOFTWARE. IN NO EVENT
obligation with respect to non-conforming product shall be, at WILL NETSCREEN'S OR ITS LICENSORS' AGGREGATE LIABILITY
NetScreen’s option, to replace the product or use commercially CLAIM BY YOU, OR ANYONE CLAIMING THROUGH OR ON
reasonable efforts to provide Customer with a correction of the BEHALF OF YOU, EXCEED THE ACTUAL AMOUNT PAID BY YOU
defect, or to refund to customer the purchase price paid for the TO NETSCREEN FOR SOFTWARE. Some jurisdictions do not allow
1HW6FUHHQ&RQFHSWV ([DPSOHV LLL

the exclusions and limitations of incidental, consequential or 10. Tax Liability. You agree to be responsible for the payment of
special damages, so the above exclusions and limitations may not any sales or use taxes imposed at any time whatsoever on this
apply to you. transaction.
8. Export Law Assurance. You understand that the Software is 11. General. If any provisions of this Agreement are held invalid,
subject to export control laws and regulations. YOU MAY NOT the remainder shall continue in full force and effect. The laws of
DOWNLOAD OR OTHERWISE EXPORT OR RE-EXPORT THE the State of California, excluding the application of its conflicts of
SOFTWARE OR ANY UNDERLYING INFORMATION OR law rules shall govern this License Agreement. This Agreement
TECHNOLOGY EXCEPT IN FULL COMPLIANCE WITH ALL UNITED will not be governed by the United Nations Convention on the
STATES AND OTHER APPLICABLE LAWS AND REGULATIONS. Contracts for the International Sale of Goods. This Agreement is
the entire agreement between the parties as to the subject matter
9. U.S. Government Restricted Rights. If this Product is being hereof and supersedes any other Technologies, advertisements,
acquired by the U.S. Government, the Product and related or understandings with respect to the Software and
documentation is commercial computer Product and documentation. This Agreement may not be modified or altered,
documentation developed exclusively at private expense, and (a) if except by written amendment, which expressly refers to this
acquired by or on behalf of civilian agency, shall be subject to the Agreement and which, is duly executed by both parties.
terms of this computer Software, and (b) if acquired by or on
behalf of units of the Department of Defense (“DoD”) shall be You acknowledge that you have read this Agreement, understand
subject to terms of this commercial computer Software license it, and agree to be bound by its terms and conditions.
Supplement and its successors.
1HW6FUHHQ&RQFHSWV ([DPSOHV LY

&RQWHQWV
&RQWHQWV
3UHIDFH [LLL ([DPSOH3DUW$FFHVV3ROLFLHVIRU
DQ(QWHUSULVHZLWK6L[=RQHV
1HW6FUHHQ'RFXPHQWDWLRQ [Y
&KDSWHU=RQHV
&RQFHSWV ([DPSOHV0DQXDO2UJDQL]DWLRQ [YLL
6HFXULW\=RQHV
&RQYHQWLRQV [L[
*OREDO=RQH
:HE8,1DYLJDWLRQ&RQYHQWLRQV [L[
([DPSOH3ROLF\!!,QFRPLQJ!!1HZ3ROLF\ [L[
7XQQHO=RQHV
&UHDWLQJD6HFXULW\=RQH
&/,&RQYHQWLRQV[L[
0RGLI\LQJD6HFXULW\=RQH
&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 'HOHWLQJD6HFXULW\=RQH
0XOWLSOH6HFXULW\=RQHV )XQFWLRQ=RQHV
6HFXULW\=RQH,QWHUIDFHV 1XOO=RQH
3K\VLFDO,QWHUIDFHV 0*7=RQH
6XELQWHUIDFHV +$=RQH
6HOI=RQH
9LUWXDO5RXWHUV
5RXWH5HGLVWULEXWLRQ &KDSWHU,QWHUIDFHV
$FFHVV3ROLFLHV ,QWHUIDFH7\SHV
6HFXULW\=RQH,QWHUIDFHV
931V
3K\VLFDO
9LUWXDO6\VWHPV 6XELQWHUIDFH
=RQHVLQD9LUWXDO6\VWHP )XQFWLRQ=RQH,QWHUIDFHV
,QWHUIDFHV 0DQDJHPHQW,QWHUIDFH
9LUWXDO5RXWHUV +$,QWHUIDFH
3DFNHW)ORZ6HTXHQFH 7XQQHO,QWHUIDFHV
9LHZLQJLQWHUIDFHV
([DPSOH3DUW(QWHUSULVHZLWK6L[=RQHV
,QWHUIDFH7DEOH
([DPSOH3DUW,QWHUIDFHVIRU6L[=RQHV
([DPSOH3DUW(QWHUSULVHZLWK ,QWHUIDFH6HWWLQJVDQG2SHUDWLRQDO0RGHV
7ZR5RXWLQJ'RPDLQV 7UDQVSDUHQW0RGH
1HW6FUHHQ&RQFHSWV ([DPSOHV Y

&RQWHQWV
,QWHUIDFH6HWWLQJV ([DPSOH1HW6FUHHQ'HYLFHDV'+&3&OLHQW

([DPSOH+RZWRVHW9/$1,QWHUIDFH 333R(
([DPSOH7UDQVSDUHQW0RGH ([DPSOH6HWWLQJ8S333R(
1HWZRUN$GGUHVV7UDQVODWLRQ0RGH
85/)LOWHULQJ&RQILJXUDWLRQ
,QWHUIDFH6HWWLQJV
([DPSOH1$70RGH 'RZQORDGLQJ8SORDGLQJ6HWWLQJVDQG6RIWZDUH
5RXWH0RGH 6DYLQJDQG,PSRUWLQJ6HWWLQJV
3DFNHW)ORZ6HTXHQFH 8SORDGLQJDQG'RZQORDGLQJ6RIWZDUH
,QWHUIDFH6HWWLQJV 6RIWZDUH.H\V
([DPSOH5RXWH0RGH ([DPSOH([SDQGLQJ8VHU&DSDFLW\
6HFRQGDU\,3$GGUHVVHV $XWKHQWLFDWLRQ
6HFRQGDU\$GGUHVV3URSHUWLHV ,GOH7LPH2XW6HWWLQJ
([DPSOH&UHDWLQJD6HFRQGDU\,3$GGUHVV %XLOWLQ8VHU'DWDEDVH
0DQDJHPHQW6HUYLFHV2SWLRQV ([DPSOH$XWKHQWLFDWLRQYLD%XLOWLQ8VHU
'DWDEDVH
,QWHUIDFH6HUYLFHV2SWLRQV
5HPRWH$XWKHQWLFDWLRQ'LDO,Q8VHU6HUYLFH
)LUHZDOO2SWLRQV 5$',86
&RQILJXULQJDQLQWHUIDFH ([DPSOH$XWKHQWLFDWLRQYLD5$',86
&UHDWLQJDQ,QWHUIDFH 6HFXU,'6HUYHU
0RGLI\LQJDQ,QWHUIDFH ([DPSOH$XWKHQWLFDWLRQYLD6HFXU,'
'HOHWLQJDQ,QWHUIDFH /'$36HUYHU
([DPSOH$XWKHQWLFDWLRQYLD/'$3
&KDSWHU6\VWHP3DUDPHWHUV
6\VWHP&ORFN
'RPDLQ1DPH6\VWHP6XSSRUW ([DPSOH6HWWLQJWKH6\VWHP&/RFN
'16/RRNXS
&KDSWHU$GPLQLVWUDWLRQ
7KH'166WDWXV7DEOH
([DPSOH'HILQLQJ'166HUYHU$GGUHVVHV 0DQDJHPHQW0HWKRGVDQG7RROV
DQG6FKHGXOLQJ/RRNXSV :HE8VHU,QWHUIDFH
'+&3 +773
([DPSOH1HW6FUHHQ'HYLFHDV'+&36HUYHU 6HFXUH6RFNHWV/D\HU
([DPSOH1HW6FUHHQ'HYLFHDV &RPPDQG/LQH,QWHUIDFH
'+&35HOD\$JHQW 7HOQHW
1HW6FUHHQ&RQFHSWV ([DPSOHV YL

&RQWHQWV
6HFXUH6KHOO 9LUWXDO3ULYDWH1HWZRUNV

6HULDO&RQVROH ([DPSOH6HQGLQJ6103DQG6\VORJ5HSRUWV
$GPLQLVWUDWLYH,QWHUIDFH2SWLRQV WKURXJKDQ,36HF7XQQHO
([DPSOH$GPLQLVWUDWLRQWKURXJKD931
/HYHOVRI$GPLQLVWUDWLRQ 7XQQHOIURPWKH7UXVW=RQH
5RRW$GPLQLVWUDWRU
&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV
5HDG:ULWH$GPLQLVWUDWRU
5HDG2QO\$GPLQLVWUDWRU 6\VORJ
96<6$GPLQLVWUDWRU /RJJLQJ3ULRULW\/HYHOV
96<65HDG2QO\$GPLQLVWUDWRU :HE7UHQGV
$GGLQJ$GPLQ8VHUV ([DPSOH(QDEOLQJ6\VORJDQG:HE7UHQGV
([DPSOH$GGLQJD5HDG2QO\$GPLQLVWUDWRU 6103
6HFXULQJ$GPLQLVWUDWLYH7UDIILF ,PSOHPHQWDWLRQ2YHUYLHZ
([DPSOH6HWWLQJ8S6103&RPPXQLWLHV
&KDQJLQJWKH3RUW1XPEHU
9310RQLWRULQJ
([DPSOH&KDQJLQJWKH3RUW1XPEHU
&KDQJLQJWKH$GPLQ/RJLQ1DPHDQG3DVVZRUG &RXQWHUV
([DPSOH&KDQJLQJDQ$GPLQ8VHU/RJLQ ([DPSOH9LHZLQJ&RXQWHUV
1DPHDQG3DVVZRUG /RJV
([DPSOH$Q$GPLQ8VHU&KDQJLQJ (YHQW/RJ
KHU3DVVZRUG
7UDIILF/RJ
5HVWULFWLQJ$GPLQLVWUDWLYH$FFHVV
6HOI/RJ
([DPSOH5HVWULFWLQJ$GPLQLVWUDWLRQWRD
([DPSOH'RZQORDGLQJWKH6HOI/RJ
6LQJOH:RUNVWDWLRQ
([DPSOH5HVWULFWLQJ$GPLQLVWUDWLRQWRD6XEQHW $ODUPV
5HVHWWLQJWKH'HYLFHWRWKH)DFWRU\ 7UDIILF$ODUPV
'HIDXOW6HWWLQJV (YHQW$ODUPV
0DQDJH,3 ([DPSOH6HQGLQJ(PDLO$OHUWV
([DPSOH6HWWLQJ0DQDJH,3VIRU &KDSWHU9LUWXDO5RXWHUV
0XOWLSOH,QWHUIDFHV
0DQDJHPHQW=RQH,QWHUIDFHV &RQILJXULQJD9LUWXDO5RXWHU
([DPSOH$GPLQLVWUDWLRQWKURXJKWKH &UHDWLQJD9LUWXDO5RXWHU
0*7,QWHUIDFH 0RGLI\LQJD9LUWXDO5RXWHU
1HW6FUHHQ&RQFHSWV ([DPSOHV YLL

&RQWHQWV
&KDQJLQJ=RQHWR9LUWXDO5RXWHU%LQGLQJV 6HFXU,'

'HOHWLQJD8VHU'HILQHG9LUWXDO5RXWHU /LJKWZHLJKW'LUHFWRU\$FFHVV3URWRFRO
5RXWH5HGLVWULEXWLRQ 'LDOXS8VHU*URXSV
([DPSOH'HILQLQJD1HZ'LDOXS8VHU*URXS
5RXWH([SRUWLQJ DQG$GGLQJD0HPEHU
5RXWH7DEOH&RQILJXUDWLRQ ([DPSOH5HPRYLQJD*URXS0HPEHU
([DPSOH5RXWH7DEOH&RQILJXUDWLRQ ([DPSOH0RYLQJD*URXS0HPEHUWR
([DPSOH6HWWLQJD5RXWHIRU7UDIILF $QRWKHU*URXS
WKURXJKD7XQQHO,QWHUIDFH ([DPSOH5HPRYLQJD*URXS
&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHV *URXS,.(,'

DQG931V ([DPSOH'HILQLQJD8VHU'HILQLWLRQWR
8VH*URXS,.(,'
$GGUHVVHV
6HUYLFHV
$GGUHVV%RRN(QWULHV
([DPSOH9LHZLQJWKH6HUYLFH%RRN
([DPSOH$GGLQJ$GGUHVVHV
([DPSOH$GGLQJD&XVWRP6HUYLFH
([DPSOH0RGLI\LQJ$GGUHVVHV
([DPSOH0RGLI\LQJD&XVWRP6HUYLFH
([DPSOH'HOHWLQJ$GGUHVVHV
([DPSOH5HPRYLQJD&XVWRP(QWU\
$GGUHVV*URXSV
+3URWRFROIRU9RLFHRYHU,3
([DPSOH&UHDWLQJDQ$GGUHVV*URXS
([DPSOH*DWHNHHSHULQWKH7UXVW=RQH
([DPSOH(GLWLQJD*URXS$GGUHVV(QWU\
7UDQVSDUHQWRU5RXWH0RGH
([DPSOH5HPRYLQJDQ$GGUHVV*URXS
0HPEHUDQGD*URXS ([DPSOH*DWHNHHSHULQWKH7UXVW=RQH
1$70RGH
9LUWXDO,3 ([DPSOH*DWHNHHSHULQWKH8QWUXVW=RQH
9,3DQGWKH*OREDO=RQH 7UXVW=RQHLQ7UDQVSDUHQWRU5RXWH0RGH
([DPSOH&RQILJXULQJ9LUWXDO,36HUYHUV ([DPSOH*DWHNHHSHULQWKH8QWUXVW=RQH
([DPSOH(GLWLQJD9,3&RQILJXUDWLRQ 7UXVW=RQHLQ1$70RGH
([DPSOH5HPRYLQJD9,3&RQILJXUDWLRQ 6HUYLFH*URXSV
8VHUV ([DPSOH&UHDWLQJD6HUYLFH*URXS
([DPSOH0RGLI\LQJD6HUYLFH*URXS
([DPSOH&UHDWLQJ6LQJOH7\SH8VHUV
([DPSOH&UHDWLQJ0XOWLSOH7\SH8VHUV ([DPSOH5HPRYLQJD6HUYLFH
([DPSOH5HPRYLQJD6HUYLFH*URXS
8VHU$XWKHQWLFDWLRQ
,QWHUQDO'DWDEDVH 6FKHGXOHV
5$',86 ([DPSOH5HFXUULQJ6FKHGXOH
1HW6FUHHQ&RQFHSWV ([DPSOHV YLLL

&RQWHQWV
&KDSWHU$FFHVV3ROLFLHV 0RGHV

7UDQVSRUW0RGH
$FFHVV3ROLFLHV'HILQHG
7XQQHO0RGH
$QDWRP\RID3ROLF\
3URWRFROV
=RQHV
$+
$GGUHVVHV
(63
6HUYLFHV
.H\0DQDJHPHQW
$FWLRQV 0DQXDO.H\
1HWZRUN$GGUHVV7UDQVODWLRQ1$7 $XWR.H\,.(
9317XQQHO 6HFXULW\$VVRFLDWLRQ
/73
7XQQHO1HJRWLDWLRQ
$XWKHQWLFDWLRQ
3KDVH
/RJJLQJ
0DLQ0RGHDQG$JJUHVVLYH0RGH
&RXQWLQJ
7KH'LIILH+HOOPDQ([FKDQJH
$ODUP7KUHVKROG
3KDVH
6FKHGXOHV
3HUIHFW)RUZDUG6HFUHF\
7UDIILF6KDSLQJ 5HSOD\3URWHFWLRQ
$FFHVV3ROLFLHV$SSOLHG 3DFNHW)ORZ3ROLF\%DVHG/$1WR/$1931
9LHZLQJ$FFHVV3ROLFLHV ,36HF1$77UDYHUVDO
$FFHVV3ROLF\,FRQV 7UDYHUVLQJD1$7'HYLFH
&UHDWLQJ$FFHVV3ROLFLHV 8'3&KHFNVXP
([DPSOHRIELGLUHFWLRQDOWUDIILF 7KH.HHSDOLYH)UHTXHQF\9DOXH
$FFHVV3ROLF\/RFDWLRQ ,36HF1$77UDYHUVDODQG,QLWLDWRU5HVSRQGHU
([DPSOH7\SLFDO$&/IRUD6PDOOWR0HGLXP 6\PPHWU\
(QWHUSULVH ([DPSOH(QDEOLQJ1$77UDYHUVDO
0RGLI\LQJDQG'LVDEOLQJ$FFHVV3ROLFLHV
&KDSWHU3XEOLF.H\&U\SWRJUDSK\
5HRUGHULQJ$FFHVV3ROLFLHV
,QWURGXFWLRQWR3XEOLF.H\&U\SWRJUDSK\
5HPRYLQJDQ$FFHVV3ROLF\
3.,
&KDSWHU,36HF
&HUWLILFDWHVDQG&5/V
,QWURGXFWLRQWR931V 2EWDLQLQJD&HUWLILFDWH0DQXDOO\
,36HF&RQFHSWV ([DPSOH5HTXHVWLQJD&HUWLILFDWH0DQXDOO\
1HW6FUHHQ&RQFHSWV ([DPSOHV L[

&RQWHQWV
([DPSOH/RDGLQJ&HUWLILFDWHV %DFNWR%DFN931V

([DPSOH&RQILJXULQJ'HIDXOW6HUYHU6HWWLQJV ([DPSOH%DFNWR%DFN931V
IRUD&5/
2EWDLQLQJD&HUWLILFDWH$XWRPDWLFDOO\
&KDSWHU3ROLF\%DVHG931V
([DPSOH5HTXHVWLQJD&HUWLILFDWH /$1WR/$1931V
$XWRPDWLFDOO\ 7XQQHO,QWHUIDFHV
&KHFNLQJIRU5HYRFDWLRQ8VLQJ2&63 ([DPSOH3ROLF\%DVHG/$1WR/$1931
0DQXDO.H\
&RQILJXULQJIRU2&63
([DPSOH3ROLF\%DVHG/$1WR/$1931
6SHFLI\LQJ(LWKHU&5/RU2&63IRU
$XWR.H\,.(
5HYRFDWLRQ&KHFNLQJ
([DPSOH3ROLF\%DVHG/$1WR/$1931
'LVSOD\LQJ&HUWLILFDWH5HYRFDWLRQ '\QDPLF3HHU
6WDWXV$WWULEXWHV
6SHFLI\LQJWKH85/RIDQ2&635HVSRQGHU 'LDOXSWR/$1931V
IRUD&HUWLILFDWH ([DPSOH3ROLF\%DVHG'LDOXSWR/$1931
5HPRYLQJ&HUWLILFDWH5HYRFDWLRQ&KHFN 0DQXDO.H\
$WWULEXWHV ([DPSOH3ROLF\%DVHG'LDOXSWR/$1931
$XWR.H\,.(
&KDSWHU5RXWLQJ%DVHG931V ([DPSOH3ROLF\%DVHG'LDOXSWR/$1931
7XQQHO,QWHUIDFHV '\QDPLF3HHU
([DPSOH7XQQHO%RXQGWR7XQQHO,QWHUIDFH 7XQQHO=RQHVDQG3ROLF\%DVHG1$7
/$1WR/$1931V ([DPSOH7XQQHO,QWHUIDFHLQD7XQQHO=RQH
7XQQHO,QWHUIDFHV &KDSWHU/73
([DPSOH5RXWLQJ%DVHG/$1WR/$1931 ,QWURGXFWLRQWR/73
0DQXDO.H\
([DPSOH5RXWLQJ%DVHG/$1WR/$1931 3DFNHW(QFDSVXODWLRQDQG'HFDSVXODWLRQ
$XWR.H\,.( (QFDSVXODWLRQ
([DPSOH5RXWLQJ%DVHG/$1WR/$1931 'HFDSVXODWLRQ
'\QDPLF3HHU
/733DUDPHWHUV
'LDOXSWR/$1931'\QDPLF3HHU ([DPSOH&RQILJXULQJDQ,33RRODQG/73
([DPSOH5RXWLQJ%DVHG'LDOXSWR/$1931 'HIDXOW6HWWLQJV
'\QDPLF3HHU /73DQG/732YHU,36HF
+XEDQG6SRNH931V ([DPSOH&RQILJXULQJ/73
([DPSOH+XEDQG6SRNH931V ([DPSOH&RQILJXULQJ/732YHU,36HF
1HW6FUHHQ&RQFHSWV ([DPSOHV [

&RQWHQWV
&KDSWHU3ROLF\%DVHG1$7 ([DPSOH([SRUWLQJD3K\VLFDO,QWHUIDFH

IURPD9LUWXDO6\VWHP
'\QDPLF,3
/RJJLQJ2QDVD9LUWXDO6\VWHP$GPLQLVWUDWRU
3RUW$GGUHVV7UDQVODWLRQ
([DPSOH/RJJLQJ2QDQG&KDQJLQJ
([DPSOH&UHDWLQJD',33RROZLWK3$7
\RXU3DVVZRUG
([DPSOH&KDQJLQJD',33RRO
([DPSOH'HOHWLQJD7XQQHO,QWHUIDFH &RPPXQLFDWLQJ%HWZHHQ9/$1V
([DPSOH,QWHU9/$1&RPPXQLFDWLRQ
0DSSHG,3
0,3DQGWKH*OREDO=RQH &KDSWHU+LJK$YDLODELOLW\
([DPSOH$GGLQJD0,3WRD7XQQHO,QWHUIDFH &DEOLQJ3URFHGXUH
([DPSOH$GGLQJD0,3WRDQ,QWHUIDFH *HQHUDO&DEOLQJ5XOHV
LQWKH8QWUXVW=RQH
%LQGLQJD1RQ'HGLFDWHG,QWHUIDFH
3ROLF\%DVHG1$7IRU1HWZRUN7UDIILF WRWKH+$=RQH
([DPSOH1$7RQ2XWJRLQJ1HWZRUN7UDIILF 5HGXQGDQW*URXSV
&KDSWHU7UDIILF6KDSLQJ ([DPSOH)RUPLQJD5HGXQGDQW*URXS
'LVDEOLQJ+$
$SSO\LQJ7UDIILF6KDSLQJ
0DQDJLQJ%DQGZLGWKDWWKH$FFHVV3ROLF\/HYHO
6HFXULQJ+$&RPPXQLFDWLRQV
([DPSOH7UDIILF6KDSLQJ ([DPSOH(QDEOLQJ$XWKHQWLFDWLRQ
DQG(QFU\SWLRQ
6HWWLQJ6HUYLFH3ULRULWLHV
3DWK0RQLWRULQJ
([DPSOH3ULRULW\4XHXLQJ
([DPSOH(QDEOLQJ3DWK7UDFNLQJ
&KDSWHU9LUWXDO6\VWHPV
$SSHQGL[$61030,%)LOHV ,
(VWDEOLVKLQJD9LUWXDO6\VWHP 7KH3ULPDU\/HYHO0,%)LOH)ROGHUV ,
([DPSOH&UHDWLQJ9LUWXDO6\VWHPV 6HFRQGDU\/HYHO0,%)ROGHUV ,,,
DQG9LUWXDO6\VWHP$GPLQLVWUDWRUV
QHW6FUHHQ,GV ,,,
'HILQLQJ6XELQWHUIDFHVDQG9/$17DJV QHWVFUHHQ9SQ,,,
([DPSOH'HILQLQJ7KUHH6XELQWHUIDFHV QHWVFUHHQ4RV ,9
DQG9/$17DJV QHWVFUHHQ6HWWLQJ ,9
,PSRUWLQJDQG([SRUWLQJ3K\VLFDO,QWHUIDFHV QHWVFUHHQ3ROLF\ ,9
([DPSOH,PSRUWLQJD3K\VLFDO,QWHUIDFH QHWVFUHHQ1$7 9
WRD9LUWXDO6\VWHP QHWVFUHHQ6HUYLFH 9
1HW6FUHHQ&RQFHSWV ([DPSOHV [L

&RQWHQWV
QHWVFUHHQ6FKHGXOH 9 $SSHQGL[%*ORVVDU\ ,

QHWVFUHHQ5HVRXUFH 9
,QGH[ ,;,
QHWVFUHHQ,S 9
1HW6FUHHQ&RQFHSWV ([DPSOHV [LL

3UHIDFH
NetScreen devices are ASIC-based, ICSA-certified1 Internet security appliances that integrate firewall, virtual private
networking (VPN), and traffic-shaping features to provide complete protection of your local area network (LAN)
when connecting to the Internet.
• Firewall: A firewall screens traffic crossing the boundary between a private LAN and the public network,
such as the Internet.
• VPN: A VPN provides a secure communications channel between two or more remote network appliances.
• Traffic Shaping: Traffic shaping functionality allows administrative monitoring and control of traffic passing
across the NetScreen® firewall to maintain a network’s quality-of-service (QoS) level.
Note: For information on NetScreen compliance with Federal Information Processing Standards (FIPS) and for
instructions on setting a FIPS-compliant NetScreen device in FIPS mode, see the NetScreen-100 Cryptographic
Module Security Policy on the documentation CD-ROM.
1. The Internet Computer Security Association (ICSA) is an organization focused on all types of network security for Internet-connected companies. Among its
many functions, ICSA provides product certification for several kinds of security products such as virus protection, firewall, PKI, intrusion detection, IPSec,
and cryptography. ICSA has certified all NetScreen products for firewall and IPSec.
1HW6FUHHQ&RQFHSWV ([DPSOHV [LLL

LAN LAN
VPNs: Secure
communication tunnels
between sites for traffic
passing through the Internet
Firewall: Screening traffic

between the protected LAN
and the Internet
Traffic Shaping: Efficient

prioritization of traffic as it
traverses the firewall
LAN
NetScreen ScreenOS version 3.0.0 is the operating system that provides all the features needed to set up and
manage any NetScreen security appliance or system. The NetScreen Concepts & Examples ScreenOS Reference
Guide provides a useful reference guide for configuring and managing a NetScreen appliance through the
ScreenOS.
1HW6FUHHQ&RQFHSWV ([DPSOHV [LY

1HW6FUHHQ'RFXPHQWDWLRQ
1(76&5((1'2&80(17$7,21
In addition to the NetScreen Concepts & Examples ScreenOS Reference Guide guide, there are other technical
publications available from NetScreen. These publications are as follows:
What’s New in ScreenOS 3.0.0?
This manual describes all new features in ScreenOS 3.0.0. In addition, it lists all commands that have been removed
since version 2.6.1 and all commands that have remained the same. It also presents full descriptions of all new
commands, and all commands that have undergone modification.
NetScreen WebUI Reference Guide
This manual presents a brief introduction to the WebUI management application, with a glossary of important
technical terms, and general instructions on how to use the application.
NetScreen CLI Reference Guide
This manual provides descriptions of all command line interface (CLI) commands. Each command description
presents the command’s syntax and basic elements, including options, parameters, switches, and element
dependencies. The descriptions also provide practical examples of command execution.
NetScreen-5XP Installer’s Guide, NetScreen-10 Installer’s Guide, NetScreen-25 Installer’s Guide, NetScreen-50
Installer’s Guide
These manuals provide instructions for connecting a NetScreen-5XP, -10, -25, and -50 device respectively to a
network, and performing an initial configuration. The instructions explain how to set up the device in Transparent,
NAT, or Route mode, how to configure an access policy permitting outbound traffic only, and how to change the
admin’s login name and password. Each manual also provides an overview of the hardware for each specific
platform.
1HW6FUHHQ&RQFHSWV ([DPSOHV [Y

1HW6FUHHQ'RFXPHQWDWLRQ
NetScreen-100 Installer’s Guide, NetScreen-204/208 Installer’s Guide, NetScreen-500 Installer’s Guide, and
NetScreen-1000 Installer’s Guide
These manuals provide instructions for connecting a NetScreen-100, -204/208, -500, and -1000 device respectively
to a network, and performing an initial configuration. The instructions explain how to set up the device in
Transparent, NAT, or Route mode, how to configure an access policy permitting outbound traffic only, and how to
change the admin’s login name and password. The manual also provides an overview of the hardware, and cabling
and configuration instructions for single appliances and redundant appliances using High Availability (HA).
NetScreen-Remote Administrator’s Guide
This manual provides instructions for installing and using the NetScreen-Remote client software, which allows a
remote user to connect with a NetScreen security device through a virtual private network (VPN) tunnel.
NetScreen Message Log Reference Guide
This manual documents the log messages that appear in ScreenOS 3.0.0. Each log message entry includes the
message text, its meaning, and any recommended action to take upon receiving the message.
If you find any errors or omissions in the content of this or any other NetScreen manual, please contact us at the
e-mail address below:
techpubs@netscreen.com
1HW6FUHHQ&RQFHSWV ([DPSOHV [YL

&RQFHSWV ([DPSOHV0DQXDO2UJDQL]DWLRQ
&21&(376 (;$03/(60$18$/25*$1,=$7,21
The following are summaries of each of the chapters in the NetScreen Concepts & Examples ScreenOS Reference
Guide:
Chapter 1, “Universal Security Gateway Architecture” presents the fundamental elements of USGA—the
architecture presented in ScreenOS 3.1.0—and concludes with a four-part example illustrating an enterprise-based
configuration incorporating most of those elements. In this and all subsequent chapters, each concept is
accompanied by illustrative examples.
Chapter 2, “Zones” explains security zones, tunnel zones, and function zones.
Chapter 3, “Interfaces” describes the various physical, logical, and virtual interfaces on NetScreen devices, explains
the concepts behind Transparent, Network Address Translation (NAT), and Route operational modes, and includes
information on various firewall attacks and the attack blocking options that NetScreen provides.
Chapter 4, “System Parameters” presents the concepts behind Domain Name System (DNS) addressing; using
Dynamic Host Configuration Protocol (DHCP) to assign or relay TCP/IP settings; URL filtering; downloading and
uploading system configurations and software; and setting the system clock.
Chapter 5, “Administration” explains the different means available for managing a NetScreen device both locally
and remotely. This chapter also explains the privileges pertaining to each of the four levels of network administrators
that can be defined. Finally, it explains how to secure local and remote administrative traffic.
Chapter 6, “Monitoring NetScreen Devices” explains various monitoring methods and provides guidance in
interpreting monitoring output.
Chapter 7, “Virtual Routers” presents the concept of a virtual router and explains how to configure the virtual routers
on the NetScreen device. It also contains information on routing table entries.
Chapter 8, “Building Blocks for Access Policies and VPNs” discusses the elements used for creating access
policies and virtual private networks (VPNs): addresses (including VIP addresses), users, and services. It also
presents several example configurations support for the H.323 protocol.
Chapter 9, “Access Policies” explores the components and functions of access policies and offers guidance on their
creation and application.
1HW6FUHHQ&RQFHSWV ([DPSOHV [YLL

&RQFHSWV ([DPSOHV0DQXDO2UJDQL]DWLRQ
Chapter 10, “IPSec” provides background information bout IPSec, presents a flow sequence for Phase 1 in IKE
negotiations in Aggressive and Main modes, and concludes with information regarding NAT-Traversal.
Chapter 11, “Public Key Cryptography” provides information on how to obtain and load digital certificates and
certificate revocation lists (CRLs).
Chapter 12, “Routing-Based VPNs” provides extensive examples of routing-based VPN configurations, including
hub-and-spoke and back-to-back tunnel designs.
Chapter 13, “Policy-Based VPNs” provides extensive examples of policy-based VPN configurations for LAN-to-LAN
and client-to-LAN communication using Manual Key and AutoKey IKE mechanisms. It also details how to make use
of tunnel interfaces to provide policy-based NAT to traffic flowing through VPN tunnels between sites that have
trusted networks with an overlapping address space.
Chapter 14, “L2TP” explains the Layer 2 Tunneling Protocol (L2TP), its use alone and in conjunction with IPSec
(L2TP-over-IPSec).
Chapter 15, “Policy-Based NAT” explains how to provide NAT services for network traffic at the policy level.
Chapter 16, “Traffic Shaping” explains how you can manage bandwidth at the interface and Access Policy levels
and prioritize services.
Chapter 17, “Virtual Systems” presents the concepts of virtual systems and virtual local area networks (VLANs),
and explains how to set up virtual systems and create virtual system administrators.
Chapter 18, “High Availability” explains how to cable, configure, and manage two or more NetScreen-100, -204/208,
-500, or -1000 devices in a redundant group to provide high availability.
Appendix A, “SNMP MIB Files” lists and briefly describes the Management Information Base (MIB) files available for
MIB compilers.
Appendix B, “Glossary” provides a reference for the terms and acronyms used in the Security and Firewall field.
1HW6FUHHQ&RQFHSWV ([DPSOHV [YLLL

&RQYHQWLRQV
&219(17,216
This book presents two management methods for configuring a NetScreen device: the Web user interface (WebUI)
and the command line interface (CLI). The conventions used for both are introduced below.
:HE8,1DYLJDWLRQ&RQYHQWLRQV
Throughout this book, a double chevron ( >> ) is used to indicate navigation through the WebUI by clicking buttons,
tabs, and links.
([DPSOH3ROLF\!!,QFRPLQJ!!1HZ3ROLF\
To access the Policy Configuration dialog box to create an incoming Access Policy, do the following:
1. Click the Policy button in the menu column.
2. Click the Incoming tab.
3. Click the New Policy link.
The Policy Configuration dialog box appears.
&/,&RQYHQWLRQV
The CLI conventions are as follows:
• A parameter inside [ ] (square brackets) is optional.
• A parameter inside { } (braces) is required.
• Anything inside < > is a variable.
• If there is more than one choice for a parameter inside [ ] and { }, they are separated by a pipe ( | ). For
example, [auth {md5 | sha-1}] means “choose either MD5 or SHA-1 as your authentication method.”
• IP addresses are represented by <a.b.c.d> and <e.f.g.h>.
• A subnet mask is represented by <A.B.C.D>.
1HW6FUHHQ&RQFHSWV ([DPSOHV [L[

&RQYHQWLRQV
For example, when entering a route to the route table for the IP address 2.2.2.2/32 via the untrusted interface, use
the following syntax:
set route <a.b.c.d> <A.B.C.D> interface { trust | untrust | dmz | mgt | tunnel/<number> } [ gateway <a.b.c.d>
] [ metric <number> ]
to produce this command:
set route 2.2.2.2 255.255.255.255 interface untrust
Because the gateway IP address and the metric2 are optional—these arguments are presented within brackets [ ]—
you can omit them from the command. In this example, the gateway IP address would be that of a router on the
untrusted side through which you want to route traffic bound for 2.2.2.2/32. By not specifying a router, the default
router for the untrusted interface is used.
Note: When typing a key word, you only have to type enough letters to identify the word uniquely. For example,
typing set in t n is enough to enter the command set interface trust nat.
If you want to see the options following part of a command, press the SPACE key and then type ? (question mark).
For example, typing set interface ? displays the following options: trust, untrust, dmz, mgt, ha1, ha2, tunnel—which
are the available options that you can enter after typing set interface.
2. The metric <number> argument specifies the number of hops between the NetScreen-500 and the specified gateway. In this example, you do not specify
a gateway; consequently, you do not specify a metric for it. However, even if you do specify a gateway, specifying a metric is optional.
1HW6FUHHQ&RQFHSWV ([DPSOHV [[

&KDSWHU
8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH

NetScreen ScreenOS 3.1.0 introduces Universal Security Gateway Architecture (USGA), an architecture that offers
great flexibility in designing the layout of your network security. On NetScreen devices with multiple interfaces, you
can create numerous security zones and configure access policies to regulate traffic between them. You can bind
one or more interfaces to each zone and enable a unique set of management and firewall attack screening options
on a per-interface basis. Essentially, USGA allows you to create the number of zones your network environment
requires, assign the number of interfaces each zone requires, and design each interface to your specifications.
This chapter presents an overview of USGA, covering the following key components:
• “Multiple Security Zones” on page 2
• “Security Zone Interfaces” on page 3
• “Virtual Routers” on page 5
• “Access Policies” on page 7
• “VPNs” on page 8
• “Virtual Systems” on page 10
Furthermore, to better understand the ScreenOS mechanism for processing traffic, you can see the flow sequence
for an incoming packet in “Packet Flow Sequence” on page 13.
The chapter concludes with a four-part example that illustrates a basic configuration for a NetScreen device using
ScreenOS 3.1.0 with USGA.
• “Example (Part 1): Enterprise with Six Zones” on page 15
• “Example (Part 2): Interfaces for Six Zones” on page 17
• “Example (Part 3): Enterprise with Two Routing Domains” on page 22
• “Example (Part 4): Access Policies for an Enterprise with Six Zones” on page 25

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 0XOWLSOH6HFXULW\=RQHV
08/7,3/(6(&85,7<=21(6
A security zone is a collection of one1 or more network segments requiring the regulation of inbound and outbound
traffic via access policies. You can define multiple security zones, the exact number of which you determine based
on your network needs. In addition to user-defined zones, you can also use the three predefined zones: trust,
untrust, and DMZ. In fact, if you upgrade from an earlier version of ScreenOS, all your configurations for the trust,
untrust, and DMZ zones remain intact. If you like, you can continue using just the predefined zones. You can also
2
delete all predefined zones and use user-defined zones exclusively. Optionally, you can use both kinds of zones—
predefined and user-defined—side by side. USGA provides the flexibility for you to use and define security zones to
best suit your specific needs.
A network configured with 5 security Finance

zones—3 default zones (Trust,
Untrust, DMZ), and 2 user-defined
zones Untrust
(Finance, Eng)
Trust
Policy
Engine NetScreen device
Traffic (indicated by black lines)

passes from one security zone
to another only if a policy
permits it.
Eng DMZ
1. The one security zone that requires no network segment is the global zone. (For more information, see Global zone “Global Zone” on page 33.) Additionally,
any zone without an interface bound to it nor any address book entries can also be said not to contain any network segments.
2. If you delete a security zone, you also automatically delete all addresses configured for that zone.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 6HFXULW\=RQH,QWHUIDFHV
6(&85,7<=21(,17(5)$&(6
An interface for a security zone can be thought of as a doorway through which TCP/IP traffic can pass between that
zone and any other zone.
3
Through the access policies you define, you can permit traffic between zones to flow in one direction or in both .
With the routes that you define, you specify the interfaces that traffic from one zone to another must use. Because
you can bind multiple interfaces to a zone, the routes you chart are important for directing traffic to the interfaces of
your choice.
To provide a zone with a doorway, you bind an interface to the zone and—for an interface in Route or NAT mode—
assign an IP address to the interface. Such interfaces can be of two types: physical interfaces and—for those
devices with virtual system support—subinterfaces (that is, a layer 2 substantiation of a physical interface).
3K\VLFDO,QWHUIDFHV
A physical interface is identified by the position of an interface module and an ethernet port on that module. For
example, on the NetScreen-500, the interface ethernet1/2 designates the interface module in the first bay
(ethernet1/2) and the second port (ethernet1/2) on that module. A physical interface relates to components that
are physically present on the NetScreen device.
Physical Interface Assignments
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2
3. For traffic to flow between interfaces bound to the same zone, no policy is required because both interfaces have security equivalency. ScreenOS requires
policies for traffic between zones, not within a zone.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 6HFXULW\=RQH,QWHUIDFHV
6XELQWHUIDFHV
On devices that support virtual systems, you can logically divide a physical interface into several virtual
subinterfaces, each of which borrows the bandwidth it needs from the physical interface from which it stems. A
subinterface is an abstraction that functions identically to an interface for a physically present port and is
distinguished by 802.1Q VLAN tagging4. The NetScreen device directs traffic to and from a zone with a subinterface
via its IP address and VLAN tag. For convenience, administrators usually assign a VLAN tag that is the same as the
interface number. For example, an interface using VLAN tag 3 and named ethernet1/2.3 refers to the interface
module in the first bay, the second port on that module, and interface number 3 (ethernet1/2.3).
Note that although a subinterface shares part of its identity with a physical interface, the zone to which you bind it is
not dependent on the zone to which you bind the physical interface. You can bind the subinterface ethernet1/2.3 to
a different zone than that to which you bind the physical interface ethernet1/2, or to which you bind ethernet1/2.2.
Similarly, there are no restrictions in terms of IP address assignments. The term subinterface does not imply that its
address be in a subnet of the address space of the physical interface.
Note: For more information on interfaces, see “Universal Security Gateway Architecture” on page 1.
Subinterface Assignments
3/1.1 3/2.1
1/1.1 1/2.1 3/1.2 3/2.2
1/1.2 1/2.2 3/1.3 3/2.3
1/1 1/2 3/1 3/2
2/1 2/2 4/1 4/2
2/1.1 2/2.1 4/1.1 4/2.1

2/1.2 2/2.2 4/1.2 4/2.2
4. 802.1Q is an IEEE standard that defines the mechanisms for the implementation of virtual bridged LANs and the ethernet frame formats used to indicate
VLAN membership via VLAN tagging.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 9LUWXDO5RXWHUV
9,578$/5287(56
A virtual router (VR) functions identically to a nonvirtual router. It has its own interfaces and its own routing table. In
USGA, a NetScreen device supports two virtual routers. This allows the NetScreen device to maintain two separate
routing tables and conceal the routing information in one virtual router from the other. For example, virtual router 1,
which is typically used for communication with untrusted parties, does not contain any routing information for any of
the protected zones, which is maintained by virtual router 2. Thus, no internal network information can be gleaned by
the surreptitious extraction of routes from virtual router 1.
Trust-VR Routing Domain VR1 Untrust-VR Routing Domain
Finance
Untrust
Trust
Eng DMZ Note: The castle icon represents an

interface for a security zone.
Route Redistribution
Note: To create additional VRs, you must first obtain and load a virtual router software key on the NetScreen device.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 9LUWXDO5RXWHUV
5RXWH5HGLVWULEXWLRQ
Each virtual router (VR) maintains a routing table with unique entries for its routing domain. That is, the entries in
VR1 are completely different from those maintained in VR2. Because the routing table entries in VR2 cannot be
found in VR1, the VR1 routing table must include a route pointing to VR2 for any routes that it does not have and
that you want to make accessible for traffic from VR1. (Likewise, the reverse is required for traffic in the other
direction; that is, from VR2 to VR1.) The term for this link between the two virtual routers is route redistribution.
Finance
10.10.1.0/24 Untrust
210.10.1.0/24
Trust-VR (VR2) Routing Domain Untrust-VR (VR1) Routing Domain
eth1/1
Trust eth3/1
To Use To Use
10.10.2.0/24
10.10.1.0/24 eth1/1 210.10.1.0/24 eth3/1
10.10.2.0/24 eth1/2 eth1/2 210.10.2.0/24 eth4/1
10.10.3.0/24 eth2/1 DMZ 10.10.0.0/16 VR2
210.10.2.0/24
0.0.0.0/0 VR1 Engineering 0.0.0.0/0 eth3/1
10.10.3.0/24
eth4/1
eth2/1
Note: For more information about virtual routers, see Chapter 7, “Virtual Routers”.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH $FFHVV3ROLFLHV
$&&(6632/,&,(6
Every time a packet attempts to pass from one zone to another, the NetScreen device checks its access control list
(ACL) for a policy that permits such traffic. To allow traffic to pass from one security zone to another—for example,
from zone A to zone B—you must configure an access policy that permits zone A to send traffic to zone B. To allow
traffic to flow the other way, you must configure another policy permitting traffic from zone B to zone A. For any
traffic to pass from one zone to another, there must be an access policy that permits it.
Trust-VR Routing Domain Untrust-VR Routing Domain

Finance
Untrust
Trust Policy
Engine
Eng DMZ
Note: The black lines represent traffic
between security zones.
Note: For information about access policies, see Chapter 9, “Access Policies”.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 931V
9316
USGA supports several VPN configuration options, some of which allow the separation of virtual private network
(VPN) tunnels and access policies5. Once configured, such tunnels exist as available resources for securing traffic
en route between one security zone and another.
The main steps for configuring a VPN tunnel independent of any access policy are as follows:
1. While configuring the VPN tunnel (for example, vpn-to-SF, where SF is the destination or end entity),
specify a physical or subinterface on the local device. (The IP address for this interface is what the remote
peer must use when configuring its remote gateway.)
2. Create a tunnel interface (for example, tunnel.1), and bind it to a security zone6.
3. Bind the tunnel interface tunnel.1 to the VPN tunnel vpn-to-SF.
4. To direct traffic through this tunnel, set up a route stating that traffic to SF must use tunnel.1.
At this point, the tunnel is ready for traffic bound for SF. You can now set up access policies to permit or block traffic
from a specified source to that destination.
Source Zone Policy Tunnel VPN tunnel Destination Zone

Engine Interface
Routing
Table
----------------
----------------
Packet sent ---------------- Packet arrives
5. In earlier versions of ScreenOS, a VPN policy must explicitly specify tunneling and name a specific VPN tunnel. You can still configure VPN policies this way
in ScreenOS 3.1.0. However, you can also configure policies that only permit or deny traffic between two security zones. If permitted, that traffic is tunneled
if the route to the specified destination points to an interface bound to a VPN tunnel.
6. You do not have to bind the tunnel interface to the same zone from which VPN traffic originates locally. Traffic from any zone can access a tunnel interface
if a route points to that interface.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 931V
Traffic from security zone Finance to “SF LAN” in security zone Untrust is routed to the
tunnel interface tunnel.1. Because tunnel.1 is bound to VPN tunnel vpn-to-SF, the traffic
is sent through that tunnel to the remote gateway at “SF LAN”.
VR1: Untrust Virtual Router
To Reach Use
SF LAN
210.10.1.0 eth3/1 Zone: Untrust 10.20.2.0/24
eth3/1–210.10.1.1/24
0.0.0.0/0 210.10.1.2/24
Interface:
tunnel.1
VR2: Trust Virtual Router VPN Tunnel

Local Device vpn-to-SF
Default Gateway:
To Reach Use 210.10.1.2
10.20.2.0/24 tunnel.1 Zone: Finance
eth1/1–10.10.1.1/24
10.10.1.0/24 eth1/1
0.0.0.0/0 VR1

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 9LUWXDO6\VWHPV
9,578$/6<67(06
Some NetScreen devices support virtual systems (vsys)7. The application of USGA to virtual systems involves the
coordination of three main components: zones, interfaces, and virtual routers. The following illustration presents a
conceptual overview of how USGA integrates these components at both the root and vsys levels.
Note: The castle icon represents

a security zone interface.
TRUST-VR
UNTRUST-VR Finance
DMZ
Mail Trust Eng
shared interface for

root and vsys1
root sys vsys1-vr
Trust-vsys1
Untrust subinterface vsys1

dedicated to vsys2-vr
vsys2 vsys2
Trust-vsys2
vsys3
physical interface
dedicated to vsys3
vsys3-vr
Trust-vsys3
The following subsections explore each of these components—zones, interfaces, and virtual routers—and their
application within the context of virtual systems.
7. A virtual system is a subdivision of the main system that appears to the user to be a stand-alone entity. Vsys reside separately from each other and from the
root system within the same NetScreen device.

=RQHVLQD9LUWXDO6\VWHP
When a root-level admin creates a virtual system, the following zones are automatically inherited or created:
• Shared Untrust Zone (inherited from the root system)
• Shared Null Zone (inherited from the root system)
• Trust-<vsys_name> Zone
• Untrust-Tun-<vsys_name> Zone
• Self-<vsys_name> Zone
• Global-<vsys_name> Zone
All virtual systems share the untrust and null zones with the root system. Note that because the root system and all
virtual systems share the untrust zone, they also share the address book for the untrust zone.
All other zones in a vsys are owned by that vsys.
Note: For information on each of these zone types, see Chapter 2, “Zones”.
In addition, a root-level admin can create one user-defined zone for each virtual system.
,QWHUIDFHV
A virtual system can have any of the following three types of interfaces bound to the untrust zone:
• One or more vsys can share the physical interface that is bound to the untrust zone with the root system.
• A vsys can have its own subinterface bound to the untrust zone, and use VLAN tagging as the means for
trunking8 inbound and outbound traffic.
• A vsys can have its own physical interface bound to the untrust zone or to trust-<vsys-name> zone.
You can bind one, two, or all three of the above interface types to the untrust zone concurrently. You can also bind
multiple interfaces of each type to the untrust zone.
8. VLAN trunking allows one physical interface to support multiple logical subinterfaces, each of which must be identified by a unique VLAN tag. The VLAN
identifier (tag) on an incoming ethernet frame indicates its intended subinterface—and hence the virtual system—to which it is destined.

You can bind either a subinterface (with VLAN tagging to trunk traffic) or a physical interface to the
trust-<vsys_name> zone. You can also bind multiple interfaces of each type to these zones.
9LUWXDO5RXWHUV
When a root-level admin creates a virtual system, the vsys automatically has the following two virtual routers
available for its use:
• A shared virtual router: untrust-vr – In the same way that a vsys and the root system share the untrust zone,
they also share untrust-vr, which maintains the routing information for that zone.
• Its own virtual router: <vsys_name>-vr – This is a vsys-specific virtual router that, by default, maintains the
routing table for the trust-<vsys_name> zone.
If you, as a root-level administrator, want all of the vsys zones to be in the untrust-vr routing domain—for example, if
all the interfaces bound to the vsys-trust zone are in Route mode—you can dispense with the trust-vr by changing
the zone bindings from the trust-vr to the untrust-vr. For more information on virtual routers, see Chapter 7, “Virtual
Routers”.
Note: ScreenOS 3.1.0 does not support user-defined virtual routers within a vsys.

&KDSWHU8QLYHUVDO6HFXULW\*DWHZD\$UFKLWHFWXUH 3DFNHW)ORZ6HTXHQFH
3$&.(7)/2:6(48(1&(
In USGA, the flow sequence of an incoming packet progresses as illustrated below.
1 2 3 4 5
Incoming Packet
( MIP/VIP
Host IP )
Route
Lookup
Policy
Lookup ( Translation
Src Addr
) 6
Incoming Route Table ACL

Interface 10.10.10.0/24 eth1/1
0.0.0.0/0 untrust-vr
src dst service action
…
…
Source Destination Permit = Forward packet
Zone Interface Deny = Drop packet
– and – Tunnel = Use specified
Destination Zone tunnel for VPN encryption
Security
Zones
If network traffic, source
zone = security zone to
which interface or
subinterface is bound.
If destination zone = security zone,
If VPN traffic to tunnel use that zone for policy lookup.
interface bound to VPN
tunnel, source zone =
security zone in which
tunnel interface is
configured
If VPN traffic to tunnel

interface in a tunnel
zone, source zone = If destination zone = tunnel zone, use
carrier zone its carrier zone for policy lookup
Tunnel
Zone

1. The interface module identifies the incoming interface and, consequently, the source zone to which the
interface is bound.
The source zone determination is based on the following criteria:
– If the packet is not encapsulated, the source zone is the security zone to which the incoming interface
or subinterface is bound.
– If the packet is encapsulated and the tunnel interface is bound to a VPN tunnel, the source zone is the
security zone in which the tunnel interface is configured.
– If the packet is encapsulated and the tunnel interface is in a tunnel zone, the source zone is the
corresponding carrier zone (a security zone that carries a tunnel zone) for that tunnel zone.
2. If a mapped IP (MIP) or virtual IP (VIP) address is used, the address-mapping module resolves the MIP or
VIP so that the routing table can search for the actual host address.
3. The route table lookup finds the destination interface that leads to the destination address. In so doing, the
interface module identifies the destination zone to which that interface is bound.
The destination zone determination is based on the following criteria:
– If the destination zone is a security zone, that zone is used for the policy lookup.
– If the destination zone is a tunnel zone, the corresponding carrier zone is used for the policy lookup.
4. The policy engine searches the access control list (ACL) for a policy between the addresses in the identified
source and destination zones.
The action configured in the policy determines what the NetScreen firewall does with the packet:
– If the action is permit, the firewall determines to forward the packet to its destination.
– If the action is deny, the firewall determines to drop the packet.
– If the action is tunnel, the firewall determines to forward the packet to the VPN module, which
encapsulates the packet and transmits it using the specified VPN tunnel settings.
5. If source address translation is specified (either interface-based NAT or policy-based NAT), the NAT module
translates the source address before forwarding it either to its destination or to the VPN module.
6. The NetScreen device performs the action specified in the access policy.

([DPSOH3DUW(QWHUSULVHZLWK6L[=RQHV

This is the first part of an ongoing example. For the next part, in which the interfaces for each zone are set, see
“Example (Part 2): Interfaces for Six Zones” on page 17. Here you configure the following six zones for an
enterprise:
• Finance • Eng • Untrust

• Trust • Mail • DMZ
The zones Trust, Untrust, and DMZ are preconfigured. You must configure the zones Finance, Eng, and Mail. By
default, a user-configured zone is placed in the virtual router trust-vr. Thus, you do not have to specify a virtual router
for the Finance and Eng zones. However, in addition to configuring the Mail zone, you must also specify that it be in
the virtual router untrust-vr9. For both the DMZ and the Mail zones, you enable intra-zone blocking.
Trust-VR Routing Untrust-VR Routing

Domain Domain
Finance Mail
Trust Untrust
Eng DMZ
9. For more information on virtual routers and their routing domains, see Chapter 7, “Virtual Routers”.

:HE8,
1. Zone >> New Entry: Enter the following, and then click OK:
Name: Finance
Virtual Router Name: trust-vr
Zone Type: Regular: (select)
Name: Eng
Name: Mail
Intra-Zone Blocking: (select)
Virtual Router Name: untrust-vr
4. Zone >> Edit (for DMZ): Select Intra-Zone Blocking, and then click OK.
&/,
1. set zone name finance
2. set zone name eng
3. set zone name mail
4. set zone mail vrouter untrust-vr
5. set zone mail block
6. set zone dmz block
7. save

([DPSOH3DUW,QWHUIDFHVIRU6L[=RQHV

This is the second part of an ongoing example. For the first part, in which zones are configured, see
“Example (Part 1): Enterprise with Six Zones” on page 15. For the next part, in which virtual routers are
configured, see “Example (Part 3): Enterprise with Two Routing Domains” on page 22. This part of the
example demonstrates how to configure interfaces and bind them to zones.
210.10.1.1/24
eth1/1
Finance
10.10.1.1/24 Mail
eth3/2.1 210.10.2.2/24
eth1/1.2
Trust Untrust
10.10.2.1/24 210.10.3.1/24
eth3/2 eth1/2
Eng DMZ
10.10.3.1/24 210.10.4.1/24
eth3/1 eth2/2

:HE8,
,QWHUIDFHHWKHUQHW
1. Interface >> Physical >> Edit (for ethernet3/2): Enter the following, and then click Save:
IP Address: 10.10.2.1
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT (select)
Management Services: WebUI, Telnet, SNMP, SCS (select)
Other Services: Ping (select)
,QWHUIDFHHWKHUQHW
2. Interface >> Physical >> New Sub-i/f (for ethernet3/2): Enter the following, and then click Save:
Interface Name: ethernet3/2.: 1
Netmask: 255.255.255.0
VLAN Tag: 1
Zone Name: Finance
,QWHUIDFHHWKHUQHW
Netmask: 255.255.255.0

Zone Name: Eng

,QWHUIDFHHWKHUQHW
Netmask: 255.255.255.0
Zone Name: Mail
,QWHUIDFHHWKHUQHW
5. Interface >> Physical >> Sub-i/f (for ethernet1/1): Enter the following, and then click Save:
Interface Name: ethernet1/1.: 2
Netmask: 255.255.255.0
VLAN Tag: 2
Zone Name: Mail
,QWHUIDFHHWKHUQHW
Netmask: 255.255.255.0
Zone Name: Untrust
Management Services: SNMP (select)

,QWHUIDFHHWKHUQHW
Netmask: 255.255.255.0
Zone Name: DMZ
&/,
,QWHUIDFHHWKHUQHW
8. set interface eth3/2 zone trust
9. set interface eth3/2 ip 10.10.2.1/24
10. set interface eth3/2 nat
11. set interface eth3/2 manage ping
12. set interface eth3/2 manage webui
13. set interface eth3/2 manage telnet
14. set interface eth3/2 manage snmp
15. set interface eth3/2 manage scs
,QWHUIDFHHWKHUQHW
1. set interface eth3/2.1 zone finance
2. set interface eth3/2.1 ip 10.10.1.1/24 tag 1
3. set interface eth3/2.1 nat
4. set interface eth3/2.1 manage ping

,QWHUIDFHHWKHUQHW
5. set interface eth3/1 zone eng
7. set interface eth3/1 nat
8. set interface eth3/1 manage ping
,QWHUIDFHHWKHUQHW
9. set interface eth1/1 zone mail
,QWHUIDFHHWKHUQHW
11. set interface eth1/1.1 zone mail
12. set interface eth1/1.1 ip 210.10.2.2 /24 tag 2
,QWHUIDFHHWKHUQHW
13. set interface eth1/2 zone untrust
15. set interface eth1/2 manage snmp
,QWHUIDFHHWKHUQHW
16. set interface eth2/2 zone dmz
18. save

([DPSOH3DUW(QWHUSULVHZLWK7ZR5RXWLQJ'RPDLQV

This is the third part of an ongoing example. For the previous part, in which interfaces for the various security zones
are defined, see “Example (Part 2): Interfaces for Six Zones” on page 17. For the next part, in which the access
polices are set, see “Example (Part 4): Access Policies for an Enterprise with Six Zones” on page 25. In this
example, you only have to configure a route for the default gateway to the internet. The other routes are
automatically created by the NetScreen device when you create the interface IP addresses.
Trust-VR Routing Domain Untrust-VR Routing Domain
210.10.1.1/24 210.10.2.2/24
Finance eth1/1, Route eth1/1.2, Route
10.10.1.1/24 Mail
eth3/2.1, NAT
To
Internet
Trust Untrust
10.10.2.1/24 210.10.3.1/24
eth3/2, NAT eth1/2, Route
210.10.3.254
Eng DMZ
10.10.3.1/24 210.10.4.1/24
eth3/1, NAT Route eth2/2, Route
Redistribution

:HE8,
1. Routing >> Route Table >> New Entry: Enter the following, and then click OK:
Network Address: 0.0.0.0
Netmask: 0.0.0.0
Gateway IP Address: 210.10.2.254
Interface: ethernet1/2(untrust-vr)
&/,
1. set vrouter untrust-vr route 0.0.0.0/0 interface eth1/2 gateway 210.10.1.254
2. save
To see the route table entries for the ongoing example, look at the tables on the next page.

The NetScreen device automatically creates the following routes (in black):
To Reach: Use Interface: Use Gateway:

0.0.0.0/0 n/a Untrust-VR
10.10.3.0/24 eth3/1 0.0.0.0
10.10.2.0/24 eth3/2 0.0.0.0
10.10.1.0/24 eth3/2.1 0.0.0.0
To Reach: Use Interface: Use Gateway:

210.10.4.0/24 eth2/2 0.0.0.0
210.10.3.0/24 eth1/2 0.0.0.0
210.10.2.0/24 eth1/1.2 0.0.0.0
210.10.1.0/24 eth1/1 0.0.0.0
0.0.0.0/0 eth1/2 210.10.3.254 Note: This is the only
user-configured entry.

([DPSOH3DUW$FFHVV3ROLFLHVIRUDQ(QWHUSULVHZLWK6L[=RQHV

This is the last part of an ongoing example. The previous part is “Example (Part 3): Enterprise with Two Routing
Domains” on page 22. This part of the example demonstrates how to configure new access policies.
Finance Mail
Policy
Trust Engine Untrust
Eng DMZ
For the purpose of this example, before you begin configuring new access policies, you need to create new service
groups.
Note: When you create a zone, the NetScreen device automatically creates the address Any for all hosts within that
zone. This example makes use of the address Any for the hosts.

:HE8,
6HUYLFH*URXSV
1. Service >> Custom >> New Group: Enter the following, and then click OK.
Group Name: Mail-Pop3
Group Members << Available Members
Mail
Pop3
2. Service >> Custom >> New Group: Enter the following, and then click OK.
Group Name: HTTP-FTPGet
Group Members << Available Members
HTTP
FTP-Get
$FFHVV3ROLFLHV
3. Policy (From Zone: Finance, To Zone: Mail) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Destination Address: Any
Service: Mail-Pop3
Action: Permit
4. Policy (From Zone: Trust, To Zone: Mail) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: Mail-Pop3

Action: Permit
5. Policy (From Zone: Eng, To Zone: Mail) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: Mail-Pop3
Action: Permit
6. Policy (From Zone: Untrust, To Zone: Mail) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: Mail
Action: Permit
7. Policy (From Zone: Finance, To Zone: Untrust) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: HTTP-FTPGet
Action: Permit
8. Policy (From Zone: Finance, To Zone: DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Action: Permit
9. Policy (From Zone: Trust, To Zone: Untrust) >> New Policy: Enter the following, and then click OK:
Source Address: Any


Action: Permit
10. Policy (From Zone: Trust, To Zone: DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Action: Permit
11. Policy (From Zone: Eng, To Zone: DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Action: Permit
12. Policy (From Zone: Eng, To Zone: DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: FTP-Put
Action: Permit
13. Policy (From Zone: Untrust, To Zone: DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Action: Permit

&/,
6HUYLFH*URXSV
1. set group service mail-pop3 add mail
2. set group service mail-pop3 add pop3
3. set group service http-ftpget add http
4. set group service http-ftpget add ftpget
$FFHVV3ROLFLHV
5. set policy from finance to mail any any mail-pop3 permit
6. set policy from trust to mail any any mail-pop3 permit
7. set policy from eng to mail any any mail-pop3 permit
8. set policy from untrust to mail any any mail permit
9. set policy from finance to untrust any any http-ftpget permit
10. set policy from finance to dmz any any http-ftpget permit
11. set policy from trust to untrust any any http-ftpget permit
12. set policy from trust to dmz any any http-ftpget permit
13. set policy from eng to untrust any any http-ftpget permit
14. set policy from eng to dmz any any http-ftpget permit
15. set policy from eng to dmz any any ftp-put permit
16. set policy from untrust to dmz any any http-ftpget permit
17. save


&KDSWHU
=RQHV

A zone can be a segment of network space to which security measures are applied (a security zone), a logical
segment to which a VPN tunnel interface is bound (a tunnel zone), or either a physical or logical entity that performs
a specific function (a function zone). This chapter examines each type of zone, with particular emphasis given to the
security zone, and is organized into the following sections:
• “Security Zones” on page 33
• “Tunnel Zones” on page 34
• “Function Zones” on page 37
When you first boot up a NetScreen device, you can see a number of preconfigured zones. In the WebUI, click Zone
in the menu column on the left. In the CLI, use the get zone command.

&KDSWHU=RQHV
The output of the get zone command:
The root and virtual systems

ns500-> get zone share these zones.
Total of 12 zones in vsys root
------------------------------------------------------------------------
Id Name Type Attr VR Default-If vsys
0 Null Null Shared trust-vr null Root These zones do not and
1 Untrust Reg Shared untrust-vr ethernet1/2 Root cannot have an interface.
2 Trust Reg trust-vr ethernet3/2 Root
3 DMZ Reg untrust-vr ethernet2/2 Root
4 Self Reg trust-vr self Root
5 MGT Reg trust-vr mgt Root
6 HA Reg trust-vr ha1 Root These zones provide
10 Global Reg trust-vr null Root backward compatibility when
11 V1-Untrust L2 trust-vr v1-untrust Root upgrading to ScreenOS
12 V1-Trust L2 trust-vr v1-trust Root 3.1.0—the top 3 for devices in
13 V1-DMZ L2 trust-vr v1-dmz Root NAT or Route mode, the
16 Untrust-Tun Tun trust-vr tunnel Root bottom 3 for devices in
------------------------------------------------------------------------ Transparent mode.
Zone ID numbers 7–9 and 14–15 By default, VPN tunnel interfaces are bound to the Untrust-Tun
are reserved for future use. zone, whose carrier zone is the Untrust zone. (When upgrading to
ScreenOS 3.1.0, existing tunnels are bound to the Untrust-Tun zone.)
The preconfigured zones shown above can be grouped into three different types:
Security Zones: Untrust, Trust, DMZ, Global, V1-Untrust, V1-Trust, V1-DMZ
Tunnel Zone: Untrust-Tun
Function Zones: Null, Self, MGT, HA

&KDSWHU=RQHV 6HFXULW\=RQHV
6(&85,7<=21(6
On a single NetScreen device, you can configure multiple security zones, sectioning the network into segments to
which you can apply various security options to satisfy the needs of each segment. At a minimum, you must define
two security zones, basically to protect one area of the network from the other. You can also define many security
zones, bringing finer granularity to your network security design— and without deploying multiple security
appliances to do so.
*OREDO=RQH
You can identify a security zone because it has an address book and can be referenced in access policies. The
global zone satisfies these criteria. However, it does not have one element that all other security zones do have—an
interface. The global zone serves as a storage area for mapped IP (MIP) and virtual IP (VIP) addresses. Because
traffic going to these addresses is mapped to other addresses, the global zone does not require an interface for
traffic to flow through it.
Note: When configuring a policy for a MIP or VIP, you can specify the global zone as the destination zone. If you
specify the security zone to which the MIP or VIP maps the traffic it receives as the destination, the policy engine
automatically changes it to global.

&KDSWHU=RQHV 7XQQHO=RQHV
7811(/=21(6
A tunnel zone is a logical segment that hosts one or more tunnel interfaces. A tunnel zone is associated with a
security zone that acts as its carrier. The NetScreen device uses the routing information for the carrier zone to direct
traffic to the tunnel endpoint. The default tunnel zone is Untrust-Tun, and it is associated with the Untrust zone. You
can create other tunnel zones and bind them to other security zones, with a maximum of one tunnel zone per carrier
1
zone per virtual system .
By default, a tunnel zone is in the Trust-VR routing domain, but you can also move a tunnel zone into another
routing domain.
&UHDWLQJD6HFXULW\=RQH
To create a security zone or tunnel zone, do either of the following:
:HE8,
Zone >> New Entry: Enter the following, and then click OK:
Name: Type a name for the zone.
Block Intra-Zone Traffic: Select this if you want to block traffic between hosts
within the same security zone. By default, intra-zone blocking is disabled.
Virtual Router Name: Select the virtual router in whose routing domain you
want to place the zone.
Zone Type: Select Regular to create a zone to which you can bind interfaces
in NAT or Route mode. Select Layer 2 to create a zone to which you can
bind interfaces in Transparent mode. Select Tunnel Out Zone when
creating a tunnel zone and binding it to a carrier zone, and then select a
specific carrier zone from the drop-down list.
1. The root system and all virtual systems can share the Untrust zone. However, each system has its own separate Untrust-Tun zone.

&/,
set zone name <name> [ l2 <vlan_id_number> | tunnel <zone_name> ]
set zone <name> block
set zone vrouter <vrouter_name>
0RGLI\LQJD6HFXULW\=RQH
To modify the ID number or name of a security zone or tunnel zone, you must first delete the zone2, and then create
it again with the new name. To change the intra-zone blocking option or to change the virtual router, you can modify
those settings on the existing zone.
:HE8,
0RGLI\LQJWKH=RQH1DPH
1. Zone: Click Remove (for the zone whose ID number or name you want to modify).
2. When the prompt appears, asking for confirmation of the removal, click Yes.
3. Zone >> New Entry: Enter the zone settings, modifying the ID number or name, and then click OK.
&KDQJLQJWKH,QWUD=RQH%ORFNLQJ2SWLRQRU9LUWXDO5RXWHU
1. Zone >> Edit (for the zone that you want to modify): Enter the following, and then click OK:
Intra-Zone Blocking: To enable, select the check box. To disable, clear it.
Virtual Router Name: From the drop-down list, select the virtual router into
whose routing domain you want to move the zone.
2. Before you can remove a zone, you must first unbind all interfaces bound to it.

&/,
0RGLI\LQJWKH=RQH1DPH
1. unset zone <name>
2. set zone name <name> [ l2 <vlan_id_number> | tunnel <zone_name> ]
&KDQJLQJWKH,QWUD=RQH%ORFNLQJ2SWLRQRU9LUWXDO5RXWHU
{ set | unset } zone <name> block
set zone vrouter <vrouter_name>
'HOHWLQJD6HFXULW\=RQH
To delete a security zone or tunnel zone, do either of the following3:
:HE8,
1. Zone: Click Remove (for the zone you want to delete).
2. When the prompt appears, asking for confirmation of the removal, click Yes.
&/,
unset zone <name>
3. Before you can remove a zone, you must first unbind all interfaces bound to it.

&KDSWHU=RQHV )XQFWLRQ=RQHV
)81&7,21=21(6
The four function zones are Null, MGT, HA, and Self. Each zone exists for a single purpose, as explained below.
Note: Although you can set interfaces for the MGT and HA zones, the zones themselves are not configurable.
1XOO=RQH
This zone serves as temporary storage for any interfaces that are not bound to any other zone.
0*7=RQH
This zone hosts the out-of-band management interface, MGT.
+$=RQH
This zone hosts the high availability interfaces, HA1 and HA2.
6HOI=RQH
This zone hosts the interface for remote management connections. When you connect to the NetScreen device via
HTTP, SCS, or Telnet, you connect to the Self zone.

&KDSWHU=RQHV )XQFWLRQ=RQHV

&KDSWHU
,QWHUIDFHV

Creating an interface is the next step following the creation of a zone. You must create an interface and bind it to a
zone to allow traffic to flow in and out of the zone. Then, you must set routes and configure access policies to allow
traffic to pass from interface to interface . Physical interfaces and subinterfaces, like doorways, allow traffic to enter
and exit a zone. You can assign multiple interfaces to a zone, but an interface can only be assigned to one zone.
For more information on configuring access policies, see “Access Policies” on page 241, and “Policy-Based VPNs”
on page 375 for VPN tunnels. For more information on configuring routes, see “Virtual Routers” on page 165.
The great flexibility of USGA enables you to set DHCP service and firewall options on a per interface basis.
This chapter contains the following sections:
• “Interface Types” on page 40
• “Interface Settings and Operational Modes” on page 45
• “Secondary IP Addresses” on page 63
• “Management Services Options” on page 65
• “Interface Services Options” on page 66
• “Firewall Options” on page 67
• “Configuring an interface” on page 72

&KDSWHU,QWHUIDFHV ,QWHUIDFH7\SHV
,17(5)$&(7<3(6
This section describes physical interfaces, subinterfaces, and tunnel interfaces. For information on how to view a
table of all these interfaces, see “Viewing interfaces” on page 42.
6HFXULW\=RQH,QWHUIDFHV
The purpose of physical interfaces and subinterfaces is to provide an opening through which network traffic can
pass between zones.
3K\VLFDO
Each port on your NetScreen device represents a physical interface, and the name of the interface is
predefined. The name of a physical interface is composed of the media type, slot number (for some
NetScreen devices), and port number, for example, ethernet3/2 or ethernet2 (see also “Security Zone
Interfaces” on page 3). For backward compatibility, certain interfaces can still be named Trust, Untrust, and
DMZ as in the old version of ScreenOS. You can bind a physical interface to any security zone where it acts
as a doorway through which traffic enters and exits the zone. Without an interface, no traffic can access the
zone or leave it.
Three of the physical ethernet interfaces are pre-bound to specific zones—Trust, Untrust, or DMZ— and
which interface is bound to which zone is specific to each platform. For more information on the Trust,
Untrust, and DMZ zones, see “Multiple Security Zones” on page 2.
6XELQWHUIDFH
A subinterface, like a physical interface, acts as a doorway through which traffic enters and exits a security
zone. You can logically divide a physical interface into several virtual subinterfaces. Each virtual
subinterface borrows the bandwidth it needs from the physical interface from which it stems, thus its name is
an extension of the physical interface name, for example, ethernet3/2.1 or ethernet2.1 (see also “Security
Zone Interfaces” on page 3).

You can bind a subinterface to any zone. You can bind a subinterface to the same zone as its physical
interface, or you can bind it to a different zone.
)XQFWLRQ=RQH,QWHUIDFHV
Function zone interfaces, such as Management and HA, each serve a special purpose.
0DQDJHPHQW,QWHUIDFH
On some NetScreen devices, you can manage the device through a separate physical interface—the
Management (MGT) interface—moving administrative traffic outside the regular network user traffic.
Separating administrative traffic from network user traffic greatly increases security and assures constant
management bandwidth.
Note: For information on configuring the device for administration, see “Administration” on page 111.
+$,QWHUIDFH
With NetScreen devices with dedicated High Availability (HA) interfaces, you can link two or more devices
together to form a redundant group, or cluster. In a redundant group, one unit acts as the master, performing
the network firewall, VPN, and traffic-shaping functions, while the other units act as backups, basically
waiting to take over the firewall functions should the master unit fail. The HA interface is a physical port used
exclusively for HA functions.
9LUWXDO+$,QWHUIDFH
On NetScreen devices without a dedicated HA interface, a Virtual High Availability (HA) interface
provides the same functionality. Because there is no separate physical port exclusively used for HA
traffic, the Virtual HA interface must be bound to one of the physical ports—trusted, untrusted, or DMZ.

7XQQHO,QWHUIDFHV
A tunnel interface acts as a doorway to a VPN tunnel. Traffic enters and exits a VPN tunnel via a tunnel interface.
By binding a tunnel interface to a VPN, you can separate the policy from the VPN tunnel. This way, you can
configure one tunnel, and define multiple policies to regulate the traffic that flows through that tunnel. When there is
no tunnel interface bound to a VPN tunnel, only one policy can be defined per VPN tunnel.
You can perform policy-based NAT on outgoing or incoming traffic using a pool of dynamic IP (DIP) addresses in the
same subnet as the tunnel interface. A typical reason for using policy-based NAT on a tunnel interface is to avoid IP
address conflicts between the two sites on either end of the VPN tunnel. You can use the same tunnel interface and
DIP pool for more than one VPN tunnel.
In USGA, you can bind a tunnel interface to any zone. For more information on tunnel interfaces, see “Tunnel
Interfaces” on page 42.
Note: For information on how to configure an interface, see “Configuring an interface” on page 72.
9LHZLQJLQWHUIDFHV
You can view a table that lists all interfaces on your NetScreen device. Because they are predefined,
physical interfaces are listed regardless of whether or not you configure them. Subinterfaces and tunnel
interfaces are only listed once you create and configure them.
To view the interface table in the WebUI, click Interface in the menu column on the left, and to view it in the
CLI, use the get interface command. In the CLI, the get interface command includes tunnel interfaces. In
the WebUI, tunnel interfaces are separated from other interfaces. To view them, click Interface >> Tunnel.
,QWHUIDFH7DEOH
The interface table displays the following information on each interface:
– Name: This field identifies the name of the interface.
– IP/Netmask: This field identifies the IP address and netmask address of the interface.

– Zone: This field identifies the zone to which the interface is bound.
– Link: This field identifies whether the interface is active (Up) or inactive (Down).
– Configure: This field allows you configure and modify interfaces through these options:
Edit: Configure a physical interface for the first time, or modify an existing configuration.
New Sub-i/f: Create a new subinterface, or click Edit to modify an existing configuration.
Remove: Click to delete an interface.
MIP: Create a mapped IP address.
DIP: Create a dynamic IP address pool.
2IP: Create a secondary IP address.
VIP: Create a virtual IP address.
Screen: Select Network Attack Blocking Engine (Screen) options to counter network attacks such
as the ones listed in the “Firewall Options” on page 67.
Note: In the WebUI, in the physical interfaces and subinterfaces table, yellow rows identify physical
interfaces, and green rows identify subinterfaces (see “WebUI Interface Table” on page 44). In the CLI,
you can distinguish a subinterface from a physical interface by its VLAN tag (see “CLI Interface Table” on
page 44).

WebUI Interface Table
CLI Interface Table
VLAN Tag VLAN Tag

&KDSWHU,QWHUIDFHV ,QWHUIDFH6HWWLQJVDQG2SHUDWLRQDO0RGHV
,17(5)$&(6(77,1*6$1'23(5$7,21$/02'(6
Interfaces can operate in three different modes: Network Address Translation (NAT), Route, and Transparent
modes. You select an operational mode when you configure an interface.
7UDQVSDUHQW0RGH
When an interface is in a Transparent mode, the NetScreen device filters packets traversing the firewall without
modifying any of the source or destination information in the IP packet header. All interfaces behave as though they
are part of the same network, with the NetScreen device acting much like a layer-2 switch or bridge. In Transparent
mode, the IP addresses of interfaces are set at 0.0.0.0, making the presence of the NetScreen device invisible, or
“transparent,” to users.
209.122.30.3
209.122.30.2 209.122.30.4
209.122.30.1
209.122.30.5
Trust Zone
Switch
Public Address
Space
Untrust Zone
External
Router
To Internet

Transparent mode is a convenient means for protecting Web servers, or any other kind of server that mainly
receives traffic from untrusted sources. Using Transparent mode offers the following benefits:
• No need to reconfigure the IP settings of routers or protected servers
• No need to create Mapped or Virtual IP addresses for incoming traffic to reach protected servers
,QWHUIDFH6HWWLQJV
Interfaces in transparent mode can only be managed through the VLAN1 interface. By default, ScreenOS always
creates a VLAN1 interface, and three VLAN1 zones: V1-Trust, V1-Untrust, V1-DMZ.
9/$1,QWHUIDFH
While ScreenOS creates the VLAN1 interface, you need to configure it before you can use it to manage any
interface. The VLAN1 interface has in fact two main purposes: one is to provide an address for managing
the device, and the other is to terminate VPN traffic when the device is in transparent mode. The VLAN1
interface has the same configuration and management abilities as a physical interface.
You can configure the VLAN1 interface to permit hosts in the VLAN1 zones to manage it, in which case, you
must set the VLAN1 interface IP to be in the same subnet as the hosts.
The VLAN1 interface IP overrides the system IP and the manage IP. When the VLAN1 interface is
configured, neither the system IP nor the manage IP have any effect on interfaces in transparent mode.
9/$1=RQHV
VLAN1 zones are also referred to as “Layer 2 zones” because they share the same layer 2 domain. When
you configure an interface in one of the VLAN1 zones, it gets added to the layer 2 domain shared by all
interfaces in all the VLAN1 zones.
By default the following physical interfaces are bound to the VLAN1 zones:
Zone NetScreen 200 Series Interface NetScreen 500 Interface

V1-Trust ethernet1 ethernet3/2
V1-DMZ ethernet2 ethernet2/2

Zone NetScreen 200 Series Interface NetScreen 500 Interface

V1-Untrust ethernet3 ethernet1/2
All hosts in the VLAN1 zones must be on the same subnet to communicate, and you must define policies to
allow hosts to communicate between zones. For more information on how to set policies, see “Access
Policies” on page 241.
([DPSOH+RZWRVHW9/$1,QWHUIDFH
This example demonstrates how to set an IP address for the VLAN1 interface, management options, and a route to
enable traffic to flow to and from the NetScreen device.
:HE8,
1. Interface >> Physical >> Edit (for the VLAN1 interface): Enter the following, and then click OK.
IP Address: 209.122.30.254
Netmask: 255.255.255.0
Management Services: WebUI, Telnet, SCS (select)
&/,
1. set interface vlan1 ip 209.122.30.254/24
2. set interface vlan1 manage webui telnet scs ping
3. save

([DPSOH7UDQVSDUHQW0RGH
The following example illustrates a basic configuration for a single LAN protected by a NetScreen device in
Transparent mode. Access policies permit outgoing traffic for all four hosts in the Trust zone, incoming mail for the
mail server, and incoming FTP for the FTP server. The device is managed through its VLAN1 IP address.
FTP Server Mail Server Router

209.122.17.250/24 209.122.17.249/24 209.122.17.253/24
NetScreen Device
Trust Zone Internet

VLAN1 IP
209.122.17.252
Port 5555
PC #1 PC #2
209.122.17.1/24 209.122.17.2/24
:HE8,
1. Interface >> Physical >> Edit (for the VLAN1 interface): Enter the following, and then click Apply:
IP Address: 209.122.17.252
Netmask: 255.255.255.0
Management Services: WebUI, Telnet, SCS (select)
2. Admin >> Web: Enter the following, and then click Apply:
HTTP Port: 55551

3. Interface >> Physical >> Edit (for ethernet1): Enter the following, and then click Save:
IP Address: 0.0.0.0
Netmask: 0.0.0.0
Manage IP: 0.0.0.0
Traffic Bandwidth: 0
Zone Name: Trust
4. Interface >> Physical >> Edit (for ethernet3): Enter the following, and then click Save.
IP Address: 0.0.0.0
Netmask: 0.0.0.0
Manage IP: 0.0.0.0
Zone Name: Untrust
5. Address >> Address (under the “New” column for the Trust zone): Enter the following and then click OK:
Address Name: Mail Server
IP Address/Domain Name: 209.122.17.249
Netmask: 255.255.255.255
Address Name: FTP Server
Netmask: 255.255.255.255
7. Policy >> From Zone: Trust, To Zone: Untrust >> New Policy: Enter the following and then click OK:
Source Address: Any
1. The default port number is 80. Changing this to any number between 1024 and 32,767 is advised for discouraging unauthorized access to the configuration.
When logging in to manage the device later, enter the following in the URL field of your Web browser: http://209.122.17.252:5555.


Service: Any
Action: Permit
8. Policy >> From Zone: Untrust, To Zone: Trust >> New Policy: Enter the following and then click OK:
Source Address: Any
Destination Address: Mail Server
Service: Mail
Action: Permit
Note: To get the “Mail Server” address, it must already exist in the address list. You can create this address
by selecting Address >> Address (under the “New” column for the appropriate zone) and specifying the mail
server’s name and IP address.
Source Address: Any
Destination Address: FTP Server
Service: FTP
Action: Permit
Note: Because PC #1 and PC #2 are not specified in an access policy, they do not need to be added to the
address book. The term “Any” applies to any device connected to the interface in the Trust zone.

&/,
1. set vlan1 ip 209.122.17.252
2. set admin port 55552
3. set interface ethernet1 zone trust
4. set interface ethernet1 ip 0.0.0.0/0
5. set interface ethernet3 zone untrust
7. set address trust Mail_Server 209.122.17.249/24
8. set address trust FTP_Server 209.122.17.250/24
9. set policy from trust to untrust any any any permit
10. set policy from untrust to trust any 209.122.17.250/24 mail permit
11. set policy from untrust to trust any 209.122.17.249/24 ftp permit
12. save
2. When logging in to manage the device later, enter the following in the URL field of your Web browser: http://209.122.17.252:5555

1HWZRUN$GGUHVV7UDQVODWLRQ0RGH
When an interface is in Network Address Translation (NAT) mode, the NetScreen device, acting like a layer-3 switch
(or router), translates two components in the header of an outgoing IP packet traversing the firewall across an
interface in NAT mode: its source IP address and source port number. The NetScreen device replaces the source IP
address of the host that sent the packet with the IP address of the interface of the destination zone. Also, it replaces
the source port number with another random port number generated by the NetScreen device.
172.16.20.3
172.16.20.2 172.16.20.4
172.16.20.1
172.16.20.5
Trust Zone
Trust Zone
Interface
172.16.20.10
Private Address
Space
Untrust Zone
Interface
209.122.30.10
Untrust Zone
Internet
When the reply packet arrives at the NetScreen device, the device translates two components in the IP header of
the incoming packet: the destination address and port number, which are translated back to the original numbers.
The packet is then forwarded to its destination.
NAT adds a level of security not provided in Transparent mode: The addresses of hosts connected to the trusted
port are never exposed to the network in the Untrust or DMZ zones.

Also, NAT preserves the use of Internet-routable IP addresses. With only one public, Internet-routable IP address—
that of the interface in the Untrust zone—the LAN in the Trust zone, or any other zone using NAT services, can have
a vast number of hosts with private IP addresses. The following IP address ranges are reserved for private IP
networks and must not get routed on the Internet:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
A host in a zone sending traffic through an interface in NAT mode can initiate outbound traffic to another zone if an
access policy permits it, but it cannot receive traffic from another zone unless a Mapped IP (MIP), Virtual IP (VIP), or
VPN tunnel is set up for it.
Note: For more about MIPs, see “Mapped IP” on page 468. For more about VIPs, see “Virtual IP” on page 190.

,QWHUIDFH6HWWLQJV
For NAT mode, define the following interface settings, where <address1> and <address2> represent numbers in an
IP address, <netmask> represents the numbers in a netmask, <tag> represents the number of a VLAN tag, <zone>
represents the name of a zone, and <number> represents the bandwidth size in kbps:
Zone Interfaces Settings Zone Subinterfaces

Trust and User-Defined Zones using NAT IP: <address1> IP: <address1>
Netmask: <netmask> Netmask: <netmask>
Manage IP*: <address2> VLAN Tag: <tag>
Traffic Bandwidth†: <number> Zone Name: <zone>
NAT‡: (select) NAT†: (select)
Untrust and DMZ IP: <address1> IP: <address1>
* You can set the manage IP address on a per interface basis. Its primary purpose is to provide an address for accessing a specific
device when it is in a high availability configuration. You can also use the manage IP address for management purposes when using
the NetScreen device as a single security appliance.
† Optional setting for traffic shaping.
‡ Selecting NAT defines the interface mode as NAT. Selecting Route defines the interface mode as Route.
([DPSOH1$70RGH
The following example illustrates a simple configuration for a LAN with a single subnet in the Trust zone. The LAN is
protected by a NetScreen device in NAT mode. Access policies permit outgoing traffic for all three hosts in the Trust
zone and incoming mail for the mail server. The incoming mail is routed to the mail server through a Virtual IP
address.
Note: Compare this example with that for Route mode on page 60.

Mail Server
VIP 209.2.2.3 Router
NAT 172.16.10.253 200.2.2.1/24
NetScreen Device
Trust Zone Internet
Trust Zone Untrust Zone

Interface Interface
172.16.10.1/24 200.2.2.2/24
Workstation #1 Workstation #2
172.16.10.20/24 172.16.10.30/24 Untrust Zone
:HE8,
1. Admin >> Settings: Enter the following, and then click Apply.
System IP Address: 0.0.0.0
IP Address: 172.16.10.1
Netmask: 255.255.255.0
Manage IP: 0.0.0.0
Zone Name: Trust
NAT:3 (select)
3. Selecting NAT determines that the NetScreen device performs NAT on traffic entering and exiting the Trust zone.

IP Address4: 200.2.2.2
Netmask: 255.255.255.0
Manage IP: 0.0.0.0
Zone Name: Untrust
3. Interface >> Physical >> VIP (for ethernet3) >> New Entry: Enter the following, and then click OK:
Virtual IP Address: 200.2.2.3
4. Interface >> Physical >> VIP (for ethernet3) >> Services: Enter the following, and then click OK:
Virtual Port: 25
Service: Mail
Map to IP: 172.16.10.253
5. Policy >> From Zone: Trust, To Zone: Untrust >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: Any
Action: Permit
Source Address: Any
Destination Address: VIP(200.2.2.3)
Service: Mail
Action: Permit
4. If the IP address in the Untrust zone on the NetScreen device is dynamically assigned by an ISP, leave the IP address and netmask fields empty and select
DHCP. If the ISP uses Point-to-Point Protocol over Ethernet, select PPPoE and enter the name and password.

&/,
1. set admin sys-ip 0.0.0.0
3. set interface ethernet1 ip 172.16.10.1 255.255.255.0
4. set interface ethernet1 NAT5
5. set interface ethernet3 zone untrust6
8. set vip ethernet3 200.2.2.3 25 mail 172.16.10.253
10. set policy from untrust to trust any “vip 200.2.2.3” mail permit
11. save
5. The set interface ethernet<number> nat command determines that the NetScreen device operates in NAT mode.
6. If the IP address in the Untrust zone on the NetScreen device is dynamically assigned by an ISP, use the following command: set interface untrust dhcp.
If the ISP uses Point-to-Point Protocol over Ethernet, use the set pppoe and exec pppoe commands. For more information, see the NetScreen CLI
Reference Guide.

5RXWH0RGH
When an interface is in Route mode, the NetScreen device routes traffic between different zones without performing
NAT; that is, the source address and port number in the IP packet header remain unchanged as it traverses the
NetScreen device. Unlike NAT, you do not need to establish Mapped and Virtual IP addresses on an interface in
Route mode to allow inbound sessions to reach hosts. Unlike Transparent mode, the interfaces in the Trust zone
and the interfaces in the Untrust zone are on different subnets.
212.45.30.3
212.45.30.2 212.45.30.4
212.45.30.1
212.45.30.5
Trust Zone
Trust Zone
Interface
212.45.30.10
Private Address
Space
Untrust Zone
Interface
209.122.30.10
Untrust Zone
Internet
Instead of applying NAT at the interface level so that all source addresses initiating outgoing traffic get translated to
the IP address of the destination interface, when an interface operates in Route mode, you can perform NAT
selectively at the policy level. You can determine which network and VPN traffic to route and on which traffic to
perform NAT by creating access policies that enable NAT for specified source addresses on either incoming or

outgoing traffic. For network traffic, you can perform NAT using the IP address or addresses of the destination zone
interface from a Dynamic IP (DIP) pool, which is in the same subnet as the destination zone interface. For VPN
traffic, you can perform NAT using the destination zone interface IP address or an address from its associated DIP
pool, or a tunnel interface IP address or an address from its associated DIP pool.
Note: For more information about configuring policy-based NAT, see Chapter 15, “Policy-Based NAT” on page 463.
3DFNHW)ORZ6HTXHQFH
For information and examples on packet flow sequence, see “Packet Flow Sequence” on page 13.
,QWHUIDFH6HWWLQJV
For Route mode, define the following interface settings, where <address1> and <address2> represent numbers in
an IP address, <netmask> represents the numbers in a netmask, <tag> represents the number of a VLAN tag,
<zone> represents the name of a zone, and <number> represents the bandwidth size in kbps:
Zone Interfaces Settings Zone Subinterfaces
Trust and User-Defined Zones using NAT IP: <address1> IP: <address1>
Route‡: (select) Route†: (select)
Untrust and DMZ IP: <address1> IP: <address1>
* You can set the manage IP address on a per interface basis. Its primary purpose is to provide an address for accessing a specific
device when it is in a high availability configuration. You can also use the manage IP address for management purposes when using
the NetScreen device as a single security appliance.
† Optional setting for traffic shaping.
‡ Selecting NAT defines the interface mode as NAT. Selecting Route defines the interface mode as Route.

([DPSOH5RXWH0RGH
In the previous example, “Example: NAT Mode” on page 54, the hosts in the Trust zone LAN have private IP
addresses and a Mapped IP for the mail server. In the following example of the same network protected by a
NetScreen device operating in Route mode, note that the hosts have public IP addresses and that a MIP is
unnecessary for the mail server.
Mail Server Router

240.9.10.45/24 200.2.2.1/24
NetScreen Device
Internet

Interface Interface
240.9.10.10/24 200.2.2.2/24
Workstation #1 Workstation #2
240.9.10.20/24 240.9.10.30/24
:HE8,
1. Admin >> Settings: Enter the following, and then click Apply:
System IP Address: 0.0.0.0
IP Address: 240.9.10.10
Netmask: 255.255.255.0
Zone Name: Trust
Route7: (select)

IP Address8: 200.2.2.2
Netmask: 255.255.255.0
Zone Name: Untrust
Netmask: 255.255.255.255
4. Policy >> From Zone: Trust, To Zone: Untrust >> New Policy: Enter the following and then click OK:
Source Address: Any
Service: Any
Action: Permit
Source Address: Any
Service: Mail
Action: Permit
7. Selecting Route determines that the NetScreen device operates in Route mode, without performing NAT on traffic entering or exiting the Trust zone.
8. If the IP address in the Untrust zone on the NetScreen device is dynamically assigned by an ISP, leave the IP address and netmask fields empty and select
DHCP. If the ISP is using Point-to-Point Protocol over Ethernet, select PPPoE and enter the name and password.

&/,
1. set admin sys-ip 0.0.0.0
4. set interface ethernet1 route9
7. set address trust mail_server 240.9.10.45/24
9. set policy from untrust to trust any mail_server mail permit
10. save
9. The set interface ethernet<number> route command determines that the NetScreen device operates in Route mode.

&KDSWHU,QWHUIDFHV 6HFRQGDU\,3$GGUHVVHV
6(&21'$5<,3$''5(66(6
Each NetScreen interface has a single, unique primary IP address. However, some situations demand that an
interface have multiple IP addresses. For example, an organization might have additional IP address assignments,
and might not wish to add a router to accommodate them. In addition, an organization might have more network
devices than its subnet can handle, as when there are more than 254 hosts connected to a LAN. To solve such
problems, you can add secondary IP addresses to an interface in the Trust, DMZ, or user-defined zone.
Note: You cannot set multiple secondary IP addresses for interfaces in the Untrust zone.
6HFRQGDU\$GGUHVV3URSHUWLHV
Secondary addresses have certain properties that affect how you can implement such addresses. These properties
are as follows.
• There can be no subnet address overlap between any two secondary IPs. In addition, there can be no
subnet address overlap between a secondary IP and any existing subnet on the NetScreen device.
• When you manage a NetScreen device through a secondary IP address, the address always has the same
management properties as the primary IP address. Consequently, you cannot specify a separate
management configuration for the secondary IP address.
• You cannot configure a gateway for a secondary IP address.
• You cannot configure a secondary IP address in transparent mode. For example, if you configure the
secondary IP in NAT or route mode and then attempt to change the mode to transparent mode, the action
fails.
• Whenever you create a new secondary IP address, the NetScreen device automatically creates a
corresponding routing table entry. When you delete a secondary IP address, the device automatically
deletes its routing table entry.
Enabling or disabling routing between two secondary IP addresses causes no changes in the routing table.
For example, if you disable routing between two such addresses, the NetScreen device drops any packets
directed from one interface to the other, but no changes occur in the routing table.

&KDSWHU,QWHUIDFHV 6HFRQGDU\,3$GGUHVVHV
([DPSOH&UHDWLQJD6HFRQGDU\,3$GGUHVV
In this example, you set up a secondary IP address—192.168.1.2—for an interface in the Trust zone.
:HE8,
Interface >> Physical >> 2IP (for ethernet1) >> New Entry: Enter the following, and then click OK:
IP Address: 192.168.1.2
Netmask 255.255.255.0
&/,
1. set interface ethernet1 ip 192.168.1.2/24 secondary
2. save

&KDSWHU,QWHUIDFHV 0DQDJHPHQW6HUYLFHV2SWLRQV
0$1$*(0(176(59,&(6237,216
You can configure an interface to allow various methods of administration. For example, you might have local
management access the device through one interface and remote management through another interface. You
might use one interface exclusively for administration, separating management traffic completely from network user
traffic.
You can select as many or as few of the following management services options as you want.
WebUI: Selecting this option allows the interface to receive HTTP traffic to manage the NetScreen device
via the Web user interface (WebUI).
Telnet: A terminal emulation program for TCP/IP networks such as the Internet. Telnet is a common way to
remotely control network devices. Selecting this option enables Telnet manageability.
SNMP: The NetScreen device supports the Simple Network Management Protocol version 1.5 (SNMPv1),
described in RFC-1157, and all relevant Management Information Base II (MIB II) groups, as defined in
RFC-1213. Selecting this option enables SNMP manageability.
SCS: You can administer the NetScreen device from an Ethernet connection or a dial-in modem using
Secure Command Shell (SCS), which is SSH-compatible. You must have a SSH client that is compatible
with version 1.5 of the SSH protocol. These clients are available for most operating systems, including
Windows 95 and later, Linux, and UNIX. The NetScreen device communicates with the SSH client through
its built-in SCS server, which provides device configuration and management services. Selecting this option
enables SCS manageability.
SSL: Selecting this option allows the interface to receive HTTPS traffic for secure management of the
NetScreen device via the WebUI.

&KDSWHU,QWHUIDFHV ,QWHUIDFH6HUYLFHV2SWLRQV
,17(5)$&(6(59,&(6237,216
These services affect how your NetScreen device behaves. You may select as many options as required to meet the
needs of your network.
Ping: A utility that enables you to determine whether a specific IP address is accessible. Selecting this
option allows people to ping the IP address of the interface through any security zone interface.
Ident-reset: Services like Mail and FTP send identification requests. If they receive no acknowledgement,
they send the request again. While the request is processing, there is no user access. By enabling the
Ident-reset option, the NetScreen device sends a TCP reset announcement in response to an IDENT
request to port 113 and restores access that has been blocked by an unacknowledged identification
request.
DHCP Relay Agent: This option enables your NetScreen device to act as a DHCP relay agent, receiving
DHCP information from a DHCP server and relaying that information to hosts in security zones. When acting
as a DHCP relay agent, the NetScreen device forwards DHCP requests and assignments between hosts
and a DHCP server.
Enable DHCP Relay VPN Encryption: The DHCP messages between the NetScreen device and the
DHCP server can be transmitted in the open or through a VPN tunnel. Selecting this option protects the
relayed requests and responses between the NetScreen device and the DHCP server by encrypting and
then transmitting them through a VPN tunnel.

&KDSWHU,QWHUIDFHV )LUHZDOO2SWLRQV
),5(:$//237,216
NetScreen firewall options secure a zone by inspecting, and then allowing or denying, all connection attempts that
require crossing an interface. To protect against attacks from other zones, you can enable defense mechanisms that
detect and deflect the following common network attacks. The following options are available for physical interfaces
only: SYN Attack, ICMP Flood, UDP Flood, and Port Scan Attack.
• SYN Attack: A SYN flood attack occurs when a network becomes so overwhelmed by SYN packets
initiating uncompletable connection requests that it can no longer process legitimate connection requests,
resulting in a denial of service (DoS).
• UDP Flood: Similar to the ICMP flood, UDP flooding occurs when UDP packets are sent with the purpose
of slowing down the system to the point that it can no longer handle valid connections. After enabling the
UDP flood protection feature, you can set a threshold that once exceeded invokes the UDP flood attack
protection feature. (The default threshold value is 1000 packets per second.) If the threshold is exceeded,
the NetScreen device ignores further UDP packets for the remainder of that second.
• Port Scan Attack: Port scan attacks occur when packets are sent with different port numbers with the
purpose of scanning the available services in hopes that one port will respond. The NetScreen device
internally logs the number of different ports scanned from one remote source. If a remote host scans 10
ports in 0.3 seconds, NetScreen flags this as a port scan attack, and rejects further packets from the remote
source.
• Ping of Death: The TCP/IP specification requires a specific packet size for datagram transmission. Many
ping implementations allow the user to specify a larger packet size if desired. A grossly oversized ICMP
packet can trigger a range of adverse system reactions such as denial of service (DoS), crashing, freezing,
and rebooting. If you enable the NetScreen device to do so, it can detect and reject such oversized and
irregular packet sizes.
• IP Spoofing: Spoofing attacks occur when an attacker attempts to bypass the firewall security by imitating
a valid client IP address. When IP Spoofing defense is enabled, the NetScreen device guards against this
attack by analyzing the IP addresses with its own route table. If the IP address is not in the route table, traffic
from that source is not allowed to communicate through the NetScreen device and any packets from that
source are dropped.

• Land Attack: Combining a SYN attack with IP spoofing, a Land attack occurs when an attacker sends
spoofed SYN packets containing the IP address of the victim as both the destination and source IP address.
The receiving system responds by sending the SYN-ACK packet to itself, creating an empty connection that
lasts until the idle timeout value is reached. Flooding a system with such empty connections can overwhelm
the system, causing a DoS. By combining elements of the SYN flood defense and IP Spoofing protection,
the NetScreen device blocks any attempts of this nature.
• Tear Drop Attack: Tear Drop attacks exploit the reassembly of fragmented IP packets. In the IP header,
one of the options is offset. When the sum of the offset and size of one fragmented packet differ from that of
the next fragmented packet, the packets overlap, and the server attempting to reassemble the packet can
crash. If the NetScreen sees this discrepancy in a fragmented packet, it drops it.
• Filter IP Source Route Option: IP header information has an option to contain routing information that may
specify a different source than the header source. Enable this option to block all IP traffic that employs the
Source Route Option. Source Route Option can allow an attacker to enter a network with a false IP address
and have data sent back to his real address.
• Address Sweep Attack: Similar to a port scan attack, an address sweep attack occurs when an attacker
sends ICMP echo requests (or pings) to different destination addresses hoping that one will reply, thus
uncovering an address to target. The NetScreen device internally logs the number of different addresses
being pinged from one remote source. If a remote host pings 10 addresses in 0.3 seconds, NetScreen flags
this as an address sweep attack, and rejects further ICMP echo requests from that host.
• Block Java/ActiveX/ZIP/EXE Component: Malicious Java or ActiveX components can be hidden in Web
pages. When downloaded, these applets install a Trojan horse10 on your computer. Similarly, Trojan horses
can be hidden in compressed files such as .zip, .gzip, and .tar, and executable (.exe) files. Enabling this
feature blocks all embedded Java and ActiveX applets from Web pages and strips attached .zip, .gzip, .tar
and .exe files from e-mail.
• WinNuke Attack: WinNuke is a pervasive application, whose sole intent is to cause any computer on the
Internet running Windows to crash. WinNuke sends out-of-band (OOB) data—usually to NetBIOS port
139—to a host with an established connection, and introduces a NetBIOS fragment overlap, which causes
many machines to crash. After rebooting, the following message appears, indicating that an attack has
occurred:
10. A Trojan horse is a program that when surreptitiously installed on a computer provides direct control of the computer to an outside party.

An exception OE has occurred at 0028:[address] in VxD MSTCP(01) +

000041AE. This was called from 0028:[address] in VxD NDIS(01) +
00008660. It may be possible to continue normally.
Press any key to attempt to continue.
Press CTRL+ALT+DEL to restart your computer. You will lose any unsaved information in all
applications.
Press any key to continue.
If you enable the WinNuke attack defense mechanism, the NetScreen device scans any incoming Microsoft
NetBIOS Session Service (port139) packets. If the NetScreen device observes that TCP URG code bit is set
on one of those packets, it inspects the offset, removes the fragmented overlap, and corrects the offset as
necessary to prevent an OOB error. The modified packet is then passed, and a WinNuke attack log entry is
created in the Event Alarm log.
• Malicious URL Protection: When you enable Malicious URL Detection, the NetScreen device monitors
each HTTP packet and detects any URL that matches any of several user-defined patterns. The device
automatically drops any such packet.
• Bad IP Option: Triggered when the list of IP options in the IP datagram header is incomplete or malformed.
• Record Route Option: The NetScreen device blocks packets where the IP option is 7 (Record Route). This
option is used to record the route of a packet. A recorded route is composed of a series of internet
addresses, which an outsider can analyze to learn details about your network’s addressing scheme and
topology.
• IP Timestamp Option: The NetScreen device blocks packets where the IP option list includes option 4
(Internet Timestamp).
• Loose Source Route Option: The NetScreen device blocks packets where the IP option is 3 (Loose
Source Routing). This option provides a means for the source of a packet to supply routing information to be
used by the gateways in forwarding the packet to the destination. This option is a loose source route
because the gateway or host IP is allowed to use any route of any number of other intermediate gateways to
reach the next address in the route.
• IP Security Option: This option provides a way for hosts to send security, compartmentation, TCC (closed
user group) parameters, and Handling Restriction Codes compatible with DOD requirements.

• IP Stream Option: The NetScreen device blocks packets where the IP option is 8 (Stream ID). This option
provides a way for the 16-bit SATNET stream identifier to be carried through networks that do not support
the stream concept.
• IP Strict Source Route Option: The NetScreen device blocks packets where the IP option is 9 (Strict
Source Routing). This option provides a means for the source of a packet to supply routing information to be
used by the gateways in forwarding the packet to the destination. This option is a strict source route
because the gateway or host IP must send the datagram directly to the next address in the source route,
and only through the directly connected network indicated in the next address to reach the next gateway or
host specified in the route.
• Unknown Protocol: The NetScreen device drops packets where the protocol field is set to 101 or greater.
These protocol types are reserved and undefined at this time.
• ICMP Flood: An ICMP flood occurs when ICMP pings overload a system with so many echo requests that
the system expends all its resources responding until it can no longer process valid network traffic. When
enabling the ICMP flood protection feature, you can set a threshold that once exceeded invokes the ICMP
flood attack protection feature. (The default threshold value is 1000 packets per second.) If the threshold is
exceeded, the NetScreen device ignores further ICMP echo requests for the remainder of that second.
There are different types of ICMP messages, each with their own purpose.
– ICMP Echo Reply: (Code 0, Echo Reply) A response to a ping. Many firewalls allow ping responses
so that internal people can gain access to external resources. Therefore, they are an effective flooding
technique.
– ICMP Host Unreachable: (Code 3, Destination Unreachable) An error message from a host or router
indicating that a packet you sent did not reach its destination.
– ICMP Source Quench: (Code 4, Source Quench) A response indicating congestion on the Internet.
Somebody may be trying to flood your network with these packets in an attempt to convince your
machines to slow down data transmission.
– ICMP Redirect: (Code 5, Redirect) A message advising to redirect traffic, for example, for network X
directly to gateway G2 as this is a shorter path to the destination. Somebody may be trying to redirect
your default router. This could be from a hacker trying to execute a man-in-the-middle attack against
you by causing you to route through their own machine.

– ICMP Echo Request: (Code 8, Echo Request) These are ping request packets. They are commonly
used. They may indicate hostile intent of someone trying to scan your computer, but they may be part
of the normal network functionality.
– ICMP Time Exceeded for a Datagram: (Code 11, Time Exceeded in Transit) A message indicating
that a packet never reached its target because something timed out.
– ICMP Parameter Problem on Datagram: (Code 12, Parameter Problem on datagram) A message
advising that something unusual is going on, and probably indicates an attack.
– ICMP Timestamp Request: (Code 13, Timestamp Request)
– ICMP Timestamp Reply: (Code 14, Timestamp Reply)
– ICMP Information Request and Information Reply: (Code 15& 16) A host may use this method to
find out the number of the network it is on.
– ICMP Information Reply: (Code 16, Information Request Reply)
– ICMP Address Mask Request: (Code 17, Address Mask Request)
– ICMP Fragment: When the protocol field indicates ICMP packets, and the fragment flag is set to 1 or
an offset is indicated.
– Large ICMP Packet: An ICMP packet with a length greater than 1024.
• TCP Packet Without Flag: TCP packet that does not have any bits set in the flags.
• FIN Bit With No ACK Bit: TCP packet with a FIN set but no ACK set in the flags field.

&KDSWHU,QWHUIDFHV &RQILJXULQJDQLQWHUIDFH
&21),*85,1*$1,17(5)$&(
This section describes how to create, configure, modify, and delete physical interfaces and subinterfaces.
&UHDWLQJDQ,QWHUIDFH
:HE8,
1. Interface >> Physical: To configure a physical interface, click Edit. To create a new subinterface, click New
Sub-i/f.
2. Enter the required information, and then click Save.
&/,
Use the set interface command.
0RGLI\LQJDQ,QWHUIDFH
:HE8,
Interface >> Physical >> Edit (for the interface that you want to modify): Make your modifications, and then
click Save.
&/,
Use the set interface command.

'HOHWLQJDQ,QWHUIDFH
Before you can delete an interface that hosts MIPs, VIPs, or DIP pools, you must first remove any policies using
them. Then you must delete the MIPs, VIPs, and DIP pools.
:HE8,
1. Interface >> Physical >> Remove.
2. A system message prompts you to confirm the removal. Click Yes to delete the interface.
&/,
Use the unset interface command.


&KDSWHU
6\VWHP3DUDPHWHUV

This chapter focusses on the concepts involved in establishing system parameters affecting the following areas of a
NetScreen security appliance:
• “Domain Name System Support” on page 76
• “DHCP” on page 80
• “URL Filtering Configuration” on page 97
• “Downloading/Uploading Settings and Software” on page 99
• “Software Keys” on page 102
• “Authentication” on page 104
• “System Clock” on page 110

&KDSWHU6\VWHP3DUDPHWHUV 'RPDLQ1DPH6\VWHP6XSSRUW
'20$,11$0(6<67(06833257
The NetScreen device incorporates Domain Name System (DNS) support allowing you to use domain names as
well as IP addresses for identifying locations. A DNS server keeps a table of the IP addresses associated with
domain names. Using DNS makes it possible to reference locations by domain name (such as www.netscreen.com)
in addition to using the routable IP address, which for www.netscreen.com is 209.125.148.135. DNS translation is
supported in all the following programs:
• Address Book
• Syslog
• E-mail
• WebTrends®
• Websense®
• LDAP
• SecurID®
• RADIUS
• NetScreen Global-Manager
Before you can use DNS for domain name/address resolution, you must enter the addresses for DNS servers (the
primary and secondary DNS servers) in the NetScreen device.
Note: When enabling the NetScreen device as a Dynamic Host Configuration Protocol (DHCP) server (see “DHCP”
on page 80), you must also enter the IP addresses for DNS servers in the DHCP page on the WebUI or through the
set interface <interf_name> dhcp command in the CLI.

'16/RRNXS
When the NetScreen device connects to the DNS server to resolve a domain name/IP address mapping, it stores
that entry in its DNS status table. Some details involved in a DNS lookup follow:
• In the WebUI, the DNS lookup is performed as soon as you press Apply or OK on a page that supports
DNS. In the CLI, the DNS lookup occurs when you enter a command that supports DNS.
• When a DNS lookup returns multiple entries, the address book accepts all entries. The other programs
listed above accept only the first one.
• The NetScreen device reinstalls all access policies if it finds that anything in the domain name table has
changed when you refresh a lookup using the Refresh button in the WebUI or enter the exec dns refresh
CLI command.
• If a DNS server fails, the NetScreen device looks up everything again.
• If a lookup fails, the NetScreen device removes it from the cache table.
• If the domain name lookup fails when adding addresses to the address book, the NetScreen device displays
an error message and prompts you to choose to continue adding the entry to the address book or not.
The NetScreen device must do a new lookup once a day, which you can schedule the NetScreen device to do at a
specified time:
:HE8,
Configure >> DNS: Enter the following, and then click Apply:
DNS refresh every day at: Select check box and enter time <hh:mm>
&/,
1. set dns host schedule <hh:mm>
2. save

7KH'166WDWXV7DEOH
The DNS status table reports all the domain names looked up, their corresponding IP addresses, whether the
lookup was successful, and when the domain name/IP address was last resolved. The report format looks like the
example below:
Domain Name Corresponding IPs Status Last Resolved

www.yahoo.com 204.71.200.74 Success 8/13/2000 16:45:33
204.71.200.75
204.71.200.67
204.71.200.68
www.hotbot.com 209.185.151.28 Success 8/13/2000 16:45:38
209.185.151.210
216.32.228.18
([DPSOH'HILQLQJ'166HUYHU$GGUHVVHVDQG6FKHGXOLQJ/RRNXSV
To implement DNS functionality, the IP addresses for the DNS servers at 24.1.64.38 and 24.0.0.3 are entered in the
NetScreen device, protecting a single host in a home office. The NetScreen device is scheduled to refresh the DNS
settings stored in its DNS status table everyday at 11:00 P.M.
Secondary DNS Server

24.1.64.38
Trust Zone Untrust Zone Primary DNS Server
24.0.0.3
Internet

:HE8,
Configure >> DNS: Enter the following, and then click Apply:
Primary DNS Server: 24.0.0.3
Secondary DNS Server: 24.1.64.38
DNS refresh every day at: 23:00
&/,
1. set dns host dns1 24.0.0.3
2. set dns host dns2 24.1.64.38
3. set dns host schedule 23:00
4. save

&KDSWHU6\VWHP3DUDPHWHUV '+&3
'+&3
Dynamic Host Configuration Protocol (DHCP) was designed to reduce the demands on network administrators by
automatically assigning the TCP/IP settings for the hosts on a network. Instead of requiring administrators to assign,
configure, track, and change (when necessary) all the TCP/IP settings for every machine on a network, DHCP does
it all automatically. Furthermore, DHCP ensures that duplicate addresses are not used, reassigns unused
addresses, and automatically assigns IP addresses appropriate for the subnet on which a host is connected.
Some NetScreen devices can act as a DHCP client, receiving a dynamically assigned IP address for the Untrust
zone interface from an ISP. Some NetScreen devices can also act as a DHCP server, allocating dynamic IP
addresses to hosts, acting as DHCP clients, on the network in the Trust zone. Some NetScreen devices can also act
as a DHCP relay agent, receiving DHCP information from a DHCP server and relaying that information to hosts in
the Trust zone.
Note: While using DHCP to assign addresses to hosts such as workstations and printers in the Trust zone, you can
still use fixed IP addresses for other machines such as mail servers and WINS servers.
DHCP consists of two components: a protocol for delivering host-specific TCP/IP configuration settings and a
mechanism for allocating IP addresses. When the NetScreen device acts as a DHCP server, it provides the
following TCP/IP settings to each host when that host boots up:
• Default gateway IP address of the router—if there is one—that connects a subnet to the Trust zone
interface.
• The IP addresses of the following servers:
– WINS servers (2):1 A Windows® Internet Naming Service (WINS) server maps a NetBIOS name used
in a Windows NT network environment to an IP address used on an IP-based network.
– NetInfo servers (2): NetInfo® is an Apple® network service used for the distribution of administrative
data within a LAN.
– NetInfo tag (1): The identifying tag used by the Apple NetInfo database.
– DNS servers (3): A Domain Name System (DNS) server maps a uniform resource locator (URL) to an
IP address.
1. The number in parentheses indicates the number of servers supported.

– SMTP server (1): A Simple Mail Transfer Protocol (SMTP) server delivers SMTP messages to a mail
server, such as a POP3 server, which stores the incoming mail.
– POP3 server (1): A Post Office Protocol version 3 (POP3) server stores incoming mail. A POP3 server
must work conjointly with an SMTP server.
– News server (1): A news server receives and stores postings for news groups.
Note: If a DHCP client to which the NetScreen device is passing the above parameters has a specified IP
address, that address overrides all the dynamic information received from the DHCP server.
When acting as a DHCP server, a NetScreen device allocates IP addresses and subnet masks in two modes:
• In Dynamic mode, the NetScreen device, acting as a DHCP server, assigns (or “leases”) an IP address from
an address pool2 to a host, acting as a DHCP client. The IP address is leased for a determined period of
time or until the client relinquishes the address. (To define an unlimited lease period, enter 0.)
• In Reserved mode, the NetScreen device assigns a designated IP address from an address pool exclusively
to a specific client every time that client goes online.
Note: The NetScreen device saves every IP address assigned through DHCP in flash memory.
Consequently, rebooting the NetScreen device does not affect address assignments.
When the master unit in a redundant group functions as a DHCP server, all DHCP configurations and IP address
assignments are maintained by all members in the group. In the event of a failover, the new master unit maintains all
the DHCP assignments. However, if HA communication becomes temporarily disabled, you can again synchronize
the DHCP assignments among the group members by using the following CLI command: exec dhcp server
syncsync.
2. An address pool is a defined range of IP addresses within the same subnet from which the NetScreen device can draw DHCP address assignments. You
can group up to 255 IP addresses in up to 64 address pools.

When acting as a DHCP relay agent, the NetScreen device forwards DHCP requests and assignments between
hosts in the Trust zone and a DHCP server in the Untrust zone. The DHCP messages between the NetScreen
device and the DHCP server can be transmitted in the open or through a VPN tunnel.
Note: When a NetScreen device acts as a DHCP relay agent, no status reports are generated because the remote
DHCP server controls all the IP address allocations.
The following simplified illustration presents the process involved in using a NetScreen device as a DHCP relay
agent. Note that to ensure security, the DHCP messages pass through a VPN tunnel when traveling over the
untrusted network.
Host Trust Relay VPN Tunnel in DHCP

Zone Agent Untrust Zone Server
1
Request Request
2
Assignment Assignment
3 Release Release
Note: When the NetScreen device functions as a DHCP relay agent, its interfaces must be in either Route mode or
Transparent mode.

([DPSOH1HW6FUHHQ'HYLFHDV'+&36HUYHU
Using DHCP, the 172.16.10.0/24 network in the Trust zone is sectioned into three IP address pools. All IP
addresses are assigned dynamically, except for two workstations with reserved IP addresses, and four servers that
have static IP addresses. The interface ethernet1 is bound to the Trust zone, has IP address 172.16.10.1/24, and is
in NAT mode. The domain name is dynamic.com.
DNS Servers
Trust Zone Fixed IPs
ethernet1 172.16.10.240
172.16.10.1/24 172.16.10.241
172.16.10.0/24
Address Pool LAN Address Pool
172-16.10.10 – 172-16.10.210 –
172.16.10.19 172.16.10.219
Address Pool
172-16.10.120 –
Reserved IP 172.16.10.129
172.16.10.11
SMTP and POP3 Servers
MAC: 12:34:ab:cd:56:78
Fixed IPs
172.16.10.25 and 172.16.10.10
Reserved IP
172.16.10.112
MAC: ab:cd:12:34:ef:gh
:HE8,
1. Address >> Address >> New Address: Enter the following, and then click OK:
Address Name: DNS#1
Netmask: 255.255.255.255
Comment: Primary DNS Server
Zone: Trust

Address Name: DNS#2
Netmask: 255.255.255.255
Comment: Secondary DNS Server
Zone: Trust
Address Name: SMTP
Netmask: 255.255.255.255
Comment: SMTP Server
Zone: Trust
Address Name: POP3
Netmask: 255.255.255.255
Comment: POP3 Server
Zone: Trust
5. Interface >> Physical >> DHCP (for ethernet1): Select DHCP Server, and then click Apply.

6. Interface >> Physical >> DHCP (for ethernet1) >> Options: Enter the following, and then click OK:
Lease: Unlimited (select)
WINS#1: 0.0.0.0
WINS#2: 0.0.0.0
DNS#1: 172.16.10.240
DNS#2: 172.16.10.241
DNS#3: 0.0.0.0
SMTP: 172.16.10.25
POP3: 172.16.10.110
NEWS: 0.0.0.0
NetInfo Server #1: 0.0.0.0
NetInfo Server #2: 0.0.0.0
NetInfo Tag: (leave field empty)
Domain Name: dynamic.com
7. Interface >> Physical >> DHCP (for ethernet1) >> New Address: Enter the following, and then click OK:
Dynamic: (select)
IP Address Start: 172.16.10.10
IP Address End: 172.16.10.19
Dynamic: (select)

Dynamic: (select)
Reserved: (select)
IP Address: 172.16.10.21
Ethernet Address: 1234 abcd 5678
Reserved: (select)
IP Address: 172.16.10.112
Ethernet Address: abcd 1234 efgh
&/,
1. set address trust dns1 172.16.10.240 255.255.255.255 “primary dns server”
2. set address trust dns2 172.16.10.241 255.255.255.255 “secondary dns server”
3. set address trust snmp 172.16.10.25 255.255.255.255 “snmp server”
4. set address trust pop3 172.16.10.110 255.255.255.255 “pop3 server”
5. set interface ethernet1 dhcp server option domainname dynamic.com
6. set interface ethernet1 dhcp server option lease 0
7. set interface ethernet1 dhcp server option netmask 255.255.255.0
8. set interface ethernet1 dhcp server option dns1 172.16.10.240
9. set interface ethernet1 dhcp server option dns2 172.16.10.241
10. set interface ethernet1 dhcp server option smtp 172.16.10.25
11. set interface ethernet1 dhcp server option pop3 172.16.10.110

12. set interface ethernet1 dhcp server ip 172.16.10.10 to 172.16.10.19

15. set interface ethernet1 dhcp server ip 172.16.10.11 mac 1234abcd5678
16. set interface ethernet1 dhcp server ip 172.16.10.112 mac abcd1234efgh
17. set interface ethernet1 dhcp server service
18. save
([DPSOH1HW6FUHHQ'HYLFHDV'+&35HOD\$JHQW
In this example, a NetScreen device receives its DHCP information from a DHCP server at 194.2.9.10 and relays it
to hosts in the Trust zone. The hosts receive IP addresses from an IP pool defined on the DHCP server. The
address range is 10.10.10.2—10.10.10.254. The DHCP messages pass through a VPN tunnel between the local
NetScreen device and the DHCP server, located behind a second NetScreen device. The interface ethernet1 is
bound to the Trust zone, has the IP address 10.10.10.1/24, and is in Route mode. The interface ethernet3 is bound
to the Untrust zone and has the IP address 201.10.10.1/24.
Trust Zone Untrust Zone DHCP

ethernet1 ethernet3 Server
180.10.10.1/24 201.10.10.1/24 194.2.9.10
Internet
Local NetScreen Device Remote NetScreen Device
VPN Tunnel
Router
201.10.10.2
IP Pool
180.10.10.2 –
180.10.10.254

:HE8,
IP Address: 180.10.10.1
Netmask: 255.255.255.0
Zone: Trust
Interface Mode: Route
2. Interface >> Physical >> Edit (for ethernet3): Enter the following, and then click Save and Reset:
IP Address: 201.10.10.1
Netmask: 255.255.255.0
Zone: Untrust
Netmask: 0.0.0.0
Interface: ethernet3(untrust-vr)
Address Name: DHCP Server
Netmask: 255.255.255.255
Zone: Untrust
3. Setting a route to the external router designated as the default gateway is essential for both outbound VPN and network traffic. In this example, the NetScreen
device sends encapsulated VPN traffic to this router as the first hop along its route to the remote NetScreen device. In the illustration for this example, the
concept is presented by depicting the tunnel passing through the router.

5. VPN >> Gateway(P1) >> New Remote Tunnel Gateway: Enter the following, and then click OK:
Name: dhcp server
Static IP Address: 194.2.9.1
Main (ID Protection): (select)
Outgoing Interface: ethernet3
Phase 1 Proposal: rsa-g2-3des-sha
6. VPN >> AutoKey (P2) >> New AutoKey IKE Entry: Enter the following, and then click OK:
Name: to_dhcp
Remote Gateway Tunnel: dhcp
Phase 2 Proposal: g2-esp-3des-sha
Bind to: None
7. Interface >> Physical >> DHCP (for ethernet1): Enter the following, and then click Apply:
DHCP Relay Agent: (select)
Server: 194.2.9.10
Use Trust Interface as Source IP for VPN: (select)
8. Policy >> Policy (From Zone Trust, To Zone Untrust) >> New Policy: Enter the following, and then click OK:
Source Address: Any
Destination Address: DHCP Server
Service: DHCP-Relay
Action: Tunnel
VPN Tunnel: to_dhcp
Create matching VPN policy: (select)

&/,
3. set interface ethernet1 route
6. set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3 gateway 201.10.10.2
7. set address untrust dhcp_server 194.2.9.10/32
8. set ike gateway “dhcp server” ip 194.2.9.1 main outgoing-interface ethernet3 proposal rsa-g2-3des-sha
9. set vpn to_dhcp gateway “dhcp server” proposal g2-esp-3des-sha
10. set interface ethernet1 dhcp relay server-name 194.2.9.10
11. set interface ethernet1 dhcp relay vpn
12. set policy from trust to untrust any dhcp_server dhcp-relay tunnel vpn to_dhcp
13. set policy from untrust to trust dhcp_server any dhcp-relay tunnel vpn to_dhcp
14. save

([DPSOH1HW6FUHHQ'HYLFHDV'+&3&OLHQW
The Untrust zone interface of the NetScreen device has a dynamically assigned IP address. When the NetScreen
device requests its IP address from its ISP, it receives its IP address, subnet mask, gateway IP address, and the
length of its lease for the address. The IP address of the DHCP server is 222.33.44.55.
Trust Zone
1. IP address requested for

ethernet3 (Untrust zone)
2. IP address assigned
ISP
(DHCP
Server)
Internet
Untrust Zone
Note: Before setting up a site for DHCP service, you must have the following:
• Digital subscriber line (DSL) modem and line
• Account with ISP

:HE8,
Interface >> Physical >> Edit (for ethernet3): Select Obtain IP using DHCP, and then click Save and
Reset4 .
&/,
1. set interface ethernet3 dhcp
2. set interface ethernet3 dhcp settings server 222.33.44.55
3. save
4. You cannot specify the IP address of the DHCP server through the WebUI; however, you can do so through the CLI.

&KDSWHU6\VWHP3DUDPHWHUV 333R(
3332(
Point-to-Point Protocol over Ethernet (PPPoE) is a protocol that allows the members of an Ethernet LAN to make
individual PPP connections with their ISP by encapsulating the IP packet within the PPP payload, which is
encapsulated inside the PPPoE payload.
Some NetScreen devices support PPPoE, allowing them to operate compatibly on DSL, Ethernet Direct, and cable
networks run by ISPs using PPPoE for their clients’ Internet access.
([DPSOH6HWWLQJ8S333R(
The following example illustrates how to define the untrusted interface of a NetScreen device for PPPoE
connections, and how to initiate PPPoE service.
In this example, the NetScreen device receives a dynamically assigned IP address for its Untrust zone interface
(ethernet3) from the ISP, and the NetScreen device also dynamically assigns IP addresses for the three hosts in its
Trust zone. In this case, the NetScreen device acts both as a PPPoE client and a DHCP server. The Trust zone
interface must be in either NAT mode or Route mode. In this example, it is in NAT mode.
NetScreen DSL
Device Modem
ISP
DSLAM
Hub AC Internet
DSL
Line
Primary DNS Server

Secondary DNS Server

Before setting up the site in this example for PPPoE service, you must have the following:
• Digital subscriber line (DSL) modem and line
• Account with ISP
• User name and password (obtained from the ISP)
:HE8,
IP Address: 172.16.30.10
Netmask: 255.255.255.0
Interface Mode: NAT
2. Interface >> Physical >> Edit (for ethernet3): Enter the following:
Obtain IP using PPPoE (select)
User Name: <name>
Password: <password>
3. Interface >> Physical >> Edit (for ethernet3): To test your PPPoE connection, click Connect.
Note: When you initiate a PPPoE connection, your ISP automatically provides the IP addresses for the
untrusted interface and the IP addresses for the Domain Name Service (DNS) servers.
If you use a static IP address for the untrusted interface, you must obtain the DNS servers’ IP addresses
and then manually enter them on the NetScreen-5XP and on the trusted hosts.
4. Interface >> Physical >> DHCP (for ethernet1): Select DHCP Server, and then click Apply.

5. Interface >> Physical >> DHCP (for ethernet1) >> Options: Select the following, and then click OK:
Lease: 1 hour
Gateway: 0.0.0.0
Netmask: 0.0.0.0
DNS#1: 0.0.0.0
DNS#2: 0.0.0.0
Domain Name: (leave blank)
Dynamic: (select)
7. Turn off the power to the DSL modem, the NetScreen device, and the three workstations.
8. Turn on the DSL modem.
9. Turn on the NetScreen device.
The NetScreen device makes a PPPoE connection to the ISP and, through the ISP, gets the IP addresses
for the DNS servers.
10. Turn on the workstations.
The workstations automatically receive the IP addresses for the DNS servers. They get an IP address for
themselves when they attempt a TCP/IP connection.
Note: When you use DHCP to assign IP addresses to hosts on the trusted side, the NetScreen-5XP
automatically forwards the IP addresses of the DNS servers that it receives from the ISP to the trusted
hosts.
If the IP addresses for the hosts are not dynamically assigned through DHCP, you must manually enter the
IP addresses for the DNS servers on each host.
Every TCP/IP connection that a host in the Trust zone makes to the Untrust zone automatically goes
through the PPPoE encapsulation process.

&/,
4. set pppoe interface ethernet3
5. set pppoe username <name> password <password>
6. To test your PPPoE connection:
exec pppoe connect
get pppoe
7. set interface ethernet1 dhcp server service
9. set interface ethernet1 dhcp server option lease 60
10. save
11. Turn off the power to the DSL modem, the NetScreen device, and the three workstations.
12. Turn on the DSL modem.
13. Turn on the NetScreen device.
14. Turn on the workstations.
The workstations automatically receive the IP addresses for the DNS servers. They get an IP address for
themselves when they attempt a TCP/IP connection.
Every TCP/IP connection that a host in the Trust zone makes to the Untrust zone automatically goes
through the PPPoE encapsulation process.

&KDSWHU6\VWHP3DUDPHWHUV 85/)LOWHULQJ&RQILJXUDWLRQ
85/),/7(5,1*&21),*85$7,21
NetScreen supports URL filtering using the Websense® Enterprise Engine (version 4.x and earlier), which enables
you to block or permit access to different sites based on their URLs, domain names, and IP addresses. With the
Websense API built directly into the NetScreen firewall, the NetScreen device creates a direct link to a Websense
URL-blocking server, running on either Microsoft Windows NT 4.0 or Solaris 2.5 or 2.6. Microsoft Windows 2000 can
also support Websense 4.2.
Using Websense manager, the NetScreen administrator can do the following:
• Alter the URL-blocking database to block or allow access to any sites they choose
• Schedule different URL filtering profiles for different times of the day
• Download Websense Reporter logs of blocked or viewed URLs
Note: For additional information about Websense, visit www.websense.com.
To specify URL filtering options:
:HE8,
Configure >> URL Filtering: Enter the following information, and then click Apply:
Enable URL Filtering via Websense Server: (select)
Websense Server Name: The IP address of the computer running the Websense
server.
Websense Server Port: The default port for Websense is 15868. If you have
changed the default port on the Websense server you must also change it on the
NetScreen device. Please see your Websense documentation for full details.
Communication Timeout: The time interval, in seconds, that the NetScreen device
waits for a response from the Websense filter. If Websense does not respond
within the time interval, the NetScreen device either blocks the request or allows
it, as you choose (see below).

&KDSWHU6\VWHP3DUDPHWHUV 85/)LOWHULQJ&RQILJXUDWLRQ
Current Server Status: The NetScreen device reports the status of the Websense
server. To update the status report, click the Server Status icon.
If connectivity to the Websense server is lost, Block all HTTP requests/Permit all
HTTP requests: If the NetScreen device loses contact with the Websense server,
you can specify whether to block or permit all HTTP requests.
Blocked URL Message Type: The source of the message the user receives when
Websense blocks a site. If you select Websense, the Websense server sends the
message. When you select NetScreen, the NetScreen device sends the
message, which you entered in the NetScreen Blocked URL Message field.
Note: If you select NetScreen, some of the functionality that Websense provides, such as redirection, are
suppressed.
NetScreen Blocked URL Message: This is the message the NetScreen device
returns to the user after blocking a site. You can use the message sent from the
Websense server, or create a message (up to 220 characters) to be sent from the
NetScreen device.
&/,
1. set url config { enable | disable }
2. set url message <string>
3. set url msg-type {0 | 1}
4. set url server { <domain_name> | <a.b.c.d> } <port_number> <timeout_value>
5. set url fail-mode <fail-allow | fail-block>
Note: See the NetScreen CLI Reference Guide for an explanation of the set url arguments, plus examples
and related commands.

&KDSWHU6\VWHP3DUDPHWHUV 'RZQORDGLQJ8SORDGLQJ6HWWLQJVDQG6RIWZDUH
'2:1/2$',1*83/2$',1*6(77,1*6$1'62)7:$5(
You can upload and download configuration settings and software to and from a NetScreen device. The kinds of
location that you upload from and download to depend on whether you use the WebUI or the CLI to perform the
operation. Using the WebUI and Web browser support, you can upload and download configuration settings and
upload ScreenOS software from any local directory. Through the CLI, you can upload and download settings and
software from and to a TFTP server or PC card.
6DYLQJDQG,PSRUWLQJ6HWWLQJV
It is good practice to backup your settings after every significant change you make. Through the WebUI, you can
download the configuration to any local directory as a backup precaution. With some NetScreen devices, you can
use the CLI to download the configuration to a TFTP server or PC card. Should you need the saved backup
configuration, you can then simply upload it to the NetScreen device.
The ability to download and upload a configuration also provides the means for mass distribution of configuration
templates.
To download a configuration:
:HE8,
1. Admin >> Settings: Click Save Current Configuration, select Save this file to disk, and then click OK.
2. Browse to the location where you want to keep the configuration file, and then click Save.
&/,
save config to { tftp <ip_addr> | slot } <filename>
Note: On the NetScreen-1000, you must specify slot 1 or slot 2.

To upload a configuration:
:HE8,
Admin >> Settings: Specify the file name and location, and then click Apply:
In the Load New Configuration Script field, type the configuration file location.
Or
Click Browse and navigate to the file location, select the file, and then click
Open.
&/,
save config from { tftp <ip_addr>| slot } <filename> to flash
Note: On the NetScreen-1000, you must specify slot 1 or slot 2.

8SORDGLQJDQG'RZQORDGLQJ6RIWZDUH
When the NetScreen ScreenOS operating system is updated, a customer can purchase and upload it to their
NetScreen device. With some NetScreen devices, you can use the WebUI to upload software from a local directory.
Through the CLI, you can upload the software from a TFTP server or PC card, and you can download software to a
TFTP server.
Note: After the software is upgraded, the NetScreen device reboots. This process takes a few minutes.
:HE8,
Configure >> General: Specify the file name and location, and then click Apply:
Software Update: Type the software file location in the entry field.
Or
Click Browse and navigate to the file location, select the file, and then click
Open.
&/,
save software from { tftp <ip_addr> | slot } <filename> to flash
Note: On some NetScreen devices, you must specify slot 1 or slot 2.
Through the CLI, you can also download software to a TFTP server, using the save command:
save software from flash to tftp <ip_addr> <filename>

&KDSWHU6\VWHP3DUDPHWHUV 6RIWZDUH.H\V
62)7:$5(.(<6
The software key feature allows you to expand the capabilities of your NetScreen device without having to upgrade
to a different device or system image. You can purchase a key that unlocks specified features already loaded in the
software, such as the following:
• VPN tunnels
• Zones
• User capacity
• Virtual systems
• Virtual routers
• High Availability
Each NetScreen device ships with a standard set of features enabled and might support the activation of optional
features or the increased capacity of existing features. For information regarding which features are currently
available for upgrading, refer to the latest marketing literature from NetScreen.
([DPSOH([SDQGLQJ8VHU&DSDFLW\
A small company using a single NetScreen device with a license for 10 users has grown to the point where it now
needs an unrestricted user license. The NetScreen administrator expands the capabilities of the device by obtaining
a software key for an unrestricted number of users.
1. Contact the value-added reseller (VAR) who sold you the NetScreen device or contact NetScreen
Technologies directly.
2. Provide the digit serial number of your device and state the feature option you want—an unrestricted user
license, in this example.
A combination of the serial number, the feature keyword (vpn, capacity, ha, vsys), and the feature option
keyword (<number> or “unlimited” tunnels, users, users) is used to generate the software key (for example,
7e58e876ca050192). The key is then sent to you via e-mail.
3. Enter the key through either the WebUI or CLI:

&KDSWHU6\VWHP3DUDPHWHUV 6RIWZDUH.H\V
:HE8,
Configure >> Software Key: Specify the path and file name, and then click Apply and Reset 5:
License File Update: Type the software key file location.
Or
Click Browse and navigate to the software key file location, select the file, and
then click Open.
&/,
1. exec software-key { capacity | ha | vpn | vsys } <key_value>
2. reset
5. Through the CLI, you can schedule the NetScreen device to reset at a time that is convenient for maintaining uninterrupted network operation: set timer
<mm|dd|yyyy> <hh:mm> action reset.

&KDSWHU6\VWHP3DUDPHWHUV $XWKHQWLFDWLRQ
$87+(17,&$7,21
To guard against unwanted access, you can configure your NetScreen device to use any of several authentication
services.
,GOH7LPH2XW6HWWLQJ
To specify the amount of idle time (in minutes) that must elapse before the NetScreen device automatically ends a
session, select the Enable New Connection Idle Timeout check box. In the entry field, enter a value from 0 to 255
minutes. A value of zero specifies that the NetScreen device never terminates a session. The recommended default
period is ten minutes, because users may find shorter time intervals bothersome, while longer intervals might leave
the network open to unwanted access.
The following example enables idle timeout, and sets the timeout interval to 10 seconds.
:HE8,
Configure >> Authen: Enter the following, and then click Apply:
Enable New Connection Idle Timeout: select.
Enable New Connection Idle Timeout entry field: 10
&/,
set auth timeout 10

%XLOWLQ8VHU'DWDEDVH
Select the Built-in User Database option if your authentication needs do not require external RADIUS, SecurID, or
LDAP services. The built-in user database can support up to 1,500 user entries, which you create in the Users
section.
([DPSOH$XWKHQWLFDWLRQYLD%XLOWLQ8VHU'DWDEDVH
The following example configures the NetScreen device to use the built-in database.
:HE8,
Built-in User Database: (select)
&/,
set auth type 0
5HPRWH$XWKHQWLFDWLRQ'LDO,Q8VHU6HUYLFH5$',86
Select the Remote Authentication Dial-In User Service (RADIUS) option to authenticate users from a RADIUS
server. To configure the NetScreen device for RADIUS, you must specify the IP address of the RADIUS server and
define a shared secret. The shared secret is a password the RADIUS server uses to generate a key to encrypt traffic
between the devices. Many RADIUS servers can support tens of thousands of users.
The information needed to configure your NetScreen device for RADIUS are as follows.
• Server Name The IP address of the RADIUS server.
• Shared Secret The password shared between the NetScreen device and the RADIUS server. The devices
use this password to encrypt the transactions they exchange.

([DPSOH$XWKHQWLFDWLRQYLD5$',86
The following example configures the NetScreen device to use a RADIUS server, specifies a RADIUS server named
NY_RAD_Server, and a shared secret of A56htYY97kl.
:HE8,
RADIUS Server: (select).
Server Name: NY_RAD_Server
Shared Secret: A56htYY97kl
&/,
1. set auth type 1
2. set auth server-name NY_RAD_Server
3. set auth secret A56htYY97kl
6HFXU,'6HUYHU
Select the SecurID Server option to authenticate users with a Security Dynamics SecurID (ACE) server. Users
prove their identity using an access card provided by Security Dynamics Incorporated. The user enters a number
along with a personal ID (PIN) number for authentication.
The information needed to configure your NetScreen device for SecurID are as follows.
• Master Server Name The IP address of the primary SecurID server.
• Slave Server Name The IP address of the secondary (backup) SecurID server.
• Authentication Port The port number on the SecurID server to which the NetScreen device sends
authentication requests. The default port number is 5500.

• Encryption Type The algorithm used for encrypting communication between the NetScreen device and the
SecurID server.
• Client Retries The number of times that the NetScreen device tries to establish communication with the
SecurID server before aborting the attempt.
• Client Timeout The length of idle time in minutes that the NetScreen device waits before terminating
authentication status.
• Use Duress An option that prevents or allows use of a different PIN number. When this option is enabled,
and a user enters an incorrect PIN number, the NetScreen device sends a signal to the SecurID server,
indicating that the user is performing the login against his or her will; that is, while under duress. The
SecurID server permits access that one time, and then it denies any further login attempts by that user until
he or she contacts the SecurID administrator. Duress mode is available only if the SecurID Server supports
this option.
([DPSOH$XWKHQWLFDWLRQYLD6HFXU,'
The following example configures the NetScreen device to use a SecurID server at IP address 192.168.10.10, with
a slave server at IP address 192.168.20.10. The authentication port is 5500. The NetScreen device and the SecurID
server protect the authentication information using DES encryption. There are three allowable retries, and a timeout
value of 3 minutes. The Use Duress setting is enabled.
:HE8,
SecurID Server: (select)
Master Server Name: 192.168.10.10
Slave Server Name: 192.168.20.10
Authentication Port: 5500
Encryption Type: DES
Client Retries: 3

Client Timeout: 3
User Duress: Yes
&/,
1. set auth type 2
2. set auth securid master 192.168.10.10
3. set auth securid slave 192.168.20.10
4. set auth securid auth-port 5500
5. set auth securid encr 1
6. set auth securid retries 3
7. set auth securid timeout 3
8. set auth securid duress 1
/'$36HUYHU
Select this option to allow the NetScreen device to link to a Lightweight Directory Access Protocol (LDAP) server.
This server uses the LDAP hierarchical syntax to identify each user uniquely.
• LDAP Server Name/Port The IP address and port number of the Lightweight Directory Access Protocol
(LDAP) server.
• Common Name Identifier The identifier used by the LDAP server to identify the Distinguished Name. For
example, an entry of “uid” means “user ID.”
• Distinguished Name (dn) The path used by the LDAP server before using the Common Name Identifier to
search for a specific entry. (For example, c=us, o=netscreen, where c stands for “country”, and o for
“organization”.)

([DPSOH$XWKHQWLFDWLRQYLD/'$3
The following example configures the NetScreen device to use an LDAP server at IP address 172.16.20.10. The
LDAP common name identifier is cn, and the Distinguished Name is o=netscreen.com;ou=marketing.com
:HE8,
LDAP Server: (select)
LDAP Server Name/Port: 172.16.20.10, 389
Common Name Identifier: cn
Distinguished Name: o=netscreen.com;ou=marketing
&/,
1. set auth type 3
2. set auth server-name NY_RAD_Server
3. set auth ldap server-name 172.16.20.10 389 o=netscreen.com;ou=marketing cn
Note: If an access policy requiring authentication applies to a subnet of IP addresses, authentication is

required for each IP address.
If one of host supports multiple user accounts (as with a Unix host running Telnet), then after the first user
authenticates, all other users from that host can pass traffic through the device without authentication.

&KDSWHU6\VWHP3DUDPHWHUV 6\VWHP&ORFN
6<67(0&/2&.
Each NetScreen device has a system clock you can set to your local time zone. You can use the WebUI or the CLI
to configure the current clock settings.
Your NetScreen device uses Network Time Protocol (NTP) to synchronize its system clock with that of an NTP
server. Thus, the device can synchronize its system clock through the Internet at specified intervals.
You set the time zone by specifying the number of hours, added to the local time, needed to equal GMT. For
example, if your time zone is Pacific Standard Time, adding 8 hours equals GMT.
([DPSOH6HWWLQJWKH6\VWHP&/RFN
In the following example you set the system clock to Pacific Standard Time, and configure the NetScreen device to
update the clock at five-minute intervals from a server at IP address 172.168.10.10.
:HE8,
Admin >> Settings: Enter the following, and then click Apply:
GMT Time Zone: (hours) 8, (minutes) 0
Server: 172.168.10.10
Update system clock every: 5
&/,
1. set clock ntp
2. set ntp timezone 8 0
3. set ntp server 172.168.10.10
4. set ntp interval 5

&KDSWHU
$GPLQLVWUDWLRQ

This chapter describes various management methods and tools, ways to secure administrative traffic, and the
administrative privilege levels that you can assign to admin users:
• “Management Methods and Tools” on page 112
• “Levels of Administration” on page 123
• “Securing Administrative Traffic” on page 126

&KDSWHU$GPLQLVWUDWLRQ 0DQDJHPHQW0HWKRGVDQG7RROV
0$1$*(0(170(7+2'6$1'722/6
The management methods and the tools with which to apply each method are presented in the following sections:
• “Web User Interface” on page 112
– HTTP
– HTTPS using Secure Sockets Layer (SSL)
• “Command Line Interface” on page 117
– Telnet
– SSH® Secure Shell™
– Serial console
:HE8VHU,QWHUIDFH
For administrative ease and convenience, you can use the Web user interface (WebUI). NetScreen devices use
Web technology that provides a Web-server interface to configure and manage the software.

Web User Interface Information
Menu Column
Central Display
To use the WebUI, you must have the following:

• Netscape® Communicator® (version 4.5 or later) or Microsoft® Internet Explorer (version 5 or later)
• TCP/IP network connection to the NetScreen device
Note: For a complete description of WebUI, refer to the NetScreen WebUI Reference Guide.

+773
With a standard Web browser you can access, monitor, and control your network security configurations remotely
using the Hypertext Transfer Protocol (HTTP).
You can secure HTTP traffic by either encapsulating it in a virtual private network (VPN) tunnel or through the
Secure Sockets Layer (SSL) protocol. You can also secure it by completely separating management traffic from
network user traffic. With some NetScreen device models, you can run all administrative traffic through the MGT
interface, or devote an interface (such as the DMZ) entirely to administrative traffic.
Note: For more information, see “Virtual Private Networks” on page 136, “Secure Sockets Layer” (below), and
“Manage IP” on page 132.

6HFXUH6RFNHWV/D\HU
Secure Sockets Layer (SSL) is a set of protocols that can provide a secure connection between a Web client and
server communicating over a TCP/IP network. NetScreen ScreenOS provides:
• Web SSL support
• SSL version 3 compatibility
• Netscape Navigator 4.7x and Internet Explorer 5.x compatibility1
• Public Key Infrastructure (PKI) key management integration (see “Public Key Cryptography” on page 285.)
SSL is not a single protocol, but consists of the SSL Handshake Protocol (SSLHP), which allows the server and
client to authenticate each other and negotiate an encryption method, and the SSL Record Protocol (SSLRP), which
provides basic security services to higher-level protocols such as HTTP. These two protocols operate at the
following two layers in the Open Systems Interconnection (OSI) model:
• SSLHP at the application layer (layer 7)
• SSLRP at the presentation layer (layer 6)
Independent of application protocol, SSL uses TCP to provide secure service. SSL uses certificates to authenticate
first the server or both the client and the server, and then encrypt the traffic sent during the session. Before using
SSL, you must first create a public/private key pair and then load a certificate. Because SSL is integrated with PKI
key/certificate management, you can select the SSL certificate from one of the certificates in the certificate list. You
can also use the same certificate for an IPSec VPN.
Note: For information on obtaining certificates, see “Certificates and CRLs” on page 291.
1. Check your Web browser to see how strong the ciphers can be and which ones your browser supports. (Both the NetScreen device and your Web browser
must support the same kind and size of ciphers you use for SSL.) In Internet Explorer 5x, click Help, About Internet Explorer, and read “Cipher Strength.”
To obtain the advanced security package, click the Update Information link. In Netscape Navigator, click Help, About Communicator, and read the section
about RSA®. To change the SSL configuration settings, click Security Info, Navigator, Configure SSL v3.

NetScreen supports the following encryption algorithms for SSL:

• RC4 with 40-bit and 56-bit keys
• DES: Data Encryption Standard
• 3DES: Triple DES
NetScreen supports the same authentication algorithms for SSL as for VPNs—Message Digest version 5 (MD5) and
Secure Hash Algorithm version 1 (SHA-1). The RC4 algorithms are always paired with MD5; DES and 3DES with
SHA-1.
The basic steps for setting up SSL are as follows:
1. Obtain a certificate2.
For details on requesting and loading a certificate, see “Certificates and CRLs” on page 291.
2. Enable SSL management:
Admin >> Web: Enter the following, and then click OK:
Certificate: Select the certificate you intend to use from the drop-down list.
Cipher: Select the cipher you intend to use from the drop-down list.
3. Configure the interface through which you manage the NetScreen device to permit SSL management:
Interface >> Edit: Enable the SSL management service checkbox, and then click Save.
4. Connect to the NetScreen device via the SSL port:
When you type the IP address for managing the NetScreen device in your browser’s URL field, change
“http” to “https”, and follow the IP address with a colon and the HTTPS (SSL) port number (for example,
https://123.45.67.89:1443).
2. Be sure to specify a bit length that your Web browser also supports.

&RPPDQG/LQH,QWHUIDFH
Advanced administrators can attain finer control by using the command line interface (CLI). To configure a
NetScreen device with the CLI, you can use any software that emulates a VT100 terminal. With a terminal emulator,
™ ®
you can configure the NetScreen device using a console from any Windows, UNIX , or Macintosh operating
system. For remote administration through the CLI, you can use Telnet or Secure Command Shell (SCS). With a
direct connection through the console port, you can use Hyperterminal®.
Note: For a complete listing of the CLI commands for the NetScreen devices, refer to the NetScreen CLI Reference
Guide.
7HOQHW
Telnet is a login and terminal emulation protocol that uses a client/server relationship to connect to and remotely
configure network devices over a TCP/IP network. The administrator launches a Telnet client program on the
administration workstation and creates a connection with the Telnet server program on the NetScreen device. After
logging in, the administrator can issue CLI commands, which are sent to the Telnet program on the NetScreen
device, effectively configuring the device as if operating through a direct connection. Using Telnet to manage
NetScreen devices requires the following:
• Telnet software on the administrative workstation
• An Ethernet connection to the NetScreen device
You can secure Telnet traffic by encapsulating it in a virtual private network (VPN) tunnel or by completely
separating it from network user traffic. Depending upon your NetScreen device model, you can run all administrative
traffic through the MGT interface or devote an interface such as the DMZ entirely to administrative traffic.
Note: For more information, see “Virtual Private Networks” on page 136, “Secure Sockets Layer” on page 115, and
“Manage IP” on page 132.

6HFXUH6KHOO
You can use secure shell (SSH™) for secure CLI access over insecure channels. On UNIX platforms and on other
hosts, SSH allows you to open a remote command shell securely, execute commands, and copy files to or from the
remote device. Secure Command Shell (SCS) is a SSH-compatible agent in the NetScreen device that allows you to
remotely manage your NetScreen device without establishing a VPN.
The built-in SCS server on the NetScreen device allows the SSH client, installed on the administrator’s workstation,
to open a secure connection to the NetScreen device console, which makes secure configuration and management
possible.
SSH Client SCS server

(Remote)
Encrypted Administrative
Traffic
Internet
Administrator’s ScreenOS
Workstation

You can connect to a NetScreen device with SSH in two ways.

• Through a user name and password authentication
This is the method commonly used by network administrators, security administrators, and other users who
need to access, configure, or manage the NetScreen device. (The SSH client sends the user name and
password to the NetScreen device. In response to an attempt to open SSH, the NetScreen device presents
a prompt requiring the user name and password.)
• Using SCS Public Key Authentication (PKA)
This is the method commonly used by clients such as intrusion detection devices or organizations which use
application programs or script routines to access the NetScreen device. SCS Public Key makes this
possible by allowing the application or a script to initiate SSH without entering a password, using
public/private key pairs for authentication.
The process for initiating SCS PKA is as follows.
1. The client host generates a public and private key pair.
2. From the client host, the user manually logs into the NetScreen device as admin.
3. Using the CLI, WebUI or TFTP, the admin user uploads the public key to the NetScreen device.
4. Thereafter, the client can connect to the NetScreen device automatically.
Because the NetScreen device can have 4 public keys per admin account, there can be only 4 corresponding
private keys per account.
Note: It is possible to keep and use a single private key on multiple clients, but be sure to keep it protected from
potential intruders.
To set up SCS, complete the following steps using the Command Line Interface (CLI)
1. From the public key file for your host, obtain the key length, exponent, and modulus.
2. Enable SCS PKA for the current admin user, specifying the key length, exponent, and modulus, as with the
following example.

ns-> set scs pka-rsa key 512 65537 9687527248844895807195605409339193503321

3724615582796813757422715643970626128793365599992658289801116115376527150778370890191
19296718115311887359071551679
This command binds the specified public key to the admin user’s login name.
The command must not exceed 256 characters in length. If the modulus value requires the command to be
of greater length, use the set command instead. The following example uses key length, exponent, and
modulus values from a public key file named ourkeyfile.pub.
ns-> set scs pka-rsa tftp file-name ourkeyfile.pub ip-addr 172.16.10.10
3. (Optional) Display the list of SSH public keys bound to the current admin user.
ns-> get scs pka-rsa
4. (Optional) Display the list of SSH public keys bound to the login name of the specified user (mkt_admin).
ns-> get scs pka-rsa username mkt_admin
Note: Only the root administrator can execute this command.
6HULDO&RQVROH
You can manage a NetScreen device through a direct serial connection from the administrator’s workstation to the
NetScreen device via the Console port. Although a direct connection is not always possible, this is surely the
most secure method for managing the device provided that the location around the NetScreen device is
secure.
Depending on your NetScreen device model, creating a serial connection might require any of the following items:
• A DB-9 female to DB-25 male straight-through serial cable
• A DB-9 female to DB-9 male straight-through serial cable
• A DB-9 female to MiniDIN-8 male serial cable
You will also need Hyperterminal software (or another kind of VT100 terminal emulator) on the management
workstation, with the Hyperterminal port settings configured as follows:

– Serial communications 9600 bps

– 8 bit, no parity
– 1 stop bit
– no flow control
Note: For more details on using Hyperterminal, see the “Getting Started” chapter in the NetScreen CLI
Reference Guide or one of the installer’s guides.
$GPLQLVWUDWLYH,QWHUIDFH2SWLRQV
You can configure a NetScreen device to allow administration of the device through one or more interfaces. For
example, you might have local management access the device through the trusted interface and remote
management through the untrusted interface. With a NetScreen model that has a DMZ interface, you might use that
interface exclusively for administration, separating management traffic completely from network user traffic for the
trusted and untrusted interfaces.
To enable an interface to allow various methods of administration to traverse it through the WebUI and the CLI, do
the following:
:HE8,
Interface >> Physical >> Edit (for the interface you want to edit): Select the following management service
options, and then click Save 3 :
WebUI: Selecting this option allows the interface to receive HTTP traffic to
manage the NetScreen device via the Web user interface (WebUI).
3. Through the CLI, you can schedule the NetScreen device to reset at a time that is convenient for maintaining uninterrupted network operation: set timer
<mm|dd|yyyy> <hh:mm> action reset.

SCS: You can administer the NetScreen device from an Ethernet connection or a
dial-in modem using Secure Command Shell (SCS), which is SSH-compatible.
You must have a SSH client that is compatible with Version 1.5 of the SSH
protocol. These clients are available for Windows 95, Windows 98, Windows NT,
Linux, and UNIX. The NetScreen device communicates with the SSH client
through its built-in SCS server, which provides device configuration and
management services. Selecting this option enables SCS manageability.
Telnet: A terminal emulation program for TCP/IP networks such as the Internet.
Telnet is a common way to remotely control network devices. Selecting this option
enables Telnet manageability.
SSL: Selecting this option allows the interface to receive HTTPS traffic for secure
management of the NetScreen device via the Web user interface (WebUI).
SNMP: The NetScreen device supports the Simple Network Management
Protocol version 1.5 (SNMPv1), described in RFC-1157, and all relevant
Management Information Base II (MIB II) groups, as defined in RFC-1213.
Selecting this option enables SNMP manageability.
Ping: Selecting this option allows the NetScreen device to respond to an ICMP
echo request, or “ping,” which determines whether a specific IP address is
accessible from the device.
Ident-Reset: When a service such as Mail or FTP sends an identification request
and receives no acknowledgment, it sends the request again. While the request is
in progress, user access is disabled. With the Ident-Reset checkbox enabled, the
NetScreen device automatically restores user access.
&/,
To set up the management (mgt) interface for SSL, execute the following command.
set interface mgt manage ssl

&KDSWHU$GPLQLVWUDWLRQ /HYHOVRI$GPLQLVWUDWLRQ
/(9(/62)$'0,1,675$7,21
NetScreen devices support multiple administrative users. For any configuration changes made by an administrator,
the NetScreen device logs the following information.
• The name of the administrator making the change
• The IP address from which the change was made
• The time of the change
There are several levels of administrative user. The availability of these levels depends on the model of your
NetScreen device.
5RRW$GPLQLVWUDWRU
The root administrator has complete administrative privileges. There is only one root administrator per NetScreen
device. The root administrator 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
5HDG:ULWH$GPLQLVWUDWRU
The read/write administrator has the same privileges as the root administrator, but cannot create, modify, or remove
other admin users. The read/write administrator has the following privileges.
• Creates virtual systems and assigns a virtual system administrator for each one
• Monitors any virtual system
• Tracks statistics (a privilege that cannot be delegated to a virtual system administrator)

5HDG2QO\$GPLQLVWUDWRU
The read-only administrator has only viewing privileges using the WebUI, and can only issue the get and ping CLI
commands. The 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
96<6$GPLQLVWUDWRU
The VSYS administrator can configure any NetScreen device that supports virtual systems (VSYS). Each VSYS is a
unique security domain, managed by administrative users with privileges that apply only to that VSYS.
Virtual system administrators independently manage virtual systems through CLI or the WebUI. On each virtual
system, the virtual system administrator has the following privileges:
• Creates and edits users
• Creates and edits services
• Creates and edits access policies
• Creates and edits addresses
• Creates and edits VPNs
• Creates the VSYS administrator login password
• Creates and manages security zones
96<65HDG2QO\$GPLQLVWUDWRU
The VSYS read-only administrator has only viewing privileges using the WebUI, and can only issue the enter, exit,
get, and ping CLI commands.
Note: For more information on virtual systems, see “Virtual Systems” on page 491.

$GGLQJ$GPLQ8VHUV
The root administrator is the only one who can create, modify, and remove admin users. In the following example,
the one performing the procedure must be a root administrator.
([DPSOH$GGLQJD5HDG2QO\$GPLQLVWUDWRU
In this example, the root administrator adds a read/only administrator named Roger with password 2bd21wG7.
:HE8,
Admin >> Admin >> New Local Administrator: Enter the following, and then click OK:
Name: Roger
New Password: 2bd21wG74
Confirm Password: 2bd21wG7
Privileges: READ_ONLY (select)
&/,
To add a sub administrator named “Roger” with password “2bd21wG7” and read-only privilege, execute the
following command.
set admin user Roger password 2bd21wG7 privilege read-only
4. The password can be up to 31 characters long and is case sensitive.

&KDSWHU$GPLQLVWUDWLRQ 6HFXULQJ$GPLQLVWUDWLYH7UDIILF
6(&85,1*$'0,1,675$7,9(75$)),&
To secure the NetScreen device during setup, perform the following steps:
1. On the Web interface, change the administrative port.
See “Changing the Port Number” on page 127.
2. Turn off any unnecessary interface management service options.
See “Administrative Interface Options” on page 121.
3. Disable the ping and ident-reset service options on the interfaces, both of which respond to requests
initiated by unknown parties and can reveal information about your network:
:HE8,
Interface >> Physical >> Edit (for the interface you want to edit): Disable the following service options, and
then click Save:
Ping: Selecting this option allows the NetScreen device to respond to an ICMP
echo request, or “ping,” which determines whether a specific IP address is
accessible from the device.
Ident-Reset: When a service such as Mail or FTP sends an identification request
and receives no acknowledgment, it sends the request again. While the request is
in progress, user access is disabled. With the Ident-Reset checkbox enabled, the
NetScreen device automatically restores user access.
&/,
To disable the ping and ident-reset services, execute the following commands.
unset interface mgt manage ping
unset interface mgt manage ident-reset

1. Change the user name and password for administration access.

See “Changing the Admin Login Name and Password” on page 128.
2. Define the management client IP addresses for the admin users.
See “Restricting Administrative Access” on page 130.
&KDQJLQJWKH3RUW1XPEHU
Changing the port number to which the NetScreen device listens for HTTP management traffic improves security.
The default setting is port 80, the standard port number for HTTP traffic. After you change the port number, you must
then type the new port number in the URL field in your Web browser when you next attempt to contact the
NetScreen device. (In the following example, the administrator needs to enter http://188.30.12.2:15522.)
([DPSOH&KDQJLQJWKH3RUW1XPEHU
In this example, the System IP is 188.30.12.2 with the standard port number 80. You change the port number from
80 to 15522.
:HE8,
1. Admin >> Web >> HTTP Port: 15522
2. Click Apply.
&/,
To change the administration port number, execute the following commands.
1. set admin port 15522
2. save

&KDQJLQJWKH$GPLQ/RJLQ1DPHDQG3DVVZRUG
By default, the initial login name for NetScreen devices is netscreen. The initial password is also netscreen.
Because these have been widely published, you should change the login name and password immediately. The
login name and password are both case-sensitive. Each must be one word, alphanumeric, with no symbols. Record
the new admin login name and password in a secure manner.
Warning: Be sure to record your new password! If you forget it, you must reset the NetScreen device to its factory
settings, and all your configurations will be lost. For more information, see “Resetting the Device to the Factory
Default Settings” on page 131.
Administrative users for the NetScreen device can be authenticated using the internal database and an external
RADIUS server5. When the admin user logs in to the NetScreen device, it first checks the local internal database for
authentication. If there is no entry present and a RADIUS server is connected, it then checks for a matching entry in
the RADIUS server database.
Note: For more information about admin user levels, see “Levels of Administration” on page 123. For more about
using a RADIUS server for authentication, see “RADIUS” on page 205.
([DPSOH&KDQJLQJDQ$GPLQ8VHU/RJLQ1DPHDQG3DVVZRUG
The root administrator has decided to change a super administrator’s login name from John to Smith and his
6
password from xL7s62a1 to 3MAb99j2 .
Note: For information on the different levels of administrators, see “Levels of Administration” on page 123.
5. Remote Authentication Dial-In User Service (RADIUS) is a protocol for authenticating and authorizing dial-up users. The NetScreen device can act as a client
of a RADIUS server.
6. Instead of using actual words for passwords, which might be guessed or discovered through a dictionary attack, you can use an apparently random string
of letters and numbers. To create such a string that you can easily remember, compose a sentence and use the first letter from each word. For example,
“Charles will be 6 years old on November 21” becomes “Cwb6yooN21.”

:HE8,
Admin >> Admin >> Edit (for John): Enter the following, and then click OK:
Name: Smith
Old Password: xL7s62a1
New Password: 3MAb99j2
Confirm Password: 3MAb99j2
&/,
To change the user name from John to Smith, and set the password to 3MAb99j2, execute the following
commands.
1. unset admin user John
2. set admin user Smith password 3MAb99j2 privilege all
3. save
([DPSOH$Q$GPLQ8VHU&KDQJLQJKHU3DVVZRUG
Non-root users can change their own administrator password, but not their login name. In this example, a super
administrator with the login name “starling” is changing her password from 3MAb99j2 to ru494Vq5.
:HE8,
Admin >> Admin >> Edit (for first entry): Enter the following, and then click OK:
Name: starling
Old Password: 3MAb99j2
New Password: ru494Vq5
Confirm Password: ru494Vq5

&/,
To set the administration password to ru494Vq5, execute the following commands.
1. set admin password ru494Vq5
2. save
5HVWULFWLQJ$GPLQLVWUDWLYH$FFHVV
You can administer NetScreen devices from one or multiple addresses of a subnet. By default, any host on the
trusted interface can administer a NetScreen device. To restrict this ability to specific workstations, you must
configure Management Client IP addresses.
Note: The assignment of a management client IP address takes effect immediately. If you are managing the device via
a network connection and your workstation is not included in the assignment, the NetScreen device will immediately
terminate your current session and you will no longer be able to manage the device from that workstation.
([DPSOH5HVWULFWLQJ$GPLQLVWUDWLRQWRD6LQJOH:RUNVWDWLRQ
In this example, the administrator at the workstation with the IP address 172.16.40.42 is the only administrator
specified to manage the NetScreen device.
:HE8,
Admin >> Admin >> New Restricted Management IP: Enter the following, and then click OK:
IP Address: 172.16.40.42
Netmask: 255.255.255.255
&/,
1. set admin manager-ip 172.16.40.42 255.255.255.255
2. save

([DPSOH5HVWULFWLQJ$GPLQLVWUDWLRQWRD6XEQHW
In this example, the group of administrators with workstations in the 172.16.40.0/24 subnet are specified to manage
a NetScreen device.
:HE8,
Admin >> Admin >> New Restricted Management IP: Enter the following, and then click OK:
IP Address: 172.16.40.0
Netmask: 255.255.255.0
&/,
1. set admin manager-ip 172.16.40.0 255.255.255.0
2. save
5HVHWWLQJWKH'HYLFHWRWKH)DFWRU\'HIDXOW6HWWLQJV
If the admin password is lost, you can use the following procedure to reset the NetScreen device to its default
settings. The configurations will be lost, but access to the device will be restored. To perform this operation, you
need to make a console connection, which is described in detail in the NetScreen CLI Reference Guide and the
installer’s guides.
Note: By default the device recovery feature is enabled. You can disable it by entering the unset admin
device-reset command. Also, if the NetScreen device is in FIPS mode, the recovery feature is automatically
disabled.
1. At the login prompt, type the serial number of the device.

2. At the password prompt, type the serial number again.

The following message appears:

!!!! Lost Password Reset !!!! You have initiated a command to reset the device to factory defaults, clearing all
current configuration, keys and settings. Would you like to continue? y/n
3. Press the y key.
The following message appears:
!! Reconfirm Lost Password Reset !! If you continue, the entire configuration of the device will be erased. In
addition, a permanent counter will be incremented to signify that this device has been reset. This is your last
chance to cancel this command. If you proceed, the device will return to factory default configuration, which
is: System IP: 192.168.1.1; username: netscreen; password: netscreen. Would you like to continue? y/n
4. Press the y key to reset the device.
You can now login in using netscreen as the default username and password.
0DQDJH,3
Any interface you bind to a security zone can have two IP addresses.
• a physical port interface IP address (or a logical subinterface), which connects to a network.
• a logical manage IP address for receiving administrative traffic.
When a NetScreen device is a backup unit in a redundant group for High Availability (HA), you can access and
configure the unit through its manage IP address (or addresses)
Note: The manage IP address differs from the system IP address in the following two ways:
• When the NetScreen device is in Transparent mode, the system IP address can be the endpoint of a
VPN tunnel, but the manage IP address cannot.
• You can define multiple manage IP addresses—one for each network interface—but you can only
define one system IP address—for the entire system.

([DPSOH6HWWLQJ0DQDJH,3VIRU0XOWLSOH,QWHUIDFHV
In this example, an interface bound to the DMZ zone gives access to a group of administrators using HTTP, SNMP,
or Telnet. The interface bound to the DMZ zone (ethernet2/2) and the interface bound to the Untrust zone
(ethernet1/2) each have a Manage IP address, which allows administrative access.
Untrust Zone
NetScreen-Global PRO
Internet
Interface Ethernet2,
bound to DMZ Zone
Manage IP:
Interface Ethernet3,
211.24.55.43/24
bound to Untrust Zone
Manage IP:
DMZ Zone
211.24.54.43125/24 HTTP, SNMP, or
Telnet hosts
LAN
Trust Zone

:HE8,
Interface >> Physical >> Edit (ethernet2): Enter the following, and then click Save:
IP Address: 211.24.55.144
Netmask: 255.255.255.0
Manage IP: 211.24.55.43
Zone Name: DMZ
Management Services: WebUI, Telnet, SNMP: (select)
&/,
To set up the same configuration using the CLI, execute the following commands.
2. set interface ethernet2 manage-ip 211.24.55.43
3. set interface ethernet2 manage web
4. set interface ethernet2 manage telnet
5. set interface ethernet2 manage snmp
6. save
0DQDJHPHQW=RQH,QWHUIDFHV
On some NetScreen devices, the Management (MGT) zone allows you to manage the device through a separate
interface, moving administrative traffic outside the regular network user traffic. Separating administrative traffic from
network user traffic greatly increases administrative security and assures constant management bandwidth.

There are two interfaces, bound by default to the MGT zone:

• vlan1 Use this interface when running the NetScreen device in transparent mode. The device is in
transparent mode when it works at Level 2.
• mgt Use this interface when running the NetScreen device in non-transparent (NAT or Router) mode. The
device is in non-transparent mode when it works at Level 3.
These interfaces provide dedicated connections for management traffic. With this arrangement, you can use a Web
browser to manage through the WebUI (see “Web User Interface” on page 112) or use other services such as Telnet
(see “Telnet” on page 117) to manage through the CLI.
([DPSOH$GPLQLVWUDWLRQWKURXJKWKH0*7,QWHUIDFH
You can configure some NetScreen devices to allow administration through one or more of the trusted, untrusted,
DMZ or Management (mgt) interfaces. To maintain the highest level of security, NetScreen recommends that you
limit administrative traffic exclusively to the vlan1 or mgt interface and user traffic to the trusted and untrusted
interfaces. These interfaces are bound by default to the Management (MGT) zone. Using these interfaces prohibits
administrative access from trusted and untrusted workstations that are connected to your network and assures
bandwidth availability for administrative traffic.
In the following example, the IP address of the MGT interface is 192.168.20.2/24, and the MGT interface is enabled
to receive Telnet and Web administrative traffic.
:HE8,
Interface >> Physical >> Edit (for mgt): Enter the following, and then click Save:
IP Address: 192.168.20.2
Netmask: 255.255.255.0
WebUI: enable
Telnet: enable

&/,
1. set interface mgt ip 192.168.20.2/24
2. set interface mgt manage web
3. set interface mgt manage telnet
4. save
9LUWXDO3ULYDWH1HWZRUNV
You can use a Virtual Private Network (VPN) to secure remote management and monitoring of a NetScreen device
from either a dynamically assigned or fixed untrusted IP address. Using a VPN, you can protect any kind of traffic,
such as HTTP, Telnet, or SNMP.

NetScreen supports three methods for creating a VPN tunnel:

• Manual Key: You manually set the three elements that define a Security Association (SA) at both ends of
the tunnel: a Security Parameters Index (SPI), an encryption key, and an authentication key. To change any
element in the SA, you must manually enter it at both ends of the tunnel.
• AutoKey IKE with Preshared Key: One or two preshared secrets—one for authentication and one for
encryption—function as seed values. Using them, the IKE protocol generates a set of symmetrical keys at
both ends of the tunnel; that is, the same key is used to encrypt and decrypt. At predetermined intervals,
these keys are automatically regenerated.
• AutoKey IKE with Certificates: Using the Public Key Infrastructure (PKI), the participants at both ends of the
tunnel use a digital certificate (for authentication) and an RSA public/private key pair (for encryption). The
encryption is asymmetrical; that is, one key in a pair is used to encrypt and the other to decrypt.
Note: For a complete description of VPN tunnels, see the VPN chapters. For more information on
NetScreen-Remote, refer to the NetScreen-Remote User’s Guide.
By default, NetScreen VPN tunnels use the untrusted interface IP address (in NAT mode) or the System IP address
(in Transparent mode) as the tunnel endpoint. Optionally, you can designate the trusted interface as the endpoint
when directing management traffic through a VPN tunnel to an address on the untrusted side. This allows you to
create an outgoing access policy encrypting management traffic, such as SNMP or syslog, originating within the
NetScreen device (with the source address being the trusted interface) and destined for a remote server on the
untrusted side. To enable this functionality, do the following:
:HE8,
To enable VPN for syslog traffic, make the following settings, and then click Apply.
Admin >> Syslog: Enable Syslog Messages: (select)
Admin >> Syslog: Syslog Host Name (enter name)
To enable VPN for WebTrends Message traffic, make the following settings, and then click Apply.
Admin >> Syslog: Enable WebTrends Messages: (select)
Admin >> Syslog: WebTrends Host Name: (enter name)

&/,
To enable VPN for SNMP traffic, execute the following command.
set snmp vpn
Note: You also need to define the trusted interface as an address in the trusted address book, configure the VPN
tunnel, and create incoming and outgoing access policies.
([DPSOH6HQGLQJ6103DQG6\VORJ5HSRUWVWKURXJKDQ,36HF7XQQHO
In this example, a remote administrator behind a NetScreen device receives SNMP traps and syslog reports7 from a
another NetScreen device through an AutoKey IKE IPSec tunnel. The tunnel uses a preshared key (Ci5y0a1aAG)
for data origin authentication and 3DES and SHA-1 for data encryption and authentication. The tunnel is in IPSec
main mode, using Diffie-Hellman group 2 exchanges for the Phase 1 and Phase 2 IPSec negotiations.
Note: For the following example, assume that one ethernet interface is bound to the Trust zone, and another
ethernet interface is bound to the Untrust zone.
7. This example assumes that the remote administrator has already set up the syslog server (see “Syslog” on page 148) and an SNMP community (see “SNMP”
on page 151).

Trust Zone Untrust Zone Untrust Zone Trust Zone

Ethernet Interface: Ethernet Interface: Interface: Interface:
10.10.1.1/24 2.2.2.2/24 172.16.10.2/24 3.3.3.3/24
Internet
VPN Tunnel NetScreen Peer

LAN
Gateway IP: Gateway IP:
2.2.2.1 172.16.10.1
Remote Admin
:HE8,
1. Interface >> Physical >> Edit (ethernet, Trust zone): Enter the following, and then click Save:
Netmask: 255.255.255.0
2. Interface >> Physical >> Edit (ethernet, Untrust zone): Enter the following, and then click Save:
IP Address: 2.2.2.2
Netmask: 255.255.255.0
Netmask: 0.0.0.0
Gateway IP Address: (select) 2.2.2.1
Interface: None
Metric: 1

4. Address >> Address (under the “New” column for the Trust zone) >> Address: Enter the following, and
then click OK:
Address Name: trust_int
Netmask: 255.255.255.255
5. Address >> Address (under the “New” column for the Untrust zone) >> Address: Enter the following, and
then click OK:
Address Name: remote_admin
Netmask: 255.255.255.255
6. VPN >> Gateway(P1) >> New Remote Tunnel Gateway: Enter the following, and then click OK:
Gateway Name: to_admin
Static IP Address: 3.3.3.3
Mode (Initiator): Main (ID Protection): (select)
Phase 1 Proposal: pre-g2-3des-sha
Preshared Key: Ci5y0a1aAG
7. VPN >> AutoKey(P2) >> New AutoKey IKE Entry: Enter the following, and then click OK:
Name: admin
Remote Gateway Tunnel: to_admin
8. Admin >> Syslog: Enter the following, and then click Apply.
Enable Syslog Messages: (select)
Syslog Host Name (enter the host name of the syslog server)

Service: SNMP
Source Address: trust_int
Destination Address: remote_admin
Action: Tunnel
VPN Tunnel: admin
Service: SYSLOG
Source Address: trust_int
Destination Address: remote_admin
Action: Tunnel
VPN Tunnel: admin
&/,
Note: For this example, assume that one ethernet interface (ethernet4/1) is bound to the Trust zone, and
another ethernet interface (ethernet4/2) is bound to the Untrust zone.
1. set interface ethernet4/1 zone trust

2. set interface ethernet4/1 ip 10.10.1.1 255.255.255.0
3. set interface ethernet4/2 zone untrust
4. set interface ethernet4/2 ip 2.2.2.2 255.255.255.0
5. set vrouter untrust route 0.0.0.0/0 gateway 2.2.2.1
6. set address trust trust_int 10.10.1.1 255.255.255.0
7. set address untrust remote_admin 172.16.10.1 255.255.255.255
8. set ike gateway to_admin ip 3.3.3.3 main preshare Ci5y0a1aAG proposal pre-g2-3des-sha

9. set vpn admin gateway to_admin tunnel proposal g2-esp-3des-sha

10. set snmp vpn
11. set syslog vpn
12. set policy outgoing trust_int remote_admin snmp tunnel vpn admin
13. set policy outgoing trust_int remote_admin syslog tunnel vpn admin
14. save
([DPSOH$GPLQLVWUDWLRQWKURXJKD9317XQQHOIURPWKH7UXVW=RQH
In this example, the network security administrator uses a VPN to keep security separate from general network
administration. The administrator creates a Manual Key VPN tunnel from the workstation at 10.10.11.56 to
10.10.10.1, the IP address of an interface bound to a tunnel zone. The workstation runs NetScreen-Remote.
Internet
Trust Zone
Interface IP:
10.10.10.1/24
LAN in
Trust Zone
VPN Tunnel
Administrative Workstation IP:

10.10.11.56/24

:HE8,
1. Interface >> Physical >> Edit (ethernet1): Enter the following, and then click OK:
Netmask: 255.255.255.0
Zone Name: Trust
Zone Name: Other_Zone
Zone Type: select Regular
3. Interface >> Physical >> Edit (ethernet5): Enter the following, and then click OK:
Netmask: 255.255.255.0
Zone Name: Other_Zone
4. Address >> Address (under the “New” column for the Trust zone): Enter the following, and then click
OK:
Address Name: Admin_Interface
Netmask: 255.255.255.0
Zone: Trust
5. Address >> Address (under the “New” column for the Other_ Zone): Enter the following, and then click
OK:
Address Name: Other_Interface

Netmask: 255.255.255.255
Zone: Other_Zone
6. VPN >> Manual Key >> New Manual Key Entry: Enter the following, and then click OK:
VPN Tunnel Name: Admin_Tunnel
Gateway IP: 10.10.10.56
Security Index: 4567 (Local) 5555 (Remote)
Tunnel Zone: (select) Untrust_Tun
ESP-CBC: (select)
Encryption Algorithm: DES-CBC
Generate Key by Password8: netscreen1
Authentication Algorithm: MD5
Generate Key by Password: netscreen2
7. Policy >> From Zone: Trust, To Zone: Other_Zone >> New Policy: Enter the following, and then click
OK:
Source Address: Admin_Interface
Destination Address: Other_Interface
Service: ANY
Action: Tunnel
VPN Tunnel: Admin_Tunnel
8. Because NetScreen-Remote processes passwords into keys differently than other NetScreen products do, after you configure the tunnel do the following:
(1) Return to the Manual Key
Configuration dialog box (click Edit in the Configure column for “Admin Tunnel”); (2) copy the generated hexadecimal key; and (3) use that hexadecimal key
when configuring the NetScreen-Remote end of the tunnel.

&/,
4. set zone name Other_Zone
5. set interface ethernet5 zone Other_Zone
7. set address trust Admin_Interface 10.10.10.56/24
8. set address Other_Zone Other_Interface 10.20.10.2/24
9. set vpn Admin_Tunnel manual 4567 5555 gateway 10.10.10.56 outgoing ethernet1 esp des password
netscreen1 auth md5 password netscreen2
10. set policy from trust to Other_Zone Admin_Interface Other_Interface any tunnel vpn Admin_Tunnel
11. set policy from Other_Zone to trust Other_Interface Admin_Interface any tunnel vpn Admin_Tunnel
12. save


&KDSWHU
0RQLWRULQJ1HW6FUHHQ'HYLFHV

This chapter discusses the following topics that can be used when monitoring NetScreen devices:
• “Syslog” on page 148
• “SNMP” on page 151
• “Counters” on page 157
• “Logs” on page 158
• “Alarms” on page 161

&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV 6\VORJ
6<6/2*
Syslog is facility that enables the logging of system events to a single file for later review. A NetScreen device
generates syslog messages for system events at user-defined priority levels and sends these messages via UDP
(port 514) to a syslog host, which runs on a UNIX/Linux system. Syslog messages can be used by the syslog host to
create e-mail alerts for the system administrator, or be displayed on the console of the designated host using UNIX
syslog conventions.
Note: On UNIX/Linux platforms, modify the /etc/rc.d/init.d/syslog file so that syslog retrieves information from the
remote source (syslog -r).
You can also send syslog messages through a VPN tunnel. In the WebUI, select the Enable Syslog VPN
encryption. In the CLI, use the set syslog vpn command.
/RJJLQJ3ULRULW\/HYHOV
The syslog message levels are as follows:
• EMERGENCY: Generates messages on SYN attacks, Tear Drop attacks, and Ping of Death attacks. For
more information on these types of attacks, see “Firewall Options” on page 67.
• ALERT: Generates messages for multiple user authentication failures and other firewall attacks not
included in the emergency category.
• CRITICAL: Generates messages for URL blocks, traffic alarms, high availability (HA) status changes, and
global communications.
• ERROR: Generates messages for admin name and password changes.
• WARNING: Generates messages for admin logins and logouts, failures to log in and log out, and user
authentication failures, successes, and timeouts.
• NOTICE: Generates messages for link status changes, load balancing server status changes, and traffic
logs.
• INFO: Generates any kind of message not specified in other categories.
• DEBUG: Generates all messages.

Syslog messages are organized hierarchically, so that setting a level includes that level and all levels above it. For
example, an alert setting generates messages for alert and emergency messages, whereas a debug setting
generates messages for all levels.
Note: You can also send traffic logs with the syslog messages.
:HE7UHQGV
WebTrends® offers a product called the WebTrends Firewall Suite that allows you to customize syslog reports to
display the information you want in the format you specify. You can create reports that focus on areas such as
firewall activity, network traffic flow, or event alarms.
Note: The WebTrends Syslog Server and the WebTrends Firewall Suite must run on the same Windows NT system.
You must have administrator rights to configure it.
You can also send WebTrends messages through a VPN tunnel. In the WebUI, select the Enable WebTrends VPN
encryption. In the CLI, use the set webtrends vpn command.
([DPSOH(QDEOLQJ6\VORJDQG:HE7UHQGV
The following example illustrates how to set up the syslog facility to send messages to port 514 on a WebTrends
syslog Server at 172.10.16.25. The security and facility levels are set to Local0. Traffic logs are included with the
system event messages.
:HE8,
Admin >> Syslog: Enter the following, then click Apply:
Enable syslog messages: (select)
Include Traffic Log: (select)
Syslog Host Name: 172.10.16.25
Syslog Host Port: 5141

Security Facility: Local0

Facility: Local0
Enable WebTrends Messages: (select)
WebTrends Host Name: 172.10.16.25
WebTrends Host Port: 514
Note: When you enable syslog and WebTrends on a NetScreen device running in Transparent mode, you
must set up a static route on the Route Table.
&/,
1. set syslog config 172.10.16.25 auth/sec local0
2. set syslog port 514
3. set syslog traffic
4. set syslog enable
5. set webtrends host-name 172.10.16.25
6. set webtrends port 514
7. set webtrends enable
8. save
1. The syslog host port number must match the WebTrends® port number.

&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV 6103
6103
The Simple Network Management Protocol (SNMP) agent for the your NetScreen device provides network
administrators with a way to view statistical data about the network and the devices on it, and to receive notification
of system events of interest.
The NetScreen devices support the SNMPv1 protocol (described in RFC-1157) and all relevant Management
Information Base II (MIB II) groups defined in RFC-1213.
Accordingly, the NetScreen SNMP agent generates the following traps, or notifications, when specified events or
conditions occur:
• Cold Start Trap: The cold start trap is generated when the NetScreen device becomes operational after
you power it on.
• Trap for SNMP Authentication Failure: The authentication failure trap is triggered if the SNMP manager
sends the incorrect community string.
• Traps for System Alarms: System alarms are triggered by firewall conditions and NetScreen device error
conditions. Three NetScreen enterprise traps are defined to cover alarms related to hardware, security, and
software. (For more information on firewall settings and alarms, see “Firewall Options” on page 67, and
“Alarms” on page 161.)
• Traps for Traffic Alarms: Traffic alarms are triggered when traffic exceeds the alarm thresholds set in
access policies. (For more information on configuring access policies, see Chapter 9, “Access Policies”.
The following table list possible alarm types and their associated trap number:
Trap Enterprise ID Description

100 Hardware problems
200 Firewall problems
300 Software problems
400 Traffic problems
500 VPN problems

For more information on types of problems, see “Logs” on page 158.
Note: The network administrator must have an SNMP manager application such as HP OpenView® or SunNet
ManagerTM to browse the SNMP MIB II data and to receive traps from either the trusted or untrusted interface. There
are also several shareware and freeware SNMP manager applications available from the Internet.
NetScreen devices do not ship with a default configuration for the SNMP manager. To configure your NetScreen
device for SNMP, you must first create communities, define their associated hosts, and assign permissions
(read-write or read only).
,PSOHPHQWDWLRQ2YHUYLHZ
The following points summarize how SNMP is implemented in NetScreen devices:
• The network administrator can create up to three communities, each containing up to eight hosts. Hosts
must be listed individually; they cannot be specified as a range.
• Each community has either read-only or read-write permission for the MIB II data.
• Each community can be allowed or denied receiving traps.
• Access to the MIB II data and traps is available through any physical interface.
• Each system alarm generates a single NetScreen enterprise SNMP trap to each of the hosts in each
community that is set to receive traps.
• Cold Start / Link Up / Link Down traps will be sent to all hosts in communities that are set to receive traps.
• If you specify trap-on for a community, you also have the option to allow traffic alarms.
You can also send SNMP messages through a VPN tunnel. In the WebUI, select the Enable SNMP VPN
encryption. In the CLI, use the set snmp vpn command.

([DPSOH6HWWLQJ8S6103&RPPXQLWLHV
In the example below, you configure SNMP for two communities, named “JCarney” and “TCooper.” In the first
community, its members can read MIB II data and receive traps. In the second community, its members can read
and write MIB II data, receive traps, and traffic alarms. The contact person is “John Fisher” in “Miami.” The JCarney
community host IP addresses are 172.16.20.181, 172.16.40.245, and 172.16.40.55. The TCooper community host
is 172.16.20.250.
Note: The MIB II system group variables sysContact, sysName (which is the same as the host name), sysLocation,
and sysServices are read-write objects. All other variables are read-only.
:HE8,
1. Admin >> SNMP: Enter the following settings, and then click Apply:
System Contact: John Fisher
Location: Miami
2. Admin >> SNMP >> New Community: Enter the following settings, and then click OK:
Community Name: JCarney
Trap: (select)
Hosts: 172.16.20.181
172.16.40.245
172.16.40.55
3. Admin >> SNMP >> New Community: Enter the following settings, and then click OK:
Community Name: TCooper
Write: (select)
Trap: (select)
Including Traffic Alarms: (select)
Hosts: 172.16.20.250

&/,
1. set snmp contact John Fisher
2. set snmp location Miami
3. set snmp community JCarney read-only trap-on
4. set snmp host JCarney 172.16.20.181
7. set snmp community TCooper read-write trap-on traffic
8. set snmp host TCooper 172.16.20.250
9. reset
9310RQLWRULQJ
The NetScreen ScreenOS provides the ability to determine the status and condition of active VPNs through the use
of SNMP VPN monitoring objects and traps.
Note: To enable your SNMP manager application to recognize the VPN monitoring MIBs, you must import the
NetScreen-specific MIB extension files into the application. You can find the MIB extension files on the NetScreen
documentation CD that shipped with your NetScreen device.
By enabling the VPN monitoring feature on a Manual Key or AutoKey IKE VPN tunnel, the NetScreen device
activates its SNMP VPN monitoring objects, which note data on the following:
• The total number of active VPN sessions
• The time each session started
• The Security Association (SA) elements for each session:
– ESP encryption (DES or 3DES) and authentication algorithm (MD5 or SHA-1) types
– AH algorithm type (MD5 or SHA-1)
– Key exchange protocol (AutoKey IKE or Manual Key)

– Phase 1 authentication method (Preshared Key or certificates)

– VPN type (dialup or peer-to-peer)
– Peer and local gateway IP addresses
– Peer and local gateway IDs
– Security Parameter Index (SPI) numbers
• Session status parameters
– VPN monitoring status (up or down)
– Tunnel status (up or down)
– Phase 1 and 2 status (inactive or active)
– Phase 1 and 2 lifetime (time in seconds before rekeying; Phase 2 lifetime is also reported in remaining
bytes before rekeying)
When VPN monitoring is enabled, the NetScreen device also pings the remote gateway at specified intervals (in
10-second increments) to monitor network connectivity between the two VPN gateways.2 The pings are sent through
the VPN tunnel between the two end points of the tunnel—the untrusted interface IP addresses (NAT or Route
mode) or the System IP addresses (Transparent mode). The VPN monitoring MIB notes whether the ping elicited a
response, a running average of successful responses, the latency of the response, and the average latency over the
last 30 attempts.
An SNMP trap is triggered when the ping activity indicates that the VPN status has changed:
• Up to Down: The state of the VPN tunnel is up, but the ping request has not elicited a response after a
specified number of attempts.
• Down to Up: The state of the VPN tunnel is down, but the ping request elicits a response.
To enable VPN monitoring, do the following:
2. You must use the following CLI command to change the ping interval: set vpnmonitor. The
default is 10 seconds.

:HE8,
VPN >> Manual Key >> New Manual Key Entry: Configure the VPN, select the VPN Monitor check box,
and then click OK.
Or
VPN >> AutoKey (P2) >> New AutoKey IKE Entry: Configure the VPN, select the VPN Monitor check box,
and then click OK.
&/,
Configure the Manual Key or AutoKey IKE VPN, then execute the following commands.
1. set vpn <vpn_name> monitor
2. set vpnmonitor frequency <number3>
3. save
3. You can set the VPN monitoring frequency in 10-second increments.

&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV &RXQWHUV
&2817(56
Counters measure traffic as defined in the access policies section.
([DPSOH9LHZLQJ&RXQWHUV
This example illustrates how to view the amount of traffic per second handled by the first incoming access policy,
which has a policy ID of 3.
:HE8,
1. Counters >> Count >> View Count Details: Click on a line in the graph to view information at that
interval.
Note: The X-axis represents time and the Y-axis represents the number of bytes. The X-axis displays
seconds, minutes, hours, days, or months, depending on which tab you select. The color of the bar appears
in blue, unless an alarm threshold was set and exceeded, in that case the bar is red.
2. Counters >> Count >> View Count Details >> Download to File: Specify the desired location of the
counter data for review and analysis.
3. Counters >> Count >> View Count Details >> Update Now: The screen refreshes with the most recent
data available.
&/,
get counter policy 3 second

&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV /RJV
/2*6
NetScreen devices categorize system-level events as system events, traffic events, and denied traffic. System
events are discussed in “Event Log” on page 158, traffic events in “Traffic Log” on page 159, and denied traffic in
“Self Log” on page 160.
(YHQW/RJ
System events are classified into two distinct categories: information (indicated by a yellow circle in the WebUI) and
configuration (indicated by a red circle).
You can view system events through the WebUI, the CLI, or you can send event logs to a syslog host, (see “Syslog”
on page 148) or a WebTrends host (“WebTrends” on page 149).
Note: For detailed information about the messages that appear in the event log, refer to the NetScreen Message
Log Reference Guide.
:HE8,
Log >> Event Log
&/,
The get log command allows you to impose parameters to determine the events displayed. (For more
information, see the NetScreen CLI Reference Guide.)
To list the current event log, execute the following CLI command:
get log event

7UDIILF/RJ
NetScreen devices provide comprehensive monitoring tools to monitor traffic flow in real-time. You can view all
graphs of the usage data with a browser on the Internet, or download it and import it into a spreadsheet or database
for numerous applications.
NetScreen devices maintain a traffic log. To view traffic logs you have defined in the Access Policies page, do the
following:
:HE8,
Log >> Traffic Log >> View All Log Entries: Select the action you want to perform:
Click Download to File to save the data to a desired location for review and
analysis.
You can save the data to your local C: drive in a *.txt text format. The file contents
are tab-delimited.
Click Clear Logs to clear the log after downloading the most recent data
available.
&/,
get log traffic

6HOI/RJ
In addition to the event log and traffic log, each NetScreen device supports a logging function called self log. The self
log records all the dropped packets detected by that NetScreen device; that is, the log shows all the traffic which
terminated at the device and was denied.
In addition to viewing the self log through the WebUI or CLI, you can also open or save the file to the location you
specify. Use an ASCII text editor (such as Notepad) to view the file.
([DPSOH'RZQORDGLQJWKH6HOI/RJ
This example illustrates how to download a self log to your workstation desktop (WebUI) or to a TFTP server with
the IP address 10.10.20.200 (CLI).
:HE8,
1. Log >> Self Log: Select the Download to File option.
The File Download wizard prompts you to open the file (using an ASCII editor) or save it to disk.
2. Select the Save this file to disk option, and then click OK.
The File Download wizard prompts you to choose a directory.
3. Specify the desktop, name the file and give it a .txt extension, and then click Save.
&/,
The following example assumes an output file named OutFile.txt:
get log self > tftp 10.10.20.200 OutFile.txt

&KDSWHU0RQLWRULQJ1HW6FUHHQ'HYLFHV $ODUPV
$/$506
Your NetScreen device maintains two types of alarms—traffic alarms, when traffic thresholds on access policies are
exceeded, and event alarms, when system events occur. You can also configure the your NetScreen device to alert
you through one or more of the following methods whenever an alarm is generated:
• E-mail
• Syslog or WebTrends
• SNMP
7UDIILF$ODUPV
You define and enable Traffic Alarms by setting alarm thresholds in the Access Policy Configuration dialog box.
They are triggered when traffic exceeds those thresholds. (For more information on monitoring traffic, see “Traffic
Log” on page 159.)
Alarm >> Traffic Alarm >> Recent Alarm Time: View alarm details by selecting the following:
To save the data to the specified location for review and analysis, click Download
to File.
are tab-delimited.
To erase all the data, click Clear Alarms.
To move to the next/previous page, click Next/Previous.
(YHQW$ODUPV
Event alarms, such as those for attacks against which you have configured the device to guard, are triggered by the
events themselves. (For more information on monitoring events, see “Event Log” on page 158.)
:HE8,
Alarm >> Event Alarm: View the Event Alarm details by selecting the following:

To save the data to the specified location for review and analysis, click Download
to File.
are tab-delimited.
Click the Next/Previous option to see the next/previous page.
&/,
1. get alarm traffic
2. get alarm event

([DPSOH6HQGLQJ(PDLO$OHUWV
This example shows how you set up notification by e-mail alerts when there is an alarm. The mail server is at
172.16.10.254, the first e-mail address to be notified is jharker@netscreen.com, and the second address is
driggs@netscreen.com. The NetScreen device includes traffic logs with event logs sent via e-mail.
:HE8,
Admin >> Settings: Enter the following information, then click Apply:
Enable E-Mail Notification for Alarms: (select)
SMTP Server Name: 172.16.10.2544
E-Mail Address 1: jharker@netscreen.com
E-Mail Address 2: driggs@netscreen.com
Include Traffic Log: select
&/,
1. set admin mail alert
2. set admin mail mail-addr1 jharker@netscreen.com
3. set admin mail mail-addr2 driggs@netscreen.com
4. set admin mail server-name 172.16.10.254
5. set admin mail traffic-log
6. save
4. If you have DNS enabled, you can also use a host name for the mail server, such as mail.netscreen.com.


&KDSWHU
9LUWXDO5RXWHUV

The routing component of a NetScreen security appliance maintains a routing table with entries for all the IP
addresses in its routing domain so that it can forward packets from one subnet to another. A NetScreen device
running ScreenOS 3.1.0 logically subdivides its routing module into two virtual routers1—Trust-VR (VR-2), which
contains the trust zone and, by default, any user-defined zone, and Untrust-VR (VR-1), which contains the untrust
zone. Each virtual router has a memory buffer, a route entry maximum, and a routing table.
ScreenOS 3.1.0 supports the following kinds of virtual routers:
• Two predefined virtual routers
– Trust-VR, which contains the trust zone and, by default, any user-defined zone
– Untrust-VR, which contains the untrust zone
– Untrust-vr, which contains the untrust zone, DMZ zone, and any user-defined zone assigned to it
• Multiple user-defined virtual routers, the number of which depends on the amount specified in the virtual
router software key that you must first obtain
This chapter contains the following sections about the creation, modification, and deletion of virtual routers, as well
as information about route redistribution, route exporting, and route table configuration:
• “Configuring a Virtual Router” on page 166
– “Creating a Virtual Router” on page 166
– “Modifying a Virtual Router” on page 167
– “Changing Zone-to-Virtual Router Bindings” on page 168
– “Deleting a User-Defined Virtual Router” on page 168
• “Route Redistribution” on page 169
• “Route Exporting” on page 170
• “Route Table Configuration” on page 171
1. Each virtual system shares the untrust-vr with the root system and has its own vsys-vr. Therefore, by increasing the number of virtual systems, you increase
the number of virtual routers.

&KDSWHU9LUWXDO5RXWHUV &RQILJXULQJD9LUWXDO5RXWHU
&21),*85,1*$9,578$/5287(5
By separating routing information into two or more virtual routers, you can control the information that is visible to
others in any given routing domain. For example, you can keep the routing information for all the security zones
inside a corporate network on the predefined virtual router trust-vr, and all the zones outside the corporate network
on the other predefined virtual router untrust-vr. Because the information in the routing table of one virtual router is
not visible to the other, you can keep internal network routing information hidden from untrusted sources outside the
company.
&UHDWLQJD9LUWXDO5RXWHU
If you have obtained a software key permitting the addition of user-defined virtual routers, you can define them either
through the WebUI or CLI as follows:
:HE8,
1. Routing >> Virtual Router >> New Entry: Enter the following, and then click OK:
Virtual Router Name: Type the name of the virtual router.
Maximum Route Entry: Type the maximum number of routes that the virtual
router can maintain. (The minimum is 10.)
Route Export: Select this check box to enable route exporting. Clear it to
disable route exporting.
2. Routing >> Redist. Rule >> New Entry: Enter the following, and then click OK:
Virtual Router Name: From the drop-down list, select the virtual router to
which you want to redistribute routing information.
Network Address: Type the address to which the route leads.
Netmask: Type the netmask for the address.
Source Virtual Router Name: From the drop-down list, select the name of the
virtual router that maintains the address in its routing table.

&/,
1. set vrouter <name> id <number>
2. set vrouter <name> { max-routes <number> | auto-route-export | redistribute ip <ip_addr> <netmask>
vrouter <name> }
0RGLI\LQJD9LUWXDO5RXWHU
You can modify all aspects of a user-defined virtual router. For the predefined virtual router trust-vr, you can change
its name and whether or not it automatically exports route information for interfaces configured in Route mode to the
untrust-vr (see “Route Exporting” on page 170). For the predefined virtual router untrust-vr, no modifications are
allowed.
To modify the ID number or name of a user-defined virtual router, you must first delete the virtual router, and then
recreate it with the new name or ID number.
:HE8,
1. Routing >> Virtual Router >> Edit (for the virtual router that you want to modify): Change the settings, and
then click OK.
2. Routing >> Redist. Rule >> { New Entry (if no entry exists) | Edit (for an existing entry that you want to
modify }: Change the settings, and then click OK .
&/,
1. set vrouter <name> { max-routes <number> | auto-route-export | redistribute ip <ip_addr> <netmask>
vrouter <name> }
2. save

&KDQJLQJ=RQHWR9LUWXDO5RXWHU%LQGLQJV
You can change the binding of a security zone from one virtual router to another. (First, however, you must remove
all interfaces from the zone. For information on binding and unbinding an interface to a security zone, see “Creating
an Interface” on page 72.)
:HE8,
1. Zone >> Zone >> Edit (for the zone whose binding you want to change): Select the virtual router to which
you want to bind the zone from the Virtual Router Name drop-down list, and then click OK.
&/,
1. set zone <name> vrouter <vr_name>
2. save
'HOHWLQJD8VHU'HILQHG9LUWXDO5RXWHU
You cannot delete the predefined virtual routers untrust-vr and trust-vr, although you can modify some aspects of
the trust-vr. However, you can delete any user-defined virtual router.
:HE8,
1. Routing >> Virtual Router >> Remove (for the virtual router that you want to remove).
2. When the prompt appears asking you to confirm the removal, click Yes.
&/,
1. unset vrouter <name>
2. save

&KDSWHU9LUWXDO5RXWHUV 5RXWH5HGLVWULEXWLRQ
5287(5(',675,%87,21
Because each virtual router maintains its own routing table, for traffic originating in one routing domain to reach a
destination in another routing domain, there must be a link between the two virtual routers. Such route “leakage” is
made possible via route redistribution. Route redistribution locates a route that is unavailable on one virtual router by
requesting another virtual router to check its routing table. For example, for host A in the trust-vr routing domain to
communicate with host B in the untrust-vr routing domain, the trust-vr must contain a route that states “to reach host
B, go to untrust-vr.” By default, trust-vr has the following route to untrust-vr so that any routes not available on
trust-vr are deferred to untrust-vr: (VR) trust-vr, (IP/Netmask) 0.0.0.0/0, (Gateway) untrust-vr, (Interface) n/a.

&KDSWHU9LUWXDO5RXWHUV 5RXWH([SRUWLQJ
5287((;3257,1*
You can specify that trust-vr or a user-configured virtual router exports routes to other virtual routers2. These
exported routes are for zones with interfaces in Route mode. When you define the operational mode of an interface
for a security zone in the trust-vr routing domain as Route, an entry is automatically added to the untrust-vr routing
table.
To enable route exporting for trust-vr, do either of the following:
:HE8,
Routing >> Virtual Router >> Edit (for trust-vr): Select the Route Export check box, and then click OK.
&/,
set vrouter trust-vr auto-route-export
To disable route exporting for trust-vr, do either of the following:
:HE8,
Routing >> Virtual Router >> Edit (for trust-vr): Clear the Route Export check box, and then click OK.
&/,
unset vrouter trust-vr auto-route-export
If the operational mode of an interface for a security zone in the trust-vr routing domain is NAT, and if you have
configured a MIP or VIP on that interface to receive incoming traffic from a source in the untrust-vr routing domain,
then you must create a route to the MIP or VIP in untrust-vr that points to trust-vr as the gateway.
2. By default, route exporting is enabled on trust-vr.

&KDSWHU9LUWXDO5RXWHUV 5RXWH7DEOH&RQILJXUDWLRQ
5287(7$%/(&21),*85$7,21
The route table provides information that helps the virtual router direct traffic to different interfaces3 and subnets.
You need to define static routes for conditions such as the following:
• If the Trust zone interface or a user-defined interface is on a subnet with more than one router leading to
other subnets, you must define static routes that specify which router to use when forwarding traffic destined
for those subnets.
• If the Untrust zone interface is on a subnet with more than one router leading to multiple Internet
connections, you must define static routes that specify which router to use for forwarding traffic to specific
ISPs.
• You must define static routes that direct management traffic originating from the device itself (as opposed to
user traffic traversing the firewall). For example, you need to define static routes directing syslog, SNMP,
OneSecure, and WebTrends messages to the administrator’s address, authentication requests to the
RADIUS, SecurID, and LDAP servers, and URL checks to the Websense server.
Note: When the NetScreen device is in Transparent mode, you must define a static route for management
traffic from the device even if the destination is on the same subnet as the device. This route is necessary to
specify the interface through which to send traffic.
• For outbound VPN traffic when there is more than one outgoing interface, you need to set a route for
directing the outbound traffic through the desired interface to the external router.
([DPSOH5RXWH7DEOH&RQILJXUDWLRQ
In the following example, a NetScreen device operating in NAT mode protects a multilevel network. There is both
local and remote management (via NetScreen-Global PRO). SNMP traps and syslog reports are sent to the local
administrator, located on a network in the Trust zone, while NetScreen-Global PRO reports are sent to the remote
administrator, located on a network in the Untrust zone. A SecurID server in the DMZ zone is used to authenticate
users, and a Websense server in the Trust zone performs URL blocking.
3. When you set the interface IP addresses for a NetScreen device in NAT mode, the route table automatically creates static routes for traffic traversing the
interfaces.

There must be statements in the Trust-VR and Untrust-VR routing tables specifying the destination network address
4
and netmask, and the gateway IP address and interface through which the NetScreen device directs traffic to the
following destinations:
8QWUXVW95
1. Default gateway to the Internet
2. Remote administrator in the 3.3.3.0/24 subnet
3. The 2.2.40.0/24 subnet in the DMZ zone
4. The 2.20.0.0/16 subnet in the DMZ zone
7UXVW95
5. Untrust-VR for all addresses not found in the Trust-VR
6. The 10.10.0.0/16 subnet in the Trust zone
Note: The following example assumes that you have already bound ethernet1 to the Trust zone, ethernet2
to the DMZ zone, and ethernet3 to the Untrust zone. The interface IP addresses are 10.1.1.1/24,
2.2.10.1/24, and 2.2.2.1/24 respectively.
4. For each route table entry, there is also metric statement of either 0 or 1. This parameter specifies the priority of the route; that is, when there are multiple
route entries for the same subnet in the route table, the NetScreen device uses the one with the lowest metric value. All route table entries that are
automatically created when you enter the interface, subinterface, and tunnel interface addresses have a value of 0, and any user-defined routes have a
default metric value of 1.

Untrust Zone Remote Management

2 NetScreen-Global PRO
Internet 3.3.3.10/32
= Router
1 Untrust-VR
3.3.3.0/24
= Switch/Hub
200.20.2.2/24
2.2.2.2/24 3.3.3.1/24
5 2.2.2.3/24
DMZ Zone
2.2.2.0/24
2.2.10.3/24
Route 2.20.30.1/24
Redistribution NetScreen 2.2.10.0/24
10.1.1.0/24 2.2.10.2/24
2.2.40.1/24 4
10.1.1.2/24 10.1.1.4/24
10.10.30.1/24 10.30.1.1/24 3 2.2.40.0/24 2.20.30.0/24
10.10.40.1/24 10.1.1.3/24
6 10.20.1.1/24 8 2.20.30.2/24
SecurID Server 2.20.3.1/24
7 2.2.45.7/32 2.20.4.1/24
10.10.30.0/24 10.10.40.0/24 10.30.1.0/24
2.20.3.0/24 2.20.4.0/24
10.20.1.0/24
Websense Server
Local Management 10.30.4.7/32
10.10.30.5/32 10.20.1.2/24
10.20.3.1/24
10.20.4.1/24
Trust-VR
10.20.3.0/24 10.20.4.0/24
Trust Zone

:HE8,
8QWUXVW95
1. Routing >> Route Table >> New Entry: Enter the following to create the untrusted default gateway, and then
click OK:
Netmask: 0.0.0.0
Gateway: (select)
2. Routing >> Route Table >> New Entry: Enter the following to direct system reports generated by the
NetScreen device to remote management, and then click OK:
Netmask: 255.255.255.0
Gateway: (select)
Netmask: 255.255.255.0
Gateway: (select)

Interface: DMZ
Netmask: 255.255.0.0
Gateway: (select)
Interface: DMZ
7UXVW95
Netmask: 0.0.0.0
Next Hop Virtual Router Name: (select), untrust-vr
Netmask: 255.255.0.0
Gateway: (select)
Interface: ethernet1(trust-vr)

Netmask: 255.255.0.0
Gateway: (select)
Netmask: 255.255.255.0
Gateway: (select)
Note: To modify a route table entry, click Edit under the Configure section for the entry you want to modify.
The Route Table Configuration dialog box for that entry opens. Make your changes and click OK.
To remove an entry, click Remove. A System Message appears prompting you to confirm the removal.
Click Yes to proceed, or No to cancel the action.

&/,
5. set vrouter trust-vr route 10.10.0.0/16 interface ethernet1 gateway 10.1.1.2
8. save

([DPSOH6HWWLQJD5RXWHIRU7UDIILFWKURXJKD7XQQHO,QWHUIDFH
In this example, a trusted host is in a different subnet than the trusted interface. It is an FTP server that receives
inbound traffic through a VPN tunnel. You need to set a route to direct traffic exiting the tunnel interface to the
internal router leading to the subnet where the server is located.
Trust Interface Untrust Interface FTP Server

ethernet1 ethernet3 (MIP): 210.30.1.2 –> 10.20.2.2
10.20.1.1/24 210.20.1.1/24
Untrust Zone
Trust Zone
Internet
VPN Tunnel 10.20.2.0/24
Tunnel.1
10.30.1.1/24
Router
210.20.1.2/24
:HE8,
1. Routing >> Route Table >> New Entry: Enter the following, and then click Apply:
Netmask: 255.255.255.255
Gateway: (select)
Interface: tunnel.1
Note: For tunnel.1 to appear in the Interface drop-down list, you must first create the tunnel.1 interface.

Netmask: 0.0.0.0
Next Hop Virtual Router name: (select), untrust-vr
Netmask: 0.0.0.0
Gateway: (select)
Interface: ethernet3
&/,
1. set vrouter trust-vr route 10.20.2.2/32 interface tunnel.1
2. set vrouter trust-vr route 0.0.0.0/0 vrouter untrust-vr
4. save


&KDSWHU
%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V

This chapter discusses the concepts common to access policies and Virtual Private Networks (VPNs). The specific
topics discussed are:
• “Addresses” on page 182
– “Address Groups” on page 185
• “Virtual IP” on page 190
• “Users” on page 196
– “User Authentication” on page 204
– “Dialup User Groups” on page 208
– “Group IKE ID” on page 211
• “Services” on page 214
– “H.323 Protocol for Voice-over-IP” on page 218
– “Service Groups” on page 232
• “Schedules” on page 237

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V $GGUHVVHV
$''5(66(6
The NetScreen ScreenOS classifies the addresses of all other devices by location and netmask. Each zone
possesses it’s own list of addresses and address groups.
Individual hosts have only a single IP address defined and are represented by a single computer icon in the WebUI.
Individual hosts must have a netmask setting of 255.255.255.255 (which masks out all but this host).
Subnets have an IP address and a netmask (for example, 255.255.255.0 or 255.255.0.0) and are represented by
multiple computer icons in the WebUI.
Before you can configure access policies to permit, deny, or tunnel traffic to and from individual hosts and subnets,
you must make entries for them in the NetScreen address book.
Note: You do not have to make address book entries for “Any”. This term automatically applies to all devices
physically located within their respective zones.

$GGUHVV%RRN(QWULHV
Before you can set up many of the NetScreen firewall, VPN, and traffic shaping features, you need to define
addresses in the address book. The address book contains the IP addresses or domain names1 of hosts or subnets
whose traffic is either allowed, blocked, encrypted, or user-authenticated.
([DPSOH$GGLQJ$GGUHVVHV
In this example, you add the subnet “Santa Clara Eng” with the IP address 192.10.10.0/24 as an address in the
Trust zone, and the address www.firenet.com as an address in the Untrust zone.
:HE8,
1. Address >> Address >> New Address: Enter the following information, and then click OK:
Address Name: Santa Clara Eng
Netmask: 255.255.255.0
Zone: Trust (select)
2. Address >> Address >> New Address: Enter the following information, and then click OK:
Address Name: FireNet
IP Address/Domain Name: www.firenet.com
Netmask: 255.255.255.255
Zone: Untrust (select)
1. Before you can use domain names for address book entries, you must configure the NetScreen device for Domain Name System (DNS) services. For
information on DNS configuration, see “Domain Name System Support” on page 76.

&/,
1. set address trust “Santa Clara Eng” 192.10.10.0 255.255.255.0
2. set address untrust www.firenet.com 255.255.255.255
3. save
([DPSOH0RGLI\LQJ$GGUHVVHV
In this example, you change the address entry for the host “Santa Clara Eng” to reflect that this host has moved to
Dallas and reassigned an IP address of 192.10.40.0/24.
:HE8,
Address >> Address >> Edit (for Santa Clara Eng): Change the name and IP address to the following, and
then click OK:
Address Name: Dallas Eng
&/,
1. unset address trust “Santa Clara Eng”
2. set address trust “Dallas Eng” 192.10.40.0 255.255.255.0
3. save
Note: After you define an address—or an address group—and associate it with an access policy, you cannot
change the address location to another zone (such as from Trust to Untrust). To change its location, you must first
disassociate it from the underlying access policy.

([DPSOH'HOHWLQJ$GGUHVVHV
In this example, you remove the address entry for the subnet “Dallas Eng.”
:HE8,
Address >> Address: Click Remove in the Configure column for Dallas Eng.
&/,
1. unset address trust “Dallas Eng”
2. save
$GGUHVV*URXSV
The previous section explained how you create, modify, and delete address book entries for individual hosts and
subnets. As you add addresses to the address book, it becomes difficult to manage how access policies affect each
address entry. NetScreen allows you to create groups of addresses. Rather than manage a large number of address
book entries, you can manage a small number of groups. Changes you make to the group are applied to each
address entry in the group.

1 Access Policy per 1 Access Policy per

Address Address Group
The address group option has the following features:

• You can create address groups in any zone.
• You can create address groups with existing users, or you can create empty address groups and later fill
them with users.
• An address group entry can be used like an individual address book entry.
• NetScreen applies access policies to each member of the group by creating individual access policies for
each group member. While you only have to create one access policy for a group, NetScreen actually
creates an access policy for each member in the group (as well as for each service configured for each
user).2
• When an individual address book entry is deleted from the address book, it is also removed from all groups
in which it was referenced.
2. The automatic nature by which the NetScreen device applies access policies to each address group member, saves you from having to create them one by
one for each address. Furthermore, NetScreen writes these access policies to ASIC which makes lookups run very fast.

The following constraints apply to address groups:

• Address groups can only contain addresses that belong to the same zone.
• Address names cannot be the same as group names. If the name “Paris” is used for an individual address
entry, it cannot be used for a group name.
• If an address group is referenced in an access policy, the group cannot be removed. It can, however, be
edited.
• When a single access policy is assigned to an address group, it is applied to each group member
individually, and the NetScreen device makes an entry for each member in the access control list (ACL). If
you are not vigilant, it is possible to exceed the number of available access policy resources, especially if
both the source and destination are address groups.
• You cannot add the predefined addresses: “Any”, “All Virtual IPs,” and “Dial-Up VPN” to groups.
([DPSOH&UHDWLQJDQ$GGUHVV*URXS
In the following example, you create a group named “HQ 2nd Floor” that includes “Santa Clara Eng” and “Tech
Pubs,” two addresses that you have already entered in the address book for the Trust zone.
:HE8,
1. Address >> Address >> Group (under the “New” column, for the zone in which you want to add the address
group).
2. Group Name: HQ 2nd Floor.
3. Select Santa Clara Eng and Tech Pubs from the Available Members column, and then click << to move
your selection to the Group Members column.
4. Click OK.
&/,
1. set group address trust “HQ 2nd Floor” add “Santa Clara Eng”
2. set group address trust “HQ 2nd Floor” add “Tech Pubs”

3. save
([DPSOH(GLWLQJD*URXS$GGUHVV(QWU\
In this example, you add “Support” (an address that you have already entered in the address book) to the “HQ 2nd
Floor” address group.
:HE8,
1. Address >> Address >> Group (for the zone in which the group is located) >> Edit (HQ 2nd Floor).
2. Select Support from the Available Members column, and then click << to move your selection to the Group
Members column.
3. Click OK.
&/,
1. set group address trust “HQ 2nd Floor” add Support
2. save
([DPSOH5HPRYLQJDQ$GGUHVV*URXS0HPEHUDQGD*URXS
In this example, you remove the member “Support” from the HQ 2nd Floor address group, and delete “Sales”, an
address group that you had previously created.
:HE8,
1. Address >> Address >> Group (for the zone in which the group is located) >> Edit (HQ 2nd Floor).
a. Select Support from the Group Members column, and then click >> to move your selection to the
Available Members column.
b. Click OK.
2. Address >> Address >> Group (for the zone in which the group is located) >> Remove (Sales) >> Yes.

&/,
1. unset group address trust “HQ 2nd Floor” remove Support
2. unset group address trust Sales
3. save
Note: The NetScreen device does not automatically delete a group from which you have removed all names.

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V 9LUWXDO,3
9,578$/,3
The Virtual IP (VIP) feature provides network flexibility and security. In a Network Address Translation (NAT)
environment, host computers use non-routable IP addresses inside the firewall while maintaining full Internet
connection and functionality. This feature gives network administrators flexibility to expand their networks without
being constrained by the scarcity of legal IP addresses. In addition, NAT also provides better network security by
hiding internal network topology and host information from the outside world.
However, to maintain some Internet services (for example, e-mail, POP3, FTP), a server with a legal IP address
must be present to service the requests. VIP allows you to map routable IP addresses to internal servers, thereby
providing transparent connections for a NAT network to the Internet. Other benefits of using VIP include:
Scalability: As Internet service demand increases, companies need to improve servers’ performance in order to
maintain the quality of their services. While upgrading the server to a larger, faster machine generally relieves the
short-term pressures, the disruption to services and the prohibitive cost of upgrading quickly make this solution
undesirable.
Reduction in capital cost: Multiple domains and Web servers can be mapped to the same physical server, thus
reducing the cost of computer equipment as well as the associated administration tasks.

A VIP can use the destination port number in the incoming packet header to distinguish it from other kinds of traffic
and route it to the appropriate host on a network within any zone. As seen below, all incoming traffic is destined for
IP address 209.122.17.3, but the destination port numbers dictate the host in the Trust zone to which the NetScreen
device then routes this traffic. The mail server at 172.16.10.251 receives traffic for port 25 (SMTP), the Web server
at 172.16.10.252 receives traffic for port 80 (HTTP), and the FTP server at 172.16.10.253 receives traffic for port 21
(FTP).
FTP Server
Untrust Zone Trust Zone
172.16.10.253
Mail Server
172.16.10.251
Internet IP Packet IP Packet LAN
In IP Header: Destination:
209.122.17.3/ Mail Server
Port 25
Web Server
172.16.10.252
Virtual IP Routing Table

IP in Untrust Port IP in Trust Zone
Zone
209.122.17.3 25 (SMTP) 172.16.10.251
209.122.17.3 80 (WWW) 172.16.10.252
209.122.17.3 21 (FTP) 172.16.10.253
. . . .
. . . .
. . . .

You can also use virtual port numbers for well-known services to increase security. For example, if you only want to
allow employees at a branch office to have access to the FTP server at the corporate site, you can specify a
registered port number from 1024 to 65,535 as the port number for incoming FTP traffic. Any traffic attempting to
reach the FTP server at its well-known port number of 21 is denied. Only those who know the virtual port number in
advance and append it the packet header can gain access.
You need the following information to define a Virtual IP:
• The IP address for the VIP, which must be in the same subnet as the interface of the zone from which traffic
is originating, and can even be the same address as that interface3
• The IP addresses for the servers that process the requests
Note: You can only create a virtual IP for the Untrust zone.
9,3DQGWKH*OREDO=RQH
Setting a VIP for an interface in the Untrust zone generates a book entry in the Global zone address book. The
Global zone address book keeps all the VIPs of all interfaces, regardless of which zone the interfaces belong to. You
can use these VIP addresses as the destination addresses in access policies between any two zones.
3. On some NetScreen devices, an interface in the Untrust zone can receive its IP address dynamically via DHCP or PPPoE. If you want to use a VIP in such
a situation, do either of the following: In the WebUI (Interface >> Physical >> Edit (for an interface in the Untrust zone).

([DPSOH&RQILJXULQJ9LUWXDO,36HUYHUV
In this example, you configure a VIP at 2.2.2.20 to route inbound HTTP traffic to a pool of two Web servers at
172.16.12.10 and 172.16.12.11. (The IP address of the NetScreen device in the Untrust zone is 2.2.2.10/24.) The
port number for HTTP is translated from 80 (the standard protocol ID number) to 1142.
172.16.12.10
Untrust Zone Trust Zone Service: HTTP
VIP: 2.2.2.20
Internet
LAN
IP in Untrust Zone:
2.2.2.10/24
172.16.12.11
Service: FTP
Virtual Port: 1142
:HE8,
1. Interface >> Physical >> VIP (for ethernet3) >> New Entry: Enter the following address, and then click OK:
Virtual IP Address: 2.2.2.20
2. Interface >> Physical >> VIP (for ethernet3) >> Services >> New Entry: Enter the following, and then click
OK:
Virtual Port: 80
Map to Service: HTTP
Map to IP: 172.16.12.10

3. Interface >> Physical >> VIP (for the interface VIP for which you want to configure a service) >> Services >>
New Entry: Enter the following, and then click OK:
Virtual Port: 11424
Map to Service: FTP
Map to IP: 172.16.12.11
&/,
1. set interface ethernet3 vip 2.2.2.20 80 http 172.16.12.10
2. set interface ethernet3 vip 2.2.2.20 1142 ftp 172.16.12.11
3. save
([DPSOH(GLWLQJD9,3&RQILJXUDWLRQ
In this example, you modify the Virtual IP server configuration you just created. In this case, you specify the virtual
port number 2211 for HTTP traffic.
:HE8,
Interface >> Physical >> VIP (for ethernet3) >> Services >> Edit (in the HTTP row): Enter the following, and
then click OK:
Virtual Port: 2211
&/,
1. set interface ethernet3 vip 2.2.2.20 2211 http 172.16.12.10
2. save
4. Using non-standard port numbers adds another layer of security, thwarting attacks that check for services at standard port numbers.

([DPSOH5HPRYLQJD9,3&RQILJXUDWLRQ
In this example, you delete the VIP configuration that you just created and modified.
:HE8,
Interface >> Physical >> VIP (for ethernet3): Click Remove for the appropriate VIP.
&/,
1. unset interface ethernet3 vip 2.2.2.20
2. save
Note: You cannot edit or remove a Virtual IP entry when existing access policies are still associated with it.

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V 8VHUV
86(56
NetScreen supports four kinds of users:
• Authentication User – A network user who must provide a user name and password for authentication when
initiating a connection across the firewall.
• IKE User – A remote VPN user with a dynamically assigned IP address. The user provides his or her identity
using an e-mail address, an IP address, a domain name, or ASN1-DN. The VPN can use either AutoKey
IKE with a preshared key or AutoKey IKE with a certificate.
It is often impractical to create separate user definitions for every host that uses a NetScreen device. In such
circumstances, you can make one user definition available to any host with a local certificate containing a
specified value in a distinguished name field. This technique is known as Group IKE ID. For more
information, refer to “Dialup User Groups” below.
• L2TP User – A remote user whose IP address a NetScreen device assigns from a pool of addresses via
Point-to-Point Protocol (PPP). The NetScreen device communicates with the remote user through PPP
frames encapsulated in L2TP frames.
• Manual Key User – A remote VPN user with a dynamically assigned IP address. The VPN uses the manual
key method for encryption and/or IPSec authentication.
You can also combine the first three kinds of users—Authentication, IKE, L2TP—to create the following four
combinations, referred to later in this chapter as multiple-type users:
• Auth/IKE User – The remote VPN user uses one term for its network authentication password (which must
be one word, alphanumeric, with no symbols), and another term (which can be an e-mail address, IP
address, domain name, or ASN1-DN) for its IKE identity.
• Auth/L2TP User – The remote user uses the same password for network and L2TP authentication.
• Auth/IKE/L2TP User – The remote VPN user uses the same password for network and L2TP authentication,
and another to verify its IKE identity.
• IKE/L2TP User – The remote VPN user uses one term for its L2TP authentication password, and another
term for its IKE identity.

Before traffic from an authentication user can traverse the firewall, and before a remote user can participate in a
VPN, you must create a configuration profile for each one.
Note: For more information on creating VPNs, see “Policy-Based VPNs” on page 375, and “Routing-Based VPNs”
on page 305.
([DPSOH&UHDWLQJ6LQJOH7\SH8VHUV
In this example, you create the following four kinds of users: authentication, IKE, Manual Key, and L2TP.
• Alice: An authentication user with the password Cwb6yooN215
• Bob: An IKE user with the ID bob@netscreen.com
• Christine: An L2TP user with password Mgh13s1N. The NetScreen device assigns the default L2TP settings
to Christine’s computer.
• Dan: A Manual Key VPN dialup user, who is assigned to the dialup user group “Western” and uses 3DES
encryption with SHA-1 authentication
“Charles will be 6 years old on November 21” becomes “Cwb6yooN21.”

:HE8,
$XWK8VHU
1. Users >> Users >> New Auth/IKE/L2TP User: Enter the following, and then click OK:
User Name: Alice
Status: Enable (select)
Authentication User: (select)
User Password: Cwb6yooN21
Confirm Password: Cwb6yooN21
,.(8VHU
User Name: Bob
IKE User: (select)
Simple Identity: (select)
IKE Identity: bob@netscreen.com
/738VHU
User Name: Christine
L2TP User: (select)
User Password: Mgh13s1N
Confirm Password: Mgh13s1N

0DQXDO.H\8VHU
4. Users >> Users >> New Manual Key User: Enter the following, and then click OK:
User Name: Dan
User Group: Western
Security Index: 1000 (Local); 1001 (Remote)
Outgoing Interface: ethernet 1/2
ESP: (select)
ESP-Encryption-Algorithm: 3DES-CBC
Generate Key by Password: W1goAciM32
Authentication Algorithm: SHA-1
Generate Key by Password: TmoR104iVs
&/,
$XWK8VHU
1. set user Alice password Cwb6yooN216
,.(8VHU
2. set user Bob ike-id u-fqdn bob@netscreen.com
/738VHU
3. set user Christine password Mgh13s1N
4. set user Christine type l2tp7
6. When you create a user through the CLI, the user is enabled by default. Note that an L2TP user requires a password to be enabled.
7. If you enter these two commands in the reverse order (that is, set user Christine type l2tp and then set user Christine password Mgh1321N) the user
type automatically becomes AUTH/L2TP.

0DQXDO.H\8VHU
5. set user Dan dialup 1000 1001 esp 3des pass W1goAciM32 auth sha-1 pass TmoR104iVs
6. save
([DPSOH&UHDWLQJ0XOWLSOH7\SH8VHUV
In this example, you create the following multiple-type users by combining authentication user, IKE user, and L2TP
user attributes:
• Elly: An Auth/IKE user with the password T2iF273d and the IKE identity 190.2.2.1
• Fred: An Auth/L2TP user with the password G84t2m13. The NetScreen device assigns the default L2TP
settings to Fred’s computer except for his IP address, which comes from the IP pool “castle.”
• Grace: An Auth/IKE/L2TP user with the password 56mc2Wed and the IKE identity www.netscreen.com
• Harry: An IKE-L2TP user with the password Qbls462R and the IKE identity harry@ha.com. Harry gets his
address from the IP pool “wizard” and uses DNS servers 204.11.2.3 (primary) and 204.11.2.8 (secondary).

:HE8,
$XWK,.(8VHU
User Name: Elly
IKE User: (select)
IKE Identity: 190.2.2.1
User Password: T2iF273d
Confirm Password: T2iF273d
$XWK/738VHU
User Name: Fred
L2TP User: (select)
Password: G84t2m13
Confirm Password: G84t2m13
L2TP Remote Settings: IP Pool (select); castle

$XWK,.(/738VHU
User Name: Grace
IKE User: (select)
IKE Identity: www.netscreen.com
Auth User: (select)
L2TP User: (select)
User Password: 56mc2Wed
Confirm Password: 56mc2Wed
,.(/738VHU
User Name: Harry
IKE User: (select)
IKE Identity: harry@ha.com
L2TP User: (select)
User Password: Qbls462R

Confirm Password: Qbls462R

L2TP Remote Settings:
IP Pool (select): wizard
Primary DNS IP: 204.11.2.3
Secondary DNS IP: 204.11.2.8
&/,
$XWK,.(8VHU
1. set user Elly password T2iF273d
2. set user Elly ike-id ip 190.2.2.1
$XWK/738VHU
3. set user Fred password G84t2m13
4. set user Fred type auth l2tp
5. set user Fred remote-settings ippool castle
$XWK,.(/738VHU
6. set user Grace password 56mc2Wed
7. set user Grace ike-id fqdn www.netscreen.com
8. set user Grace type auth ike l2tp
,.(/738VHU
9. set user Harry password Qbls462R
10. set user Harry ike-id u-fqdn harry@ha.com
11. set user Harry type ike l2tp
12. set user Harry remote-settings ippool castle

13. set user Harry remote-settings dns1 204.11.2.3

14. set user Harry remote-settings dns2 204.11.2.8
15. save
8VHU$XWKHQWLFDWLRQ
There are a number of different protocols that your NetScreen device can use to verify that a user is who they say
they are. These different techniques are discussed in this section.
,QWHUQDO'DWDEDVH
A VPN dialup user The NetScreen device uses its

requests internal database to authenticate the
a connection to the dialup VPN user before approving
protected network. the connection request.
All NetScreen devices support a built-in user database for authentication. After entering the user name and
password in the database, you must create an access policy that requires a user to authenticate him or herself when
initiating a specified connection (for example, outbound or inbound HTTP, or Telnet traffic). When the user attempts
to initiate traffic for which the access policy applies, he or she is prompted to enter his or her name and password.
Before granting permission, the NetScreen device validates the user name and password by checking them against
those stored in the database.

5$',86
A VPN dialup user

requests
a connection to the The NetScreen device uses an
protected network. external RADIUS server to
authenticate the
dialup VPN user before approving
the connection request.
The Remote Authentication Dial-In User Service (RADIUS) is a protocol for an authentication server which can be
modified to run on different kinds of networks, and makes it easy and efficient to manage large modem pools. The
focus for RADIUS is the remote user who needs to dial into the network.
RADIUS uses an authentication server to solve the security problems associated with remote computing. Distributed
security separates user authentication and authorization from the communications process and creates a single,
central location for user authentication data.
One RADIUS server can support up to tens of thousands of users, making it a very practical service for rapidly
growing networks.
The RADIUS client (that is, the NetScreen device) authenticates users through a series of communications between
the client and the server. Basically, RADIUS asks the person logging on to enter his or her user name and
password. It then compares these values to those in its database, and once a user is authenticated, the client
provides the user with access to the appropriate network services.

6HFXU,'
The relationship of NetScreen device and a Security Dynamics Technologies® SecurIDACE server is similar to
that of a NetScreen device and a RADIUS server; that is, the NetScreen device acts as a client, forwarding
authentication requests to the external server for approval. SecurID differs from RADIUS in that the user password
involves a continually changing string of numbers.
A VPN dialup user

requests
a connection to the
protected network.
The NetScreen device uses an
external SecurID server to
authenticate the
dialup VPN user before approving
the connection request.
SecurID issues a credit card sized device with an LCD window that displays a randomly generated string of numbers
that changes every minute. There is no other information on the card besides the number in the LCD display.

Security Dynamics issues a card and a personal ID number (PIN) to a registered user and maintains the user profile
in their database. When the user is prompted to authenticate himself, he enters his name and password, which is his
PIN followed by the string of numbers currently displayed on his card. The numbers displayed on the card change
every minute. The values that display are generated by an algorithm known only by Security Dynamics. This value is
saved to the Security Dynamics database entry for this PIN. When the user to be authenticated enters his PIN and
the number on his card, Security Dynamics compares these values to those in the database. If they match, the user
is authenticated.
/LJKWZHLJKW'LUHFWRU\$FFHVV3URWRFRO
A VPN dialup user

requests
a connection to the
protected network.
The NetScreen device uses an
external LDAP server to
authenticate the dialup VPN user
before approving the
connection request.
Lightweight Directory Access Protocol (LDAP) is a directory server standard developed by Netscape® to help
authenticate users attempting to connect to networks controlled by directory servers.
LDAP is a client-server protocol for accessing a directory service. You can use it as a front-end to X.500, as a
stand-alone protocol, or as a directory server.
LDAP does not require the upper layers of the OSI stack, it is a simpler protocol to implement (especially in clients),
and LDAP is under IETF change control and so can more easily evolve to meet Internet requirements.

The LDAP information model is based on the entry, which contains information about some object (for example, a
person). Entries are composed of attributes, which have a type and one or move values. Each attribute has a syntax
that determines what kind of values are allowed in the attribute and how those values behave during directory
operations.
'LDOXS8VHU*URXSV
VPNs allow remote dialup users to traverse firewalls from anywhere in the world and access data in a secure
environment. A VPN tunnel connection from a dialup user to a corporate site assures security as well as access.
1 Access Policy 1 Access Policy per

per VPN Dialup User
To manage a number of remote dialup users, NetScreen enables you to create dialup user groups. Rather than
manage each user individually, you can aggregate users into a group. Changes you make to the group are then
propagated to each group member. The examples that follow illustrate how to create new dialup user groups and
then add users to it. Other examples show how to remove members from a group, move members from one group to
another, and delete a group.

([DPSOH'HILQLQJD1HZ'LDOXS8VHU*URXSDQG$GGLQJD0HPEHU
In this example, you define a new remote IKE/L2TP dialup user group named Tahoe. You then add an IKE user
named Bob to the group.
:HE8,
1. Users >> Dialup Group >> New Group.
2. Group Name: Tahoe.
3. Group Type: IKE/L2TP.
4. Click Add Members.
5. Select Bob from the Available Members column, and then click << to move your selection to the Group
Members column.
6. Click OK.
Note: To add a user to the group later, you can do either of the following:
• Users >> Users >> Edit (Bob): Select Tahoe from the User Group drop-down list, and then click OK.
• Users >> Dialup Group >> Edit (Tahoe): Select Bob from the Available Members column, click <<,
and then click OK
&/,
1. set dialup-group Tahoe + Bob
2. save

([DPSOH5HPRYLQJD*URXS0HPEHU
In this example, you remove Bob from the Tahoe dialup user group.
:HE8,
Users >> Dialup Group >> Edit (for Tahoe): Select Bob in the Group Members column, click >> to move
Bob to the Available Members column, and then click OK.
Note: You can also remove Fred from the group as follows:
• Users >> Users >> Edit (for Bob): In the User Group drop-down list, select None, and then
click OK.
&/,
1. set dialup-group Tahoe - Bob
2. save
([DPSOH0RYLQJD*URXS0HPEHUWR$QRWKHU*URXS
In this example, you move Bob from the group Tahoe to the group Santa Cruz.
:HE8,
Users >> Users >> Edit (for Bob): In the User Group drop-down list, select Santa Cruz, and then click OK.
&/,
1. set dialup-group Tahoe - Bob
2. set dialup-group “Santa Cruz” + Bob
3. save

([DPSOH5HPRYLQJD*URXS
In this example, you delete the dialup group Tahoe.
:HE8,
Users >> Dialup Group: Click Remove (for Tahoe).
&/,
1. unset dialup-group Tahoe
2. save
*URXS,.(,'
Some organizations have many hosts that need to exchange traffic through a single NetScreen device. For
example, a Marketing department might have hundreds of users, each requiring secure Internet communication
through a NetScreen device. With so many users, it is impractical to create a separate user definition for each host
machine.
To avoid this difficulty, the Group IKE ID method makes one user definition available to multiple hosts. This user
definition applies to all hosts having certificates with specified values in the distinguished name (DN).
In the following example, a user’s certificate has “Organization=ACME” and “OU=Marketing” in the distinguished
name:
Country =US
State=CA
Location =Santa Clara
Organization =ACME
OU=Marketing
CN=Michael Zhang
CN=a2010002

CN=ns500
CN=(408) 555-7800
CN=rsa-key
CN=10.10.5.44
Using Group IKE ID, you can configure a user definition to automatically accept tunnel connections from any host
having such a certificate. The hosts can establish secure communication through the NetScreen device, without a
separate user definition for each host. Because these users have valid, non-revoked certificates containing the
necessary distinguished name values, authentication of these users is implicit.
Note: It is impossible to use Group IKE ID while using a Preshared Key.
([DPSOH'HILQLQJD8VHU'HILQLWLRQWR8VH*URXS,.(,'
In this example, you create a new user definition named Market_Dept, and configure it to concurrently accept
tunnels from up to 10 hosts having certificates that match specific distinguished name fields. This user definition
recognizes any host with a certificate containing “Organization=ACME” and “OU=Marketing” in the O and OU fields
respectively.
Note: The user in this example must be in a dial-up group, and must setup the VPN gateway using this dial-up
group.
:HE8,
1. Users >> Users >> New Auth/IKE/L2TP User: Enter the following, then click OK:
User Name: Market_Dept
Status: Enable
IKE User: Enabled
Numbers of Multiple Login with same ID: 10
2. Select the Use Distinguished Name For ID radio button. This displays the distinguished name fields for the
certificate.

3. Enter ACME in the Organization field.

4. Enter Marketing in the OU field.
5. Click OK.
&/,
set user “marketing” ike-id asn1-dn wildcard “o=ACME,ou=Marketing” share-limit 10
Note: This command is only applicable to systems that use IKE dial-up

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V 6HUYLFHV
6(59,&(6
Services are types of IP traffic for which protocol standards exist. Each service has a port number associated with it,
such as 21 for FTP and 23 for Telnet. This section is meant as a brief overview of services available, and does not
cover each one of them in depth except for “H.323 Protocol for Voice-over-IP” on page 218.
The illustration below shows the services supported in this version of ScreenOS. For information on each service,
hold your cursor over the service icon. In this illustration, the mouseover information block is displayed for
X-Windows.

When you create an access policy, you must specify a service for it. You can select one of the pre-configured
services from the service book, or a custom service or service group that you created. You can see which service
you can use in an access policy by examining the Service drop-down List in the Policy Configuration dialog box
(WebUI), or by using the get service command (CLI).
The following section provides examples for viewing the service book and for creating, modifying, and deleting
custom services.
([DPSOH9LHZLQJWKH6HUYLFH%RRN
In this example, you view the predefined and custom services in the service book.
:HE8,
1. Service >> Pre-defined
2. Service >> Custom
&/,
get service
The output from the CLI is similar to that shown below.
Individual Services:
Name Proto Port Group Timeout Flag

ANY 0 0/65535 other 0 Pre-defined
AOL 6 5190/5194 remote 0 Pre-defined
BGP 6 179 other 0 Pre-defined
DHCP-Relay 17 67 info seeking 0 Pre-defined
DNS 17 53 info seeking 0 Pre-defined
FINGER 6 79 info seeking 0 Pre-defined

Name Proto Port Group Timeout Flag

FTP 6 21 remote 0 Pre-defined
FTP-Get 6 21 remote 0 Pre-defined
FTP-Put 6 21 remote 0 Pre-defined
GOPHER 6 70 info-seeking 0 Pre-defined
H.323 6 389 remote 0 Pre-defined
--- more ---
([DPSOH$GGLQJD&XVWRP6HUYLFH
To add a custom service to the service book, you need the following information:
• A name for the service, in this example “corp”
• A range of internal port numbers valid for the service. For example, 1500-10000.
• A range of external port numbers to receive the service request; for example, 15000-25000.
• Whether the service uses TCP or UDP protocol, or some other protocol as defined by the Internet
specifications. In this example, the protocol is TCP.
:HE8,
Service >> Custom >> New Service: Enter the following, and then click OK:
Service Name: corp
Source Port Low: 1500
Source Port High: 1500
Destination Port Low: 15000
Destination Port High: 15000
Transport: TCP (select)

&/,
1. set service corp protocol tcp src-port 1500-1500 dst-port 15000-55000
2. set service corp timeout 30
3. save
([DPSOH0RGLI\LQJD&XVWRP6HUYLFH
In this example, you change the custom service corp. In this case, the transport changes from TCP to UDP, and the
source port range changes to 1 through 1000.
Use the set service <name> clear command to remove the definition of a custom service without removing the
service from the service book:
:HE8,
Service >> Custom >> New Service: Enter the following and then click OK:
Service Name: corp
Source Port Low: 1
Source Port High: 1000
Destination Port Low: 15000
Destination Port High: 15000
Transport: UDP (select)
&/,
1. set service corp clear
2. set service corp protocol udp src-port 1-1000 dst-port 15000-15000
3. save

([DPSOH5HPRYLQJD&XVWRP(QWU\
In this example, you remove the custom service “corp”.
:HE8,
Service >> Custom: Click Remove in the Configure column for “corp”.
&/,
1. unset service corp
2. save
+3URWRFROIRU9RLFHRYHU,3
To allow secure Voice-over-IP (VoIP) communication between terminal hosts, NetScreen devices support H.323
protocol. In such a telephony system, gatekeeper devices manage call registration, admission, and call status for
VoIP calls. Gatekeepers can reside on the NetScreen device’s trusted side, the untrusted side, or both.
Gatekeeper Gatekeeper
Allowed
Internet
Trust Zone
Allowed
Untrust Zone
Endpoint Endpoint

([DPSOH*DWHNHHSHULQWKH7UXVW=RQH7UDQVSDUHQWRU5RXWH0RGH
In the following example, you set up two policies. Together, these policies allow H.323 traffic to pass between IP
phone hosts and a gatekeeper in the Trust zone, and an IP phone host (209.16.2.2) in the Untrust zone. In this
example, the NetScreen device can be in either Transparent mode or Route mode.
Gatekeeper
Internet
IP Phones Endpoint Endpoint

IP Phone
209.16.2.2
:HE8,
1. Address >> Address (under the “New” column for the Untrust zone): Enter the following, and then click OK:
Address Name: IP_Phone
Netmask:255.255.255.255
Zone: Untrust
2. Policy >> Policy (From Zone Trust, To Zone Untrust) New Policy: Enter the following, and then click OK:
Source Address: Any
Destination Address: IP_Phone
Service: H.323
Action: Permit

3. Policy >> Policy (From Zone Untrust, To Zone Trust) New Policy: Enter the following, and then click OK:
Source Address: IP_Phone
Service: H.323
Action: Permit
&/,
1. set address untrust IP_Phone 209.16.2.2/32
2. set policy from trust to untrust any IP_Phone h.323 permit
3. set policy from untrust to trust IP_Phone any h.323 permit
4. save
([DPSOH*DWHNHHSHULQWKH7UXVW=RQH1$70RGH
When the NetScreen device is in NAT mode, a gatekeeper or endpoint device is said to be private when it resides
on the trusted side, and public when it resides on the untrusted side. When you set a NetScreen device in NAT
mode, you must map a public IP address to each private device.

In this example, the devices in the Trust zone include the endpoint host (10.10.1.2/32) and the gatekeeper device
(10.10.1.10/32). IP_Phone2 (200.20.1.2/32) is in the Untrust zone. You configure the NetScreen device to allow
traffic between the endpoint host IP_Phone1 and the gatekeeper in the Trust zone and the endpoint host IP_Phone2
(210.10.1.2) in the Untrust zone.
Trust Zone ethernet3 Untrust Zone

ethernet1 210.10.1.1/24
10.10.1.1/24 Gateway
210.10.1.2
Gatekeeper
10.10.1.10/32
IP_Phone1 IP_Phone2
10.10.1.2/32 200.20.1.2/32
MIP 210.10.1.10 -> 10.10.1.10

MIP 210.10.1.2 -> 10.10.1.2
:HE8,
,QWHUIDFHV²6HFXULW\=RQHV
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
Netmask: 255.255.255.0

Zone Name: Untrust

$GGUHVVHV
3. Address >> Address (under the “New” column for the Trust zone): Enter the following, and then click OK:
Address Name: IP_Phone1
Netmask: 255.255.255.255
Zone: Trust
Address Name: Gatekeeper
Netmask: 255.255.255.255
Zone: Trust
Netmask: 255.255.255.255
Zone: Untrust

0DSSHG,3$GGUHVVHV
6. Interface >> MIP (for ethernet3) >> New Entry: Enter the following, and then click OK:
Mapped IP Address: 210.10.1.2
Netmask: 255.255.255.255
Host IP Address: 10.10.1.2
Host Virtual Router Name: trust-vr
7. Interface >> MIP (for ethernet3) >> New Entry: Enter the following, and then click OK:
Netmask: 255.255.255.255
Host Virtual Router Name: trust-vr
5RXWHV
Netmask: 0.0.0.0
Hop Virtual Router Name: (select), untrust-vr
Netmask: 0.0.0.0

3ROLFLHV
Source Address: IP_Phone1
Destination Address: Phone2
Service: H.323
Action: Permit
Source Address: Gatekeeper
Destination Address: Phone2
Service: H.323
Action: Permit
12. Policy >> Policy (From Zone Untrust, To Zone Trust) >> New Policy: Enter the following, and then click OK:
Destination Address: MIP(210.10.1.10)
Service: H.323
Action: Permit
Service: H.323
Action: Permit

&/,
3. set interface ethernet1 nat
$GGUHVVHV
6. set address trust IP_Phone1 10.10.1.2/32
7. set address trust gatekeeper 10.10.1.10/32
8. set address untrust IP_Phone2 200.20.1.2/32
0DSSHG,3$GGUHVVHV
9. set interface ethernet3 mip 210.10.1.2 host 10.10.1.2
5RXWHV
3ROLFLHV
13. set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
14. set policy from trust to untrust gatekeeper IP_Phone2 h.323 permit
15. set policy from untrust to trust IP_Phone2 mip(210.10.1.2) h.323 permit
16. set policy from untrust to trust IP_Phone2 mip (210.10.1.10) h.323 permit
17. save

([DPSOH*DWHNHHSHULQWKH8QWUXVW=RQH7UXVW=RQHLQ7UDQVSDUHQWRU5RXWH0RGH
Because Transparent mode and Route mode do not require address mapping of any kind, NetScreen device
configuration for a gatekeeper on the untrusted side is usually identical to the configuration for a gatekeeper on the
trusted side.
In the following example, you set up two policies to allow H.323 traffic to pass between IP phone hosts (and the
gatekeeper) on the trusted side, and the IP phone at IP address 209.16.2.2 on the untrusted side. The device can be
in Transparent or Route mode.
Gatekeeper
Internet
IP_Phones IP_Phone
209.16.2.2/32
:HE8,
Address Name: IP_Phone
Netmask:255.255.255.255
Zone: Untrust

Source Address: Any
Destination Address: IP_Phone
Service: H.323
Action: Permit
Source Address: IP_Phone
Service: H.323
Action: Permit
&/,
1. set address untrust IP_Phone 209.16.2.2/32
2. set policy from trust to untrust any IP_Phone h.323 permit
3. set policy from untrust to trust IP_Phone any h.323 permit
4. save

([DPSOH*DWHNHHSHULQWKH8QWUXVW=RQH7UXVW=RQHLQ1$70RGH
In this example, the gatekeeper device (210.10.1.10/32) and host IP_Phone2 are in the Untrust zone and host
IP_Phone1 is in the Trust zone. You configure the NetScreen device to allow traffic between host IP_Phone1 on the
trusted side, and (and the gatekeeper) on the untrusted side.
ethernet1 ethernet3
10.10.1.1/24 210.10.1.1/24
NAT Mode Gateway 210.10.1.2 Untrust Zone
Trust Zone
Internet
Gatekeeper
IP_Phone1 210.10.1.10/32 IP_Phone2
10.10.1.2/32 200.20.1.2/32
MIP 210.10.1.2 -> 10.10.1.2
:HE8,
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
Netmask: 255.255.255.0
Zone Name: Untrust

$GGUHVVHV
Netmask: 255.255.255.255
Zone: Trust
Address Name: Gatekeeper
Netmask: 255.255.255.255
Zone: Untrust
Netmask: 255.255.255.255
Zone: Untrust
0DSSHG,3$GGUHVV
6. Interface >> (Interface bound to Untrust zone >> MIP >> New Entry: Enter the following, and then click OK:
Netmask: 255.255.255.255

5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
3ROLFLHV
9. Policy >> Policy (From Zone Trust ,To Zone Untrust) >> New Policy: Enter the following, and then click OK:
Destination Address: IP_Phone2
Service: H.323
Action: Permit
10. Policy >> Policy (From Zone Trust ,To Zone Untrust) >> New Policy: Enter the following, and then click OK:
Destination Address: Gatekeeper
Service: H.323
Action: Permit

Service: H.323
Action: Permit
Source Address: Gateway
Service: H.323
Action: Permit
&/,
$GGUHVVHV
6. set address trust IP_Phone1 10.10.1.2/32
7. set address untrust gatekeeper 210.10.1.10/32
8. set address untrust IP_Phone2 200.20.1.2/32

0DSSHG,3$GGUHVVHV
5RXWHV
3ROLFLHV
12. set policy from trust to untrust IP_Phone1 IP_Phone2 h.323 permit
13. set policy from trust to untrust IP_Phone1 gatekeeper h.323 permit
14. set policy from untrust to trust IP_Phone2 mip(210.10.1.2) h.323 permit
15. set policy from untrust to trust gatekeeper mip(210.10.1.2) h.323 permit
16. save
6HUYLFH*URXSV
A service group is a set of services that you have gathered together under one name. After you create a group
containing several services, you can then apply services at the group level to access policies, thus simplifying
administration.
The NetScreen service group option has the following features:
• Each service book entry can be referenced by one or more service groups.
• Each service group can contain pre-defined and user-defined service book entries.
• Each service group can be referenced by other service groups, providing that a group referencing other
groups does not include itself in the reference list.
Service groups are subject to the following limitations:
• Service groups cannot have the same names as services; therefore, if you have a service named “FTP,”
you cannot have a service group named “FTP.”

• If a service group is referenced in an access policy, you can edit the group but you cannot remove it until
you have first removed the reference to it in the access policy.
• If a custom service book entry is deleted from the service book, the entry is also removed from all the groups
in which it was referenced.
• The all-inclusive service term “ANY” cannot be added to groups.
([DPSOH&UHDWLQJD6HUYLFH*URXS
This example illustrates how you create a custom service named Wiget that supports IKE, FTP, and LDAP services.
:HE8,
1. Service >> Custom >> New Group.
2. Group Name: Wiget.
3. Select IKE, FTP, and LDAP from the Available Members column, and then click << to move your selection
to the Group Members column.
4. Click OK.
&/,
1. set group service Wiget
2. set group service Wiget add ike
3. set group service Wiget add ftp
4. set group service Wiget add ldap
5. save
Note: If you attempt to add a service to a service group that does not exist, the NetScreen device creates the group.
Also, ensure that groups referencing other groups do not include themselves in the reference list.

([DPSOH0RGLI\LQJD6HUYLFH*URXS
Although you cannot modify any of the pre-defined NetScreen services, you can modify existing user-defined
custom services and service groups.
In this example, you change the existing user-defined services from IKE, FTP, and LDAP to HTTP, FINGER, IMAP,
and H.323 protocols.
:HE8,
1. Service >> Custom >> Edit (Wiget).
2. Select IKE, FTP, and LDAP from the Group Members column, and then click >> to move your selection to
the Available Members column.
3. Select HTTP, FINGER, IMAP and H.323 from the Available Members column, and then click << to move
your selection to the Group Members column.
4. Click OK.
&/,
1. clear group service Wiget
2. set group service Wiget add http
3. set group service Wiget add finger
4. set group service Wiget add imap
5. set group service Wiget add h.323
6. save

([DPSOH5HPRYLQJD6HUYLFH
Although you cannot remove any of the pre-defined NetScreen services, you can remove existing user-defined
custom services and service groups.
In this example, you delete HTTP from the service group Wiget.
:HE8,
Service >> Custom >> Edit (for Wiget): Move the following service, and then click OK:
Group Members >> Available Members:
HTTP
&/,
1. unset group service Wiget remove http
2. get service Wiget
3. save

([DPSOH5HPRYLQJD6HUYLFH*URXS
In this example, you delete the service group Wiget.
:HE8,
Service >> Custom: Click Remove (for Wiget).
&/,
1. unset group service Wiget
2. save
Note: The NetScreen device does not automatically delete a group from which you have removed all members.

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHVDQG931V 6FKHGXOHV
6&+('8/(6
A schedule is a configurable object that you can associate with one or more access policies to define when they are
in effect. Through the application of schedules, you can control network traffic flow and enforce network security.
When you define a schedule, enter values for the following parameters:
Schedule Name: The name that appears in the Schedule drop-down list in the Policy Configuration dialog
box. Choose a descriptive name to help you identify the schedule. The name must be unique and is limited
to 19 characters.
Comment: Any additional information that you want to add.
Recurring: Enable this when you want the schedule to repeat on a weekly basis.
Start and End Times: You must configure both a start time and an end time. You can specify up to
two time periods within the same day.
Once: Enable this when you want the schedule to start and end only once.
mm/dd/yyyy hh:mm: You must enter both start and stop dates and times.
([DPSOH5HFXUULQJ6FKHGXOH
In this example, there is a short-term marketing employee named Tom who is using the company’s Internet access
for personal pursuits after work. You create a schedule for non-business hours that you can then associate with an
access policy to deny outbound TCP/IP traffic from that worker’s computer (10.10.4.5/24) outside of regular
business hours.
:HE8,
1. Schedule >> Schedule >> New Schedule: Enter the following, and then click OK:
Schedule Name: After Hours
Comment: For non-business hours
Recurring: (select)

Period 1:
Week Day Start Time End Time

Sunday 00:00 23:59
Monday 00:00 06:00
Tuesday 00:00 06:00
Wednesday 00:00 06:00
Thursday 00:00 06:00
Friday 00:00 06:00
Saturday 00:00 23:59
Period 2:
Week Day Start Time End Time

Sunday 17:00 23:59
Monday 17:00 23:59
Tuesday 17:00 23:59
Wednesday 17:00 23:59
Thursday 17:00 23:59
Friday 17:00 23:59
Saturday 17:00 23:59
2. Address >> Address >> Address (under the “New” column for the appropriate zone): Enter the following,
and then click OK:
Address Name: Tom
Netmask: 255.255.255.255

Comment: Temp
Location: Trust
3. Policy >> From Zone: Marketing, To Zone: Untrust >> New Policy: Enter the following, and then click OK:
Name: No Net
Source Address: Tom
Service: HTTP
Action: Deny
Schedule: After Hours
&/,
1. set schedule “after hours” recurrent sunday start 00:00 stop 23:59
2. set schedule “after hours” recurrent monday start 00:00 stop 06:00 start 17:00 stop 23:59
3. set schedule “after hours” recurrent tuesday start 00:00 stop 06:00 start 17:00 stop 23:59
4. set schedule “after hours” recurrent wednesday start 00:00 stop 06:00 start 17:00 stop 23:59
5. set schedule “after hours” recurrent thursday start 00:00 stop 06:00 start 17:00 stop 23:59
6. set schedule “after hours” recurrent friday start 00:00 stop 06:00 start 17:00 stop 23:59
7. set schedule “after hours” recurrent saturday start 00:00 stop 23:59 comment “for non-business hours”
8. set address trust tom 10.10.4.5 255.255.255.0 “temp”
9. set policy from marketing to untrust tom any http deny schedule “after hours”
10. save


&KDSWHU
$FFHVV3ROLFLHV

By default, a NetScreen device denies all traffic in all directions. Through the creation of access policies, you can
control the traffic flow across an interface by defining the kinds of traffic permitted to pass from one security zone to
another.
This chapter describes what access policies do and how the various elements that comprise an access policy are
related. It is divided into the following two main sections:
• “Access Policies Defined” on page 242
• “Access Policies Applied” on page 251

&KDSWHU$FFHVV3ROLFLHV $FFHVV3ROLFLHV'HILQHG
$&&(6632/,&,(6'(),1('
A firewall provides a network boundary with a single point of entry and exit—a choke point. Because all incoming
and outgoing traffic must pass through the choke point, you can screen and direct all that traffic through the
implementation of a set of access policies—the Access Control List (ACL).
Access 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.
Warning: Access policies set in the root system of certain NetScreen devices do not affect access policies set in
Virtual Systems.

$QDWRP\RID3ROLF\
An access policy must contain the following elements:
• Zones (source and destination)
• Addresses (source and destination)
• Service
• Action (permit, deny, tunnel)
An access policy can also contain the following elements:
• Network Address Translation (NAT), using Dynamic IP (DIP) pools
• VPN tunneling
• Layer 2 Transfer Protocol (L2TP) tunnel
• Authentication
• Logging
• Counting
• Traffic alarm settings
• Scheduling
• Traffic shaping
The remainder of this section examines each of the above elements in turn.

Policy Configuration
Dialog Box
Note: This
option appears
when the
Action is
Tunnel and a
VPN tunnel is
selected.
Note: In
Transparent
mode, these
features are not
available.

=RQHV
A zone can be a segment of network space to which security measures are applied (a security zone), a
logical segment to which a VPN tunnel interface is bound (a tunnel zone), or either a physical or logical
entity that performs a specific function (a function zone). An access policy allows traffic to flow between two
zones. An access policy enters and exits a zone via an interface or subinterface that is bound to that zone.
For more information on zones, see “Zones” on page 31. For more information on interfaces, see
“Interfaces” on page 39.
$GGUHVVHV
Addresses are objects that identify network devices such as hosts and networks by their location in relation
to the firewall—in one of the security zones. Individual hosts are specified using the mask 255.255.255.255,
indicating that all 32 bits of the address are significant. Networks are specified using their subnet mask to
indicate which bits are significant. To create an access policy for specific addresses, you must first create
entries for the relevant hosts and networks in the address book.
You can also create address groups and apply access policies to them as you would to other address book
entries. When using address groups as elements of access policies, be aware that because the NetScreen
device applies the access policy to each address in the group, the number of available access policies can
become depleted more quickly than expected. This is a danger especially when you use address groups for
both the source and destination.
6HUYLFHV
Services are objects that identify application protocols using layer 4 information such as standard and
accepted TCP and UDP port numbers for application services like Telnet, FTP, SMTP, and HTTP. The
ScreenOS includes predefined core Internet services. Additionally, you can define custom services.
You can define access policies that specify which services are permitted, denied, encrypted, authenticated,
logged, or counted, and which transmit alarm messages.

$FWLRQV
Actions are objects that describe what the firewall does to the traffic it receives.
– Permit allows the packet to pass the firewall.
– Deny blocks the packet from traversing the firewall.
– Tunnel encapsulates outgoing IP packets and decapsulates incoming IP packets. For an IPSec VPN
tunnel, specify which VPN tunnel to use. For an L2TP tunnel, specify which L2TP tunnel to use. For
L2TP-over-IPSec, specify both an IPSec VPN tunnel and an L2TP tunnel1.
The NetScreen device applies the specified action on traffic that matches the first two criteria: addresses
(source and destination) and service.
1HWZRUN$GGUHVV7UDQVODWLRQ1$7
You can apply NAT at the interface level or at the policy level. With policy-based NAT, you can translate the
source address on either incoming or outgoing network and VPN traffic. The new source address can come
from either a Dynamic IP pool or from a Mapped IP (for incoming network traffic and incoming and outgoing
VPN traffic).
9317XQQHO
You can apply a single access policy or multiple access policies to any VPN tunnel that you have
configured. In the WebUI, the VPN Tunnel option provides a drop-down list of all such tunnels. In the CLI,
you can see all available tunnels with the get vpn command. (For more information, see “VPNs” on page
15.)
When the VPN configuration at both ends of a VPN tunnel are using policy-based-NAT, then the
administrators of both gateway devices each need to create an inbound and an outbound access policy
(four policies in total). When the VPN policies constitute a matching pair (that is, everything in the inbound
and outbound policy configurations is the same except that the source and destination addresses are
reversed), you can configure one policy and then select the Create matching VPN policy check box to
1. For L2TP-over-IPSec, the source and destination addresses for the IPSec VPN tunnel must be the same as those for the L2TP tunnel.

create a second policy automatically for the opposite direction. For the configuration of a new policy, the
matching VPN policy check box is cleared by default. For the modification of an existing policy that is a
member of a matching pair, the check box is selected by default, and any changes made to one policy are
propagated to the other. (Note that this option is only available through the WebUI.)
/73
You can apply a single access policy or multiple access policies to any Layer 2 Tunneling Protocol (L2TP)
tunnel that you have configured. In the WebUI, the L2TP option provides a drop-down list of all such tunnels.
In the CLI, you can see all available tunnels with the get l2tp all command. You can also combine a VPN
tunnel and an L2TP tunnel—if both have the same endpoints—to create a tunnel combining the
characteristics of each. This is called L2TP-over-IPSec.
Note: L2TP is not supported in Transparent mode.
$XWKHQWLFDWLRQ
Selecting this option requires the user at the source address to authenticate his/her identity by supplying a
user name and password before traffic is allowed to traverse the firewall or enter the VPN tunnel. The
NetScreen device can use the internal user database or an external RADIUS, SecurID, or LDAP server to
perform the authentication check.
Here’s a brief description of the authentication process. First the user sends a HTTP, FTP or Telnet
connection request to the destination address, which the NetScreen device intercepts. The NetScreen
device then sends the user a “Firewall Login/Password” prompt. The user responds to this prompt by
entering his/her firewall login and password, and sending it. The NetScreen device authenticates the user’s
firewall login and password, and if the authentication is successful, a connection is established between the
user and the destination address.
For the initial connection request, a policy must include one or all of the three following services: Telnet,
HTTP, or FTP. Only a policy with one or all of these services is capable of initiating the authentication
process. You can set a policy service to “any” (because it includes all three required services), or you can
set it to either Telnet, FTP, or HTTP. For any connection following a successful authentication, all services
specified in the policy are valid.

If you want a policy to only include one service or a set of services other than Telnet, FTP, or HTTP, you can
create a service group that includes the service or services you want, plus one or more of the required three
services (required to initiate the authentication process).
For example, you can create a custom service group named “Login” that supports FTP, Netmeeting, and
H.323 services. Then, when you set the policy, you specify “Login” as the service.
This only applies to policies that include the authentication option.
/RJJLQJ
When you enable logging in an access policy, the NetScreen device logs all connections to which that
particular access policy applies. You can view the logs through either the WebUI or CLI, and the graphs in
the Monitor section of the WebUI.
Note: For more information about viewing logs and graphs, see “Monitoring NetScreen Devices” on page
147.
&RXQWLQJ
When you enable counting in an access policy, the NetScreen device counts the total number of bytes of
traffic to which this access policy applies and records the information in historical graphs.
$ODUP7KUHVKROG
You can set a threshold that triggers an alarm when the traffic permitted by the access policy exceeds a
specified number of bytes per second, bytes per minute, or both. Because the traffic alarm requires the
NetScreen device to monitor the total number of bytes, you must also enable the counting feature.
Note: For more information about traffic alarms, see “Alarms” on page 161.

6FKHGXOHV
By associating a schedule to an access policy, you can determine when the access policy is in effect. You
can configure schedules on a recurring basis and as a one-time event. Schedules provide a powerful tool in
controlling the flow of network traffic and in enforcing network security. For an example of the latter, if you
were concerned about employees transmitting important data outside the company, you might set an
access policy that blocked outbound FTP-Put and MAIL traffic after normal business hours.
In the WebUI, define schedules in the Schedule section. In the CLI, use the set schedule command.
Note: In the WebUI, scheduled access policies appear in green to indicate that the current time is not within
the defined schedule. When a scheduled access policy becomes active, it appears in red.
7UDIILF6KDSLQJ
You can set parameters for the control and shaping of traffic for each access policy. The traffic shaping
parameters include:
Guaranteed Bandwidth: Guaranteed throughput in kilobits per second (kbps). Traffic below this
threshold passes with the highest priority without being subject to any traffic management or shaping
mechanism.
Maximum Bandwidth: Secured bandwidth available to the type of connection in kilobits per second
(kbps). Traffic beyond this threshold is throttled and dropped.
Note: It is advised that you do not use rates less than 10 kbps. Rates below this threshold lead to
dropped packets and excessive retries that defeat the purpose of traffic management.
Traffic Priority: When traffic bandwidth falls between the guaranteed and maximum settings, the
NetScreen device passes higher priority traffic first, and lower priority traffic only if there is no other
higher priority traffic. There are eight priority levels.

DiffServ Codepoint Marking: Differentiated Services (DiffServ) is a system for tagging (or “marking”)
traffic at a position within a hierarchy of priority. The eight NetScreen priority levels can be mapped to
the TOS DiffServ system. By default, the highest priority (priority 7) maps to the first three bits (000) in
the DS field (see RFC 2472) or the IP precedence field in the TOS byte (see RFC 1349) in the IP
packet header. The lowest priority (priority 0) in the NetScreen system maps to (111) in the TOS
DiffServ system.
Note: For a more detailed discussion of traffic management and shaping, see “Traffic Shaping” on
page 477.
To change the mapping between the NetScreen priority levels and the DS system, use the following
CLI command:
set traffic-shaping ip_precedence <number for priority 0 (highest priority)> <number for priority 1>
<number for priority 2> <number for priority 3> <number for priority 4> <number for priority 5>
<number for priority 6> <number for priority 7>

&KDSWHU$FFHVV3ROLFLHV $FFHVV3ROLFLHV$SSOLHG
$&&(6632/,&,(6$33/,('
This section describes the management of access policies: viewing, creating, modifying, ordering and reordering,
and removing access policies.
9LHZLQJ$FFHVV3ROLFLHV
To view access policies through the WebUI, click Policy >> List Policy. In the CLI, use the get policy command.
$FFHVV3ROLF\,FRQV
When viewing a list of access policies, the WebUI uses icons to provide you a graphical summary of policy
components. The table below defines the different icons used in the access policies page.
Icon Function Description

Network-level NAT Because the NetScreen device is
operating in NAT mode, NAT is
applied on all outgoing traffic.
Policy-level NAT The NetScreen device performs
policy-based NAT on all traffic
meeting the criteria.
Permit All traffic meeting the criteria is
passed.
Deny All traffic meeting the criteria is

denied.
Enable encapsulation All outgoing traffic meeting the

criteria is encapsulated. All
incoming traffic meeting the criteria
is decapsulated.

Icon Function Description

Bidirectional VPN A matching VPN policy exists for
policies the opposite direction.
Authenticate The user must authenticate

himself/herself when initiating a
connection.
Log All traffic is logged and made
available for syslog and e-mail, if
enabled.
Count The amount of traffic is counted in
bytes per second.
Alarm Indicates that you have set alarm

thresholds.
Schedule An access policy is only active

during the time defined by the
chosen schedule.
Traffic Shaping Bandwidth shaping is active.
&UHDWLQJ$FFHVV3ROLFLHV
To allow traffic to flow between zones, you assign access policies to interfaces, which act as doorways to zones.
You cannot create policies for traffic within the same zone. Access policies apply only to traffic between zones.
To allow bidirectional traffic between two zones, for example, between the “abc” and “xyz” zones, you need to create
a policy that goes from “abc” to “xyz”, and then create a second policy from “xyz” to “abc”. The policies use the same
IP addresses, only the source and destination addresses are reversed. Depending on your needs, the policies can
have the same configuration or different ones.

([DPSOHRIELGLUHFWLRQDOWUDIILF
:HE8,
1. Policy (From Zone: abc, To Zone: xyz) >> New Policy: Enter the following, and then click OK:
Source Address: Host A
Service: Mail-Pop3
Action: Permit
2. Policy (From Zone: xyz, To Zone: abc) >> New Policy: Enter the following, and then click OK:
Source Address: Mail Server
Destination Address: Host A
Service: Mail
Action: Permit
&/,
1. set policy from abc to xyz host a mail server mail-pop3 permit
2. set policy from xyz to abc mail server host a mail permit
3. save

$FFHVV3ROLF\/RFDWLRQ
You can define access policies between any zones that are located within the same system, root or virtual, else, one
of the zones must be a shared zone.
([DPSOH7\SLFDO$&/IRUD6PDOOWR0HGLXP(QWHUSULVH
This example assumes that you have already configured the addresses and default routes. For more information on
configuring addresses, see “Addresses” on page 182. For more information on how to set default routes, see the
chapter on “Virtual Routers” on page 165
A small software firm, ABC Design, has divided its network into two subnets, and both are in the Trust zone. The
subnets are:
• Engineering (with the defined address “Engineering”)
• The rest of the company (with the defined address “Office”).
It also has a DMZ for its Web and mail servers.
The following example presents a typical set of access policies for the following users:
• Engineering is permitted to use all the services for outbound traffic except FTP-Put, IMAP, MAIL, and POP3.
• Office is permitted to use e-mail and access the Internet, provided they authenticate themselves.
• The entire company can access the company Web and mail servers on the DMZ.
• There is also a group of system administrators (with the defined address “Sys-admins”), who have complete
user and administrative access to the servers on the DMZ.

Untrust Zone
Internet
www.abc.com mail.abc.com
Router
NetScreen device
DMZ
Router
DMZ Zone
Office LAN Engineering LAN
Trust Zone
Note: The following example uses service groups. For information on creating such groups, see “Service Groups”
on page 232.

From Zone - To Zone - Service Action

Source Address Destination Address
Trust - Any Untrust - Any Com (service group: Deny
FTP-Put, IMAP, MAIL,
POP3)
Trust - Engineering Untrust - Any Any Permit
Trust - Office Untrust - Any Internet (service Permit
group: FTP-Get, (+ Authentication)
HTTP, HTTPS)

Untrust - Any Trust - Any Any Deny

Untrust Any DMZ - mail.abc.com MAIL Permit
Untrust Any DMZ - www.abc.com Web (service group: Permit
HTTP, HTTPS)
Trust Any DMZ - mail.abc.com e-mail (service group: Permit
IMAP, MAIL, POP3)
Trust Any DMZ - www.abc.com Internet Permit

DMZ - mail.abc.com Untrust Any MAIL Permit

:HE8,
Source Address: Any
Service: Com2
Action: Deny
Source Address: Engineering
Service: ANY
Action: Permit
Source Address: Office
Service: Internet3
Action: Permit
Authentication: (select)
Note: For incoming traffic (from Untrust zone to Trust zone), use the default access policy to deny
everything.
2. “Com” is a service group with the following members: FTP-Put, MAIL, IMAP, and POP3.
3. “Internet” is a service group with the following members: FTP-Get, HTTP, and HTTPS.

4. Policy >> From Zone: Trust, To Zone: DMZ >> New Policy: Enter the following, and then click OK:
Source Address: Any
Destination Address: mail.abc.com
Service: MAIL
Action: Permit
Source Address: Any
Destination Address: www.abc.com
Service: Web4
Action: Permit
Source Address: Any
Destination Address: mail.abc.com
Service: e-mail5
Action: Permit
Source Address: Any
Destination Address: www.abc.com
Service: Internet
Action: Permit
4. “Web” is a service group with the following members: HTTP and HTTPS.
5. “e-mail” is a service group with the following members: MAIL, IMAP, and POP3.

Source Address: Sys-admins
Service: ANY
Action: Permit
9. Policy >> From Zone: DMZ, To Zone: Trust >> New Policy: Enter the following, and then click OK:
Source Address: mail.abc.com
Service: MAIL
Action: Permit
&/,
1. set policy from trust to untrust any any com deny
2. set policy from trust to untrust engineering any any permit
3. set policy from trust to untrust office any internet permit auth
4. set policy from trust to dmz any mail.abc.com mail permit
5. set policy from trust to dmz any www.abc.com web permit
6. set policy from trust to dmz any mail.abc.com e-mail permit
7. set policy from trust to dmz any www.abc.com internet permit
8. set policy from trust to dmz sys-admins any any permit
9. set policy from dmz to trust mail.abc.com any mail permit
10. save

0RGLI\LQJDQG'LVDEOLQJ$FFHVV3ROLFLHV
After you create an access policy, you can always return to it to make modifications. In the WebUI, click the Edit link
in the Configure column for the access policy that you want to change. In the Policy Configuration dialog box that
appears for that access policy, make your changes, and then click OK. In the CLI, use the set policy command.
The ScreenOS also provides a means for enabling and disabling access policies.
By default, an access policy is enabled. To disable it, do the following:
:HE8,
Policy: Select the Disable option from the Configure column for the policy that you want to disable.
The row containing the policy information is shaded grey to indicate that the policy is disabled.
&/,
1. set policy from <zone name> to <zone name> id <id_num> disable
2. save
Note: To enable the policy again, click Enable in the Configure column for the policy that you want to enable
(WebUI), or type unset policy from <zone name> to <zone name> id <id_num> disable (CLI).
5HRUGHULQJ$FFHVV3ROLFLHV
The NetScreen device checks all attempts to traverse the firewall against access policies, beginning with the first
one listed in the ACL for the appropriate direction (incoming or outgoing) and moving through the list. Because
action applies to the first matching access policy, you must arrange them from the most specific to the most general.
(Whereas a specific access policy does not preclude the application of a more general access policy located down
the list, a general access policy appearing before a specific one does.)

To move an access policy to a different position in the ACL:
:HE8,
1. Policy: Click the circular arrows in the Configure column for the policy you want to move to display the Move
Policy dialog box:
2. Change the order of the access policy to fit your needs, and then click OK.
The access policies page reappears with the access policy you moved in its new position.
&/,
1. set policy move <id number> { before | after } <number>
2. save
5HPRYLQJDQ$FFHVV3ROLF\
In addition to modifying an access policy, you can also delete it from the ACL. In the WebUI, click Remove in the
Configure column for the access policy that you want to remove. When the system message prompts for
confirmation to proceed with the removal, click Yes. In the CLI, use the unset policy <id_number> command.


&KDSWHU
,36HF

This chapter introduces the various elements of Internet Protocol Security (IPSec) and how they relate to virtual
private network (VPN) tunneling. Follwing an “Introduction to VPNs” on page 264, the remainder of the chapter
covers the following elements of IPSec:
• “IPSec Concepts” on page 265
– “Modes” on page 266
– “Protocols” on page 269
– “Key Management” on page 271
– “Security Association” on page 272
• “Tunnel Negotiation” on page 273
– “Phase 1” on page 273
– “Main Mode and Aggressive Mode” on page 274
– “Phase 2” on page 275
– “Packet Flow: Policy-Based LAN-to-LAN VPN” on page 277
• “IPSec NAT Traversal” on page 279
– “Traversing a NAT Device” on page 280
– “UDP Checksum” on page 281
– “The Keepalive Frequency Value” on page 281
– “IPSec NAT-Traversal and Initiator/Responder Symmetry” on page 282

&KDSWHU,36HF ,QWURGXFWLRQWR931V
,1752'8&7,21729316
A virtual private network (VPN) provides a means for securely communicating between remote computers across a
public wide area network (WAN), such as the Internet.
A VPN connection can link two local area networks (LANs) or a remote dialup user and a LAN. The traffic that flows
between these two points passes through shared resources such as routers, switches, and other network equipment
that make up the public WAN. To secure VPN communication while passing through the WAN, the two participants
create an IP Security (IPSec) tunnel1.
An IPSec tunnel consists of a pair of unidirectional Security Associations (SAs)—one at each end of the tunnel—that
specify the security parameter index (SPI), destination IP address, and security protocol (Authentication Header or
Encapsulating Security Payload) employed.
Note: For more information on SPIs, see “Security Association” on page 272. For more about the IPSec security
protocols, see “Protocols” on page 269.
Through the SA, an IPSec tunnel can provide the following security functions:
• Privacy (via encryption)
• Content integrity (via data authentication)
• Sender authentication and—if using certificates—nonrepudiation (via data origin authentication)
The security functions you employ depend on your needs. If you only need to authenticate the IP packet source and
content integrity, you can authenticate the packet without applying any encryption. On the other hand, if you are only
concerned with preserving privacy, you can encrypt the packet without applying any authentication mechanisms.
Optionally, you can both encrypt and authenticate the packet. Most network security designers choose to encrypt,
authenticate, and replay-protect their VPN traffic.
NetScreen supports IPSec technology for creating VPN tunnels with two kinds of key creation mechanisms:
• Manual Key
• AutoKey IKE with a preshared key or a certificate
1. The term “tunnel” does not denote either transport or tunnel mode (see “Modes” on page 266). It simply refers to the IPSec connection.

&KDSWHU,36HF ,36HF&RQFHSWV
,36(&&21&(376
IP Security (IPSec) is a suite of related protocols for cryptographically securing communications at the IP packet
layer. IPSec consists of two modes and two main protocols:
• Transport and tunnel modes
• The Authentication Header (AH) protocol for authentication and the Encapsulating Security Payload (ESP)
protocol for encryption (and authentication)
IPSec also provides methods for the manual and automatic negotiation of Security Associations (SAs) and key
distribution, all the attributes for which are gathered in a Domain of Interpretation (DOI) document (see RFC 2407
and 2408).
IPSec Architecture
Transport Mode Tunnel Mode
AH Protocol ESP Protocol
Authentication Algorithm Encryption Algorithm

(MD5, SHA-1) (DES, 3DES)
Domain of Interpretation
(DOI)
SA and Key Management

(Manual and Automatic)

Note: The IPSec Domain of Interpretation (DOI) is a document containing definitions for all the security parameters
required for the successful negotiation of a VPN tunnel—essentially, all the attributes required for SA and IKE
negotiations.
0RGHV
IPSec operates in one of two modes: transport and tunnel. When both ends of the tunnel are hosts, transport mode
and tunnel mode can be used. When at least one of the endpoints of a tunnel is a security gateway, such as a router
or firewall, tunnel mode must be used. NetScreen devices always operate in tunnel mode for IPSec tunnels and
transport mode for L2TP-over-IPSec tunnels.
7UDQVSRUW0RGH
The original IP packet is not encapsulated within another IP packet. The entire packet can be authenticated (with
AH), the payload can be encrypted (with ESP), and the original header remains in plaintext as it is sent across the
WAN.
IP Packets
Transport Mode – AH Original AH

Payload
Header Header
Authenticated
Transport Mode – ESP Original ESP Payload

Header Header
Encrypted
Authenticated

7XQQHO0RGH
The entire original IP packet—payload and header—is encapsulated within another IP payload and a new header
appended to it. The entire original packet can be encrypted, authenticated, or both. With AH, the AH and new
headers are also authenticated. With ESP, the ESP header can also be authenticated.
IP Packets The original packet

is encapsulated.
Tunnel Mode – AH New AH Original Payload
Header Header Header
Authenticated
Tunnel Mode – ESP New ESP Original Payload

Header Header Header
Encrypted
Authenticated
In a LAN-to-LAN VPN, the source and destination addresses used in the new header are the IP addresses of the
outgoing interface (in NAT or Route mode) or the VLAN1 or System IP address (in Transparent mode); the source
and destination addresses of the encapsulated packets are the addresses of the ultimate endpoints of the
connection.

NetScreen-100 NetScreen-100
Tunnel Gateway Tunnel Gateway
Internet
LAN Tunnel LAN
1 2
A B
A B Payload 1 2 A B Payload A B Payload
The original packet
is encapsulated.
LAN-to-LAN VPN in Tunnel Mode
In a dialup-to-LAN VPN, there is no tunnel gateway on the VPN dialup client end of the tunnel; the tunnel extends
directly to the client itself. In this case, on packets sent to the dialup client, both the new header and the
encapsulated original header have the same IP address: that of the client’s computer.
NetScreen-100
Tunnel Gateway
VPN Dialup Client Internet
Tunnel LAN
A=1 2
B
A B Payload 1 2 A B Payload A B Payload
The original packet
is encapsulated.
Dialup-to-LAN VPN in Tunnel Mode

3URWRFROV
IPSec uses two protocols to secure communications at the IP layer:
• Authentication Header (AH)—A security protocol for authenticating the source of an IP packet and verifying
the integrity of its content
• Encapsulating Security Payload (ESP)—A security protocol for encrypting the entire IP packet (and
authenticating its content)
$+
The Authentication Header (AH) protocol provides a means to verify the authenticity/integrity of the content and
origin of a packet. You can authenticate the packet by the checksum calculated via a hash-based message
authentication code (HMAC) using a secret key and either MD5 or SHA-1 hash functions.
Message Digest version 5 (MD5)—An algorithm that produces a 128-bit hash (also called a digital
signature or message digest) from a message of arbitrary length and a 16-byte key. The resulting hash is
used, like a fingerprint of the input, to verify content and source authenticity and integrity.
Secure Hash Algorithm-1 (SHA-1)—An algorithm that produces a 160-bit hash from a message of
arbitrary length and a 20-byte key. It is generally regarded as more secure than MD5 because of the larger
hashes it produces. Because the computational processing is done in the NetScreen ASIC, the performance
cost is negligible.
Note: For more information on MD5 and SHA-1 hashing algorithms, see the following RFCs: (MD5) 1321, 2403;
(SHA-1) 2404. For information on HMAC, see RFC 2104.

(63
The Encapsulating Security Payload (ESP) protocol provides a means to ensure privacy (encryption), and source
authentication and content integrity (authentication). ESP in tunnel mode encapsulates the entire IP packet (header
and payload), and then appends a new IP header to the now encrypted packet. This new IP header contains the
destination address needed to route the protected data through the network.
With ESP, you can encrypt and authenticate, encrypt only, or authenticate only. For encryption, you can choose
either of the following encryption algorithms:
Data Encryption Standard (DES)—A cryptographic block algorithm with a 56-bit key.
Triple DES (3DES)—A more powerful version of DES in which the original DES algorithm is applied in
three rounds, using a 168-bit key. DES provides a significant performance savings but is considered
unacceptable for many classified or sensitive material transfers.
Advanced Encryption Standard (AES)—An emerging encryption standard which, when adopted by
Internet infrastructures worldwide, will offer greater interoperability with other network security devices. This
version of AES uses a 128-bit key.
For authentication, you can use either MD5 or SHA-1 algorithms.
For either the encryption or authentication algorithm you can select NULL; however, you cannot select
NULL for both simultaneously.

.H\0DQDJHPHQW
The distribution and management of keys are critical to successfully using VPNs. IPSec supports both manual and
automatic key distribution methods.
0DQXDO.H\
With Manual Keys, administrators at both ends of a tunnel configure all the security parameters. This is a viable
technique for small, static networks where the distribution, maintenance, and tracking of keys is not difficult.
However, safely distributing Manual Key configurations across great distances poses security issues. Aside from
passing the keys face-to-face, you cannot be completely sure that the keys have not been compromised while in
transit. Also, whenever you want to change the key, you are faced with the same security issues as when you
initially distributed it.
$XWR.H\,.(
When you need to create and manage numerous tunnels, you need a method that does not require you to configure
every element manually. IPSec supports the automated generation and negotiation of keys and security
associations using the Internet Key Exchange (IKE) protocol. NetScreen refers to such automated tunnel negotiation
as AutoKey IKE and supports AutoKey IKE with preshared keys and AutoKey IKE with certificates.
$XWR.H\,.(ZLWK3UHVKDUHG.H\V
With AutoKey IKE using preshared keys to authenticate the participants in an IKE session, each side must
configure and securely exchange the preshared key2 in advance. In this regard, the issue of secure key
distribution is the same as that with Manual Keys. However, once distributed, an AutoKey, unlike a Manual
Key, can automatically change its keys at predetermined intervals using the IKE protocol. Frequently
changing keys greatly improves security, and automatically doing so greatly reduces key-management
responsibilities. However, changing keys increases traffic overhead; therefore, doing so too often can
reduce data transmission efficiency.
2. A preshared key is a key for both encryption and decryption that both participants must have before initiating communication.

$XWR.H\,.(ZLWK&HUWLILFDWHV
When using certificates to authenticate the participants during an AutoKey IKE negotiation, each side
generates a public/private key pair (see Chapter 11, “Public Key Cryptography”) and acquires a certificate
(see “Certificates and CRLs” on page 291). As long as the issuing certificate authority (CA) is trusted by
both sides, the participants can retrieve the peer’s public key and verify the peer’s signature. There is no
need to keep track of the keys and SAs; IKE does it automatically.
Note: For examples of both Manual Key and AutoKey IKE tunnels, see Chapter 13, “Policy-Based VPNs”.
6HFXULW\$VVRFLDWLRQ
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 access policy invokes the SA associated with the VPN tunnel. For inbound traffic, the
NetScreen device looks up the SA by using the following triplet: destination IP, security protocol (AH or ESP), and
security parameter index (SPI) value.

&KDSWHU,36HF 7XQQHO1HJRWLDWLRQ
7811(/1(*27,$7,21
For a Manual Key IPSec tunnel, because all of the security association (SA) parameters have been previously
defined, there is no need to negotiate which SAs to use. In essence, the tunnel has already been established. When
traffic matches an access policy using that Manual Key tunnel or when a route involves the tunnel, the NetScreen
devices simply encrypts and authenticates the data, as you determined, and forwards it to the destination gateway.
To establish an AutoKey IKE IPSec tunnel, two phases of negotiation are required:
• In Phase 1, the participants establish a secure channel in which to negotiate the IPSec SAs.
• In Phase 2, the participants negotiate the IPSec SAs for encrypting and authenticating the ensuing
exchanges of user data.
3KDVH
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 mode or Main mode (see below). Using
either mode, the participants exchange proposals for acceptable security services such as:
• Encryption algorithms (DES and 3DES) and authentication algorithms (MD5 and SHA-1). For more
information about these algorithms, see “Protocols” on page 269.
• A Diffie-Hellman Group (See “The Diffie-Hellman Exchange” on page 275.)
• Preshared Key or RSA/DSA certificates (see “AutoKey IKE” on page 271)
A successful Phase 1 negotiation concludes when both ends of the tunnel agree to accept at least one set of the
Phase 1 security parameters proposed, and then process them. NetScreen devices support up to four proposals for
Phase 1 negotiations, allowing you to define how restrictive a range of security parameters for key negotiation you
will accept.

0DLQ0RGHDQG$JJUHVVLYH0RGH
Phase 1 can take place in either Main mode or Aggressive mode. The two modes are described below.
Main Mode: The initiator and recipient send three two-way exchanges (six messages total) to accomplish the
following services:
• First exchange, (messages 1 and 2): Propose and accept the encryption and authentication algorithms.
• Second exchange, (messages 3 and 4): Execute a Diffie-Hellman exchange, and the initiator and recipient
each provide a nonce (randomly generated number).
• Third exchange, (messages 5 and 6): Send and verify their identities.
The information transmitted in the third exchange of messages is protected by the encryption algorithm established
in the first two exchanges. Thus, the participants’ identities are not transmitted in the clear.
Aggressive Mode: The initiator and recipient accomplish the same objectives, but only in two exchanges, and a
total of three messages:
• First message: The initiator proposes the SA, and sends a nonce, identity, and, if using certificates, the
initiator’s certificate.
• Second message: The recipient accepts the SA, authenticates the initiator, and sends a nonce, identity,
and, if using certificates, the recipient’s certificate.
• Third message: The initiator authenticates the recipient and confirms the exchange.
Because the participants’ identities are exchanged in the clear (in the first two messages), Aggressive mode does
not provide identity protection.
Note: When a dialup VPN user negotiates an AutoKey IKE tunnel with a preshared key, Aggressive mode must be
used.

7KH'LIILH+HOOPDQ([FKDQJH
A Diffie-Hellman exchange allows the participants to produce a shared secret value. The strength of the technique is
that it allows the participants to create the secret value over an unsecured medium without passing the secret value
through the wire. There are five Diffie-Hellman (DH) groups (NetScreen supports groups 1, 2, and 5). The size of the
prime modulus used in each group’s calculation differs as follows:
• DH Group 1: 768-bit modulus3
• 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; however, the larger the modulus,
the longer the key-generation process takes. Because the modulus for each group is a different size, the participants
must agree to use the same group.
3KDVH
After the participants have established a secure and authenticated channel, they proceed through Phase 2, in which
they negotiate the SAs to secure the data to be transmitted through the IPSec tunnel.
Similarly to the process for Phase 1, the participants exchange proposals to determine which security parameters to
employ in the SA. A Phase 2 proposal also includes a security protocol—either Encapsulating Security Payload
(ESP) or Authentication Header (AH), and selected encryption and authentication algorithms. The proposal can also
specify a Diffie-Hellman group, if Perfect Forward Secrecy (PFS) is desired.
Note: For more about Diffie-Hellman groups, see “The Diffie-Hellman Exchange” on page 275. For more about PFS,
see “Perfect Forward Secrecy” on page 276.
Regardless of the mode used in Phase 1, Phase 2 always operates in Quick mode and involves the exchange of
three messages.
3. The strength of DH Group 1 security has depreciated, and NetScreen does not recommend its use.

NetScreen devices support up to four proposals for Phase 2 negotiations, allowing you to define how restrictive a
range of tunnel parameters you will accept. NetScreen also provides a replay protection feature. Use of this feature
does not require negotiation because packets are always sent with sequence numbers. You simply have the option
of checking the sequence numbers or not. (For more information about replay protection, see below.)
3HUIHFW)RUZDUG6HFUHF\
Perfect Forward Secrecy (PFS) is a method for deriving Phase 2 keys independent from and unrelated to the
preceding keys. Alternatively, the Phase 1 proposal creates the key (the SKEYID_d key) from which all Phase 2
keys are derived. The SKEYID_d key can generate Phase 2 keys with a minimum of CPU processing.
Unfortunately, if an unauthorized party gains access to the SKEYID_d key, all your encryption keys are
compromised.
PFS addresses this security risk by forcing a new Diffie-Hellman key exchange to occur for each Phase 2 tunnel.
Using PFS is thus more secure, although the rekeying procedure in Phase 2 might take slightly longer with PFS
enabled.
5HSOD\3URWHFWLRQ
A replay attack occurs when somebody intercepts a series of packets and uses them later either to flood the system,
causing a denial-of-service (DoS), or to gain entry to the trusted network. The replay protection feature enables
NetScreen devices to check every IPSec packet to see if it has been received before. If packets arrive outside a
specified sequence range, the NetScreen device rejects them.

3DFNHW)ORZ3ROLF\%DVHG/$1WR/$1931
To see the various components comprising the creation of an IPSec tunnel in relation to each other, the following
example illustrates how a packet flows through a tunnel.
A company based in Tokyo has just opened a branch office in Paris and needs to connect the two sites through an
IPSec tunnel. The tunnel uses Manual Key, the ESP protocol, 3DES for encryption and SHA-1 for authentication.
The NetScreen devices protecting each site are in NAT mode. The addresses are as follows:
• Tokyo:
– Outgoing interface (ethernet1, Untrust zone): 201.22.3.14
– Trust zone: 10.1.1.0/24
• Paris:
– Outgoing interface (ethernet1, Untrust zone): 203.3.3.10
– Trust zone: 10.2.2.0/24
Outgoing Interface
eth1, 201.22.3.14
Untrust Zone
Trust Zone Internet

Paris
10.1.1.0/24 IPSec Tunnel LAN
Tokyo Remote
Gateway
Outgoing Interface
eth1, 203.3.3.10
Untrust Zone
Internet
Tokyo Trust Zone
LAN IPSec Tunnel 10.2.2.0/24
Remote Paris
Gateway

The path of a packet coming from 192.168.10.10 and going to 172.16.5.20 through an IPSec tunnel proceeds as
follows:
1. The host on the 192.168.10.0/24 subnet sends a packet to a server on the 172.16.5.0 subnet.
2. The packet reaches its gateway; that is, the Netscreen device in Tokyo.
3. The Netscreen device in Tokyo performs the following operations:
– It checks its Access Control List (ACL) and (using the source and destination address) determines to
send the packet through the VPN tunnel to the Paris office.
– It encrypts the entire packet (including the original header) and puts a new header on the packet. In the
outer header the source IP address is 201.22.3.14, and the destination IP address is 203.3.3.10.
– It sends the packet to 203.3.3.10; that is, the outgoing interface IP address of the NetScreen device in
Paris.
4. The Netscreen device in Paris performs the following operations:
– Using the SPI, destination IP address, and IPSec protocol contained in the outer packet header, it
locates the SA and keys.
– It decrypts the packet, uncovering its ultimate destination.
– It checks the Access Control List (ACL) and, finding an access policy that grants access, forwards the
packet to its destination.

&KDSWHU,36HF ,36HF1$77UDYHUVDO
,36(&1$775$9(56$/
Network Address Translation (NAT) and Network Address Port Translation (NAPT) are Internet standards that
allows a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses
for external traffic. NAT devices generate these external addresses from predetermined pools of IP addresses.
When setting up an IPSec tunnel, the presence of a NAT device along the data path has no effect on Phase 1 and
Phase 2 IKE negotiations, which always encapsulate IKE packets within User Datagram Protocol (UDP) packets.
However, after the Phase 2 negotiations are completed, performing NAT on the IPSec packets causes the tunnel to
fail. Of the many reasons why NAT causes disruption to IPSec4, one reason is that, for the Encapsulating Security
Protocol (ESP), NAT devices cannot discern the location of the Layer 4 header (because it is encrypted) for port
translation. For the Authentication Header (AH) protocol, NAT devices can modify the port number, but the
authentication check, which includes the entire IPSec packet, fails.
To solve this problem, NetScreen devices (with ScreenOS 3.0.0 or later) and the NetScreen-Remote client (version
6.0 or later) can apply the NAT-Traversal (NAT-T) feature. NAT-T adds a layer of UDP encapsulation after detecting
one or more NAT devices along the data path during Phase 1 exchanges.
4. For a list of IPSec/NAT incompatibilities, see draft-ietf-ipsec-nat-regts-00.txt by Bernard Aboba.

7UDYHUVLQJD1$7'HYLFH
In the following illustration, a NAT device at the perimeter of a hotel LAN receives a packet from a VPN dialup client
with IP address 200.1.1.1, assigned by its ISP. For all outbound traffic, the NAT device replaces the original source
IP address in the outer header with a new address 210.2.2.2. During Phase 1 negotiations, the VPN client and the
NetScreen device detect that both VPN participants support NAT-T, that a NAT server is present along the data
path, and that it is located in front of the VPN client.
Hotel Corporate
NAT Device NetScreen Device
Internet
VPN Dialup Client
VPN Tunnel
Src IP 200.1.1.1 -> 210.2.2.2
Encapsulating the IPSec packets within UDP packets—which both the VPN client and the NetScreen device do—
solves the problem of the authentication check failure. The NAT server processes them as UDP packets, changing
the source port in the UDP header and leaving the SPI in the AH or ESP header unmodified. The VPN participants
strip off the UDP layer and process the IPSec packets, which pass the authentication check because none of the
authenticated content has been changed.

IPSec Packet without NAT-T
Outer IP AH or ESP AH or ESP

Header Header Data Payload Trailer
The outer headers contain
identical information except
that the protocol changes
from 50 or 51 (AH or ESP
respectively) to 500 (UDP).
IPSec Packet with NAT-T

Outer IP UDP NAT-T AH or ESP AH or ESP
Header Header Header Header Data Payload Trailer
Note: When NAT-T is enabled, the NetScreen device applies it only when necessary; that is, when the it detects a
NAT server between the remote host and the NetScreen device.
8'3&KHFNVXP
All UDP packets contain a UDP checksum, a calculated value that ensures UDP packets are free of transmission
errors. A NetScreen device does not require use of the UDP checksum for NAT-T, so the WebUI and CLI present
the checksum as an optional setting. Even so, some NAT devices require a checksum, so you might have to enable
this setting.
7KH.HHSDOLYH)UHTXHQF\9DOXH
When a NAT server assigns an IP address to a host, the server determines how long the new address remains valid
when no traffic occurs. For example, a NAT device might invalidate any generated IP address that remains unused
for 20 seconds. Therefore, it is usually necessary for the IPSec participants to send periodic keepalive packets—
empty UDP packets—through the NAT device, so that the NAT mapping does not change until the Phase 1 and
Phase 2 SAs expire.

Note: NAT servers have different session timeout intervals, depending on the manufacturer and model. It is
important to determine what the interval is for the NAT server, and to set the keepalive frequency value below that.
,36HF1$77UDYHUVDODQG,QLWLDWRU5HVSRQGHU6\PPHWU\
When two NetScreen devices establish a tunnel in the absence of a NAT device, either device can serve as initiator
or responder. However, if either host resides behind a NAT device, such initiator/responder symmetry might be
impossible. This happens whenever the NAT device generates IP addresses dynamically.
Note: Security zones depicted below are

from the perspective of NetScreen B.
Untrust Zone Trust Zone
NAT
NetScreen A Device NetScreen B
Internet Host B
Host A 210.1.1.1
Tunnel
211.1.10.10 210.1.1.2
In the above illustration, NetScreen B resides in a subnet located behind a NAT device. If the NAT device generates
the new IP address (210.1.1.1) dynamically from a pool of IP addresses, NetScreen A cannot unambiguously
identify NetScreen B. Therefore, NetScreen A cannot successfully initiate a tunnel with NetScreen B. NetScreen A
must be the responder, NetScreen B must be the initiator, and they must perform Phase 1 negotiations in
Aggressive mode.
However, if the NAT device generates the new IP address using a mapped IP (MIP) address, or some other
one-to-one addressing method, NetScreen A can unambiguously identify NetScreen B. Consequently, either
NetScreen A or NetScreen B can be the initiator, and both can use Main mode or Aggressive mode for Phase 1.

Note: If you enable NAT-T on the responder and configure it to view the initiator as a static peer, then peers of the
following types must use the same P1 proposal:
• Peers with dynamically assigned IP addresses
• Dialup VPN users
• NAT-T-enabled peers with static IP addresses
([DPSOH(QDEOLQJ1$77UDYHUVDO
In the following example, a NAT device at the perimeter of a hotel LAN assigns an address to the VPN dialup client
used by Michael Smith, a salesman attending a convention. For Michael Smith to reach the corporate LAN via a
dialup VPN tunnel, you must enable NAT-T for the remote gateway “msmith,” configured on the NetScreen device,
and for the remote gateway configured on the VPN dialup client. You also enable the NetScreen device to include a
UDP checksum in its transmissions, and you set the keepalive frequency to 8 seconds.
Hotel Corporate
NAT Device NetScreen Device
Internet
VPN Dialup Client
VPN Tunnel

:HE8,
1. VPN >> Gateway(P1) >> New Remote Tunnel Gateway: Enter the necessary parameters for the new tunnel
gateway as described in Chapter 12, “Routing-Based VPNs” or Chapter 13, “Policy-Based VPNs”, include
the following, and then click OK:
Nat-Traversal: Enable
UDP Checksum: Enable
Keepalive Frequency: 8
Note: The NetScreen device enables NAT traversal automatically for dial-up VPNs.
&/,
1. set ike gateway msmith nat-traversal
2. set ike gateway msmith nat-traversal enable-udp-checksum
3. set ike gateway msmith nat-traversal keepalive-frequency 8
4. save

&KDSWHU
3XEOLF.H\&U\SWRJUDSK\

This chapter provides an introduction to public key cryptography and the use of certificates and certificate revocation
lists (CRLs) within the context of Public Key Infrastructrue (PKI). The material is organized into the following
sections:
• “Introduction to Public Key Cryptography” on page 286
• “PKI” on page 288
• “Certificates and CRLs” on page 291
– “Obtaining a Certificate Manually” on page 292
– “Obtaining a Certificate Automatically” on page 298
• “Checking for Revocation Using OCSP” on page 302
– “Configuring for OCSP” on page 302

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ ,QWURGXFWLRQWR3XEOLF.H\&U\SWRJUDSK\
,1752'8&7,217238%/,&.(<&5<372*5$3+<
In public key cryptography, a public/private key pair is used to encrypt and decrypt data. Data encrypted with a
public key, which the owner makes available to the public, can only be decrypted with the corresponding private key,
which the owner keeps secret and protected. For example, if Alice wants to send Bob an encrypted message, Alice
can encrypt it with Bob’s public key and send it to him. Bob then decrypts the message with his private key.
The reverse is also useful; that is, encrypting data with a private key and decrypting it with the corresponding public
key. This is known as creating a digital signature. For example, if Alice wants to present her identity as the sender of
a message, she can encrypt the message with her private key and send the message to Bob. Bob then decrypts the
message with Alice’s public key, thus verifying that Alice is indeed the sender.
Public/private key pairs also play an important role in the use of digital certificates. The procedure for signing a
certificate (by a CA) and then verifying the signature works as follows (by the recipient):
6LJQLQJD&HUWLILFDWH
1. The Certificate Authority (CA) that issues a certificate hashes the certificate by using a hash algorithm (MD5
of SHA-1) to generate a digest.
2. The CA then “signs” the certificate by encrypting the digest with its private key. The result is a digital
signature.
3. The CA then sends the digitally signed certificate to the person who requested it.
9HULI\LQJD'LJLWDO6LJQDWXUH
1. When the recipient gets the certificate, he or she also generates another digest by applying the same hash
algorithm (MD5 of SHA-1) on the certificate file.
2. The recipient uses the CA’s public key to decrypt the digital signature.
3. The recipient compares the decrypted digest with the digest he or she just generated. If the two digests
match, the recipient can confirm the integrity of the CA’s signature and, by extension, the integrity of the
accompanying certificate.

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ ,QWURGXFWLRQWR3XEOLF.H\&U\SWRJUDSK\
Sender (CA) 1
1. Using either the MD5 or SHA-1 hash Digest A Cert
algorithm, the CA makes digest A from
the certificate. Hash Algorithm
2. Using the its private key, the CA (MD5 or SHA-1)
encrypts digest A. The result is digest B,
the digital signature.
3. The CA sends the digitally signed Digest B
certificate to the person who requested
it. 2 CA’s Private Key
1. Using either MD5 or SHA-1, the Recipient

1
recipient makes digest A from the
certificate. Digest A Cert
2. Using the CA’s public key, the
recipient decrypts digest B. 3 Compare Hash Algorithm
3. The recipient compares digest A with (MD5 or SHA-1)
digest B. If they match, the recipient
knows that the certificate has not been
tampered with. Digest B
2 CA’s Public Key
The procedure for digitally signing messages sent between two participants in an IPSec session works very
similarly, with the following differences:
• Instead of making a digest from the CA certificate, the sender makes it from the data in the IP packet
payload.
• Instead of using the CA’s public/private key pair, the participants use the sender’s public/private key pair.

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ 3.,
3.,
The term Public Key Infrastructure (PKI) refers to the hierarchical structure of trust required for the successful
implementation of public key cryptography. To verify the trustworthiness of a certificate, you must be able to track a
path of certified CAs from the one issuing your local certificate back to a root authority of a CA domain.
PKI Hierarchy of Trust – CA Domain
The root level CA validates subordinate CAs.
Subordinate CAs
validate
local certificates and
other CAs.
Local certificates contain the

user’s public key.

If certificates are used solely within an organization, that organization can have its own CA domain within which a
company CA issues and validates certificates among its employees. If that organization later wants its employees to
be able to exchange their certificates with those from another CA domain (for example, with employees at another
organization that also has its own CA domain), the two CAs can develop cross-certification; that is, they can agree to
trust the authority of each other. In this case, the PKI structure does not extend vertically but horizontally.
CA Domain – A CA Domain – B
Cross-certification
Users in CA domain A can use their certificates and key pairs with users
in CA domain B because the CAs have cross-certified each other.
For convenience and practicality, PKI must be transparently managed and implemented. Toward this goal, the
NetScreen ScreenOS does the following:
1. Generates a public/private key pair when you create a certificate request.
2. Supplies that public key as part of the certificate request in the form of a text file for transmission to a
Certificate Authority (CA) for certificate enrollment (PKCS10 file).

3. Supports loading the local certificate, the CA certificate, and the certificate revocation list (CRL)1 into the
unit.
You can also specify an interval for refreshing the CRL online. For more information on CRLs, see
“Certificates and CRLs” on page 291.
4. Provides certificate delivery when establishing an IPSec tunnel.
5. Supports certificate path validation upward through eight levels of CA authorities in the PKI hierarchy.
6. Supports the PKCS #7 cryptographic standard, which means the NetScreen device can accept X.509
certificates and CRLs packaged within a PKCS #7 envelope2. PKCS #7 support allows you to submit
multiple X.509 certificates within a single PKI request. You can now configure PKI to validate all the
submitted certificates from the issuing CA at one time.
7. Supports online CRL retrieval via LDAP or HTTP.
1. The Certificate Authority usually provides a CRL. Although you can load a CRL into the NetScreen device, you cannot view it once loaded.
2. NetScreen supports a PKCS #7 file size of up to 7 Kilobytes.

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ &HUWLILFDWHVDQG&5/V
&(57,),&$7(6$1'&5/6
A digital certificate is an electronic means for verifying your identity through the word of a trusted third party, known
as a Certificate Authority (CA). The CA server you use can be owned and operated by an independent CA3, or by
your own organization, in which case you become your own CA. If you use an independent CA, you must contact
them for the addresses of their CA and CRL servers (for obtaining certificates and certificate revocation lists), and
for the information they require when submitting personal certificate requests. When you are your own CA, you
determine this information yourself.
To use a digital certificate to authenticate your identity when establishing a secure VPN connection, you must first do
the following:
• Obtain a personal certificate (also known as a local certificate) from a CA, and load the certificate in the
NetScreen device.
• Obtain a CA certificate for the CA that issued the personal certificate (basically verifying the identity of the
CA verifying you), and load the CA certificate in the NetScreen device. You can perform this task manually,
or automatically using Simple Certificate Enrollment Protocol (SCEP).
• If the certificate does not contain a certificate distribution point (CDP) extension, and you cannot
automatically retrieve the CRL via LDAP or HTTP, you can retrieve a CRL manually and load that in the
NetScreen device.
During the course of business, there are several events that make it necessary to revoke a certificate. You might
wish to revoke a certificate if you suspect that it has been compromised or when a certificate holder leaves a
company. Managing certificate revocations and validation can be accomplished locally (which is a limited solution)
or by referencing a CA’s CRL, which you can automatically access online at daily, weekly, or monthly intervals, or at
the default interval set by the CA.
® ® ® ®
3. NetScreen supports the following CAs: Baltimore , Entrust , Microsoft, Netscape, RSA Keon , and Verisign .

2EWDLQLQJD&HUWLILFDWH0DQXDOO\
To obtain a signed digital certificate using the manual method, you must complete several tasks in the following
order:
1. Configure default server settings.
2. Generate a public/private key pair.
3. Fill out the Certificate Request.
4. Submit your request to your CA of choice.
5. After you receive your signed certificate, you must load it into the NetScreen device along with the CA
certificate.
You now have the following items for the following uses:
• A local certificate for the NetScreen device, to validate your identity with each tunnel connection
• A CA Certificate (their public key), to be used to verify the peer’s certificate
• If the Certificate Revocation List (CRL) was included with the CA certificate4, a CRL to identify invalid
certificates
When you receive these files (the certificate files typically have the extension .cer, and the CRL typically has the
extension .crl), load them into your NetScreen using the procedure described in the following section.
Note: If you are planning to use e-mail to submit a PKCS10 file to obtain your certificates, you must properly
configure your NetScreen settings so that you can send e-mail to your system administrator. You have to modify the
route table, correctly set your primary and secondary domain servers, and specify the SMTP server and e-mail
address settings.
4. A CRL might accompany a CA certificate and be stored in the NetScreen database. Alternatively, the CA certificate might contain the CRL URL (either LDAP
or HTTP) for a CRL that is stored in the CA’s database. If the CRL is unobtainable by either method, you can manually enter the default server settings for
the CRL URL in the NetScreen device, as explained in “Example: Configuring Default Server Settings for a CRL” on page 297.

([DPSOH5HTXHVWLQJD&HUWLILFDWH0DQXDOO\
When you request a certificate, the NetScreen device generates a key pair. The public key becomes incorporated in
the request itself and, eventually, in the digitally signed local certificate you receive from the CA.
In the following example, the security administrator is making a certificate request for Michael Zhang in the
Development department at NetScreen Technologies in Santa Clara, California. The certificate is going to be used
for a NetScreen-100 at IP address 10.10.5.44. The administrator instructs the NetScreen device to write the request
to a file, which he then copies and pastes in the certificate request text field at the CA’s certificate enrollment site.
After the enrollment process is complete, the CA usually sends the certificates via e-mail to the security
administrator.
:HE8,
1. Certificate >> Local >> Certificate Request: Enter the following, and then click Generate:
Name: Michael Zhang
Phone: (408) 330-7800
Unit/Department: Development
Organization: NetScreen Technologies
County/Locality: Santa Clara
State: CA
Country: US
E-mail: (leave blank; some CAs do not support this field)
Note: If no e-mail address appears in the local certificate, you cannot use an e-mail address as the local
IKE ID when configuring the NetScreen device as a dynamic peer. Instead, you can use an IP address (if it
is in the local certificate), or you can leave the local ID field empty. By default the NetScreen device sends
its hostname.domainname. If you do not specify a local ID for a dynamic peer, enter the
hostname.domainname of that peer on the device at the other end of the IPSec tunnel in the peer ID field.

Write to file: (select)

Create new key pair of 10245 length: (select)
The NetScreen generates a PKCS #10 file and prompts you to open the file or save it to disk.
2. Open the file, and copy its contents, taking care to copy the entire text but not any blank spaces before or
after the text. (Start at “-----BEGIN CERTIFICATE REQUEST-----”, and end at “-----END CERTIFICATE
REQUEST-----”.)
3. Follow the certificate request directions at the CA’s Web site, pasting the PKCS #10 file in the appropriate
field when required.
4. When you receive the certificate from the CA via e-mail, copy it to a text file, and save it to your workstation
(to be loaded to the NetScreen device later through the WebUI) or to a TFTP server (to be loaded later
through the CLI).
&/,
1. set pki x509 dn country-name US
2. set pki x509 dn state-name CA
3. set pki x509 dn local-name “Santa Clara”
4. set pki x509 dn org-name “NetScreen Technologies”
5. set pki x509 dn org-unit-name Development
6. set pki x509 dn name “Michael Zhang”
7. set pki x509 dn ip 10.10.5.44
8. set pki x509 default send-to mzhang@netscreen.com6
9. exec pki rsa new-key 1024
The certificate request is sent via e-mail to mzhang@netscreen.com.
5. The value 1024 indicates the bit length of the key pair. If you are using the certificate for SSL (see “Secure Sockets Layer” on page 115), be sure to use a
bit length that your Web browser also supports.
6. Using the e-mail address assumes that you have already configured the IP address for your SMTP server (set admin mail server-name <IP address or
server name>).

10. Copy the contents of the request, taking care to copy the entire text but not any blank spaces before or after
the text. (Start at “-----BEGIN CERTIFICATE REQUEST-----”, and end at “-----END CERTIFICATE
REQUEST-----”.)
11. Follow the certificate request directions at the CA’s Web site, pasting the PKCS #10 file in the appropriate
field when required.
When you receive the certificate from the CA via e-mail, copy it to a text file, and save it to your workstation (to be
loaded to the NetScreen device later through the WebUI) or to a TFTP server (to be loaded later through the CLI).
([DPSOH/RDGLQJ&HUWLILFDWHV
The CA returns the following three files to you for loading into the NetScreen device:
• A CA certificate, which contains the CA’s public key
• A local certificate that identifies your local machine (your public key)
• A CRL, which lists any certificates revoked by the CA
For the WebUI example, you have downloaded the files to the administrator’s workstation. For the CLI example, you
have downloaded them to a TFTP server with IP address 198.168.1.5.
Note: NetScreen devices, including virtual systems, configured with ScreenOS 2.5 or later support loading multiple
local certificates from different CAs.
This example illustrates how to load two certificate files named auth.cer (CA certificate) and local.cer (your public
key), and the CRL file named distrust.crl.

:HE8,
1. VPN >> Certificates >> Load: Select Certificate, and then click Browse.
2. Navigate to the certificate file directory, select auth.cer, and then click Open.
The directory path and file name appear in the Browse field in the Load Certificate or CRL dialog box.
3. Click Load.
The certificate file loads, and then the Load Certificate or CRL dialog box reappears.
4. Click Browse again, navigate to the certificate file directory, select local.cer, and then click Open.
The directory path and file name for local.cer appear in the Browse field in the Load Certificate or CRL
dialog box.
5. Click Load.
The certificate file loads, and then the Load Certificate or CRL dialog box reappears.
6. Select CRL, click Browse once more.
7. Navigate to the certificate file directory, select distrust.crl, and then click Open.
8. Click Load.
The CRL file loads.
&/,
1. exec pki x509 tftp 198.168.1.5 cert-name auth.cer
2. exec pki x509 tftp 198.168.1.5 cert-name local.cer
3. exec pki x509 tftp 198.168.1.5 crl-name distrust.crl

([DPSOH&RQILJXULQJ'HIDXOW6HUYHU6HWWLQJVIRUD&5/
In Phase 1 negotiations, participants check the CRL list to see if certificates received during an IKE exchange are
still valid. If a CRL did not accompany a CA certificate and is not loaded in the NetScreen database, the NetScreen
7
device tries to retrieve the CRL through the LDAP or HTTP CRL location defined within the certificate itself. If there
is no URL address defined in the certificate, the NetScreen device uses the URL of the server that you define.
Note: With ScreenOS 2.5 and later, you can disable the checking of a CRL’s digital signature when you load the
CRL. However, disabling CRL certificate checking compromises the security of your NetScreen device.
This example shows how to configure the default server to check the CRL daily by going to the LDAP server at
2.2.2.121 and locating the CRL file.
:HE8,
VPN >> Certificates >> Default Server Settings: Enter the following, and the click OK.
LDAP Server: 2.2.2.121
CRL URL: ldap:///CN=Netscreen,
CN=ns2001,CN=Public KeyServices,
CN=Services,CN=Configuration,DC=NS2001,DC=com?CertificateRevocat
ionList?base?objectclass=CRLDistribution
Point
CRL Refresh Frequency: Daily
X509 Cert_Path Validation Level: Full
7. The CRL distribution point extension (.cdp) in an X509 certificate can be either an HTTP URL or an LDAP URL.

&/,
1. set pki ldap server-name 2.2.2.121
2. set pki ldap “crl-url ldap:///CN=Netscreen,CN=ns2001,CN=PublicKey
Services,CN=Services,CN=Configuration,DC=NS2000,DC=com?Certificate
RevocationList?base?objectclass=CRLDistributionPoint”
3. set pki x509 default crl-refresh daily
4. set pki x509 default cert-path full
2EWDLQLQJD&HUWLILFDWH$XWRPDWLFDOO\
To use a digital certificate to authenticate your identity when establishing a secure VPN connection, you must first do
the following:
• Obtain a personal certificate (also known as a local certificate) from a certificate authority (CA), and load the
certificate in the NetScreen device.
• Obtain a CA certificate for the CA that issued the personal certificate (basically verifying the identity of the
CA verifying you), and load the CA certificate in the NetScreen device. You can perform this task manually,
or automatically using Simple Certificate Enrollment Protocol (SCEP).
Because the manual method of requesting CA certificates has steps requiring you to copy information from one
certificate to another, it can be a somewhat lengthy process. To bypass these steps, use the automatic method.

([DPSOH5HTXHVWLQJD&HUWLILFDWH$XWRPDWLFDOO\
In this example, you use the automatic method to request a certificate.
:HE8,
1. Certificates >> Local >> Certificate Request: Enter the following, and then click Generate:
Name: Michael Zhang
Phone: (408) 330-7800
Unit/Department: Development
Organization: NetScreen Technologies
County/Locality: Santa Clara
State: CA
Country: US
Email: (leave blank; some CAs do not support this field)
Note: If no e-mail address appears in the local certificate, you cannot use an e-mail address as the local
IKE ID when configuring the NetScreen device as a dynamic peer. Instead, you can use a fully-qualified
domain name (if it is in the local certificate), or you can leave the local ID field empty. By default the
NetScreen device sends its hostname.domainname. If you do not specify a local ID for a dynamic peer,
enter the hostname.domainname of that peer on the device at the other end of the IPSec tunnel in the peer
ID field.
Automatically Enroll to CA: (select radio button)
Create new key pair of 10248 length: (select)
The NetScreen device generates a PKCS #10 file and prompts you to open the file or save it to disk.
8. The value 1024 indicates the bit length of the key pair. If you are using the certificate for SSL, be sure to use a bit length that your Web browser also supports.

2. Contact your certificate authority to inform them of your certificate request. They must authorize the
certificate request before you can download the certificate.
3. You can wait for the system to download the certificate automatically using SCEP (if your CA supports it).
This might take fifteen minutes or longer, so you might want to quicken the process by selecting the
Certificate >> Pending >> Retrieve option.
&/,
1. Specify a certificate authority CA CGI path.
set pki auth -1 scep ca-cgi “http://pilotonsiteipsec.verisign.com/cgi-bin/pkiclient.exe”9
2. Specify a registration authority RA CGI path.
set pki auth -1 scep ra-cgi “http://pilotonsiteipsec.verisign.com/cgi-bin/pkiclient.exe”10
3. Generate an RSA key pair, specifying a key length of 1024 bits.
exec pki rsa new 1024
4. Initiate the SCEP operation to request a local certificate.
exec pki x509 scep -1
5. If this is the first attempt to apply for a certificate from this certificate authority, a prompt appears presenting
a fingerprint value for the CA certificate. (Otherwise, go on to Step 6.)
You need to contact the certificate authority to confirm that this is the correct CA certificate.
Execute the following command to get the device’s authentication mode.
get pki auth -1 scep
If the authentication mode is auto, go on to Step 6. Otherwise, execute:
set pki auth -1 scep auth passed
9. The Common Gateway Interface (CGI) is a standard way for a web server to pass a user request to an application program, and to receive data back. CGI
is part of the Hypertext Transfer Protocol (HTTP).
10. You must specify an RA CGI path even if the RA does not exist. If the RA does not exist, use the value specified for the CA CGI.

6. When the confirmation prompt appears, contact your certificate authority administrator to approve the local
certificate request.
7. (Optional) Display a list of pending certificates. This allows you to see and record the index number
identifying the certificate.
get pki x509 list pending-cert
8. (Optional) Obtain the local certificate from the CA (using the index number obtained in Step 7) to identify the
certificate.
exec pki x509 scep 1
If you do not execute Steps 7 and 8, the NetScreen device still retrieves the certificate automatically from
the CA. However, there is a time delay of at least 15 minutes. This delay period depends upon how you
configured the device. The configuration command for this feature is:
set pki auth -1 scep polling-int <number>
where <number> is time in minutes. The minimum is 15.

&KDSWHU3XEOLF.H\&U\SWRJUDSK\ &KHFNLQJIRU5HYRFDWLRQ8VLQJ2&63
&+(&.,1*)255(92&$7,2186,1*2&63
When a NetScreen device performs an operation that uses a certificate, it may be necessary to check the certificate
for premature revocation. The default way to check the revocation status of a digital certificate is to use CRL.
Online Certificate Status Protocol (OCSP) is an alternative way to check the status of a digital certificate. OCSP may
provide additional information about the certificate. It may also provide the certificate status in a more timely manner.
When a NetScreen device uses OCSP, it is referred to as the OCSP client (or requester). This client sends a
verification request to a server device called the OCSP responder. The client’s request contains the identity of the
certificate to check. Before the NetScreen device can perform any OCSP operation, you must configure it to
recognize the location of the OCSP responder.
After receiving the request, the OCSP responder confirms that the status information for the certificate is available,
then returns the current status to the client. Besides the certificate’s revocation status, the generated response
includes the name of the responder and the validity interval of the response. Unless the response is an error
message, the responder signs the response using the responder’s private key. The OCSP client verifies the validity
of the response signature.
&RQILJXULQJIRU2&63
You can use CLI commands to configure a NetScreen device to support OCSP operation. Most of these commands
use an identification number to associate the revocation reference URL with the CA certificate. You can obtain this
ID number using the following CLI command:
ns-> get pki x509 list ca-cert
Note: The NetScreen device dynamically assigns the ID number to the CA certificate when you list the CA
certificates. This number might change after you modify the certificate store.

6SHFLI\LQJ(LWKHU&5/RU2&63IRU5HYRFDWLRQ&KHFNLQJ
To specify the revocation check method (CRL, OCSP, both, or none) for a certificate of a particular CA, use the
following CLI syntax:
ns-> set pki authority <id_num> cert-status revoc { CRL | OCSP | all | none }
where <id_num> is the identification number for the certificate.
The following example specifies OCSP revocation checking.
ns-> set pki authority 3 cert-status revocation-check ocsp
The ID number 3 identifies the certificate of the CA.
'LVSOD\LQJ&HUWLILFDWH5HYRFDWLRQ6WDWXV$WWULEXWHV
To display the revocation check attributes for a particular CA, use the following CLI syntax:
ns-> get pki authority <id_num> cert-status
where <id_num> is the identification number for the certificate issued by the CA.
To display the revocation status attributes for the CA that issued certificate 7:
ns-> get pki authority 7 cert-status
6SHFLI\LQJWKH85/RIDQ2&635HVSRQGHUIRUD&HUWLILFDWH
To specify the URL string of an OCSP responder for a particular certificate, use the following CLI syntax:
ns-> set pki authority <id_num> cert-status ocsp url <url_str>
To specify the URL string of an OCSP responder (http:\\192.168.10.10) for the CA with certificate at index 5, use the
following CLI syntax:
ns-> set pki authority 5 cert-status ocsp url http:\\192.168.10.10
To remove the URL (http:\\192.168.2.1) of a CRL server for a certificate 5:
ns-> unset pki authority 5 cert-status ocsp url http:\\192.168.2.1

5HPRYLQJ&HUWLILFDWH5HYRFDWLRQ&KHFN$WWULEXWHV
To remove all attributes related to a certificate revocation check for a CA that issued a particular certificate, use the
following syntax:
ns-> unset pki authority <id_num> cert-status
To remove all revocation attributes related to certificate 1:
ns-> unset pki authority 1 cert-status

&KDSWHU
5RXWLQJ%DVHG931V

The configuration of a NetScreen device for virtual private network (VPN) support is particularly flexible with USGA.
In ScreenOS releases prior to 3.1.0, VPN tunnels are treated as objects (or building blocks) that together with
source, destination, service, and action, comprise an access policy that permits VPN traffic. (Actually, the VPN
policy action is tunnel, but the action permit is implied, if unstated). In ScreenOS 3.1.0, the concept of a VPN tunnel
has shifted. In addition1 to the previous notion of a tunnel as an object used to build policies—see Chapter 13,
Policy-Based VPNs—a tunnel can also be viewed as a network resource used to transport traffic. Thus, you can
consider a tunnel as a means for delivering traffic between points A and B, and a policy as a method for either
permitting or denying the delivery of that traffic. Simply put, USGA allows you the freedom to decouple the regulation
of traffic from the means of its delivery.
This chapter presents an overview of the VPN concepts in USGA, and offers four examples of device configurations
supporting LAN-to-LAN VPNs. The main sections are as follows:
• “Tunnel Interfaces” on page 306
– “Example: Tunnel Bound to Tunnel Interface” on page 306
• “LAN-to-LAN VPNs” on page 314
– “Example: Routing-Based LAN-to-LAN VPN, Manual Key” on page 317
– “Example: Routing-Based LAN-to-LAN VPN, AutoKey IKE” on page 328
– “Example: Routing-Based LAN-to-LAN VPN, Dynamic Peer” on page 333
• “Dialup-to-LAN VPN, Dynamic Peer” on page 348
– “Example: Routing-Based Dialup-to-LAN VPN, Dynamic Peer” on page 349
• “Hub-and-Spoke VPNs” on page 357
– “Example: Hub-and-Spoke VPNs” on page 358
• “Back-to-Back VPNs” on page 365
– “Example: Back-to-Back VPNs” on page 366
1. ScreenOS 3.1.0 continues to support pre-USGA VPN configuration concepts and methods.

&KDSWHU5RXWLQJ%DVHG931V 7XQQHO,QWHUIDFHV
7811(/,17(5)$&(6
When you configure the remote gateway for a VPN tunnel, you must also specify a security zone interface as the
local gateway2. After configuring the rest of the tunnel, you can create a tunnel interface and bind it to the VPN
tunnel. Now you have a VPN tunnel that is bound both to a tunnel interface and to a local zone interface. You can
set up routes to the tunnel interface to direct traffic through the tunnel.
Conceptually, you can view VPN tunnels as pipes that you have laid. They extend from the local device to remote
gateways, and the tunnel interfaces are the openings to these pipes. The pipes are always there, available for use
whenever the routing engine directs traffic to one of their interfaces.
([DPSOH7XQQHO%RXQGWR7XQQHO,QWHUIDFH
In this example, you configure a VPN tunnel between the corporate site and a branch office. The tunnel has the
following characteristics:
• The VPN tunnel is bound to a tunnel interface named tunnel.1.
• AutoKey IKE VPN using a preshared key (netscreen1), Main mode, Encapsulating Security Protocol (ESP),
Diffie-Hellman Group 2, 3DES encryption, and SHA-1 authentication.
• The interface specified as the local gateway on the corporate site is 210.1.1.1. (The branch office uses this
address as the remote gateway in its IKE configuration.)
• The NetScreen device at the corporate site is running ScreenOS 3.1.0.
• The NetScreen device at the remote site is running an earlier version of ScreenOS.
Note: Only the configuration for the corporate end of the tunnel is given below. For information on configuring a
NetScreen device running pre-USGA ScreenOS, see the NetScreen Concepts & Examples ScreenOS Reference
Guide for the version of ScreenOS that is appropriate for your device.
2. Your IKE peer uses the IP address of your local gateway interface (or outgoing-interface) when configuring the remote gateway on his NetScreen device.

Note: The castle icon represents Untrust-VR Routing Domain

a security zone interface.
Default Gateway
210.1.1.254
Branch1
Trust-VR Routing Domain 10.2.1.0/24
Gateway
tunnel.1 VPN tunnel: 211.2.2.2/24
to_branch1
Zone: Untrust
210.1.1.1/24
Zone: Sales eth1/2
10.1.1.1/24
eth2/1
The NetScreen device sends the encapsulated VPN

traffic to the external router acting as the default gateway.
:HE8,
6HFXULW\=RQHV
Name: Sales
Note: The Untrust zone is preconfigured. You do not have to create it.

,QWHUIDFHV²=RQHVDQG7XQQHO
2. Interface >> Edit (for ethernet2/1): Enter the following, and then click OK:
Netmask: 255.255.255.0
Zone Name: Sales
Netmask: 255.255.255.0
Zone Name: Untrust
4. Interface >> Tunnel >> New Entry: Enter the following, and then click Save:
Tunnel Interface Name Tunnel.: 1
Zone: Untrust
Unnumbered: (select)
Interface: ethernet1/2(Untrust)3
3. The source interface must be in the same zone to which the tunnel interface is bound; in this case, the Untrust zone. The unnumbered tunnel interface
borrows the IP address of the specified security zone interface.

931
5. VPN >> Gateway (P1) >> New Remote Tunnel Gateway: Enter the following, and then click OK:
Gateway Name: branch1
Remote Gateway Static IP Address: (select)
Mode (Initiator) Main (ID Protection): (select)
Outgoing Interface: ethernet1/24
Preshared Key: netscreen1
Name: to_branch1
Enable Replay Protection: (select)
Remote Gateway Tunnel: branch1
Bind to: Tunnel Interface: tunnel.1
Enable Proxy-ID: (select)
Local IP: 10.1.1.0
Netmask: 255.255.255.0
Remote IP: 10.2.1.0
Netmask: 255.255.255.0
Service: ANY
4. The outgoing interface does not have to be in the same zone to which the tunnel interface is bound.

$GGUHVVHV
7. Address >> New Address: Enter the following, and then click OK:
Address Name: sales-any
Netmask: 255.255.255.0
Zone: Sales
Address Name: branch1
Netmask: 255.255.255.0
Zone: Untrust
5RXWHV
9. Routing >> Route Table >> New Entry: Enter the following, and then click OK 5:
Netmask: 0.0.0.0
Hop Virtual Router Name: untrust-vr
Netmask: 255.255.255.0
Gateway IP Address Interface: tunnel.1
5. This route exists by default and does not need to be configured for this example. Its inclusion here is purely to illustrate how to configure it.

Netmask: 0.0.0.0
Note: Because the interface for the Sales zone (eth2/1) is in Route mode, the NetScreen device
automatically makes an entry for it in the untrust-vr route table. You do not have to enter one manually.
3ROLFLHV
12. Policy (From Zone: Sales, To Zone: Untrust) >> New Policy: Enter the following, and then click OK:
Source Address: sales-any
Destination Address: branch1
Service: Any
Action: Permit
13. Policy (From Zone: Untrust, To Zone: Sales) >> New Policy: Enter the following, and then click OK:
Source Address: branch1
Destination Address: sales-any
Service: Any
Action: Permit
6. Setting a route to the external router designated as the default gateway is essential for both outbound VPN and network traffic. In this example, the NetScreen
device sends encapsulated VPN traffic to this router as the first hop along its route to the remote peer’s gateway. In the illustration for this example, the
concept is presented by depicting the tunnel passing through the router.

&/,
6HFXULW\=RQHV
1. set zone name sales
Note: The Untrust zone is preconfigured. You do not have to create it.
2. set interface eth2/1 zone sales
3. set interface eth2/1 ip 10.1.1.1 255.255.255.0
4. set interface eth2/1 route
7. set interface tunnel.1 zone untrust
8. set interface tunnel.1 ip unnumbered interface eth1/2
931
9. set ike gateway branch1 ip 211.2.2.2 main outgoing-interface eth1/2 preshare netscreen1 proposal
pre-g2-3des-sha
10. set vpn to_branch1 gateway branch1 replay proposal g2-esp-3des-sha
11. set vpn to_branch bind interface tunnel.1
12. set vpn to_branch1 proxy-id local-ip 10.1.1.0 255.255.255.0 remote-ip 10.2.1.0 255.255.255.0 any
$GGUHVVHV
13. set address sales sales-any 10.1.1.0 255.255.255.0
14. set address untrust branch1 10.2.1.0 255.255.255.0

5RXWHV
15. set vrouter trust-vr route 0.0.0.0 0.0.0.0 vrouter untrust-vr
16. set vrouter untrust-vr route 10.2.1.0 255.255.255.0 interface tunnel.1
17. set vrouter untrust-vr route 0.0.0.0 0.0.0.0 interface eth1/2 gateway 210.1.1.254
3ROLFLHV
18. set policy from sales to untrust sales-any branch1 any permit
19. set policy from untrust to sales branch1 sales-any any permit
20. save

&KDSWHU5RXWLQJ%DVHG931V /$1WR/$1931V
/$172/$19316
An IPSec VPN tunnel exists between two gateways, and each gateway needs an IP address. When both gateways
have static IP addresses, you can configure the following kinds of tunnels:
• LAN-to-LAN VPN, Manual Key tunnel
• LAN-to-LAN VPN, AutoKey IKE tunnel (with a preshared key or certificates)
When one gateway has a static address and the other has a dynamically assigned address, you can configure the
following kind of tunnel:
• Dynamic Peer LAN-to-LAN VPN, AutoKey IKE tunnel (with a preshared key or certificates)
As used here, a static LAN-to-LAN VPN involves an IPSec tunnel connecting two LANs, each with a NetScreen
device operating as a secure gateway. The physical interface or subinterface used as the outgoing interface on both
devices has a fixed IP address, and the internal hosts also have static IP addresses. If the NetScreen device is in
Transparent mode, the VLAN1 address or the System IP address—both of which are fixed addresses—is used.7
(See “Example: Routing-Based LAN-to-LAN VPN, Manual Key” on page 317, and “Example: Routing-Based
LAN-to-LAN VPN, AutoKey IKE” on page 328.) With a static LAN-to-LAN VPN, hosts at either end of the tunnel can
initiate the VPN tunnel setup because the IP address of the remote gateway remains constant and thus reachable.
If the outgoing interface of one of the NetScreen devices has a dynamically assigned IP address, that device is
termed a dynamic peer and the VPN is configured differently. (See “Example: Routing-Based LAN-to-LAN VPN,
Dynamic Peer” on page 333.) With a dynamic peer LAN-to-LAN VPN, only hosts behind the dynamic peer can
initiate the VPN tunnel setup because only their remote gateway has a fixed IP address and is thus reachable from
their local gateway. However, after a tunnel has been set up between a dynamic peer and a static peer, hosts
behind either gateway can initiate VPN traffic if the destination hosts have fixed IP addresses.
7. If you set both the System IP and the VLAN1 IP address, the VLAN1 address takes priority and is the address to which you can terminate a VPN.

7XQQHO,QWHUIDFHV
Beyond the VPN tunnel termination points (the local and remote gateways), you can also configure tunnel interfaces
in either a security zone or in a tunnel zone through which the NetScreen device directs traffic to and from the VPN
tunnel8. You can bind a VPN tunnel to a specific numbered (with IP address/netmask) or unnumbered (without IP
address/netmask) tunnel interface in a security zone. If the tunnel interface is unnumbered, it borrows the IP
address from the interface of the security zone in which you created it.
Tunnel Security Zone

Interfaces Interfaces
When a numbered tunnel interface is in a tunnel zone, you
cannot bind a VPN tunnel to the tunnel interface. You can only
Tunnel VPN Tunnel bind a tunnel to the tunnel zone. This allows multiple tunnel
Numbered interfaces to link to a single tunnel, or multiple tunnels to link
Zone
to a single tunnel interface. In such cases, you must create a
policy-based VPN configuration.
When a tunnel interface is in a security zone, you must bind a

VPN tunnel to the tunnel interface. Doing so allows you to
create a routing-based VPN configuration.
Security VPN Tunnel
Numbered or The tunnel interface can be numbered or unnumbered. If it is
Unnumbered Zone unnumbered, the tunnel interface borrows the IP address from
the security zone interface. Note: Only a numbered tunnel
interface (that is, an interface with an IP address and
netmask) can support policy-based NAT.
When a numbered tunnel interface is in a security zone and is

Security VPN Tunnel the only interface in that zone, you do not need to create a
Numbered security zone interface. In this case, the security zone
Zone supports VPN traffic via the tunnel interface, but no other kind
of traffic.
Generally, assign an IP address to a tunnel interface if you want the interface to support policy-based NAT. For
more information about policy-based NAT, see . You can create a numbered tunnel interface in either a tunnel zone
or security zone.
8. If you do not specify a tunnel interface, the tunnel uses the default interface for the security zone.

If the tunnel interface does not need to support policy-based NAT, and your configuration does not require the tunnel
interface to be bound to a tunnel zone, you can specify the interface as unnumbered. You must bind an unnumbered
tunnel interface to a security zone; you cannot bind it to a tunnel zone. You must also specify an interface bound to
that security zone whose IP address the unnumbered tunnel interface borrows.
Note: The security zone interface that you specify must be in the same zone to which you have bound the tunnel
interface.

([DPSOH5RXWLQJ%DVHG/$1WR/$19310DQXDO.H\
In this example, a Manual Key tunnel provides a secure communication channel between offices in Tokyo and Paris,
using ESP with 3DES encryption and SHA-1 authentication. The Trust zones at each site are in NAT mode. The
addresses are as follows:
• Tokyo: • Paris:
- Trust interface (ethernet1): 192.168.10.1/24 - Trust Interface (ethernet1): 172.16.5.1/24
- Untrust interface (ethernet3): 201.22.3.14/24 - Untrust interface (ethernet3): 203.3.3.10/24
The Trust security zone and the Untrust-Tun tunnel zone are in the Trust-VR routing domain. The Untrust security
zone is in the Untrust-VR routing domain. The Untrust zone interface (ethernet3) serves as the outgoing interface for
the VPN tunnel.
Topology of the zones Topology of the zones

configured on the NetScreen configured on the NetScreen
device in Tokyo. device in Paris.
Tokyo Paris Tokyo Paris
Trust Untrust Untrust Trust

Zone Zone Zone Zone
Outgoing Interface Outgoing Interface

Untrust Zone Untrust Zone
eth3, 201.22.3.14/24 eth3, 203.3.3.10/24
Tokyo Paris
Gateway 201.22.3.20 Gateway 203.3.3.1
Trust Zone Trust Zone
eth1, 192.168.10.1/24 eth1, 172.16.5.1/24
Internet
VPN Tunnel
Tunnel Interface Tunnel Interface

Tunnel.1 Tunnel.1

To set up the tunnel, perform the following five steps on the NetScreen devices at both ends of the tunnel:
1. Assign IP addresses to the physical interfaces bound to the security zones and to the tunnel interface.
2. Configure the VPN tunnel, designate its outgoing interface in the Untrust zone, bind it to the tunnel interface,
and configure its proxy-ID.
3. Enter the IP addresses for the local and remote endpoints in the trust and untrust address books.
4. Enter a default route from the Trust-VR to the Untrust-VR, another default route to the external router in the
Untrust-VR, and a route to the destination via the tunnel interface.
5. Set up access policies for VPN traffic to pass between each site.
:HE8,7RN\R
,QWHUIDFHV²6HFXULW\=RQHVDQG7XQQHO
IP Address: 192.168.10.1
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
IP Address: 201.22.3.14
Netmask: 255.255.255.0
Zone Name: Untrust
Zone: Untrust
Interface: ethernet3(Untrust)

931
VPN Tunnel Name: Tokyo_Paris
Gateway IP: 203.3.3.10
Security Index: 3020 (Local), 3030 (Remote)
Bind to Tunnel Interface: (select), tunnel.1
ESP-CBC: (select)
Encryption Algorithm: 3DES-CBC
Generate Key by Password: asdlk24234
Generate Key by Password: PNas134a
$GGUHVVHV
Address Name: Trust_LAN
Netmask: 255.255.255.0
Zone: Trust
Address Name: Paris_office
Netmask: 255.255.255.0
Zone: Untrust

5RXWHV
Virtual Router Name: trust_vr
Netmask: 0.0.0.0
Virtual Router Name: untrust_vr
Netmask: 0.0.0.0
Netmask: 255.255.255.0
Interface: Tunnel.1

3ROLFLHV
Name: To Paris
Source Address: Trust_LAN
Destination Address: Paris_office
Service: ANY
Action: Permit
Name: From Paris
Source Address: Paris_office
Destination Address: Trust_LAN
Service: ANY
Action: Permit

:HE8,3DULV
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
Netmask: 255.255.255.0
Zone Name: Untrust
Zone: Untrust

931
VPN Tunnel Name: Paris_Tokyo
Gateway IP: 201.22.3.14
Outgoing Interface: ethernet3(Untrust)
ESP-CBC: (select)
$GGUHVVHV
Netmask: 255.255.255.0
Zone: Trust
Address Name: Tokyo_office
Netmask: 255.255.255.0
Zone: Untrust

5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
Netmask: 255.255.255.0
Interface: Tunnel.1

3ROLFLHV
Name: To Tokyo
Destination Address: Tokyo_office
Service: ANY
Action: Permit
Name: From Tokyo
Source Address: Tokyo_office
Destination Address: Trust_LAN
Service: ANY
Action: Permit

&/,7RN\R
3. set interface ethernet1 nat9
7. set interface tunnel.1 ip unnumbered interface ethernet3
931
8. set vpn tokyo_paris manual 3020 3030 gateway 203.3.3.10 outgoing-interface ethernet3 esp 3des
password asdlk24234 auth sha-1 password PNas134a
9. set vpn tokyo_paris bind interface tunnel.1
$GGUHVVHV
10. set address trust Trust_LAN 192.168.10.0/24
11. set address untrust paris_office 172.16.5.0/24
5RXWH
14. set vrouter untrust-vr route 172.16.5.0/24 interface tunnel.1
3ROLFLHV
15. set policy name “To Paris” from trust to untrust Trust_LAN paris_office any permit
16. set policy name “From Paris” from untrust to trust paris_office Trust_LAN any permit
17. save
9. By default, the Trust zone is in NAT mode. This command is unnecessary but is included to maintain symmetry with the WebUI configuration.

&/,3DULV
931
8. set vpn paris_tokyo manual 3030 3020 gateway 201.22.3.14 outgoing-interface ethernet3 esp 3des
9. set vpn paris_tokyo bind interface tunnel.1
$GGUHVVHV
11. set address untrust tokyo_office 192.168.10.0/24
5RXWH
3ROLFLHV
15. set policy name “To Tokyo” from trust to untrust Trust_LAN tokyo_office any permit
16. set policy name “From Tokyo” from untrust to trust tokyo_office Trust_LAN any permit
17. save

([DPSOH5RXWLQJ%DVHG/$1WR/$1931$XWR.H\,.(
In this example, an AutoKey IKE tunnel using either a preshared secret or a pair of certificates (one at each end of
the tunnel) provides the secure connection between the Tokyo and Paris offices. The Phase 1 negotiations are in
Main mode, and the tunnel uses ESP with 3DES encryption and SHA-1 authentication.

Trust Untrust Untrust Trust

Zone Zone Zone Zone

eth3, 201.22.3.14/24 eth3, 203.3.3.10/24
Tokyo Paris
Gateway 201.22.3.20 Gateway 203.3.3.1
eth1, 192.168.10.1/24 eth1, 172.16.5.1/24
Internet
VPN Tunnel
Tunnel Interface Tunnel Interface

Tunnel.1 Tunnel.1
Setting up a routing-based AutoKey IKE tunnel using either a preshared secret or certificates involves the following
two steps:
1. Define the remote gateway and key exchange mode, and specify either a preshared secret or a certificate.
2. Create the Autokey IKE VPN entry, bind the tunnel to a tunnel interface, and configure a proxy-ID.

Note: The full AutoKey IKE configuration also involves the following procedures:
• Defining security zone interface IP addresses
• Creating an unnumbered tunnel interface
• Making address book entries for the local and remote end entities
• Setting up routes
• Configuring access policies.
However, because those steps are the same as those explained in “Example: Routing-Based LAN-to-LAN
VPN, Manual Key” on page 317, they are omitted here.
In the following examples, the preshared key is h1p8A24nG5. It is assumed that both participants already have
certificates. (For more information about obtaining and loading certificates, see “Certificates and CRLs” on page
291.)
:HE8,7RN\R
1. VPN >>Gateway (P1) >>New Remote Tunnel Gateway: Enter the following, and then click OK:
Gateway Name: To_Paris
Mode (Initiator): Main (ID Protection)
For preshared key:
Preshared Key: h1p8A24nG5
For certificate:

Name: Tokyo_Paris
Remote Gateway Tunnel: To_Paris
Phase 2 Proposal: nopfs-esp-3des-sha
Local IP: 192.168.10.0
Netmask: 255.255.255.0
Remote IP: 172.16.5.0
Netmask: 255.255.255.0
Service: ANY
:HE8,3DULV
Gateway Name: To_Tokyo
IP Address: 201.22.3.14
For preshared key:
For certificate:

Preferred certificate Peer CA: Entrust

Preferred certificate Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway Tunnel: To_Tokyo
Local IP: 172.16.5.0
Netmask: 255.255.255.0
Remote IP: 192.168.10.0
Netmask: 255.255.255.0
Service: ANY
&/,7RN\R
3UHVKDUHG.H\
1. set ike gateway to_paris ip 203.3.3.10 main outgoing-interface eth3 preshare h1p8A24nG5 proposal
pre-g2-3des-sha-1
2. set vpn tokyo_paris gateway to_paris tunnel proposal nopfs-esp-3des-sha
4. set vpn tokyo_paris proxy-id local-ip 192.168.10.0/24 remote-ip 172.16.5.0/24 any
5. save

&HUWLILFDWH
1. set ike gateway to_paris ip 203.3.3.10 main outgoing-interface eth3 proposal rsa-g2-3des-sha
4. set vpn tokyo_paris proxy-id local-ip 192.168.10.0/24 remote-ip 172.16.5.0/24 any
5. save
&/,3DULV
3UHVKDUHG.H\
1. set ike gateway to_tokyo ip 201.22.3.14 main outgoing-interface eth3 preshare h1p8A24nG5 proposal
pre-g2-3des-sha-1
2. set vpn paris_tokyo gateway to_tokyo tunnel proposal nopfs-esp-3des-sha
4. set vpn paris_tokyo proxy-id local-ip 172.16.5.0/24 remote-ip 192.168.10.0/24 any
5. save
&HUWLILFDWH
1. set ike gateway to_tokyo ip 201.22.3.14 main outgoing-interface eth3 proposal rsa-g2-3des-sha
4. set vpn paris_tokyo proxy-id local-ip 172.16.5.0/24 remote-ip 192.168.10.0/24 any
5. save

([DPSOH5RXWLQJ%DVHG/$1WR/$1931'\QDPLF3HHU
In this example, a VPN tunnel securely connects the users in the Trust zone behind NetScreen A to the mail server
in the corporate DMZ zone, protected by NetScreen B. The Untrust zone interface for NetScreen B has a static IP
address. The ISP serving NetScreen A assigns the IP address for its Untrust zone interface dynamically via DHCP.
Because only NetScreen B has a fixed address for its Untrust zone, VPN traffic must originate from hosts behind
NetScreen A. After NetScreen A has established the tunnel, traffic through the tunnel can originate from either end.

configured on NetScreen A configured on NetScreen B
at the branch office. at the corporate site.
A B A B
Trust Untrust Untrust DMZ

Zone Zone Zone Zone
Outgoing Interface
Untrust Zone Outgoing Interface Corporate Office
Branch Office eth3 and gateway Untrust Zone DMZ Zone
Trust Zone dynamically assigned eth3, 203.10.20.1/24 eth2, 172.30.5.1/24
eth1, 10.10.10.1/24 by ISP Gateway 203.10.20.2
Mail Server
Internet 172.30.5.5
NetScreen A VPN Tunnel NetScreen B IDENT

SMTP or POP3 Request
Request DHCP Server
Tunnel Interface 203.2.3.1 Tunnel Interface
Tunnel.1 Tunnel.1
Note: Before making an SMTP or POP3 connection to the corporate

mail server, Phil must first initiate an HTTP, FTP, or Telnet connection
so that NetScreen A can authenticate him.

In this example, authentication user Phil (login name: pmason; password: Nd4syst4) wants to get his e-mail from the
mail server at the corporate site. When he attempts to do so, he is authenticated twice: first, NetScreen A
authenticates him locally before allowing traffic from him through the tunnel10; second, the mail server program
authenticates him, sending the IDENT request through the tunnel.
Note: The mail server can send the IDENT request through the tunnel only if the NetScreen A and B administrators
add a custom service for it (TCP, port 113) and set up access policies allowing that traffic through the tunnel to the
10.10.10.0/24 subnet.
The preshared key is h1p8A24nG5. It is assumed that both participants already have certificates, and that the e-mail
address jking@abc.com appears in the local certificate on NetScreen A. (For more information about obtaining and
loading certificates, see “Certificates and CRLs” on page 291.)
:HE8,1HW6FUHHQ$
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
2. Interface >> Physical >> Edit (for ethernet3): Enter the following, and then click Save11 :
IP Address: Obtain IP using DHCP (select)
Zone Name: Untrust
10. Because Phil is an authentication user, before he can make an SMTP of POP3 request, he must first initiate an HTTP, FTP, or Telnet connection so that
NetScreen A can respond with a firewall user/login prompt to authenticate him. After NetScreen A authenticates him, he has permission to contact the
corporate mail server via the VPN tunnel.

Zone: Untrust
8VHU
4. Users >> Users >> New AUTH/IKE/L2TP User: Enter the following, and then click OK:
User Name: pmason
User Password: Nd4syst4
Confirm Password: Nd4syst4
$GGUHVVHV
Address Name: Trusted network
Netmask: 255.255.255.0
Zone: Trust
Netmask: 255.255.255.255
Zone: Untrust

6HUYLFHV
7. Service >> Custom >> New Service: Enter the following, and then click OK:
Service Name: Ident
Source Port: (Low) 113, (High) 113
8. Service >> Custom >> New Group: Enter the following, move the following services, and then click OK:
Group Name: Remote_Mail
Group Members << Available Members:
HTTP
FTP
Telnet
Ident
MAIL
POP3
931
Gateway Name: To_Mail
Remote Gateway: Static IP Address: (select)
IP Address: 203.10.20.1
Mode (Initiator): Aggressive
For preshared key:
Local ID: jking@abc.com

For certificate:
Name: branch_corp
Remote Gateway Tunnel: To_Mail
Local IP: 10.10.10.0
Netmask: 255.255.255.0
Remote IP: 172.30.5.5
Netmask: 255.255.255.255
Service: Remote_Mail

5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
Gateway IP Address: (select), 0.0.0.012
Interface: ethernet3(untrust)
Netmask: 255.255.255.255
Interface: Tunnel.1
12. The ISP provides the gateway IP address dynamically through DHCP.

3ROLFLHV
Source Address: Trusted network
Action: Permit
Destination Address: Trusted network
Action: Permit

:HE8,1HW6FUHHQ%
Netmask: 255.255.255.0
Zone Name: DMZ
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
Zone: DMZ
Interface: ethernet2(DMZ)
$GGUHVVHV
Netmask: 255.255.255.255
Zone: DMZ

Address Name: branch office
Netmask: 255.255.255.0
Zone: Untrust
6HUYLFHV
Service Name: Ident
Ident
MAIL
POP3
931
8. VPN >> Gateway (P1) >> New Remote Gateway: Enter the following, and then click OK:
Gateway Name: To_branch
Remote Gateway: Dynamic IP Address: (select)
Peer ID: jking@abc.com

For preshared key:

For certificate:
Name: corp_branch
Remote Gateway Tunnel: To_branch
Local IP: 172.30.5.5
Netmask: 255.255.255.255
Remote IP: 10.10.10.0
Netmask: 255.255.255.0
5RXWH
Netmask: 0.0.0.0

Netmask: 255.255.255.0
Interface: Tunnel.1
3ROLFLHV
12. Policy >> Policy (From Zone DMZ, To Zone Untrust) >> New Policy: Enter the following, and then click OK:
Destination Address: branch office
Action: Permit
13. Policy >> Policy (From Zone Untrust, To Zone DMZ) >> New Policy: Enter the following, and then click OK:
Source Address: branch office
Action: Permit

&/,1HW6FUHHQ$
6. set dhcp client server 201.2.3.1
8VHU
9. set user pmason password Nd4syst4
$GGUHVVHV
10. set address trust “trusted network” 10.10.10.0 255.255.255.0
11. set address untrust “mail server” 172.30.5.5 255.255.255.255
6HUYLFHV
12. set service ident protocol tcp src-port 113-113
13. set group service remote_mail
14. set group service remote_mail add http
15. set group service remote_mail add ftp
16. set group service remote_mail add telnet
17. set group service remote_mail add ident

18. set group service remote_mail add mail

19. set group service remote_mail add pop3
931
Preshared Key:
20. set ike gateway to_mail ip 203.10.20.4 aggressive outgoing-interface eth3 local-id jking@abc.com preshare
h1p8A24nG5 proposal pre-g2-3des-sha-1
21. set vpn branch_corp gateway to_mail tunnel proposal nopfs-esp-3des-sha
22. set vpn branch_corp bind interface tunnel.1
23. set vpn branch_corp proxy-id local-ip 10.10.10.0/24 remote-ip 172.30.5.5/32 remote_mail
Certificate:
18. set ike gateway to_mail ip 203.10.20.4 aggressive outgoing-interface eth3 local-id jking@abc.com proposal
rsa-g2-3des-sha
20. set vpn branch_corp bind interface tunnel.1
21. set vpn branch_corp proxy-id local-ip 10.10.10.0/24 remote-ip 172.30.5.5/32 remote_mail
5RXWHV
23. set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3
24. set vrouter-untrust-vr route 172.30.5.5/32 interface tunnel.1
3ROLFLHV
25. set policy from trust to untrust “trusted network” “mail server” remote_mail permit auth
26. set policy from untrust to trust “mail server” “trusted network” remote_mail permit
27. save

&/,1HW6FUHHQ%
1. set interface ethernet2 zone dmz
$GGUHVVHV
7. set address dmz “mail server” 172.30.5.5/32
8. set address untrust “branch office” 10.10.10.0/24
6HUYLFHV

931
Preshared Key:
14. set ike gateway to_branch dynamic name@company.com aggressive outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
15. set vpn corp_branch gateway to_branch tunnel proposal nopfs-esp-3des-sha
17. set vpn to_branch proxy-id local-ip 172.30.5.5/32 remote-ip 10.10.10.0/24 remote_mail
18. Certificate:
13. set ike gateway to_branch dynamic name@company.com aggressive outgoing-interface ethernet3 proposal
rsa-g2-3des-sha
16. set vpn to_branch proxy-id local-ip 172.30.5.5/32 remote-ip 10.10.10.0/24 remote_mail
5RXWH
3ROLFLHV
19. set policy from dmz to untrust “mail server” “branch office” remote_mail permit
20. set policy from untrust to dmz “branch office” “mail server” remote_mail permit
21. save

&KDSWHU5RXWLQJ%DVHG931V 'LDOXSWR/$1931'\QDPLF3HHU
',$/8372/$1931'<1$0,&3((5
NetScreen devices also support VPN dialup connections. You can configure a NetScreen security gateway with a
static IP address to secure an IPSec tunnel with a NetScreen-Remote client or with another NetScreen device with a
dynamic IP address.
You can configure policy-based VPN tunnels for VPN dialup users. For a dialup dynamic peer client14, you can
configure either a policy-based or routing-based VPN. Because a dialup dynamic peer client can support a virtual
internal IP address, which the NetScreen-Remote does, you can configure a routing table entry to that virtual
internal address via a designated tunnel interface, allowing you to configure a routing-based VPN tunnel between
the NetScreen device and that peer.
Note: The dialup-to-LAN dynamic peer is nearly identical to the LAN-to-LAN dynamic peer except that the
internal IP address for the dialup client is a virtual address.
14. A dialup dynamic peer client is a dialup client that supports a virtual internal IP address.

([DPSOH5RXWLQJ%DVHG'LDOXSWR/$1931'\QDPLF3HHU
In this example, a VPN tunnel securely connects the user behind the NetScreen-Remote to the Untrust zone
interface of the NetScreen device protecting the mail server in the DMZ zone. The Untrust zone interface has a
static IP address. The NetScreen-Remote client has a dynamically assigned external IP address and a static
(virtual) internal IP address, which must be known to the administrator of the NetScreen device so that he can add it
to the Untrust address book for use in access policies to tunnel traffic from that source. After the NetScreen-Remote
client establishes the tunnel, traffic through the tunnel can originate from either end.
Remote User: Phil Outgoing Interface

NetScreen-Remote Untrust Zone Corporate Office
eth3, 203.10.20.1/24 DMZ Zone
Gateway 203.10.20.2 eth2, 172.30.5.1/24
SMTP
Request Mail Server
172.30.5.5
Internet
IDENT
VPN Tunnel Request
Internal IP Address External IP Address Untrust DMZ

10.10.10.1 Dynamic Zone Zone
In this example, Phil wants to get his e-mail from the mail server at the company site. When he attempts to do so, he
is authenticated by the mail server program, which sends him an IDENT request through the tunnel.
Note: The mail server can send the IDENT request through the tunnel only if the NetScreen-100 administrator adds
a custom service for it (TCP, port 113) and sets up an outgoing access policy allowing that traffic through the tunnel
to 10.10.10.1.
The preshared key is h1p8A24nG5. It is assumed that both participants already have certificates, and that the local
certificate on the NetScreen-Remote contains the IP address 10.10.10.1. (For more information about obtaining and

:HE8,
Netmask: 255.255.255.0
Zone Name: DMZ
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
$GGUHVVHV
Netmask: 255.255.255.255
Zone: DMZ
Address Name: Phil
Netmask: 255.255.255.255
Zone: Untrust

6HUYLFHV
Service Name: Ident
Ident
MAIL
POP3
931
Gateway Name: To_Phil
Peer ID: 10.10.10.1
For preshared key:
For certificate:

Name: corp_Phil
Remote Gateway Tunnel: To_Phil
5RXWH
Netmask: 0.0.0.0
3ROLF\
Action: Tunnel
VPN Tunnel: corp_Phil

&/,
$GGUHVVHV
6. set address untrust phil 10.10.10.1/32
6HUYLFHV

931
Preshared Key:
12. set ike gateway to_phil dynamic 10.10.10.1 aggressive outgoing-interface ethernet3 preshare h1p8A24nG5
proposal pre-g2-3des-sha
13. set vpn corp_phil gateway to_phil tunnel proposal nopfs-esp-3des-sha
Certificate:
13. set ike gateway to_phil dynamic name@company.com aggressive outgoing-interface ethernet3 proposal
rsa-g2-3des-sha
5RXWH
3ROLFLHV
16. set policy from dmz to untrust “mail server” phil remote_mail tunnel vpn corp_phil
17. set policy from untrust to dmz phil “mail server” remote_mail tunnel vpn corp_phil
18. save

1HW6FUHHQ5HPRWH
1. Click Options >> Global Policy Settings, and select the Allow to Specify Internal Network Address
check box.
2. Options >> Secure >> Specified Connections.
3. Click the Add a new connection button, and type Mail next to the new connection icon that appears.
4. Configure the connection options:
Connection Security: Secure
Remote Party ID Type: IP Address
Connect using Secure Gateway Tunnel: (select)
ID Type: IP Address; 203.10.20.1
5. Click the PLUS symbol, located to the left of the unix icon, to expand the connection policy.
6. Click My Identity: Do either of the following:
Click Pre-shared Key >> Enter Key: Type h1p8A24nG5, and then click OK.
ID Type: Internal Network IP Address: Type 10.10.10.1.
or
Select a certificate from the Select Certificate drop-down list.
ID Type: (select IP Address); Internal Network IP Address: Type 10.10.10.1.
7. Click the Security Policy icon, and select Aggressive Mode.

8. Click the PLUS symbol, located to the left of the Security Policy icon, and then the PLUS symbol to the left
of Authentication (Phase 1) and Key Exchange (Phase 2) to expand the policy further.
9. Click Authentication (Phase 1) >> Proposal 1: Select the following Encryption and Data Integrity
Algorithms:
Encrypt Alg: Triple DES
Hash Alg: SHA-1
Key Group: Diffie-Hellman Group 2
10. Click Key Exchange (Phase 2) >> Proposal 1: Select the following IPSec Protocols:
Encapsulation Protocol (ESP): (select)
Encrypt Alg: 3DES
Hash Alg: SHA-1
Encapsulation: Tunnel
11. Click the Save button.

&KDSWHU5RXWLQJ%DVHG931V +XEDQG6SRNH931V
+8%$1'632.(9316
If you create two VPN tunnels that terminate at a NetScreen device, you can set up a pair of routes so that the
NetScreen device directs traffic exiting one tunnel to the other tunnel. If both tunnels are contained within a single
zone, you do not need to create an access policy to permit the traffic to pass from one tunnel to the other. You only
need to define the routes. Such an arrangement is known as hub-and-spoke VPNs.
Remote Sites
Hub-and-Spoke
Untrust Zone VPN Tunnels
The NetScreen device routes traffic

from one tunnel to the other tunnel.
You can also configure multiple VPNs in one zone and route traffic between any two tunnels.
Untrust Zone
Multiple Hub-and-Spoke VPN Tunnels
The NetScreen device

routes traffic between tunnels.

([DPSOH+XEDQG6SRNH931V
In this example, two branch offices in Tokyo and Paris communicate with each other via a pair of VPN tunnels—
VPN1 and VPN2. Each tunnel originates at the remote site and terminates at the corporate site in New York. The
NetScreen device at the corporate site routes traffic exiting one tunnel into the other tunnel.
Because both remote endpoints are in the same zone (the Untrust Zone), the NetScreen device at the corporate site
only needs to do a route lookup, not a policy lookup, when conducting traffic from tunnel to tunnel. (An access policy
is only required to permit traffic when it flows between security zones, not within a security zone.)
You bind the tunnels to the tunnel interfaces—tunnel.1 and tunnel.2—which are both unnumbered. The tunnels use
AutoKey IKE, with preshared keys, Diffie-Hellman Group 2, 3DES encryption, and SHA-1 authentication. The
Untrust zone interface is ethernet3.
Note: Only the configuration for the NetScreen device at the corporate site is provided below.
Untrust Zone Untrust VR Routing Domain
Outgoing Default Gateway

Interface IP 123.1.1.2 Tokyo 110.1.1.1
eth3 (Spoke)
Tokyo LAN
IP 123.1.1.1 10.10.1.0/24
Internet
VPN1
VPN2 Paris 220.2.2.2

(Spoke) Paris LAN
New York – Corporate Site Interface:
(Hub) 10.20.1.0/24
tunnel.1
Interface:
tunnel.2

:HE8,
=RQHV
1. Zone >> Zone >>Edit (for Untrust): Enter the following, and then click OK:
Block Intra-Zone Traffic: (clear)
,QWHUIDFHV²=RQHVDQG7XQQHOV
2. Interface >> Physical >> Edit (for ethernet3): Enter the following, and then click OK:
Netmask: 255.255.255.0
Zone Name: Untrust
Tunnel Interface Name: tunnel.: 1

931IRU7RN\R2IILFH
Gateway Name: Tokyo
Name: VPN1
Remote Gateway Tunnel: Tokyo
Enable Proxy-ID: (select)15
Local IP: 10.0.0.0
Netmask: 255.0.0.0
Remote IP: 10.10.1.0
Netmask: 255.255.255.0
Service: ANY
15. When configuring the VPN tunnel on the NetScreen device protecting the Tokyo and Paris offices, do either of the following:
(Routing-based VPN) Select the Enable Proxy-ID check box and enter 10.10.1.0 255.255.255.0 (Tokyo) and 10.20.1.0 255.255.255.0 (Paris) for the Local
IP and Netmask, and 10.0.0.0 255.0.0.0 for the Remote IP and Netmask.
(Policy-based VPN) Make an entry in the Trust zone address book for 10.10.1.0 255.255.255.0 (Tokyo) and 10.20.1.0 255.255.255.0 (Paris) and another in
the Untrust zone address book for 10.0.0.0 255.0.0.0, and use those as the source and destination addresses in the access policy referencing the VPN
tunnel to the hub site.

931IRU3DULV2IILFH
Gateway Name: Paris
Name: VPN2
Remote Gateway Tunnel: Paris
Local IP: 10.0.0.0
Netmask: 255.0.0.0
Netmask: 255.255.255.0
Service: ANY

5RXWHV
Netmask: 255.255.255.0
Interface: tunnel.1(untrust-vr)
10. Routing >> Route Table >> New Entry: Enter the following, and then click OK
Netmask: 255.255.255.0
Interface: tunnel.2(untrust-vr)
11. Routing >> Route Table >> New Entry: Enter the following, and then click OK
Netmask: 0.0.0.0

&/,
=RQH
1. unset zone untrust block
,QWHUIDFHV²=RQHVDQG7XQQHOV
5. set interface tunnel.1 ip unnumbered interface eth3
7. set interface tunnel.2 ip unnumbered interface eth3
931IRU7RN\R2IILFH
8. set ike gateway Tokyo ip 110.1.1.1 main outgoing-interface eth3 preshare netscreen1 proposal
pre-g2-3des-sha
9. set vpn VPN1 gateway Tokyo replay proposal g2-esp-3des-sha
10. set vpn VPN1 bind interface tunnel.1
11. set vpn VPN1 proxy-id local-ip 10.0.0.0/8 remote-ip 10.10.1.0/24 any16
(Routing-based VPN) Enter the following commands: set vpn VPN1 proxy-id local-ip 10.10.1.0/24 remote-ip 10.0.0.0/8 (Tokyo) and set vpn VPN1
proxy-id local-ip 10.20.1.0/24 remote-ip 10.0.0.0/8 (Paris).
(Policy-based VPN) Make an entry in the Trust zone address book for 10.10.1.0/24 (Tokyo) and 10.20.1.0/24 (Paris) and another in the Untrust zone address
book for 10.0.0.0/8, and use those as the source and destination addresses in the access policy referencing the VPN tunnel to the hub site.

931IRU3DULV2IILFH
12. set ike gateway Paris ip 220.2.2.2 main outgoing-interface eth3 preshare netscreen1 proposal
pre-g2-3des-sha
13. set vpn VPN2 gateway Paris replay proposal g2-esp-3des-sha
15. set vpn VPN2 proxy-id local-ip 10.0.0.0/8 remote-ip 10.20.1.0/24 any
5RXWHV
18. set vrouter untrust-vr route 0.0.0.0/0 interface eth3 gateway 123.1.1.2
19. save

&KDSWHU5RXWLQJ%DVHG931V %DFNWR%DFN931V
%$&.72%$&.9316
You can enforce access policies at the hub site for traffic passing from one VPN tunnel to another by putting the
spoke sites in different zones. Because they are in different zones, the NetScreen device at the hub must do a policy
lookup before routing the traffic from one tunnel to another. Thus you can control the traffic flowing via the VPN
tunnels between the spoke sites. Such an arrangement is called back-to-back VPNs.
Back-to-Back VPNs
X1 X2
Spoke A Zone Zone Spoke B
VPN1 VPN2
Policy
Lookup
Hub
A few benefits of back-to-back VPNs:

• You can conserve the number of VPNs you need to create. For example, perimeter site A can link to the
hub, and to perimeter sites B, C, D…, but A only has to set up one VPN tunnel. Especially for
NetScreen-5XP users, who can use a maximum of just ten VPN tunnels concurrently, applying the
hub-and-spoke method dramatically increases their VPN options and capabilities.

• The administrator at the hub device can completely control VPN traffic between perimeter sites. For
example,
– He or she might permit only HTTP traffic to flow from sites A to B, but allow any kind of traffic to flow
from B to A.
– He or she can allow traffic originating from A to reach C, but deny traffic originating from C to reach A.
– He or she can allow a specific host at A to reach the entire D network, while allowing only a specific
host at D to reach a different host at A.
• The administrator at the hub device can completely control outbound traffic from all perimeter networks. At
each perimeter site, there must first be an access policy that tunnels all outbound traffic through the spoke
VPNs to the hub; for example: set policy from trust to untrust any any any tunnel vpn <name> (where
<name> defines the specific VPN tunnel from each perimeter site to the hub). At the hub, the administrator
can control Internet access, allowing certain kinds of traffic (such as HTTP only), performing URL blocking
on undesirable Web sites, and so on.
• Regional hubs can be used and interconnected via spoke tunnels, allowing spoke sites in one region to
reach spoke sites in another.
([DPSOH%DFNWR%DFN931V
The following example is similar to “Example: Hub-and-Spoke VPNs” on page 358 except that the NetScreen device
at the hub site in New York performs policy checking on the traffic it routes between the two tunnels to the branch
offices in Tokyo and Paris. By putting each remote site in a different zone, you control the VPN traffic at the hub.
The Tokyo LAN address is in the user-defined X1 zone, and the Paris LAN address is in the user-defined X2 zone.
Both zones are in the Trust-VR routing domain.
Note: To create user-defined zones, you must first obtain and load a zone software key on the NetScreen device.
You bind the VPN1 tunnel to the tunnel.1 interface and the VPN2 tunnel to the tunnel.2 interface. Although you do
not assign IP addresses to the X1 and X2 zone interfaces, you do give addresses to both tunnel interfaces. Routes
for these interfaces automatically appear in the Trust-VR routing table. By putting the IP address for a tunnel
interface in the same subnet as that of the destination, traffic destined for that subnet is routed to the tunnel
interface.

The outgoing interface is ethernet3, which is bound to the Untrust zone. As you can see in the illustration below,
both tunnels terminate in the Untrust zone; however, the endpoints for the traffic that makes use of the tunnels are in
the X1 and X2 zones.
The tunnels use AutoKey IKE, with preshared keys, Diffie-Hellman Group 2, 3DES encryption, and SHA-1
authentication. Because the tunnels are routing-based (that is, the correct tunnel is determined by routing, not by a
tunnel name specified in an access policy), proxy IDs are included in the configuration of each tunnel.
Note: Only the configuration for the NetScreen device at the hub site is provided below.
New York Default Tokyo (Spoke)

Outgoing Interface Gateway 110.1.1.1
Untrust Zone IP 123.1.1.2 Paris (Spoke)
eth3, IP 123.1.1.1/24 220.2.2.2
VPN1 Untrust-VR
Routing Domain
Trust-VR
Routing Domain Interface: VPN2
tunnel.1
10.10.1.2/24
New York
Corporate Site
(Hub) X1 Zone Tokyo LAN
10.10.1.0/24
Trust Zone Policy

Lookup
X2 Zone Paris LAN

10.20.1.0/24
eth1, 10.1.1.1/24
Interface:
tunnel.2
10.20.1.2/24

:HE8,
6HFXULW\=RQHV
Name: X1
Virtual Router Name: Trust-VR
Name: X2
Virtual Router Name: Trust-VR
,QWHUIDFHV²8QWUXVW=RQHDQG7XQQHOV
3. Interface >> Edit (for ethernet3): Enter the following, and then click OK:
Netmask: 255.255.255.0
Zone Name: Untrust
Zone: X1
Fixed IP: (select)
Netmask:255.255.255.0
Zone: X2
Fixed IP: (select)
Netmask:255.255.255.0

931IRU7RN\R2IILFH
Gateway Name: Tokyo
Name: VPN1
Remote Gateway Tunnel: Tokyo
Enable Proxy-ID: (select)17
Local IP: 10.20.1.0
Netmask: 255.255.255.0
Netmask: 255.255.255.0
Service: ANY
(Routing-based VPN) Select the Enable Proxy-ID check box and enter 10.10.1.0 255.255.255.0 (Tokyo) and 10.20.1.0 255.255.255.0 (Paris) for the Local
IP and Netmask, and 10.20.1.0 255.255.255.0 (Tokyo) and 10.10.1.0 255.255.255.0 (Paris) for the Remote IP and Netmask.
book for 10.20.1.0/24 (Tokyo) and 10.10.1.0/24 (Paris). Use those as the source and destination addresses in the access policy referencing the VPN tunnel
to the hub site.

931IRU3DULV2IILFH
Gateway Name: Paris
Name: VPN2
Remote Gateway Tunnel: Paris
Local IP: 10.10.1.0
Netmask: 255.255.255.0
Netmask: 255.255.255.0
Service: ANY

5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
$GGUHVVHV
Address Name: Tokyo LAN
Netmask: 255.255.255.0
Zone: X1
Address Name: Paris LAN
Netmask: 255.255.255.0
Zone: X2

3ROLFLHV
14. Policy (From Zone: X1, To Zone: X2) >> New Policy: Enter the following, and then click OK:
Source Address: Tokyo LAN
Destination Address: Paris LAN
Service: ANY
Action: Permit
15. Policy (From Zone: X2, To Zone: X1) >> New Policy: Enter the following, and then click OK:
Source Address: Paris LAN
Destination Address: Tokyo LAN
Service: ANY
Action: Permit

&/,
6HFXULW\=RQHV
1. set zone name X1
2. set zone x1 vrouter trust-vr
3. set zone name x2
4. set zone x2 vrouter trust-vr
,QWHUIDFHV²8QWUXVW=RQHDQG7XQQHOV
5. set interface eth3 zone untrust
6. set interface eth3 ip 123.1.1.1/24
7. set interface tunnel.1 zone x1
8. set interface tunnel.1 ip 10.10.1.2/24
9. set interface tunnel.2 zone x2
10. set interface tunnel.2 ip 10.20.1.2/24
931IRU7RN\R2IILFH
11. set ike gateway Tokyo ip 110.1.1.1 main outgoing-interface eth3 preshare netscreen1 proposal
pre-g2-3des-sha
12. set vpn VPN1 gateway Tokyo replay proposal g2-esp-3des-sha
14. set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 any18
(Routing-based VPN) Enter the following commands: set vpn VPN1 proxy-id local-ip 10.20.1.0/24 remote-ip 10.10.1.0/24 (Tokyo) and set vpn VPN1
proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 (Paris).
book for 10.20.1.0/24 (Tokyo) and 10.10.1.0/24 (Paris). Use those as the source and destination addresses in the access policies referencing the VPN tunnel
to the hub site.

931IRU3DULV2IILFH
15. set ike gateway Paris ip 220.2.2.2 main outgoing-interface eth3 preshare netscreen2 proposal
pre-g2-3des-sha
16. set vpn VPN2 gateway Paris replay proposal g2-esp-3des-sha
18. set vpn VPN2 proxy-id local-ip 10.10.1.0/24 remote-ip 10.20.1.0/24 any
5RXWH
20. set vrouter untrust-vr route 0.0.0.0/0 interface eth3 gateway 123.1.1.2
$GGUHVVHV
21. set address x1 “Tokyo LAN” 10.10.1.0/24
22. set address x2 “Paris LAN” 10.20.1.0/24
3ROLFLHV
23. set policy from x1 to x2 “Tokyo LAN” “Paris LAN” any permit19
24. set policy from x2 to x1 “Paris LAN” “Tokyo LAN” any permit19
25. save
19. You can ignore the following message, which appears because tunnel interfaces are in NAT mode: Warning: Some interfaces in the <zone_name> zone are
in NAT mode. Traffic might not pass through them!

&KDSWHU
3ROLF\%DVHG931V

A policy-based VPN is a configuration in which a specific VPN tunnel is referenced in an access policy whose action
is set as tunnel. Contrast a policy-based VPN with a routing-based VPN configuration, in which the access policy
does not reference a specific VPN tunnel. Instead, a VPN tunnel is indirectly referenced by a route that points to a
specific tunnel interface. The tunnel interface might be bound to a VPN tunnel or to a tunnel zone.
Note: For examples of routing-based VPNs, see Chapter 12, “Routing-Based VPNs”. For information on binding a
tunnel interface to a VPN tunnel, see “Tunnel Interfaces” on page 377.
This chapter presents examples of the following kinds of policy-based VPN tunnels:
• “LAN-to-LAN VPNs” on page 376
– “Example: Policy-Based LAN-to-LAN VPN, Manual Key” on page 379
– “Example: Policy-Based LAN-to-LAN VPN, AutoKey IKE” on page 388
– “Example: Policy-Based LAN-to-LAN VPN, Dynamic Peer” on page 392
• “Dialup-to-LAN VPNs” on page 404
– “Example: Policy-Based Dialup-to-LAN VPN, Manual Key” on page 405
– “Example: Policy-Based Dialup-to-LAN VPN, AutoKey IKE” on page 411
– “Example: Policy-Based Dialup-to-LAN VPN, Dynamic Peer” on page 417
• “Tunnel Zones and Policy-Based NAT” on page 425
– “Example: Tunnel Interface in a Tunnel Zone” on page 427
6XE7LWOH
/$172/$19316
An IPSec VPN tunnel exists between two gateways, and each gateway needs an IP address. When both gateways
have static IP addresses, you can configure the following kinds of tunnels:
• LAN-to-LAN VPN, Manual Key tunnel
• LAN-to-LAN VPN, AutoKey IKE tunnel (with a preshared key or certificates)
When one gateway has a static address and the other has a dynamically assigned address, you can configure the
following kind of tunnel:
• Dynamic Peer LAN-to-LAN VPN, AutoKey IKE tunnel (with a preshared key or certificates)
As used here, a static LAN-to-LAN VPN involves an IPSec tunnel connecting two LANs, each with a NetScreen
device operating as a secure gateway. The physical interface or subinterface used as the outgoing interface on both
devices has a fixed IP address, and the internal hosts also have static IP addresses. If the NetScreen device is in
Transparent mode, the VLAN1 address or the System IP address—both of which are fixed addresses—is used1.
(See “Example: Policy-Based LAN-to-LAN VPN, Manual Key” on page 379, and “Example: Policy-Based
LAN-to-LAN VPN, AutoKey IKE” on page 388.) With a static LAN-to-LAN VPN, hosts at either end of the tunnel can
initiate the VPN tunnel setup because the IP address of the remote gateway remains constant and thus reachable.
If the outgoing interface of one of the NetScreen devices has a dynamically assigned IP address, that device is
termed a dynamic peer and the VPN is configured differently. (See “Example: Policy-Based LAN-to-LAN VPN,
Dynamic Peer” on page 392.) With a dynamic peer LAN-to-LAN VPN, only hosts behind the dynamic peer can
initiate the VPN tunnel setup because only their remote gateway has a fixed IP address and is thus reachable from
their local gateway. However, after a tunnel has been set up between a dynamic peer and a static peer, hosts
behind either gateway can initiate VPN traffic if the destination hosts have fixed IP addresses.
1. If you set both the System IP and the VLAN1 IP address, the VLAN1 address takes priority and is the address to which you can terminate a VPN.
%RRN7LWOH
/$1WR/$1931V
7XQQHO,QWHUIDFHV
Beyond the VPN tunnel termination points (the local and remote gateways), you can also configure tunnel interfaces
in either a security zone or in a tunnel zone through which the NetScreen device directs traffic to and from the VPN
tunnel2. You can bind a VPN tunnel to a specific numbered (with IP address/netmask) or unnumbered (without IP
address/netmask) tunnel interface in a security zone. If the tunnel interface is unnumbered, it borrows the IP
address from the interface of the security zone in which you created it.

Interfaces Interfaces
When a numbered tunnel interface is in a tunnel zone, you
cannot bind a VPN tunnel to the tunnel interface. You can only
Tunnel VPN Tunnel bind a tunnel to the tunnel zone. This allows multiple tunnel
Numbered interfaces to link to a single tunnel, or multiple tunnels to link
Zone
to a single tunnel interface. In such cases, you must create a
policy-based VPN configuration.
When a tunnel interface is in a security zone, you must bind a

VPN tunnel to the tunnel interface. Doing so allows you to
create a routing-based VPN configuration.
Security VPN Tunnel
Numbered or The tunnel interface can be numbered or unnumbered. If it is
Unnumbered Zone unnumbered, the tunnel interface borrows the IP address from
the security zone interface. Note: Only a numbered tunnel
interface (that is, an interface with an IP address and
netmask) can support policy-based NAT.
When a numbered tunnel interface is in a security zone and is

Security VPN Tunnel the only interface in that zone, you do not need to create a
Numbered security zone interface. In this case, the security zone
Zone supports VPN traffic via the tunnel interface, but no other kind
of traffic.
Generally, assign an IP address to a tunnel interface if you want the interface to support policy-based NAT. For
more information about policy-based NAT, see Chapter 15, “Policy-Based NAT”. You can create a numbered tunnel
interface in either a tunnel zone or security zone.
2. If you do not specify a tunnel interface, the tunnel uses the default interface for the security zone.
6XE7LWOH
If the tunnel interface does not need to support policy-based NAT, and your configuration does not require the tunnel
interface to be bound to a tunnel zone, you can specify the interface as unnumbered. You must bind an unnumbered
tunnel interface to a security zone; you cannot bind it to a tunnel zone. You must also specify an interface bound to
that security zone whose IP address the unnumbered tunnel interface borrows.
Note: The security zone interface that you specify must be in the same zone to which you have bound the tunnel
interface.
%RRN7LWOH
/$1WR/$1931V
([DPSOH3ROLF\%DVHG/$1WR/$19310DQXDO.H\
In this example, a Manual Key tunnel provides a secure communication channel between offices in Tokyo and Paris,
using ESP with 3DES encryption and SHA-1 authentication. The Trust zones at each site are in NAT mode. The
addresses are as follows:
• Tokyo: • Paris:
- Trust interface (ethernet1): 192.168.10.1/24 - Trust Interface (ethernet1): 172.16.5.1/24
- Untrust interface (ethernet3): 201.22.3.14/24 - Untrust interface (ethernet3): 203.3.3.10/24
The Trust security zone and the Untrust-Tun tunnel zone are in the Trust-VR routing domain. The Untrust security
zone is in the Untrust-VR routing domain. The Untrust zone interface (ethernet3) serves as the outgoing interface for
the VPN tunnel.

Trust Untrust-Tun Untrust Untrust Untrust-Tun Trust

Zone Zone Zone Zone Zone Zone

eth3, 201.22.3.14/24 eth3, 203.3.3.10/24
Tokyo Paris
Gateway 201.22.3.20 Gateway 203.3.3.1
eth1, 192.168.10.1/24 eth1, 172.16.5.1/24
Internet
VPN Tunnel
6XE7LWOH
To set up the tunnel, perform the following five steps on the NetScreen devices at both ends of the tunnel:
1. Assign IP addresses to the physical interfaces bound to the security zones.
2. Configure the VPN tunnel, designate its outgoing interface in the Untrust zone.
By default, the tunnel is bound to the Untrust-Tun tunnel zone.
3. Enter the IP addresses for the local and remote endpoints in the trust and untrust address books.
4. Enter a default route from the Trust-VR to the Untrust-VR, and another default route to the external router in
the Untrust-VR.
5. Set up access policies for VPN traffic to pass bidirectionally through the tunnel.
:HE8,7RN\R
IP Address: 192.168.10.1
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
IP Address: 201.22.3.14
Netmask: 255.255.255.0
Zone Name: Untrust
%RRN7LWOH
/$1WR/$1931V
931
VPN Tunnel Name: Tokyo_Paris
Gateway IP: 203.3.3.10
Bind to Tunnel Zone: (select), Untrust-Tun
ESP-CBC: (select)
$GGUHVVHV
Netmask: 255.255.255.0
Zone: Trust
Address Name: Paris_office
Netmask: 255.255.255.0
Zone: Untrust
6XE7LWOH
5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
3ROLFLHV
Name: To/From Paris
Destination Address: Paris_office
Service: ANY
Action: Tunnel
VPN: Tokyo_Paris
%RRN7LWOH
/$1WR/$1931V
:HE8,3DULV
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
Netmask: 255.255.255.0
Zone Name: Untrust
6XE7LWOH
931
VPN Tunnel Name: Paris_Tokyo
Gateway IP: 201.22.3.14
Outgoing Interface: ethernet3(Untrust)
ESP-CBC: (select)
$GGUHVVHV
Netmask: 255.255.255.0
Zone: Trust
Address Name: Tokyo_office
Netmask: 255.255.255.0
Zone: Untrust
%RRN7LWOH
/$1WR/$1931V
5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
3ROLF\
Name: To/From Tokyo
Destination Address: Tokyo_office
Service: ANY
Action: Tunnel
VPN: Paris_Tokyo
6XE7LWOH
&/,7RN\R
931
6. set vpn tokyo_paris manual 3020 3030 gateway 203.3.3.10 outgoing-interface ethernet3 esp 3des
7. set vpn tokyo_paris bind zone untrust-tun4
$GGUHVVHV
9. set address untrust paris_office 172.16.5.0/24
5RXWHV
3ROLFLHV
12. set policy name “To/From Paris” from trust to untrust Trust_LAN paris_office any tunnel vpn tokyo_paris
13. set policy name “To/From Paris” from untrust to trust paris_office Trust_LAN any tunnel vpn tokyo_paris
14. save
4. By default, a VPN tunnel is bound to the Untrust-Tun tunnel zone. This command is also unnecessary but is included to match the WebUI configuration.
%RRN7LWOH
/$1WR/$1931V
&/,3DULV
931
6. set vpn paris_tokyo manual 3030 3020 gateway 201.22.3.14 outgoing-interface ethernet3 esp 3des
7. set vpn paris_tokyo bind zone untrust-tun
$GGUHVVHV
9. set address untrust tokyo_office 192.168.10.0/24
5RXWH
3ROLFLHV
12. set policy name “To/From Tokyo” from trust to untrust Trust_LAN tokyo_office any tunnel vpn paris_tokyo
13. set policy name “To/From Tokyo” from untrust to trust tokyo_office Trust_LAN any tunnel vpn paris_tokyo
14. save
6XE7LWOH
([DPSOH3ROLF\%DVHG/$1WR/$1931$XWR.H\,.(
the tunnel) provides the secure connection between the Tokyo and Paris offices. The Phase 1 negotiations are in
Main mode, and the tunnel uses ESP with 3DES encryption and SHA-1 authentication.

Trust Untrust-Tun Untrust Untrust Untrust-Tun Trust


eth3, 201.22.3.14/24 eth3, 203.3.3.10/24
Tokyo Paris
Gateway 201.22.3.20 Gateway 203.3.3.1
eth1, 192.168.10.1/24 eth1, 172.16.5.1/24
Internet
VPN Tunnel
Setting up the AutoKey IKE tunnel using AutoKey IKE with either a preshared secret or certificates involves the
following two steps:
1. Define the remote gateway and key exchange mode, and specify either a preshared secret or a certificate.
2. Create the Autokey IKE VPN entry.
%RRN7LWOH
/$1WR/$1931V
Note: You also need to define security zone interface IP addresses, create address book entries for the
local and remote end entities, set up default routes, and configure access policies. However, because those
steps are the same as those explained in “Example: Policy-Based LAN-to-LAN VPN, Manual Key” on page
379, they are omitted here.
In the following examples, the preshared key is h1p8A24nG5. It is assumed that both participants already have
certificates. (For more information about obtaining and loading certificates, see “Certificates and CRLs” on page
291.)
:HE8,7RN\R
1. VPN >>Gateway (P1) >>New Remote Tunnel Gateway: Enter the following, and then click OK:
Gateway Name: To_Paris
For preshared key:
For certificate:
Name: Tokyo_Paris
Remote Gateway Tunnel: To_Paris
6XE7LWOH
:HE8,3DULV
Gateway Name: To_Tokyo
IP Address: 201.22.3.14
For preshared key:
For certificate:
Preferred certificate Peer CA: Entrust
Preferred certificate Peer Type: X509-SIG
Name: Paris_Tokyo
Remote Gateway Tunnel: To_Tokyo
%RRN7LWOH
/$1WR/$1931V
&/,7RN\R
3UHVKDUHG.H\
1. set ike gateway to_paris ip 203.3.3.10 main outgoing-interface eth3 preshare h1p8A24nG5 proposal
pre-g2-3des-sha-1
4. save
&HUWLILFDWH
1. set ike gateway to_paris ip 203.3.3.10 main outgoing-interface eth3 proposal rsa-g2-3des-sha
3. set vpn tokyo_paris bind zone untrust-tun
4. save
&/,3DULV
3UHVKDUHG.H\
1. set ike gateway to_tokyo ip 201.22.3.14 main outgoing-interface eth3 preshare h1p8A24nG5 proposal
pre-g2-3des-sha-1
4. save
&HUWLILFDWH
1. set ike gateway to_tokyo ip 201.22.3.14 main outgoing-interface eth3 proposal rsa-g2-3des-sha
4. save
6XE7LWOH
([DPSOH3ROLF\%DVHG/$1WR/$1931'\QDPLF3HHU
In this example, a VPN tunnel securely connects the users in the Trust zone behind NetScreen A to the mail server
in the corporate DMZ zone, protected by NetScreen B. The Untrust zone interface for NetScreen B has a static IP
address. The ISP serving NetScreen A assigns the IP address for its Untrust zone interface dynamically via DHCP.
Because only NetScreen B has a fixed address for its Untrust zone, VPN traffic must originate from hosts behind
NetScreen A. After NetScreen A has established the tunnel, traffic through the tunnel can originate from either end.

configured on NetScreen A configured on NetScreen B
at the branch office. at the corporate site.
A B A B
Trust Untrust Untrust DMZ

Zone Zone Zone Zone
Outgoing Interface
Untrust Zone Outgoing Interface
Branch Office eth3 and gateway Untrust Zone Corporate Office
Trust Zone dynamically assigned eth3, 203.10.20.1/24 DMZ Zone
eth1, 10.10.10.1/24 by ISP Gateway 203.10.20.2 eth2, 172.30.5.1/24
Mail Server
Internet 172.30.5.5
VPN Tunnel IDENT

NetScreen A NetScreen B Request
SMTP or POP3
Request DHCP Server
203.2.3.1
Note: Before making an SMTP or POP3 connection to the corporate

mail server, Phil must first initiate an HTTP, FTP, or Telnet connection
so that NetScreen A can authenticate him.
%RRN7LWOH
/$1WR/$1931V
In this example, authentication user Phil (login name: pmason; password: Nd4syst4) wants to get his e-mail from the
mail server at the corporate site. When he attempts to do so, he is authenticated twice: first, NetScreen A
authenticates him locally before allowing traffic from him through the tunnel5; second, the mail server program
authenticates him, sending the IDENT request through the tunnel.
Note: The mail server can send the IDENT request through the tunnel only if the NetScreen A and B administrators
add a custom service for it (TCP, port 113) and set up access policies allowing that traffic through the tunnel to the
10.10.10.0/24 subnet.
The preshared key is h1p8A24nG5. It is assumed that both participants already have certificates, and that the e-mail
address jking@abc.com appears in the local certificate on NetScreen A. (For more information about obtaining and
:HE8,1HW6FUHHQ$
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
2. Interface >> Physical >> Edit (for ethernet3): Enter the following, and then click Save6 :
IP Address: Obtain IP using DHCP (select)
Zone Name: Untrust
5. Because Phil is an authentication user, before he can make an SMTP of POP3 request, he must first initiate an HTTP, FTP, or Telnet connection so that
NetScreen A can respond with a firewall user/login prompt to authenticate him. After NetScreen A authenticates him, he has permission to contact the
corporate mail server via the VPN tunnel.
6XE7LWOH
8VHU
User Name: pmason
User Password: Nd4syst4
Confirm Password: Nd4syst4
$GGUHVVHV
Address Name: Trusted network
Netmask: 255.255.255.0
Zone: Trust
Netmask: 255.255.255.255
Zone: Untrust
6HUYLFHV
Service Name: Ident
%RRN7LWOH
/$1WR/$1931V

HTTP
FTP
Telnet
Ident
MAIL
POP3
931
Gateway Name: To_Mail
Remote Gateway: Static IP Address: (select)
IP Address: 203.10.20.1
For preshared key:
Local ID: jking@abc.com
For certificate:
Name: branch_corp
Remote Gateway Tunnel: To_Mail
6XE7LWOH
5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
3ROLF\
Source Address: Trusted network
Action: Tunnel
VPN Tunnel: branch_corp
Authentication: (select)
7. The ISP provides the gateway IP address dynamically through DHCP.
%RRN7LWOH
/$1WR/$1931V
:HE8,1HW6FUHHQ%
Netmask: 255.255.255.0
Zone Name: DMZ
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
$GGUHVVHV
Netmask: 255.255.255.255
Zone: DMZ
Address Name: branch office
Netmask: 255.255.255.0
Zone: Untrust
6XE7LWOH
6HUYLFHV
Service Name: Ident
Ident
MAIL
POP3
931
Gateway Name: To_branch
Peer ID: jking@abc.com
For preshared key:
For certificate:
%RRN7LWOH
/$1WR/$1931V
Name: corp_branch
Remote Gateway Tunnel: To_branch
5RXWH
Netmask: 0.0.0.0
3ROLF\
Action: Tunnel
VPN Tunnel: corp_branch
6XE7LWOH
&/,1HW6FUHHQ$
6. set dhcp client server 201.2.3.1
8VHU
7. set user pmason password Nd4syst4
$GGUHVVHV
8. set address trust “trusted network” 10.10.10.0 255.255.255.0
9. set address untrust “mail server” 172.30.5.5 255.255.255.255
6HUYLFHV
12. set group service remote_mail add http
13. set group service remote_mail add ftp
14. set group service remote_mail add telnet
%RRN7LWOH
/$1WR/$1931V
931
Preshared Key:
18. set ike gateway to_mail ip 203.10.20.4 aggressive outgoing-interface eth3 local-id jking@abc.com preshare
h1p8A24nG5 proposal pre-g2-3des-sha-1
Certificate:
18. set ike gateway to_mail ip 203.10.20.4 aggressive outgoing-interface eth3 local-id jking@abc.com proposal
rsa-g2-3des-sha
5RXWHV
21. set vrouter untrust-vr route 0.0.0.0/0 interface ethernet3
3ROLFLHV
22. set policy from trust to untrust “trusted network” “mail server” remote_mail tunnel vpn branch_corp auth
23. set policy from untrust to trust “mail server” “trusted network” remote_mail tunnel vpn branch_corp
24. save
6XE7LWOH
&/,1HW6FUHHQ%
$GGUHVVHV
6. set address untrust “branch office” 10.10.10.0/24
6HUYLFHV
%RRN7LWOH
/$1WR/$1931V
931
Preshared Key:
12. set ike gateway to_branch dynamic name@company.com aggressive outgoing-interface ethernet3
preshare h1p8A24nG5 proposal pre-g2-3des-sha
Certificate:
13. set ike gateway to_branch dynamic name@company.com aggressive outgoing-interface ethernet3 proposal
rsa-g2-3des-sha
5RXWH
3ROLFLHV
16. set policy from dmz to untrust “mail server” “branch office” remote_mail tunnel vpn corp_branch
17. set policy from untrust to dmz “branch office” “mail server” remote_mail tunnel vpn corp_branch
18. save
6XE7LWOH
',$/8372/$19316
NetScreen devices also support VPN dialup connections. You can configure a NetScreen security gateway with a
static IP address to secure an IPSec tunnel with a NetScreen-Remote client or with another NetScreen device with a
dynamic IP address.
You can configure tunnels for VPN dialup users on a per-user basis or form users into a VPN dialup group for which
you need only configure one tunnel. For more information on creating VPN dialup groups, see “Dialup User Groups”
on page 208.
This section describes the procedures for setting up three types of Dialup-to-LAN VPNs:
• Dialup-to-LAN VPN, Manual Key tunnel
• Dialup-to-LAN VPN, AutoKey IKE tunnel (with a preshared secret or certificates)
If the dialup client can support a virtual internal IP address, which the NetScreen-Remote does, you can also create
• Dynamic Peer Dialup-to-LAN VPN, AutoKey IKE tunnel (with a preshared key or certificates)
Note: The dialup-to-LAN dynamic peer is nearly identical to the LAN-to-LAN dynamic peer except that the
internal IP address for the dialup client is a virtual address.
%RRN7LWOH
'LDOXSWR/$1931V
([DPSOH3ROLF\%DVHG'LDOXSWR/$19310DQXDO.H\
In this example, a remote user (Wendy) needs to access a UNIX server in the Trust zone at the corporate site via a
dialup VPN tunnel. The tunnel uses 3DES for encryption and SHA-1 for authentication.
Remote User: Wendy Outgoing Interface

eth3, 203.10.20.1/24 Trust Zone
Gateway 203.10.20.2 eth1, 172.30.5.1/24
UNIX Server
172.30.5.6
Internet
VPN Tunnel
Untrust Trust
Zone Zone
:HE8,
Netmask: 255.255.255.0
Zone Name: Trust
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
6XE7LWOH
$GGUHVV
Address Name: UNIX
Netmask: 255.255.255.255
Zone: Trust
0DQXDO.H\8VHU
4. Users >> Users >> New Manual Key User: Enter the following, and then click OK:
User Name: Wendy
ESP: (select)
Generate Key by Password9: PNas134a
(1) Return to the Manual Key User configuration dialog box by clicking Edit in the Configure column for the Manual Key user “Wendy”); (2) copy the
two generated hexadecimal keys; and (3) use those hexadecimal keys when configuring the NetScreen-Remote end of the tunnel.
%RRN7LWOH
'LDOXSWR/$1931V
5RXWHV
Netmask: 0.0.0.0
Netmask: 0.0.0.0
3ROLF\
7. Policy >> Incoming >> New Policy: Enter the following, and then click OK:
Source Address: Dial-up VPN
Destination Address: UNIX
Service: ANY
Action: Tunnel
VPN Tunnel: Dialup User–Wendy
Create matching outgoing VPN policy: (clear)
6XE7LWOH
&/,
$GGUHVV
5. set address trust unix 172.30.5.6/32
0DQXDO.H\8VHU
6. set user wendy dialup 3000 3000 outgoing-interface ethernet3 esp 3des password asdlk24234 auth sha-1
password PNas134a10
5RXWHV
3ROLF\
9. set policy from untrust to trust “dial-up vpn” unix any tunnel vpn-dialup wendy
10. save
(1) Enter the command get user wendy; (2) copy the two generated hexadecimal keys; and (3) use those hexadecimal keys when configuring the
NetScreen-Remote end of the tunnel.
%RRN7LWOH
'LDOXSWR/$1931V
1HW6FUHHQ5HPRWH6HFXULW\3ROLF\(GLWRU
1. Click Options >> Secure >> Specified Connections.
2. Click the Add a new connection button, and type Unix next to the new connection icon that appears.
5. Click Security Policy, and select Use Manual Keys.
of Key Exchange (Phase 2) to expand the policy further.
7. Click Proposal 1, and select the following IPSec Protocols:
Encrypt Alg: 3DES
Hash Alg: SHA-1
6XE7LWOH
8. Click Inbound Keys, and in the Security Parameters Index field, type 3000.
9. Click Enter Key, enter the following11, and then click OK:
Choose key format: Binary
ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c
10. Click Outbound Keys, and in the Security Parameters Index field, type 3000.
11. Click Enter Key, enter the following11, and then click OK:
Choose key format: Binary
ESP Encryption Key: dccbee96c7e546bc
ESP Authentication Key: dccbe9e6c7e546bcb0b667794ab7290c
11. These are the two generated keys that you copied after configuring the NetScreen device.
%RRN7LWOH
'LDOXSWR/$1931V
([DPSOH3ROLF\%DVHG'LDOXSWR/$1931$XWR.H\,.(
the tunnel12) provides the secure communication channel between the IKE user Wendy and the UNIX server. The
tunnel again uses ESP with 3DES encryption and SHA-1 authentication.
Setting up the AutoKey IKE tunnel using AutoKey IKE with either a preshared secret or certificates requires you to
do the following at the corporate site:
1. Configure interfaces for the Trust and Untrust zones.
2. Enter the address of the UNIX server in the Trust zone address book.
3. Define Wendy as an IKE user.
4. Configure the remote gateway and AutoKey IKE VPN.
5. Set up default routes
6. Create an access policy from the Untrust zone to the Trust zone permitting access to the UNIX from the
dialup user.
Remote User: Wendy Outgoing Interface

eth3, 203.10.20.1/24 Trust Zone
Gateway 203.10.20.2 eth1, 172.30.5.1/24
UNIX Server
172.30.5.6
Internet
VPN Tunnel
Untrust Trust
Zone Zone
12. The preshared key is h1p8A24nG5. It is assumed that both participants already have certificates. For more information about certificates, see “Certificates
and CRLs” on page 291.
6XE7LWOH
:HE8,1HW6FUHHQ
Netmask: 255.255.255.0
Zone Name: Trust
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
$GGUHVV
Address Name: UNIX
Netmask: 255.255.255.255
Zone: Trust
8VHU
User Name: Wendy
IKE User: (select)
IKE Identity: wparker@email.com
%RRN7LWOH
'LDOXSWR/$1931V
Gateway Name: Wendy_NSR
Remote Gateway
Dialup User: (select)
User/Group: Dialup User–Wendy
For preshared key:
For certificate:
Name: Wendy_UNIX
Remote Gateway Tunnel: Wendy_NSR
Source Address: Dial-Up VPN
Destination Address: UNIX
Service: ANY
Action: Tunnel
VPN Tunnel: Wendy_UNIX
Create matching outgoing policy: (clear)
6XE7LWOH
&/,
1. set address trust unix 172.30.5.6 255.255.255.255
2. set user wendy ike-id wparker@email.com
Preshared Key:
3. set ike gateway wendy_nsr dialup wendy aggressive preshare h1p8A24nG5 proposal pre-g2-3des-sha-1
4. set vpn wendy_unix gateway wendy_nsr tunnel proposal nopfs-esp-3des-sha-1
5. set policy incoming “dial-up vpn” unix any tunnel vpn wendy_unix
Certificates:
1. set ike gateway wendy_nsr dialup wendy aggressive proposal rsa-g2-3des-sha-1
2. set vpn wendy_unix gateway wendy_nsr tunnel proposal nopfs-esp-3des-sha-1
3. set policy incoming “dial-up vpn” unix any tunnel vpn wendy_unix
4. save
1HW6FUHHQ5HPRWH6HFXULW\3ROLF\(GLWRU
1. Click Options >> Secure >> Specified Connections.
2. Click the Add a new connection button, and type UNIX next to the new connection icon that appears.
4. Click the PLUS symbol, located to the left of the UNIX icon, to expand the connection policy.
%RRN7LWOH
'LDOXSWR/$1931V
ID Type: (select E-mail Address), and type wparker@email.com.
or
ID Type: (select E-mail Address)13
13. The e-mail address from the certificate appears in the identifier field automatically.
6XE7LWOH
Algorithms:
Hash Alg: SHA-1
Encrypt Alg: 3DES
Hash Alg: SHA-1
%RRN7LWOH
'LDOXSWR/$1931V
([DPSOH3ROLF\%DVHG'LDOXSWR/$1931'\QDPLF3HHU
In this example, a VPN tunnel securely connects the user behind the NetScreen-Remote to the Untrust zone
interface of the NetScreen device protecting the mail server in the DMZ zone. The Untrust zone interface has a
static IP address. The NetScreen-Remote client has a dynamically assigned external IP address and a static
(virtual) internal IP address, which must be known to the administrator of the NetScreen device so that he can add it
to the Untrust address book for use in access policies to tunnel traffic from that source. After the NetScreen-Remote
client establishes the tunnel, traffic through the tunnel can originate from either end.
Remote User: Phil Outgoing Interface

eth3, 203.10.20.1/24 DMZ Zone
Gateway 203.10.20.2 eth2, 172.30.5.1/24
SMTP
Request Mail Server
172.30.5.5
Internet
IDENT
VPN Tunnel Request
Internal IP Address External IP Address Untrust DMZ

10.10.10.1 Dynamic Zone Zone
In this example, Phil wants to get his e-mail from the mail server at the company site. When he attempts to do so, he
is authenticated by the mail server program, which sends him an IDENT request through the tunnel.
Note: The mail server can send the IDENT request through the tunnel only if the NetScreen-100 administrator adds
a custom service for it (TCP, port 113) and sets up an outgoing access policy allowing that traffic through the tunnel
to 10.10.10.1.
The preshared key is h1p8A24nG5. It is assumed that both participants already have certificates, and that the local
certificate on the NetScreen-Remote contains the e-mail address pmason@email.com. (For more information about
obtaining and loading certificates, see “Certificates and CRLs” on page 291.)
6XE7LWOH
:HE8,
Netmask: 255.255.255.0
Zone Name: DMZ
IP Address: 203.10.20.1
Netmask: 255.255.255.0
Zone Name: Untrust
$GGUHVVHV
Netmask: 255.255.255.255
Zone: DMZ
Address Name: Phil
Netmask: 255.255.255.255
Zone: Untrust
%RRN7LWOH
'LDOXSWR/$1931V
6HUYLFHV
Service Name: Ident
Ident
MAIL
POP3
931
Gateway Name: To_Phil
Peer ID: pmason@email.com
For preshared key:
For certificate:
6XE7LWOH
Name: corp_Phil
Remote Gateway Tunnel: To_Phil
5RXWH
Netmask: 0.0.0.0
3ROLF\
Action: Tunnel
VPN Tunnel: corp_Phil
%RRN7LWOH
'LDOXSWR/$1931V
&/,
$GGUHVVHV
6. set address untrust phil 10.10.10.1/32
6HUYLFHV
6XE7LWOH
931
Preshared Key:
12. set ike gateway to_phil dynamic pmason@email.com aggressive outgoing-interface ethernet3 preshare
h1p8A24nG5 proposal pre-g2-3des-sha
Certificate:
13. set ike gateway to_phil dynamic pmason@email.com aggressive outgoing-interface ethernet3 proposal
rsa-g2-3des-sha
5RXWH
3ROLFLHV
16. set policy from dmz to untrust “mail server” phil remote_mail tunnel vpn corp_phil
17. set policy from untrust to dmz phil “mail server” remote_mail tunnel vpn corp_phil
18. save
%RRN7LWOH
'LDOXSWR/$1931V
1HW6FUHHQ5HPRWH
1. Click Options >> Global Policy Settings, and select the Allow to Specify Internal Network Address
check box.
2. Options >> Secure >> Specified Connections.
3. Click the Add a new connection button, and type Mail next to the new connection icon that appears.
ID Type: Internal Network IP Address: Type 10.10.10.1.
or
ID Type: (select IP Address); Internal Network IP Address: Type 10.10.10.1.
6XE7LWOH
Algorithms:
Hash Alg: SHA-1
Encrypt Alg: 3DES
Hash Alg: SHA-1
%RRN7LWOH
7XQQHO=RQHVDQG3ROLF\%DVHG1$7
7811(/=21(6$1'32/,&<%$6('1$7
A tunnel zone is a logical creation that allows you to bind one or more tunnel interfaces to it. If you bind a tunnel
interface to a security zone you can configure the tunnel interface as unnumbered (that is, without an IP address) or
assign it an IP address and netmask. If you bind a tunnel interface to a tunnel zone, you must assign it an IP
address.
Giving a tunnel interface an IP address and netmask automatically makes an entry in the route table for that
interface. It also allows you to create one or more Dynamic IP (DIP) pools in the same subnet for the application of
policy-based network address translation (NAT) on traffic passing through that interface14. In the case where the
source and destination addresses are in an overlapping address space, you can use policy-based NAT to change
the source address on outbound traffic to that of a neutral address space. On the other end of the tunnel, the admin
can create a mapped IP (MIP) using an address in another neutral space. For bidirectional VPN traffic between two
end entities with overlapping addresses, policy-based NAT and MIPs are required at both ends of the tunnel.
14. The range of addresses in a DIP pool must be in the same subnet as the interface, but the pool must not include the interface IP address or any MIP or VIP
addresses that might also be in that subnet.
6XE7LWOH

configured on NetScreen A at configured on NetScreen B at
the branch office. the branch office.
A B A B
Trust Tunnel Untrust Untrust Tunnel Trust

server B
10.10.1.5
network A network B
Internet
10.10.1.0/24 NetScreen A NetScreen B 10.10.1.0/24
server A Tunnel.1 10.10.2.1/24 Tunnel.1 10.10.3.1/24

10.10.1.8
DIP 5 10.10.2.10 – 10.10.2.20 DIP 6 10.10.3.10 – 10.10.3.20

MIP 10.10.2.8 –> 10.10.1.8 MIP 10.10.3.5 –> 10.10.1.5
Users at network A can access server B. Users at network B can access server A.
All traffic flows through the VPN tunnel between the two sites.
network A server B
VPN Tunnel
server A network B
A tunnel zone is conceptually affiliated with a security zone in a child-parent relationship. The security zone acting as
the parent, which you can also conceive of as a carrier zone, provides the firewall protection to the encapsulated
traffic. The tunnel zone provides packet encapsulation/decapsulation, and—by supporting tunnel interfaces with IP
addresses and netmasks that can host DIP pools—can also provide policy-based NAT services.
%RRN7LWOH
The interface of the security zone

hosting the tunnel zone provides
Security Zone firewall protection for the
encapsulated traffic.
Tunnel Zone
Traffic to or from a VPN tunnel VPN Tunnel
The tunnel interface—which Interface Interface
when bound to a tunnel zone must
have an IP address/netmask—
supports policy-based NAT for
pre-encapsulated and
post-decapsulated VPN traffic.
Outbound traffic enters the tunnel zone via the tunnel interface, is encapsulated, and exits via the security zone interface.
Inbound traffic enters via the security zone interface, is decapsulated in the tunnel zone, and exits via the tunnel interface.
When upgrading to ScreenOS 3.1.0, existing tunnel interfaces are bound by default to the preconfigured
untrust-tunnel zone, which is a child of the preconfigured untrust security zone. You can bind multiple tunnel zones
to the same security zone; however, you cannot bind a tunnel zone to another tunnel zone.
([DPSOH7XQQHO,QWHUIDFHLQD7XQQHO=RQH
In this example, you configure a VPN tunnel between the corporate site and a branch office; however, the address
space for the VPN end entities overlaps. To overcome this conflict, you can use NAT to modify the source address
on outbound VPN traffic and a MIP to modify the destination address on inbound VPN traffic.
The tunnel parameters are the same as in the previous example:
• AutoKey IKE, preshared key (netscreen1), Main mode, ESP, Diffie-Hellman Group 2, 3DES, and SHA-1.
• The interface specified as the local gateway on the corporate site is 210.1.1.1. (The branch office uses this
address as the remote gateway in its IKE configuration.)
• The NetScreen device at the corporate site is running ScreenOS 3.1.0.
• The NetScreen device at the remote site is running an earlier version of ScreenOS.
6XE7LWOH
Note: Only the configuration for the corporate end of the tunnel is given below. For information on configuring a
NetScreen device running pre-USGA ScreenOS, see the NetScreen Concepts & Examples ScreenOS Reference
Guide for the version of ScreenOS that is appropriate for your device.
Untrust-VR Routing Domain

Note: The castle icon represents branch1-ftp
a security zone interface. tunnel/1
MIP 30.1.1.5
host 10.1.1.5
Default Gateway
210.1.1.254
Trust-VR Routing Domain VPN tunnel: Branch1
to_branch1 10.2.1.0/24
Gateway
Zone: Untrust-Tun 211.2.2.2/24
tunnel.1 10.2.1.1/24
corp-ftp DIP 10.2.1.65–10.2.1.126
10.1.1.2 MIP 10.2.1.2 host 10.1.1.2
Zone: Untrust
Zone: Sales 210.1.1.1/24
10.1.1.1/24 eth1/2
eth2/1
%RRN7LWOH
:HE8,
6HFXULW\=RQHV
Name: Sales
Note: The Untrust and Untrust-Tun zones are preconfigured. You do not have to create them.
Netmask: 255.255.255.0
Zone Name: Sales
Netmask: 255.255.255.0
Zone Name: Untrust
Zone: Untrust-Tun
Fixed IP: (select)
Netmask: 255.255.255.0
6XE7LWOH
931
Gateway Name: branch1
Outgoing Interface: ethernet1/215
Name: to_branch1
Remote Gateway Tunnel: branch1
$GGUHVVHV
Address Name: sales-any
Netmask: 255.255.255.0
Zone: Sales
15. The outgoing interface does not have to be in the same zone to which the tunnel interface is bound.
%RRN7LWOH
Address Name: corp-ftp
Netmask: 255.255.255.255
Zone: Sales
Address Name: branch1-any
Netmask: 255.255.255.192
Zone: Untrust
Address Name: branch1-ftp
Netmask: 255.255.255.255
Zone: Untrust
0,3
11. Interface >> MIP (for ethernet1/2) >> New Entry: Enter the following, and then click OK:
Netmask: 255.255.255.255
6XE7LWOH
',3
12. Interface >> Tunnel >> DIP (for tunnel.1) >> New Entry: Enter the following, and then click OK:
ID: 5
Start: 10.2.1.65
End: 10.2.1.126
Port Translation Enable: (select)
5RXWHV
13. Routing >> Route Table >> New Entry: Enter the following, and then click OK 16:
Netmask: 0.0.0.0
Netmask: 255.255.255.0
Hop Virtual Router Name: tunnel.1
16. This route exists by default and does not need to be configured for this example. Its inclusion here is purely to illustrate how to configure it.
%RRN7LWOH
Netmask: 0.0.0.0
3ROLFLHV
16. Policy (From Zone: Sales, To Zone: Untrust) >> New Policy: Enter the following, and then click OK:
Source Address: sales-any
Destination Address: branch1-ftp
Service: FTP
NAT On: (select)
DIP On: (select); 5 (10.2.1.65–10.2.1.126)/X-late
Action: Tunnel
VPN Tunnel: to_branch1
17. Policy (From Zone: Untrust, To Zone: Global) >> New Policy: Enter the following, and then click OK:
Source Address: branch1-any
Destination Address: global MIP(10.2.1.2)
Service: FTP
Action: Tunnel
VPN Tunnel: to_branch1
6XE7LWOH
&/,
6HFXULW\DQG7XQQHO=RQHV
1. set zone name sales
(The Untrust zone and the Untrust-Tun zones are preconfigured. You do not have to create them.)
2. set interface eth2/1 zone sales
6. set interface tunnel.1 zone untrust-tun
7. set interface tunnel.1 ip 10.2.1.1 255.255.255.0
931
8. set ike gateway branch1 ip 211.2.2.2 main outgoing-interface eth1/2 preshare netscreen1 proposal
pre-g2-3des-sha
9. set vpn to_branch1 gateway branch1 replay proposal g2-esp-3des-sha
$GGUHVVHV
10. set address sales sales-any 10.1.1.0 255.255.255.0
11. set address sales corp-ftp 10.1.1.2 255.255.255.255
12. set address untrust branch1-any 30.1.1.0 255.255.255.192
13. set address untrust branch-ftp 30.1.1.5 255.255.255.255
%RRN7LWOH
0,3
14. set interface eth1/2 mip 10.2.1.217 host 10.1.1.2
',3
15. set interface tunnel.1 dip 5 10.2.1.65 10.2.1.126
5RXWHV
16. set vrouter trust-vr route 0.0.0.0 0.0.0.0 vrouter untrust-vr
17. set vrouter untrust-vr route 30.1.1.0 255.255.255.192 interface tunnel.1
18. set vrouter untrust-vr route 0.0.0.0 0.0.0.0 interface eth1/2 gateway 210.1.1.254
Note: Because the interface for the sales zone (eth2/1) is in Route mode, the NetScreen device
3ROLFLHV
19. set policy from sales to untrust sales-any branch1-ftp ftp nat dip 5 permit
20. set policy from untrust to global branch1-any mip(10.2.1.2) ftp permit
21. save
17. Because the default netmask is 255.255.255.255, you do not need to specify that in the command.
6XE7LWOH
%RRN7LWOH
&KDSWHU
/73

This chapter provides an introduction to Layer 2 Tunneling Protocol (L2TP), its use alone and with IPSec support,
and then some configuration examples for L2TP and L2TP-over-IPSec:
• “Introduction to L2TP” on page 438
• “Packet Encapsulation and Decapsulation” on page 442
• “L2TP Parameters” on page 444
– “Example: Configuring an IP Pool and L2TP Default Settings” on page 445
• “L2TP and L2TP-Over-IPSec” on page 447
– “Example: Configuring L2TP” on page 447
– “Example: Configuring L2TP-Over-IPSec” on page 454

&KDSWHU/73 ,QWURGXFWLRQWR/73
,1752'8&7,2172/73
Layer 2 Tunneling Protocol (L2TP) provides a way for a dial-up user to make a virtual Point-to-Point Protocol (PPP)
connection to an L2TP network server (LNS), which can be a NetScreen device. L2TP sends PPP frames through a
tunnel between an L2TP access concentrator (LAC) and the LNS.
Originally, L2TP was designed so that a LAC residing at an ISP site tunneled to an LNS at either another ISP or
corporate site. The L2TP tunnel did not extend completely to the dial-up user’s computer, but only to the LAC at the
dial-up user’s local ISP. (This is sometimes referred to as a compulsory L2TP configuration.)
Dial-up Dial-up
User Connection
Internet NetScreen
ISP
Corporate
LAN
L2TP Access L2TP Tunnel L2TP Network

Concentrator (forwarding PPP sessions Server
(LAC) from LAC to LNS)
With the capability of a NetScreen-Remote 5.0 client on a Windows 2000 or Windows NT, or a Windows 2000 client
by itself to act as an LAC, the L2TP tunnel can extend directly to the dial-up user’s computer, thus providing
end-to-end tunneling. (This approach is sometimes referred to as a voluntary L2TP configuration.)

NetScreen-Remote
or Windows 2000 NetScreen Device
Internet (LNS)
ISP
Corporate
LAN
L2TP Tunnel
(forwarding PPP sessions
from LAC to LNS)
Because the PPP link extends from the dial-up user across the Internet to the NetScreen device (LNS), it is the
NetScreen device, not the ISP, that assigns the client its IP address, DNS and WINS servers addresses, and
authenticates the user, either from the internal database or from a RADIUS server.
The dial-up user receives two IP addresses—one for its physical connection to the ISP, and a logical one from the
LNS. When the dial-up user contacts his or her ISP, perhaps using PPP, the ISP makes IP and DNS assignments,
and authenticates the user. This allows users to connect to the Internet with a routable IP address, which becomes
the outer IP address of the L2TP tunnel.
1
ISP
IP Address: 212.30.40.56
DNS: 209.6.15.3, 209.6.15.4

Then, when the L2TP tunnel forwards the encapsulated PPP frames to the NetScreen device, the NetScreen device
assigns the user an IP address, and DNS and WINS settings. The IP address can be a private, nonroutable
address, which becomes the inner IP address of the L2TP tunnel.
2 Internet NetScreen Device

(LNS)
IP Address: 10.10.1.161
DNS: 189.16.2.4, 189.16.2.5 IP Address Pool
10.10.1.1 – 10.10.1.254
WINS: 10.20.1.48, 10.20.1.49

ScreenOS 3.1.0 provides the following L2TP support:

• L2TP tunnels originating from a NetScreen-Remote 5.0 client on a workstation running Windows 20001 or
Windows NT or a Windows 2000 client by itself
– For NetScreen-Remote 5.0, L2TP-over-IPSec with Main mode negotiations using certificates, and
Aggressive mode using either a preshared key or certificates
– For Windows 2000, L2TP-over-IPSec with Main mode negotiations using certificates
• A combination of L2TP and IPSec in transport mode (L2TP-over-IPSec)
• Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP)
authentication using the internal user database (up to 1500 entries) and a RADIUS server2
• Assignment of dialup users’ IP address, DNS servers, and WINS servers
Note: To use L2TP, the NetScreen device must be operating at layer 3, with security zones in NAT or Route
mode. When the NetScreen device is operating at layer 2, with security zones in Transparent mode, no
L2TP-related material appears in the WebUI, and L2TP-related CLI commands elicit error messages.
1. By default, Windows 2000 performs L2TP-over-IPSec. To force it to use L2TP only, you must navigate to the ProhibitIPSec key in the registry and change
0 (L2TP-over-IPSec) to 1 (L2TP only). (Before performing this, NetScreen recommends that you backup your registry.) Click Start >> Run: Type regedit.
Double-click HKEY_LOCAL_MACHINE >> System >> CurrentControlSet >> Services >> RasMan >> Parameters. Double-click ProhibitIPSec: Type 1
in the Value data field, select Hexadecimal as the base value, and then click OK. Reboot.
2. To authenticate users, the NetScreen device first checks the entries in its internal database before checking those in a RADIUS server, if one is used.

&KDSWHU/73 3DFNHW(QFDSVXODWLRQDQG'HFDSVXODWLRQ
3$&.(7(1&$368/$7,21$1''(&$368/$7,21
L2TP employs encapsulation of packets as the means for transporting PPP frames from the LAC to the LNS. Before
looking at specific examples for setting up L2TP and L2TP-over-IPSec, an overview of the encapsulation and
decapsulation involved in the L2TP process is presented.
(QFDSVXODWLRQ
When a dialup user on an IP network sends data over an L2TP tunnel, the LAC encapsulates the IP packet within a
series of layer 2 frames, layer 3 packets, and layer 4 segments. Assuming that the dialup user connects to the local
ISP over a PPP link, the encapsulation proceeds as follows:
1. The data is placed in an IP payload.

2. The IP packet is encapsulated in a PPP frame.
3. The PPP frame is encapsulated in an L2TP frame.
4. The L2TP frame is encapsulated in a UDP segment.
5. The UDP segment is encapsulated in an IP packet.
6. The IP packet is encapsulated in a PPP frame to make the physical connection between the dialup user and
the ISP.

&KDSWHU/73 3DFNHW(QFDSVXODWLRQDQG'HFDSVXODWLRQ
'HFDSVXODWLRQ
When the LAC initiates the PPP link to the ISP, the decapsulation and forwarding of the nested contents proceed as
follows:
ISP
LNS
1. The ISP completes the PPP link and assigns the user’s computer an IP address.
Inside the PPP payload is an IP packet.
2. The ISP removes the PPP header and forwards the IP packet to the LNS.
3. The LNS removes the IP header.
Inside the IP payload is a UDP segment specifying port 1701, the port number reserved for L2TP.
4. The LNS removes the UDP header.
Inside the UDP payload is an L2TP frame.
5. The LNS processes the L2TP frame, using the tunnel ID and call ID in the L2TP header to identify the
specific L2TP tunnel. The LNS then removes the L2TP header.
Inside the L2TP payload is a PPP frame.
6. The LNS processes the PPP frame, assigning the user’s computer a logical IP address.
Inside the PPP payload is an IP packet.
7. The LNS routes the IP packet to its ultimate destination, where the IP header is removed and the data in the
IP packet is extracted.

&KDSWHU/73 /733DUDPHWHUV
/733$5$0(7(56
The LNS uses L2TP to provide the PPP settings for a dial-up user that typically come from an ISP. These settings
are as follows:
• IP address – The NetScreen device selects an address from a pool of IP addresses and assigns it to the
dial-up user’s computer. The selection process operates cyclically through the IP address pool; that is, in a
pool from 1.1.1.1 to 1.1.1.3, the addresses are selected in the following cycle: 1.1.1.1 – 1.1.1.2 – 1.1.1.3 –
1.1.1.1 – 1.1.1.2 …)
• DNS primary and secondary server IP addresses – The NetScreen device provides these addresses for the
dial-up user’s computer to use.
• WINS primary and secondary server IP addresses – The NetScreen device also provides these addresses
for the dial-up user’s computer to use.
The LNS also authenticates the user through a user name and password. You can enter the user in either the
internal database or a RADIUS server.
Note: The RADIUS server that you use for authenticating L2TP users can be the same server you use for network
users, or it can be a different server.
In addition, you can specify one of the following schemes for the PPP authentication:
• Challenge Handshake Authentication Protocol (CHAP), in which the NetScreen device sends a challenge
(encryption key) to the dial-up user after he or she makes a PPP link request and the user’s login name and
password are encrypted with the key
• Password Authentication Protocol (PAP), which sends the dial-up user’s password in the clear along with
the PPP link request
• “ANY”, meaning that the NetScreen device negotiates CHAP, and then if that fails, PAP.
You can apply to dial-up users and dialup user groups the default L2TP parameters that you configure on the L2TP
Default Configuration page (VPN >> L2TP >> Default L2TP Settings Edit) or with the set l2tp default command.
You can also apply L2TP parameters that you configure specifically for L2TP users on the User Configuration page
(Users >> Users >> New Auth IKE/L2TP User) or with the set user <name> remote-settings command. The
user-specific L2TP settings supersede the default L2TP settings.

([DPSOH&RQILJXULQJDQ,33RRODQG/73'HIDXOW6HWWLQJV
In this example, you define an IP address pool with addresses ranging from 10.1.3.40 to 10.1.3.100. You specify
DNS server IP addresses 210.11.6.2 (primary) and 210.11.6.3 (secondary). Database entries for dialup users are
stored in a RADIUS server at the IP address 10.1.2.245, and the shared secret is Ooaw35GA3. The NetScreen
device performs authentication using CHAP.
RADIUS
10.1.2.245 DNS 1
Trust Untrust 210.11.6.2
Zone Zone
DNS 2
Note: The L2TP pool addresses Internet 210.11.6.3
must be in a different subnet from
those in the Trust zone.
ethernet1, ethernet3,
10.1.2.1/24
L2TP IP Pool
:HE8,
1. VPN >> IP Pool >> New IP Pool: Enter the following, and then click Save:
IP Pool Name: Sutro
Start IP: 10.1.3.40
End IP: 10.1.3.100
“Our old address was 35 Glenwood Avenue” becomes “Ooaw35GA”.

2. VPN >> L2TP >> Default L2TP Settings Edit: Enter the following, and then click OK:
IP Pool Name: Sutro
Authentication Database: RADIUS
PPP Authentication: CHAP
RADIUS Server IP/Name: 10.1.2.245
RADIUS Secret: Ooaw35GA
DNS Primary Server IP: 210.11.6.2
DNS Secondary Server IP: 210.11.40.3
WINS Primary Server IP: 0.0.0.0
WINS Secondary Server IP: 0.0.0.0
&/,
1. set ippool sutro 10.1.3.40 10.1.3.100
2. set l2tp default ippool sutro
3. set l2tp default auth radius
4. set l2tp default server-name 10.1.2.245
5. set l2tp default radius-secret Ooaw35GA
6. set l2tp default ppp-auth chap
7. set l2tp default dns1 210.11.6.2
9. save

&KDSWHU/73 /73DQG/732YHU,36HF
/73$1'/7329(5,36(&
Although the dial-up user can be authenticated using CHAP or PAP, an L2TP tunnel is not encrypted, and therefore
is not a true VPN tunnel. The purpose of L2TP is simply to permit the administrator of the local NetScreen device to
determine the range of IP addresses for remote dial-up users. These addresses can then be referenced in access
policies.
To encrypt an L2TP tunnel, you need to apply an encryption scheme to the L2TP tunnel. Because L2TP assumes
that the network between the LAC and the LNS is IP, you can employ IPSec to provide encryption. This combination
is called L2TP-over-IPSec. L2TP-over-IPSec requires setting up both an L2TP tunnel and an IPSec tunnel with the
same endpoints, and then linking them together in an access policy. L2TP-over-IPSec requires that the IPSec tunnel
be in transport mode so that the tunnel endpoint addresses remain in the clear. (For information about transport
mode and tunnel mode, see “Modes” on page 266.)
([DPSOH&RQILJXULQJ/73
In this example, you create a dialup user group called “fs” (for “field-sales”) and configure an L2TP tunnel called
“sales_corp,” using ethernet3 (Untrust zone) as the outgoing interface for the L2TP tunnel. The NetScreen device
applies the following default L2TP tunnel settings to the dialup user group:
• The users are authenticated via the internal database.
• PPP authentication uses CHAP.
• The range of addresses in the IP pool (named “global”) is from 10.10.2.100 to 10.10.2.1804.
• The DNS servers are 210.11.6.2 (primary) and 210.11.40.3 (secondary)
Note: An L2TP-only configuration is not secure. It is recommended only for debugging purposes.
4. The addresses in the L2TP IP pool must be in a different subnet than the addresses in the corporate network.

Auth/L2TP Dialup
Users Group: fs IP Pool: global
Untrust 10.10.2.100 –
Adam Zone DNS 1: 210.11.6.2 10.10.2.180 Corporate
DNS 2: 210.11.40.3 Network
Trust Zone
Betty
eth1, 10.20.1.1/24
Internet
Outgoing Interface
Carol L2TP Tunnel:
sales_corp Untrust Zone
eth3, 123.2.2.1/24
:HE8,
&UHDWH'LDOXS8VHUV
User Name: Adam
Status: Enable
L2TP User: (select)
User Password: AJbioJ15
Confirm Password: AJbioJ15

User Name: Betty
Status: Enable
L2TP User: (select)
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
User Name: Carol
Status: Enable
L2TP User: (select)
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
&UHDWHD'LDOXS8VHU*URXS
4. Users >> Dialup Group >> New Group: Enter the following, and then click Add members:
Group Name: fs
Group Type: IKE/L2TP
5. Group Configuration: Move the following members, and then click OK:
Adam
Betty
Carol

6HWWKH'HIDXOW/736HWWLQJV
IP Pool Name: global
Start IP: 10.10.2.100
End IP: 10.10.2.180
Authentication Database: Local
8. VPN >> L2TP >> New L2TP Tunnel: Enter the following, and then click OK:
Name: sales_corp
Dialup User/Group: fs
Peer IP: 0.0.0.05
Host Name (optional): Enter the name of the computer acting as the LAC6.
5. Because the IP address of the peer is dynamic, enter 0.0.0.0 here.

6. To find the name of a computer running Windows 2000, do the following: Click Start >> Settings >> Control Panel >> System. The System Properties
dialog box appears. Click the Network Identification tab, and see entry following Full computer name.

Secret (optional): Enter a secret shared between the LAC and the LNS.
Note: To add a secret to the LAC for authenticating the L2TP tunnel, you must modify the Windows 2000 registry as
follows:
(1) Click Start >> Run, and then type regedit. The Registry Editor opens.
(2) Click HKEY_LOCAL_MACHINE.
(3) Right-click SYSTEM, and then select Find from the pop-up menu that appears.
(4) Type ms_l2tpminiport, and then click Find Next.
(5) In the Edit menu, highlight New, and then select String Value.
(6) Type Password.
(7) Double-click Password. The Edit String dialog box appears.
(8) Type the password in the Value data field. This must be the same as the word in the L2TP Tunnel
Configuration Secret field on the NetScreen device.
(9) Reboot the computer running Windows 2000.
When using L2TP-over-IPSec, which is the Windows 2000 default, tunnel authentication is unnecessary; all L2TP
messages are encrypted and authenticated inside IPSec.
Keep Alive: 607

&UHDWHDQ$FFHVV3ROLF\
Destination Address: Trust Any
NAT: Off
Service: ANY
Action: Tunnel
L2TP: sales_corp
7. The Keep Alive value is the number of seconds of inactivity before the NetScreen device sends an L2TP hello signal to the LAC.

&/,
&UHDWH'LDOXS8VHUV
1. set user adam type auth l2tp
2. set user adam password AJbioJ15
3. set user betty type auth l2tp
4. set user betty password BviPsoJ1
5. set user carol type auth l2tp
6. set user carol password Cs10kdD3
7. set dialup-group fs
8. set dialup-group fs + adam
9. set dialup-group fs + betty
10. set dialup-group fs + carol
11. set ippool global 10.10.2.100 10.10.2.180
12. set l2tp default ippool global
13. set l2tp default auth local

&RQILJXUHDQ/737XQQHO
17. set l2tp sales_corp user fs outgoing-interface ethernet3
18. set policy from untrust to trust “dial-up vpn” “trust any” any tunnel l2tp sales_corp
19. save

([DPSOH&RQILJXULQJ/732YHU,36HF
This example uses the same L2TP tunnel created in the previous example (“Example: Configuring L2TP” on page
447). Additionally, you overlay an IPSec tunnel onto the L2TP tunnel to provide encryption. The IPSec tunnel
negotiates Phase 1 in Aggressive Mode using a previously loaded certificate, 3DES encryption and SHA-1
authentication. The Phase 2 negotiation employs the Encapsulating Security Payload (ESP) protocol also using
3DES and SHA-1. The IPSec tunnel is in transport mode.
The predefined Trust zone and the user-defined Dialup zone are in the trust-vr routing domain. The interfaces for the
Dialup and Trust zones are ethernet2 (210.2.1.1/24) and ethernet1 (10.20.1.1/24) respectively. The Trust zone is in
NAT mode.
Auth-IKE-L2TP
Dialup Users Group: fs IP Pool: global
Dialup 10.10.2.100 –
Adam Zone DNS 1: 210.11.6.2
10.10.2.180 Corporate
DNS 2: 210.11.40.3 Network
Trust Zone
Betty
ethernet1,
Internet 10.20.1.1/24
Carol L2TP Tunnel: sales_corp Outgoing Interface

VPN Tunnel: from_sales ethernet2, 210.2.1.1/24

:HE8,
&UHDWHD=RQH
1. Zone >> Zone >> New Entry: Enter the following, and then click OK:
Zone Name: Dialup
Zone Type: Regular (select)
Note: The Trust zone is preconfigured. You do not need to create it.
'HILQH,QWHUIDFHV
Netmask: 255.255.255.0
Zone Name: Trust
Interface Mode: NAT
Netmask: 255.255.255.0
Zone Name: Dialup

&UHDWH'LDOXS8VHUV
4. Users >> Users >> New Auth IKE/L2TP User: Enter the following, and then click OK:
User Name: Adam
Status Enable: (select)
L2TP User: (select)
User Password: AJbioJ15
Confirm Password: AJbioJ15
IKE User: (select)
IKE Identity: ajackson@abc.com8
User Name: Betty
L2TP User: (select)
User Password: BviPsoJ1
Confirm Password: BviPsoJ1
IKE User: (select)
IKE Identity: bdavis@abc.com
8. The IKE identity you enter must be the same as that which the Windows 2000 client sends, which is usually the e-mail address of the certificate installed on
the Windows 2000 client.

User Name: Carol
L2TP User: (select)
User Password: Cs10kdD3
Confirm Password: Cs10kdD3
IKE User: (select)
IKE Identity: cburnet@abc.com
7. Users >> Dialup Group >> New Group: Enter the following, and then click Add members:
Group Name: fs
Group Type: IKE
8. Group Configuration: Move the following members, and then click OK:
Adam
Betty
Carol

Start IP: 10.10.2.100
End IP: 10.10.2.180
Authentication Database: Local

11. VPN >> L2TP >> New L2TP Tunnel: Enter the following, and then click OK:
Name: sales_corp
Dialup User/Group: fs
Peer IP: 0.0.0.09
Host Name (optional): If you want to restrict the L2TP tunnel to a specific host,
enter the name of the computer acting as the LAC10.
Secret (optional): Enter a secret shared between the LAC and the LNS11
Note: The host name and secret settings can usually be ignored. Only advanced users are recommended
to use these.
Keep Alive: 6012
9. Because the IP address of the peer is dynamic, enter 0.0.0.0 here.

10. To find the name of a computer running Windows 2000, do the following: Click Start >> Settings >> Control Panel >> System. The System Properties
dialog box appears. Click the Network Identification tab, and see entry following Full computer name.
11. To add a secret to the LAC for authenticating the L2TP tunnel, you must modify the Windows 2000 registry. See the note in the previous example.
12. The Keep Alive value is the number of seconds of inactivity before the NetScreen device sends an L2TP hello signal to the LAC.

&RQILJXUHD9317XQQHO
Gateway Name: field
Remote Gateway
Dialup User: (select)
User/Group: Dialup Group - fs
Name: from_sales
Remote Gateway Tunnel: field
Transport Mode: Enable (For L2TP-over-IPSec)
14. Policy >> Policy (From Zone Dialup, To Zone Trust) >> New Policy: Enter the following, and then click OK:
Destination Address: Trust Any
Service: ANY
Action: Tunnel
VPN Tunnel: from_sales
L2TP: sales_corp

&/,
&UHDWHD=RQH
1. set zone name dialup
2. set zone dialup vrouter trust-vr
'HILQH,QWHUIDFHV
6. set interface ethernet2 zone dialup
&UHDWH'LDOXS8VHUV
1. set user adam type auth ike l2tp
2. set user adam password AJbioJ15
3. set user adam ike-id ajackson@abc.com
4. set user betty type auth ike l2tp
5. set user betty password BviPsoJ1
6. set user betty ike-id bdavis@abc.com
7. set user carol type auth ike l2tp
8. set user carol password Cs10kdD3
9. set user carol ike-id cburnet@abc.com
10. set dialup-group fs

11. set dialup-group fs + adam

12. set dialup-group fs + betty
13. set dialup-group fs + carol
14. set ippool global 10.10.2.100 10.10.2.180
15. set l2tp default ippool global
16. set l2tp default auth local
&RQILJXUHDQ/737XQQHO
20. set l2tp sales_corp user fs outgoing-interface ethernet2
&RQILJXUHD9317XQQHO
21. set ike gateway field dialup fs aggressive outgoing-interface ethernet2 proposal rsa-g2-3des-sha
22. set vpn from_sales gateway field transport proposal g2-esp-3des-sha
23. set policy from dialup to trust “dial-up vpn” “trust any” any tunnel vpn from_sales l2tp sales_corp
24. save

&KDSWHU
3ROLF\%DVHG1$7

This chapter describes policy-based NAT and how it can make use of a pool of Dynamic IP (DIP) and Mapped IP
(MIP) addresses. While you can apply Network Address Translation (NAT) at either the interface level or policy
level1, this chapter focusses exclusively on the policy-level application with particular emphasis on how it offers a
solution for overlapping address space among VPN users. (For more information on an interface-level application of
NAT, see “Network Address Translation Mode” on page 52.)
This chapter contains the following three main sections:
• “Dynamic IP” on page 464
• “Mapped IP” on page 468
• “Policy-Based NAT for Network Traffic” on page 473
1. You can use policy-based NAT with the NetScreen device in Route mode or NAT mode. When the NetScreen device is in NAT mode, the policy-level NAT
parameters supersede the interface-level NAT parameters. For example, while the NetScreen device is in NAT mode, you can specify in an access policy
a DIP pool other than that linked to the Untrusted interface.

&KDSWHU3ROLF\%DVHG1$7 '\QDPLF,3
'<1$0,&,3
A DIP pool is a range of IP addresses from which the NetScreen device can dynamically take addresses to use
when performing NAT on the source IP address of outgoing or incoming IP packets. The range of addresses in a
DIP pool must be in the same subnet as the interface IP address, but the DIP pool should not contain the interface
IP address, router IP address, or any Mapped or Virtual IP addresses that might also be on that subnet.
There are three kinds of interfaces that you can link to Dynamic IP (DIP) pools: physical interfaces and subinterfaces
for network and VPN traffic, and tunnel interfaces for VPN tunnels only.
To DMZ Zone VPN Tunnels
To Untrusted Zone
To Trusted Zone
NetScreen Firewall
10.10.1.2– 210.10.1.2– 220.10.1.2– 10.20.1.2– 10.30.1.2–
10.10.1.20 210.10.1.20 220.10.1.20 10.20.1.20 10.30.1.20
DIP Pools
Trust Untrust DMZ Tunnel Tunnel

Physical
Interfaces
10.10.1.1/24 210.10.1.1/24 220.10.1.1/24 10.20.1.1/24 10.30.1.1/24
The physical interfaces The tunnel interfaces

lead to networks or VPN lead only to VPN
tunnels. tunnels.

3RUW$GGUHVV7UDQVODWLRQ
Using Port Address Translation (PAT), multiple hosts can share the same IP address, the NetScreen device
maintaining a list of assigned port numbers to distinguish which session belongs to which host. With PAT enabled,
up to ~64,500 hosts can share a single IP address.
Some applications, such as NetBIOS Extended User Interface (NetBEUI) and Windows Internet Naming Service
(WINS), require specific port numbers and cannot function properly if PAT is applied to them. For such applications,
you can specify not to perform PAT (that is, to use a fixed port) when using DIP. For fixed port DIP, the NetScreen
device hashes the original host IP address and saves it in its host hash table, allowing the NetScreen device to
associate the right session with each host.
([DPSOH&UHDWLQJD',33RROZLWK3$7
In this example, you create a tunnel interface and associate a DIP pool with it using the following parameters:
• Zone: Finance
• Interface IP address: 10.20.3.1/24
• Interface ID: 8
• DIP pool ID: 5
• DIP pool range: 10.20.3.10 – 10.20.3.20
• PAT enabled
:HE8,
Tunnel Interface Name: 8
Zone Name: Finance
Netmask: 255.255.255.0

2. Interface >> Tunnel >> Dynamic IP (DIP) >> New Entry: Enter the following, and then click OK:
ID: 52
IP Address Range
Start: 10.20.3.10
End: 10.20.3.20
Port Translation: (select)
&/,
1. set interface tunnel.8 ip 10.20.3.1 255.255.255.0
3. save
Note: Because PAT is enabled by default, there is no argument for enabling it. To create the same DIP pool as
defined above but without PAT (that is, with fixed port numbers), do the following:
• (WebUI) Interface >> Tunnel >> Dynamic IP (DIP) >> New Entry: Clear the Port Translation check
box, and then click OK.
• (CLI) set interface tunnel.8 dip 5 10.20.3.10 10.20.3.20 fix-port
([DPSOH&KDQJLQJD',33RRO
In this example, you change the range of addresses in an existing DIP pool (ID 8) from 10.2.2.10 – 10.2.2.100 to
10.2.2.10 – 10.2.2.20. This DIP pool is associated with tunnel.2. Note that to change the DIP pool range through the
CLI, you first remove (or unset) the existing dip pool, and then you create a new pool.
Note: There are no access policies using this particular DIP pool. If there were, you would need to delete the policy
or not use this DIP pool in that policy.
2. You can use the ID number displayed, which is the next available number sequentially, or type a different number.

:HE8,
Interface >> Tunnel >> Dynamic IP (for tunnel.2) >> Edit (for ID 8): Enter the following, and then click OK:
IP Address Range End: 10.2.2.20
&/,
1. unset interface tunnel.2 dip 8
3. save
([DPSOH'HOHWLQJD7XQQHO,QWHUIDFH
In this example, tunnel interface tunnel.2 is linked to DIP pool 8. DIP pool 8 is referenced in an outgoing access
policy (ID 10). To remove the tunnel interface, you must first remove the access policy (or remove the reference to
DIP pool 8 from the policy), then the DIP pool, and then the interface.
:HE8,
1. Policy >> Policy: Click Remove for Access Policy ID 10.
2. Interface >> Tunnel >> Dynamic IP (for tunnel.2): Click Remove for DIP ID 8.
3. Interface >> Tunnel: Click Remove for tunnel.2.
&/,
1. unset policy 10
2. unset interface tunnel.2 dip 8
3. unset interface tunnel.2
4. save

&KDSWHU3ROLF\%DVHG1$7 0DSSHG,3
0$33(',3
Mapped IP (MIP) is a direct one-to-one mapping of traffic destined for one IP address to another IP address. You
can create Mapped IP (MIP) addresses for tunnel interfaces and any interface in the Untrust zone. A MIP must be in
the same subnet as the tunnel interface to which it is linked; however, for an interface in the Untrust zone, a MIP
does not need to be in the same subnet. In either case, a MIP must not be the same as the interface address or be
in any DIP pool that might also be on that subnet.
Whereas DIP assigns IP addresses randomly, MIP provides a static mapping of one address to another. A MIP
address provides a way to apply address translation to incoming traffic to reach a host at a specific IP address.
0,3DQGWKH*OREDO=RQH
Setting a MIP for an interface in any zone generates a book entry in the Global zone address book. The Global zone
address book keeps all the MIPs of all interfaces, regardless of which zone the interfaces belong to. You can use
these MIP addresses as the destination addresses in access policies between any two zones, and as the source
addresses when defining a policy from the Global zone to any other zone.

Internet
Mapped IP: Inbound traffic is

mapped from 200.2.2.10 on
the subnet in the Untrust
zone to 172.16.40 on the 200.2.2.10
subnet in the Trust zone.
Untrust
Public Zone
Address Subnet
Space
Private
Address Trust
Space Zone
Subnet
172.16.40.3
By setting up MIP addresses, you can configure the NetScreen device to route traffic destined for many different IP
addresses on the subnet of the tunnel interface and any interface in the Untrust zone to specific addresses on the
trusted network.

([DPSOH$GGLQJD0,3WRD7XQQHO,QWHUIDFH
In this example, the IP address space for the network in the Trust zone is 10.20.1.0/24 and the IP address for the
tunnel interface “tunnel.8” is 10.20.3.1. The physical IP address for a server on the network in the Trust zone is
10.20.1.25. To allow a remote site whose network in the Trust zone uses an overlapping address space to access
the local server through a VPN tunnel, you create a MIP in the same subnet as the tunnel.8 interface. The MIP
address is 10.20.3.25/32.
:HE8,
Interface >> Tunnel >> Mapped IP (for tunnel.8) >> New Entry: Enter the following, and then click OK:
Netmask: 255.255.255.255
&/,
1. set interface tunnel.8 mip 10.20.3.25 host 10.20.1.253
2. save
Note: When the remote administrator adds the untrusted address for the server to his address book, he must use
the MIP (10.20.3.25), not the server’s physical IP address (10.20.1.25).
The remote administrator also needs to apply policy-based NAT (using DIP) on the outgoing packets bound for the
server through the VPN so that the local administrator can add an untrusted address that does not conflict with the
local trusted addresses. Otherwise, the source address in the incoming access policy would seem to come from the
trusted network address space.
3. By default the netmask for a MIP is 255.255.255.255, mapping the address to a single host. You can also define a MIP for a range of addresses. For example,
to define 2.1.10.128 as a MIP for the addresses 10.1.10.129–10.1.10.254 within a class C subnet through the CLI, use the following syntax: set interface
<interface name> mip 2.1.10.128 host 10.1.10.128 netmask 255.255.255.128 . Be careful not to use a range of addresses that includes the
interface or router addresses.

([DPSOH$GGLQJD0,3WRDQ,QWHUIDFHLQWKH8QWUXVW=RQH
When the NetScreen device is operating in NAT mode, an MIP provides a means for incoming traffic to reach a
private address on a network within a zone. You can configure a MIP address to route traffic destined for an address
on the subnet in the Untrust zone to a different address on the subnet in the Trust zone, regardless of the service
and corresponding port number involved.
This example explains how to map incoming traffic destined to the IP address 209.122.17.6 in the Untrust zone to
the IP address 172.16.10.2 in the Trust zone.
Workstation#1
Workstation#2 172.16.10.1
172.16.10.2
From Untrust Zone NetScreen device
Destination IP: Destination IP:

209.122.17.6 172.16.10.2 Mail Server
172.16.10.253
Web Server
172.16.10.252
Trust Zone

:HE8,
Interface >> MIP (for the interface for which you want to add a MIP) >> New Entry: Enter the following, and
then click OK:
Netmask: 255.255.255.255
&/,
1. set interface ethernet1/2 mip 209.122.17.6 host 172.16.10.2 netmask 255.255.255.255
2. save
Note: You must define an access policy allowing the mapped IP address to be accessed. No address book entry is
required for a Mapped IP.
You can map an address-to-address or subnet-to-subnet relationship. When a subnet-to-subnet mapped IP

configuration is defined, the netmask is applied to both the mapped IP subnet and the original IP subnet.

&KDSWHU3ROLF\%DVHG1$7 3ROLF\%DVHG1$7IRU1HWZRUN7UDIILF
32/,&<%$6('1$7)251(7:25.75$)),&
You can use a DIP pool for an interface in the Untrust zone to translate the source address on outgoing network
traffic. Applying NAT from a pool of IP addresses obfuscates the physical IP address of the interface in the Untrust
zone, making it harder for anyone to target it for attacks.
Note: For information and an example on policy-based NAT for VPN traffic, see Chapter 13, “Tunnel Zones and
Policy-Based NAT” on page 425.

([DPSOH1$7RQ2XWJRLQJ1HWZRUN7UDIILF
In this example, you use a DIP pool on the interface in the Untrust zone to perform NAT on outgoing network traffic.
The IP address of the NetScreen device in the Untrust zone is 215.3.4.11. The addresses in the DIP pool range from
215.3.4.12 to 215.3.4.210.
Source IP Address:
215.3.4.159
Source IP Address: Internet Source IP Address:

215.3.4.28 215.3.4.37
DIP 6: 215.3.4.12–
215.3.4.210
Interface in the Untrust

Zone: 215.3.4.11
Source IP Address: Source IP Address:

172.16.40.1 172.16.40.100
Source IP Address:
172.16.40.10

:HE8,
1. Interface >> Edit (for ethernet3): Enter the following, and then click Save:
Netmask: 255.255.255.0
Zone Name: Untrust
2. Interface >> DIP >> New Entry: Enter the following, and then click OK:
ID: 6
IP Address Range
Start: 215.3.4.12
End: 215.3.4.210
Port Translation: Enable
3. Policy >> From Zone: Untrust, To Zone: Trust >> New Policy: Enter the following, and then click OK:
Source Address: Any
Service: Any
NAT: On
DIP On: (select); 6 (215.3.4.12–215.3.4.210)
Action: Permit

&/,
3. set interface ethernet3 dip 6 215.3.4.12 215.3.4.210
4. set policy from untrust to trust any any nat dip 6 any permit
5. save

&KDSWHU
7UDIILF6KDSLQJ

This chapter discusses the various ways you can use your NetScreen device to manage limited bandwidth without
compromising quality and availability of the network to all of your users.
The topics discussed include:
• “Applying Traffic Shaping” on page 478
• “Setting Service Priorities” on page 483

&KDSWHU7UDIILF6KDSLQJ $SSO\LQJ7UDIILF6KDSLQJ
$33/<,1*75$)),&6+$3,1*
Traffic shaping is the allocation of the appropriate amount of network bandwidth to every user and application on an
interface. The appropriate amount of bandwidth is defined as cost-effective carrying capacity at a guaranteed
Quality of Service (QoS).
You can use NetScreen-5XP, -10, -100, and -500 devices to shape traffic by creating access policies and by
applying appropriate rate controls to each class of traffic going through your NetScreen devices1.
0DQDJLQJ%DQGZLGWKDWWKH$FFHVV3ROLF\/HYHO
To classify traffic, you create an access policy which specifies the amount of guaranteed bandwidth, the maximum
bandwidth, and the priority for each class of traffic.
The physical bandwidth of every interface is allocated to the guaranteed bandwidth parameter for all policies. If there
is any bandwidth left over, it is sharable by any other traffic.
In other words, each policy gets its guaranteed bandwidth and shares whatever is left over on a priority basis (up to
the limit of its maximum bandwidth specification).
The traffic shaping function applies to traffic from all policies. If you turn off traffic shaping for an access policy, but
traffic shaping is still turned on for other policies, the system applies a default traffic shaping policy to this policy
assigning 0 guaranteed bandwidth, unlimited maximum bandwidth, and a priority of 7 (the lowest priority setting). If
you do not want the system to assign this default traffic shaping policy to policies for which you have turned off traffic
shaping, then turn off traffic shaping system wide.
Through the CLI, you can set traffic shaping to automatic: set traffic-shaping mode auto. This allows the system to
turn on traffic shaping when an access policy requires it, and turn off traffic shaping when policies do not require it.
1. Traffic shaping is not supported on the NetScreen-1000.

([DPSOH7UDIILF6KDSLQJ
In this example, you partition 45Mbps of bandwidth on a T3 interface among three departments on the same subnet.
T3–45 Mbps
Marketing: 10 Mbps In, 10 Mbps Out
Internet
Router Router
Sales: 5 Mbps In, 10 Mbps Out
DMZ for
Servers
Support: 5 Mbps In, 5 Mbps Out
:HE8,
1. Interface >> Trusted >> Edit: Enter the following, and then click Save:
2. Interface >> Untrusted >> Edit: Enter the following, and then click Save:
3. Policy >> Outgoing >> New Policy: Enter the following, and then click OK:
Name: Marketing Traffic Shaping Policy
Source Address: Marketing
Destination Address: Outside Any

Service: Any
Action: Permit
VPN Tunnel: None2
Traffic Shaping: On
Guaranteed Bandwidth: 10000
Maximum Bandwidth: 15000
Name: Sales Traffic Shaping Policy
Source Address: Sales
Service: Any
Action: Permit
Traffic Shaping: On
Name: Support Traffic Shaping Policy
Source Address: Support
Service: Any
Action: Permit
Traffic Shaping: On
2. You can also do traffic shaping on VPN tunnels.


Name: Allow Incoming Access to Marketing
Source Address: Outside Any
Destination Address: Marketing
Service: Any
Action: Permit
Traffic Shaping: On
Name: Allow Incoming Access to Sales
Destination Address: Sales
Service: Any
Action: Permit
Traffic Shaping: On
Name: Allow Incoming Access to Support

Destination Address: Support

Service: Any
Action: Permit
Traffic Shaping: On
&/,
To enable traffic shaping by access policy:
1. set interface trust bandwidth 45000
2. set interface untrust bandwidth 45000
3. set policy outgoing marketing “outside any” any permit traffic gbw 10000 priority 0 mbw 15000
4. set policy outgoing sales “outside any” any permit traffic gbw 10000 priority 0 mbw 10000
5. set policy outgoing support “outside any” any permit traffic gbw 5000 priority 0 mbw 10000
6. set policy incoming marketing “outside any” any permit traffic gbw 10000 priority 0 mbw 10000
7. set policy incoming sales “outside any” any permit traffic gbw 5000 priority 0 mbw 10000
8. set policy incoming support “outside any” any permit traffic gbw 5000 priority 0 mbw 5000
9. save
or
To enable traffic shaping at the interface:
3. set traffic-shaping mode auto
4. save

&KDSWHU7UDIILF6KDSLQJ 6HWWLQJ6HUYLFH3ULRULWLHV
6(77,1*6(59,&(35,25,7,(6
The traffic shaping feature supported on NetScreen devices allows you to perform priority queuing on the bandwidth
that is not allocated to guaranteed bandwidth, or is guaranteed but not used.
Priority queuing is a feature that lets all your users and applications have access to available bandwidth as they
need it, while ensuring that important traffic can get through, if necessary at the expense of less important traffic.
Queuing allows NetScreen to buffer traffic in up to eight different priority queues. These eight queues are:
• High priority
• 2nd priority
• 3rd priority
• 4th priority
• 5th priority
• 6th priority
• 7th priority
• Low priority (default)
The priority setting for an access policy means that the bandwidth not already guaranteed to other access policies is
queued on the basis of High priority first and Low priority last. Access policies with the same priority setting compete
for bandwidth in a Round Robin fashion. The NetScreen device processes all of the traffic from all of the access
policies with High priority before processing any traffic from access policies with the next lower priority setting, and
so on, until all traffic requests have been processed. If traffic requests exceed available bandwidth, the lowest
priority traffic is dropped.
Caution Be careful not to allocate more bandwidth than the interface can support. The access policy configuration
process does not prevent you from creating unsupported access policy configurations. You can lose data if
the guaranteed bandwidth on contending access policies surpasses the traffic bandwidth set on the interface.
If you do not allocate any guaranteed bandwidth, then you can use priority queuing to manage all of traffic on your
network. That is, all High priority traffic is sent before any 2nd priority traffic is sent, and so on. The NetScreen
device processes Low priority traffic only after all other traffic has been processed.

([DPSOH3ULRULW\4XHXLQJ
In this example, you configure the guaranteed and maximum bandwidth for three departments—Support, Sales, and
Marketing— as follows:
Outbound Inbound Combined Priority

Guar.Max. Guar.Max. Guar.Max.
*
Support 10 10 1010 2020 High
Sales 55 710 1215 2
Marketing 55 35 810 3
Total 2020 2025 4045
*
Megabits per second (Mbps)
If all three departments send and receive traffic concurrently through the NetScreen firewall, the NetScreen device
must allocate 40 Mbps of bandwidth to fulfill the guaranteed access policy requirements. Of the 5 Mbps of available
bandwidth remaining, 3 Mbps of available bandwidth goes to Sales to fulfill its maximum bandwidth allocation.
Marketing traffic, having the lowest priority, uses the 8 Mbps of guaranteed traffic, and gets the remaining 2 Mbps
towards its maximum bandwidth allocation.

T3 (45 Mbps)
Support: 10 Mbps In, 10 Mbps Out, High Priority
Internet
Router Router
Sales: 7 Mbps In, 5 Mbps Out, 2nd Priority
DMZ for
Servers
Marketing: 3 Mbps In, 5 Mbps Out, 3rd Priority
:HE8,
Name: Sup-out
Service: Any
Action: Permit
Traffic Shaping: On

Traffic Priority: High priority

DiffServ Codepoint Marking3: Enable
Name: Sal-out
Service: Any
Action: Permit
Traffic Shaping: On
Traffic Priority: 2nd priority
DiffServ Codepoint Marking: Enable
Name: Mar-out
Service: Any
Action: Permit
Traffic Shaping: On
3. Differentiated Services (DS) is a system for tagging (or “marking”) traffic at a position within a hierarchy of priority. DS Codepoint Marking maps
the NetScreen priority level of the access policy to the first three bits of codepoint in the DS field in the IP packet header. For more information about DS
Codepoint Marking, see “Traffic Shaping” on page 249.


Traffic Priority: 3rd priority
Name: Sup-in
Service: Any
Action: Permit
Traffic Shaping: On
Traffic Priority: High priority
Name: Sal-in
Service: Any
Action: Permit
Traffic Shaping: On

Traffic Priority: 2nd priority

Name: Mar-in
Service: Any
Action: Permit
Traffic Shaping: On
Traffic Priority: 3rd priority
&/,
3. set policy name sup-out outgoing support “outside any” any permit traffic gbw 10000 priority 0 mbw 10000
dscp enable
4. set policy name sal-out outgoing sales “outside any” any permit traffic gbw 5000 priority 2 mbw 5000 dscp
enable
5. set policy name mar-out outgoing marketing “outside any” any permit traffic gbw 5000 priority 3 mbw 5000
dscp enable
6. set policy name sup-in incoming “outside any” support any permit traffic gbw 10000 priority 0 mbw 10000
dscp enable

7. set policy name sal-in incoming “outside any” sales any permit traffic gbw 7000 priority 2 mbw 10000 dscp
enable
8. set policy name mar-in incoming “outside any” marketing any permit traffic gbw 3000 priority 3 mbw 5000
dscp enable
9. save


&KDSWHU
9LUWXDO6\VWHPV

This chapter discusses the concepts and implementation of virtual systems and Virtual Local Area Networks
(VLANs) that are available on some NetScreen devices.
The specific topics discussed in this chapter are:
• “Establishing a Virtual System” on page 493
• “Defining Subinterfaces and VLAN Tags” on page 496
• “Importing and Exporting Physical Interfaces” on page 502
• “Logging On as a Virtual System Administrator” on page 504
• “Communicating Between VLANs” on page 506
Some NetScreen devices can provide multi-tenant services via virtual systems, each of which is a unique security
domain with its own management. Virtual systems can have their own administrators (called “virtual system
administrators”), who can individualize their security domains by setting their own address books, user lists, custom
services, VPNs, and access policies (although setting firewall security options, creating virtual system administrators
and defining subinterfaces can only be done at the root level).
Note: For more information on the various levels of administration that NetScreen supports, see “Levels of
Administration” on page 123.
Unless a virtual system has its own dedicated physical interfaces, it must be associated with at least one trusted
VLAN1, which is bound to the virtual system through a logical trusted subinterface. The VLAN members of the same
virtual system can communicate with each other. The VLAN members of different virtual systems cannot
communicate with one another unless the participating virtual system administrators specifically configure access
policies allowing the members of their respective systems to do so (see “Communicating Between VLANs” on page
506).
1. NetScreen supports VLANs compliant with the IEEE 802.1Q VLAN standard.

&KDSWHU9LUWXDO6\VWHPV
Internal Internal
Switch Routers
External External NetScreen Device
Untrust Zone Routers Switch Trust Zone
(Shared) (Root)
Root
Internet Vsys1-Trust
Vsys 1 Zone
Vsys 2
Vsys2-Trust
Zone
If the virtual system uses subinterfaces, the switch and router in the vsys-trust and shared untrust zones must have
VLAN-support capabilities. If you create more than one subinterface on a physical interface, then you must define
the connecting switch port as a trunk port2 and make it a member of all VLANs that use it.
Virtual systems can support the following kinds of interfaces for their Untrust and Trust zones:
Untrust Zone Interface Types Trust Zone Interface Types
• Dedicated Physical Interface • Dedicated Physical Interface
• Subinterface (with VLAN tagging) • Subinterface (with VLAN tagging)
• Shared Physical Interface with Root System
If a virtual system neither shares the Untrust zone interface with the root system nor has its own dedicated physical
interface, it must be associated with a VLAN that is bound to the virtual system through a subinterface. The Untrust
zone VLAN includes the 802.1Q-compliant router that receives its inbound and outbound traffic. The router tags the
incoming frames so that when they reach the NetScreen device, it can direct them to the correct subinterface.
Similarly, unless a virtual system has its own dedicated physical interface for its Trust zone, the internal switch and
router it uses must be included as members in the Trust zone VLAN.
2. A trunk port allows a switch to bundle traffic from several VLANs through a single physical port, sorting the various packets by the VLAN identifier (VID) in
their frame headers. When you associate a VLAN with an interface or subinterface, the NetScreen device automatically defines the physical port as a trunk
port. When using VLANs at the root level in Transparent mode, you must manually define the physical ports as trunk ports with the following CLI command:
set interface {trust | untrust} vlan trunk.

&KDSWHU9LUWXDO6\VWHPV (VWDEOLVKLQJD9LUWXDO6\VWHP
(67$%/,6+,1*$9,578$/6<67(0
The root administrator or root-level read/write admin must complete the following tasks to set up a functional virtual
system:
• Create and enter a virtual system
• Define all interfaces or subinterfaces and associate each subinterface with a VLAN
• (Optional) Assign a virtual system administrator
After completing these steps, the root level administrator can exit the virtual system and allow the virtual system
administrator to log in and begin configuring addresses, users, services, addresses, VPNs, and access policies.
If a virtual system has public (Internet routable) IP addresses in its Trust zone, it operates in Route mode, routing
inbound traffic directly to those addresses. If a virtual system has private (not Internet routable) IP addresses, it
operates in Network Address Translation (NAT) mode, translating the source addresses on outbound traffic and the
destination addresses on inbound traffic using Mapped IP (MIP) addresses.
Note: Only a root level administrator can set up MIPs for virtual systems. For more information, see “Mapped IP” on
page 468.
Although a virtual system cannot be in Transparent mode, because it requires unique interface or subinterface IP
addresses, the root system can be in Transparent mode3. For the root system to support VLANs while operating in
Transparent mode, use the following CLI command to enable the v1-trust and v1-untrust interfaces to act as trunk
ports: set interface { trust | untrust } vlan trunk.
A virtual system can also be reached via VPN tunnels; however, to support dialup users and dynamic peers, each
virtual system must have its own Untrust zone interface or subinterface. If a virtual system is sharing the Untrust
zone interface with the root system, it cannot support VPNs to dialup users and dynamic peers nor can it have an
AutoKey IKE VPN to the same remote site as the root system does.
3. When the root system is in Transparent mode, it cannot support virtual systems. It can, however, support root-level VLANs while in Transparent mode.

([DPSOH&UHDWLQJ9LUWXDO6\VWHPVDQG9LUWXDO6\VWHP$GPLQLVWUDWRUV
In this example, you are a root level administrator. You create three virtual systems: 111, 222, 333. For virtual
system 111, you create virtual system administrator Alice and the admin password wIEaS1v14. For virtual system
222, you create virtual system administrator Bob and the admin password pjF56Ms2. For virtual system 333, there is
no virtual system administrator.
Note: Virtual system names, admin names, and admin passwords are case-sensitive. Virtual system “abc” is
different from virtual system “ABC.”
After you create a virtual system through the WebUI, you remain at the root level. Entering the newly created virtual
system requires a separate step:
Vsys >> Vsys: Click Enter (for the virtual system you want to enter).
The WebUI pages of the virtual system you have entered appear, with the name of the virtual system above
the central display area—Virtual System Name: <Name>.
When you create a virtual system through the CLI, you immediately enter the system that you have just created. (To
enter an existing virtual system from the root level, use the enter vsys <name> command.) When you enter a
virtual system, note that the CLI command prompt changes to include the name of the system in which you are now
issuing commands.
:HE8,
1. Vsys >> Vsys >> New Virtual System: Enter the following, and then click OK:
VSYS Name: 111
VSYS Admin Name: Alice
VSYS Admin Password: wIEaS1v1
Confirm Password: wIEaS1v1
4. Only a root level administrator can create a virtual system administrator’s profile (user name and password). Because the NetScreen device uses the user
name to determine the virtual system to which a user belongs, a virtual system administrator cannot change his or her user name. However, a virtual system
administrator can (and should) change his or her password.

2. Vsys >> New Virtual System: Enter the following, and then click OK:
VSYS Name: 222
VSYS Admin Name: Bob
VSYS Admin Password: pjF56Ms2
Confirm Password: pjF56Ms2
3. Vsys >> New Virtual System: Enter the following, and then click OK:
VSYS Name: 333
&/,
1. ns500-> set vsys 111
2. ns500(111)-> set admin name Alice
3. ns500(111)-> set admin password wIEaS1v1
4. ns500(111)-> save5
5. ns500(111)-> exit
6. ns500-> set vsys 222
7. ns500(222)-> set admin name Bob
8. ns500(222)-> set admin password pjF56Ms2
9. ns500(222)-> save
10. ns500(222)-> exit
11. ns500-> set vsys 333
12. ns500(333)-> save
5. After issuing any commands, you must issue a save command before issuing an exit command or the NetScreen device loses your changes

&KDSWHU9LUWXDO6\VWHPV 'HILQLQJ6XELQWHUIDFHVDQG9/$17DJV
'(),1,1*68%,17(5)$&(6$1'9/$17$*6
The Trust zone subinterface links a virtual system to its internal VLAN. The Untrust zone subinterface links a virtual
system to the public WAN, usually the Internet. A subinterface has the following attributes:
• A unique VLAN ID (from 1 to 4095)
• A public or private IP address (the IP address is private by default)
• A netmask for a class A, B, or C subnet
• An associated VLAN
A virtual system can have a single Untrust zone subinterface and multiple Trust zone subinterfaces. If a virtual
system does not have its own Untrust zone subinterface, it shares the root level Untrust zone interface. NetScreen
devices also support VLANs at the root level.
Vsys = Virtual System NetScreen Device

if = Interface
sif = subinterface
if if LAN
Root sif VLAN.1
sif VLAN.2
Internet Vsys1 sif VLAN.3
sif VLAN.4
sif sif VLAN.5
Vsys2
sif VLAN.6
…
sif sif VLAN.292

Vsys100

The NetScreen device supports IEEE 802.1Q-compliant VLAN tags. A tag is an added bit in the Ethernet frame
header that indicates membership in a particular VLAN. By binding a VLAN to a virtual system, the tag also
determines to which virtual system a frame belongs, and consequently, which access policy is applied to that frame.
If a VLAN is not bound to a virtual system, access policies set in the root system of the NetScreen device are applied
to the frame.
A root level administrator can create a VLAN, assign members to it, and bind it to a virtual system. (The assigning of
members to a VLAN can be done by several methods—protocol type, MAC address, port number—and is beyond
the scope of this manual.) The virtual system administrator, if there is one, then manages the virtual system through
the creation of addresses, users, services, VPNs, and access policies. If there is no virtual system administrator,
then a root level administrator performs these tasks.
Note: If the super administrator does not associate a VLAN to a virtual system, the VLAN operates within the
NetScreen device root system.
There are three tasks that a root level administrator must perform to create a VLAN for a virtual system: Enter a
virtual system, define a subinterface, and associate it with a VLAN.
Note: All subnets in a virtual system must be disjointed; that is, there must be no overlapping IP addresses among
the subnets in the same virtual system. For example: Subinterface1 – 2.2.2.1 255.255.255.0 and Subinterface2 –
2.2.3.1 255.255.255.0 are disjointed, and therefore, link to acceptable subnets.
However, subnets with the following subinterfaces overlap, and are unacceptable within the same virtual system:
Subinterface1 – 2.2.2.1 255.255.0.0 and subinterface2 – 2.2.3.1 255.255.0.0.

([DPSOH'HILQLQJ7KUHH6XELQWHUIDFHVDQG9/$17DJV
In this example, you define subinterfaces and VLAN tags for three virtual systems—111, 222, and 333. The first two
subinterfaces are for two private virtual systems operating in NAT mode, and the third subinterface is for a public
virtual system operating in Route mode. The subinterfaces are 10.1.1.1/24, 10.2.2.1/24, and 10.3.3.1/24. Create all
three subinterfaces on ethernet3/2.
:HE8,
1. Vsys >>Vsys: Click Enter (for virtual system 111).
ethernet3/2.: 1
Netmask: 255.255.255.0
VLAN Tag: 1
Zone Name: Trust-111
Interface Mode: NAT
3. Click the Exit Vsys button (on the left side of the screen) to return to the root level.
ethernet3/2.: 2
Netmask: 255.255.255.0
VLAN Tag: 2
Interface Mode: NAT

6. Click the Exit Vsys button to return to the root level.

ethernet3/2.: 3
Netmask: 255.255.255.0
VLAN Tag: 10
9. Click the Exit Vsys button to return to the root level.

&/,
1. ns500-> enter vsys 111
2. ns500(111)-> set interface ethernet3/2.1 zone trust-111
3. ns500(111)-> set interface ethernet3/2.1 ip 10.1.1.1/24 tag 16
4. ns500(111)-> save
5. ns500(111)-> exit
9. ns500(222)-> save
10. ns500(222)-> exit
6. You can define virtual systems to operate in Route mode or NAT mode. The default is NAT mode, which is why it is unnecessary to specify that in the CLI
when creating the first two subinterfaces in this example.


14. ns500(333)-> set interface ethernet3/2.3 route
15. ns500(333)-> save
16. ns500(333)-> exit

&KDSWHU9LUWXDO6\VWHPV ,PSRUWLQJDQG([SRUWLQJ3K\VLFDO,QWHUIDFHV
,03257,1*$1'(;3257,1*3+<6,&$/,17(5)$&(6
In addition to assigning one or more subinterfaces to a virtual system, you can also dedicate one or more physical
interfaces to a virtual system. In effect, you import a physical interface from the root system to a virtual system. After
importing a physical interface to a virtual system, the virtual system has exclusive use of it.
Note: Before you can import an interface to a virtual system, it must be in the Null zone at the root level.
([DPSOH,PSRUWLQJD3K\VLFDO,QWHUIDFHWRD9LUWXDO6\VWHP
In this example, you import the physical interface ethernet4/1 to virtual system 111. You bind it to the Untrust zone
and assign it the IP address 210.1.1.1/24.
:HE8,
2. Interface >> Physical: Click Import (for ethernet4/1).
Netmask: 255.255.255.0
Zone Name: Untrust-111
&/,
2. ns500(111)-> set interface ethernet4/1 import
3. ns500(111)-> set interface ethernet4/1 zone untrust-111
4. ns500(111)-> set interface ethernet4/1 ip 210.1.1.1/24
5. ns500(111)-> save
6. ns500(111)-> exit

&KDSWHU9LUWXDO6\VWHPV ,PSRUWLQJDQG([SRUWLQJ3K\VLFDO,QWHUIDFHV
([DPSOH([SRUWLQJD3K\VLFDO,QWHUIDFHIURPD9LUWXDO6\VWHP
In this example, you bind the physical interface ethernet4/1 to the Null zone in virtual system 111 and assign it the IP
address 0.0.0.0/0. Then you export interface ethernet4/1 to the root system.
:HE8,
IP Address: 0.0.0.0
Netmask: 0.0.0.0
Zone Name: Null
3. Interface >> Physical: Click Export (for ethernet4/1).
Interface ethernet4/1 is now available for use in the root system.
&/,
2. ns500(111)-> set interface ethernet4/1 zone null
3. ns500(111)-> set interface ethernet4/1 ip 0.0.0.0/0
4. ns500(111)-> set interface ethernet4/1 export
5. ns500(111)-> save
Interface ethernet4/1 is now available for use in the root system.
6. ns500(111)-> exit

&KDSWHU9LUWXDO6\VWHPV /RJJLQJ2QDVD9LUWXDO6\VWHP$GPLQLVWUDWRU
/2**,1*21$6$9,578$/6<67(0$'0,1,675$725
Whereas a root level administrator enters a virtual system from the root level, a virtual system administrator enters
his or her virtual system directly. When a root level administrator exits a virtual system, he or she exits to the root
system. When a virtual system administrator exits a virtual system, the connection is immediately severed.
The following example shows how to log on to a virtual system as a virtual system administrator, change your
password, and log off.
([DPSOH/RJJLQJ2QDQG&KDQJLQJ\RXU3DVVZRUG
In this example, you, as the virtual system administrator log on to your virtual system, using your assigned login
name jsmith and password Pd50iH10. You change your password to I6Dls13guh, and then log out.
Note: A virtual system administrator cannot change his or her login name (user name) because the NetScreen
device uses that name, which must be unique among all virtual system administrators, to route the login connection
to the appropriate virtual system.
:HE8,
/RJJLQJ2Q
1. In the URL field in your Web browser, enter the Untrust zone subinterface IP address.
2. When the Network Password dialog box appears, enter the following, and then click OK:
User Name: jsmith
Password: Pd50iH10

&KDSWHU9LUWXDO6\VWHPV /RJJLQJ2QDVD9LUWXDO6\VWHP$GPLQLVWUDWRU
&KDQJLQJ\RXU3DVVZRUG
3. Admin >> Admin >> Edit: Enter the following, and then click OK:
Old Password: Pd50iH10
New Password: I6Dls13guh
Confirm New Password: I6Dls13guh
/RJJLQJ2II
4. Click the logout button, located among the information buttons in the upper right corner of the WebUI.
&/,
/RJJLQJ2Q
1. From a Secure Command Shell (SCS), Telnet, or HyperTerminal session command-line prompt, type the
Untrust zone subinterface IP address of the virtual system.
2. Log in with the following user name and password:
– User Name: jsmith
– Password: Pd50iH10
&KDQJLQJ\RXU3DVVZRUG
3. set admin password I6Dls13guh
4. save
/RJJLQJ2II
5. exit

&KDSWHU9LUWXDO6\VWHPV &RPPXQLFDWLQJ%HWZHHQ9/$1V
&20081,&$7,1*%(7:((19/$16
A host in the Trust zone VLAN of one virtual system can communicate with a host in the Trust zone VLAN of another
virtual system if the virtual system administrators create access policies to permit interVLAN communication.
Traffic between root-level VLANs operates within the parameters set by root-level access policies. Traffic between
virtual system VLANs operates within the parameters set by the participating virtual system access policies7. Only
that traffic allowed to leave the originating virtual system and that traffic allowed to enter the destination virtual
system is passed. In other words, the virtual system administrators of both virtual systems must set access policies
allowing the traffic to flow in the appropriate direction—outgoing and incoming.
([DPSOH,QWHU9/$1&RPPXQLFDWLRQ
In this example, you set up two sets of access policies to enable traffic between a workstation (work_js with the IP
address 10.5.5.20/32) in VLAN 1 and a server (ftp_server with the IP address 10.2.2.2/32) in VLAN 2. The
connection is possible if the following two conditions are met:
• The virtual system administrator for virtual system 111 has set an outgoing access policy permitting traffic
from the workstation in VLAN 1 to the server in VLAN 2.
• The virtual system administrator for virtual system 222 has set an incoming access policy permitting traffic
from the workstation in VLAN 1 to the server in VLAN 2.
Also, notice that the switch in front of the trusted port is configured for Layer 2. This forces traffic from VLAN 1 going
to VLAN 2 to go through the switch. If the switch were a Layer 3 switch, VLAN1 could pass traffic directly with
VLAN2, and visa versa, bypassing all access policies. Thus, the switch on the trusted side of the NetScreen device
becomes part of the security domain.
7. Access policies set in the root system do not affect access policies set in virtual systems, and vice versa.

NetScreen Device
Layer 2 work_js
Switch 10.5.5.20/32
Virtual System 111 VLAN 1
ftp_server
10.2.2.2/32
VLAN 2
Virtual System 222
:HE8,
9V\V
Address Name: work_js
Netmask: 255.255.255.255
Zone: Trust-111
Address Name: ftp_server
Netmask: 255.255.255.255
Zone: Untrust

3. Policy >> Policy (From Zone Trust-111 To Zone Untrust) >> New Policy: Enter the following, and then click
OK:
Source Address: work_js
Destination Address: ftp_server
Service: FTP-Get
Action: Permit
9V\V
Address Name: ftp_server
Netmask: 255.255.255.255
Zone: Trust-222
Address Name: work_js
Netmask: 255.255.255.255
Zone: Untrust
3. Policy >> Policy (From Zone Untrust To Zone Trust-222)>> New Policy: Enter the following, and then click
OK:
Source Address: work_js
Destination Address: ftp_server
Service: FTP-Get
Action: Permit

&/,
9V\V
1. set address trust-111 work_js 10.5.5.20/32
2. set address untrust ftp_server 10.2.2.2/32
3. set policy from trust-111 to untrust work_js ftp_server ftp-get permit
4. save
9V\V
1. set address trust-222 ftp_server 10.2.2.2/32
2. set address untrust work_js 10.5.5.20/32
3. set policy from untrust to trust-222 work_js ftp_server ftp-get permit
4. save


&KDSWHU
+LJK$YDLODELOLW\

This chapter explains the following aspects of setting up two or more NetScreen-500, -204, and -208 devices for
high availability (HA):
• “Cabling Procedure” on page 513
• “Redundant Groups” on page 515
• “Disabling HA” on page 520
• “Path Monitoring” on page 522
You configure NetScreen units for HA by cabling two or more devices together. If one unit fails, the second (backup)
1
unit can assume its functions with no service interruption. The backup unit maintains all sessions and Security
Associations (SAs), thus preventing interruption of VPN traffic. Because the master and backup units continuously
update configurations and access policies, there is no loss of enforcement capability.
In each redundant group (cluster) of NetScreen devices, there is always one master device and at least one backup
device. You can configure a specific unit as the master, or you can allow the system to automatically elect a master
dynamically based on which unit boots up first.2
If a master unit detects a backup unit failure, it generates a system alarm. If the master unit fails, the remaining
backup units elect a new master unit to which traffic is seamlessly redirected. During a fail-over event, NetScreen
devices also notify the adjacent networking devices upstream and downstream so that the entire network can
quickly converge to the new data path. When changing state between master and backup, both NetScreen units
generate alarms, which can take the form of SNMP vendor-specific traps, e-mail alerts from the master unit, or any
other configured logging mechanism.
1. Because of special requirements, sessions generated from H.323-related applications (such as NetMeeting) are not maintained on the backup unit.
2. If two units in an HA cluster boot up simultaneously, the one with the lowest media access control (MAC) address is selected the master.

&KDSWHU+LJK$YDLODELOLW\
You can enable authentication and encryption for HA communication involving configuration and keying material
and control protocol material between the master and backup units to increase security.
Note: The session sync material is not encrypted.
To ensure the integrity of the data paths between the NetScreen interfaces and the adjacent networking devices,
you can configure and enable path monitoring, in which each device in the redundant group continually monitors the
accessibility of specified devices on connected networks. Each backup unit continually compares its ability to access
these addresses with that of the master unit. Should a backup unit achieve better results than the master, it then
becomes the master.
To implement HA configuration, you need to perform the following steps:
1. Cable the NetScreen units together, as described in “Cabling Procedure” on page 513.
2. For NetScreen devices that do not have dedicated physical HA interfaces, bind an available interface to the
HA zone.
3. Create redundant groups.
4. Specify device priority. (This task is optional).
5. Enter the password(s), if you want to encrypt or authenticate HA communications between members of a
redundant group.
6. Set up IP addresses with which the units can perform path monitoring tests. (This task is optional.)
7. Synchronize configurations.

&KDSWHU+LJK$YDLODELOLW\ &DEOLQJ3URFHGXUH
&$%/,1*352&('85(
Which HA cabling procedure to use depends on the physical interfaces available on your NetScreen device. For
example, the NetScreen-500 has two dedicated physical HA interface ports, HA-1 and HA-2, while the
NetScreen-208 has no dedicated physical HA ports. The following are guidelines for cabling your HA cluster.
*HQHUDO&DEOLQJ5XOHV
The rules to follow when you connect two NetScreen devices in an HA cluster are as follows.
• If the device has dedicated HA ports, use them to connect the two devices. Such ports are bound by default
to the HA zone, a special security zone used exclusively for HA purposes.
• If the device does not have dedicated physical HA interfaces, you can use another available physical
interface. To make this interface serve as an HA port, you must bind it to the HA zone. Some NetScreen
devices have non-dedicated physical interfaces bound to the HA zone by default, as with physical interface
ethernet4 (on the NetScreen-204) and ethernet8 (on the NetScreen-208).
• Both devices must be of the same model. For example, you cannot establish an HA connection between a
NetScreen-500 device and a NetScreen-208 device.
• Both devices must run the same version of ScreenOS. Be sure to update both units with the same
ScreenOS version before connecting them.
• The cables between the two NetScreen devices must connect to identical ports on each side. For example,
if you connect the cable to ethernet8 on one NetScreen-208 unit, you must connect it to etherne8 on the
other unit.

&KDSWHU+LJK$YDLODELOLW\ &DEOLQJ3URFHGXUH
%LQGLQJD1RQ'HGLFDWHG,QWHUIDFHWRWKH+$=RQH
Even when a NetScreen device has no dedicated physical HA interface ports, the device might already have a
physical interface bound to the HA zone. For example, interface ethernet4 of the NetScreen-204 (and interface
ethernet8 of the NetScreen-208) are bound to the HA zone by default. Consequently, you can use these ports as HA
connection points.
However, in some situations there may be no physical interface currently bound to the HA zone, or you might need
to pass HA traffic through a different interface. In such situations, you must bind the other interface to the HA zone.
Note: Because HA communication is a Layer 2 process, the HA interface does not have an IP address or subnet
mask.
In the following example, the administrator sets up interface ethernet8 for HA communication.
:HE8,
Interface >> Physical >> Edit (for HA): Enter the following, and then click Save.
Zone Name: HA
&/,
set interface ethernet8 zone HA

&KDSWHU+LJK$YDLODELOLW\ 5HGXQGDQW*URXSV
5('81'$17*52836
Before two NetScreen devices can interact with each other in HA mode, you must configure them in a redundant
group. In a redundant group, one of the NetScreen units acts as the master unit, performing firewall, VPN, and traffic
management. The backup unit acts as a hot stand-by, automatically keeping up with all configuration and session
state information. If the master unit fails, one of the backup units automatically becomes the new master unit. When
the failed unit is repaired and placed back in service, it becomes a backup unit for the existing master unit.
You can also specify device priority in the redundant group hierarchy. The device with the number closest to 1 is the
master unit. A value of 0 disables high availability and shuts down dedicated HA ports.
Alternatively, you can allow the devices to elect a master and determine priority numbers automatically during
startup. The device that boots up first becomes the master. If you have more than two units in the redundant group,
the order in which each of the subsequent units boots up determines their priority within the group.
Note: If two units boot up simultaneously, the unit with the lower MAC address becomes the master.
For some NetScreen devices, the HA status of the unit is indicated by the Status LED, while for others the status is
indicated by the HA LED on the front panel or on the Auxiliary board. The LED on the master unit glows green. The
LED on the backup unit glows yellow. If the LED is dark, that indicates that the unit is not configured for HA.
When forming a redundant group, it is important to configure the Manage IP address on each NetScreen device for
the interfaces through which you intend to manage the device and from which you plan to perform path monitoring.
The Manage IP remains associated with the unique MAC address for its interface, while virtual MAC addresses,
associated with the interface IP addresses, are identical among all the members of the redundant group. The virtual
MAC addresses are created when you set a group ID number. The virtual MACs are formed as follows:
0010dbff<group_number><interface_value>.

At any time, you can synchronize the master unit’s configuration file among all members of its redundant group. In
the WebUI, click the Sync All Files button on the Configure >> HA page. In the CLI, use the exec ha file-sync
command.
Note: When you synchronize all the files from the master unit, the backup units’ manage IP addresses are replaced
with those of the master unit. Consequently, you lose the ability to manage the backup units. To reconfigure the
manage IP addresses, you must enter the set interface mange-ip <ip_addr> command via the console port on
each backup unit.
([DPSOH)RUPLQJD5HGXQGDQW*URXS
In the following example, the administrator places two NetScreen devices in a redundant group with the ID number
3. He assigns each device with the same group ID number and determines the master and backup units by
assigning them priority numbers. He also configures Manage IP addresses for the trusted and untrusted interfaces
on both devices.
Through the CLI, the administrator also sets up the backup unit in a link-up state. During a failover, when a backup
unit in a link-up state becomes the active device, it does not need to perform 802.1Q trunk negotiations nor execute
the Spanning Tree Protocol (STP), which can take anywhere from 30 to 50 seconds to complete. The new master
unit simply sends out a series of ARPs, alerting other network devices to its presence.
Also, through the CLI, the administrator indicates a secondary path for the backup to communicate with the master.
In case the backup does not receive a heartbeat from the master along the primary HA path, the backup sends a
message along the secondary path to confirm that the master unit is truly down. If the master unit is still up (perhaps
only the cable carrying HA traffic has been damaged, causing the heartbeat loss) and the backup promotes itself to
master, two devices would be acting as the master, resulting in a condition known a split-brain scenario. Use of a
secondary path to confirm the master’s condition can help avoid such a problem.
Note: When a NetScreen device has no dedicated HA interfaces, you must also specify a physical interface (such
as ethernet4) to act as the Virtual HA interface.

In this example, two NetScreen devices are grouped in an HA cluster. Each device uses the following physical
interfaces:
• ethernet8 is the Virtual HA interface.
• ethernet4 is the interface bound to the Trusted zone.
• ethernet5 is the interface bound to the Untrusted zone.
External
Redundant Group
IP Address of ethernet5, ID: 3 IP Address of ethernet5,
(bound to Untrusted zone): Priority: 1 Priority: 2 (bound to Untrusted zone):
211.30.2.2 Master Backup 211.30.2.2
IP Address of ethernet4, HA
(bound to Trusted zone): IP Address of ethernet4,
10.10.2.2 (bound to Trusted zone):
10.10.2.2
Note: In this example, interface ethernet8 serves as the HA interface. To function as the HA interface, the interface
must be bound to the HA zone. On some NetScreen devices, the ethernet8 interface is bound to the HA zone by
default. If the interface you choose for HA is not already bound to the HA zone, you must perform this binding before
proceeding with the WebUI instructions that follow. The CLI command for binding an interface to the HA zone is set
interface <int_name> zone HA. For example, to bind interface ethernet8 to the HA zone, the command is set
interface ethernet8 zone HA.

:HE8,
Master Unit
1. Interface >> Physical >> Edit (ethernet4): Enter the following, and then click Save:
Netmask: 255.255.255.0
Manage IP: 10.10.2.20
Zone Name: Trust
2. Interface >> Physical >> Edit (ethernet5): Enter the following, and then click Save:
Netmask: 255.255.255.0
Manage IP: 211.30.2.20
Zone Name: Untrust
3. Configure >> HA: Enter the following, and then click Apply:
HA Port: ethernet8
Group ID: 3
Priority: 1
Backup Unit
1. Interface >> Physical >> Edit (ethernet4): Enter the following, and then click Save :
Netmask: 255.255.255.0
Manage IP: 10.10.2.30
Zone Name: Trust

2. Interface >> Physical >> Edit (ethernet5): Enter the following, and then click Save :
Netmask: 255.255.255.0
Manage IP: 211.30.2.30
Zone Name: Untrust
3. Configure >> HA: Enter the following, and then click Apply:
HA Port: ethernet8
Group ID: 3
Priority: 2
&/,
Master Unit
7. set interface ethernet8 zone ha
8. set ha interface ethernet8
9. set ha group 3
10. set ha priority 1

Backup Unit
2. set interface ethernet4 10.10.2.2/24
7. set interface ethernet8 zone ha
8. set ha interface ethernet8
9. set ha group 3
10. save config ha-master
11. reset
Configuration modified, save? [y]/n (Type n.)
System reset, are you sure? y/[n] (Type y.)
'LVDEOLQJ+$
You can disable HA functionality by removing a device from its redundant group. You can do this by setting the
group ID to 0 (in the WebUI or CLI), or by using the CLI command unset ha group.

&KDSWHU+LJK$YDLODELOLW\ 6HFXULQJ+$&RPPXQLFDWLRQV
6(&85,1*+$&20081,&$7,216
To secure HA communications, you can configure the clustered NetScreen devices to authenticate and encrypt all
exchanged HA traffic. To perform this configuration, you enable authentication and encryption and then specify
passwords. The NetScreen passwords are used as seed material for the device to generate the preshared key.
All master and backup units in the same redundant group must have the same authorization password and the same
encryption password, although the authorization password can be different from the encryption password.
([DPSOH(QDEOLQJ$XWKHQWLFDWLRQDQG(QFU\SWLRQ
The two devices in the redundant group authenticate and encrypt HA communications. The authentication password
is p6NE9mKq and the encryption password is 45Zg8HB1.
:HE8,
1. Configure >> HA: Select HA Authentication Password, and type p6NE9mKq.
2. Configure >> HA: Select HA Encryption Password, type 45Zg8HB1, and then click Apply.
&/,
1. set ha authentication password p6NE9mKq
2. set ha encryption password 45Zg8HB1
3. save

&KDSWHU+LJK$YDLODELOLW\ 3DWK0RQLWRULQJ
3$7+021,725,1*
Path monitoring checks the network connection between a NetScreen interface and the interface on another device.
Path monitoring can occur at both layer 2 (Ethernet) and layer 3 (IP). Path monitoring for the Ethernet link state
occurs automatically. Layer 3 (IP) path monitoring functions by sending a ping request at determined intervals and
then monitoring if the target replies with a ping reply. A successful attempt indicates that layer 3 connectivity is
possible over the network. A failed attempt indicates that the two devices cannot make a layer 3 connection.
Path monitoring is a useful tool for devices within a redundant group to determine whether the network connectivity
of a master unit is better than or as good as a backup unit. If backup unit has a better success rate than the master
unit (for example, the backup unit gets 5 ping replies and the master gets only 4), then it automatically is promoted to
master, and the master unit is demoted to backup.
When using path monitoring, you must set a Manage IP address for the physical interface, or interfaces, from which
the NetScreen devices ping. The backup unit uses the Manage IP address to distinguish itself from the master unit,
which uses the physical IP address shared by all the devices in the redundant group.
Note: The Manage IP address is also the address with which you can configure a backup unit.
([DPSOH(QDEOLQJ3DWK7UDFNLQJ
Two NetScreen devices are in a redundant group. Both are set to ping the IP addresses of four Web servers every
10 seconds. The alarm threshold is set to 3 failures. Not receiving a ping response after 3 consecutive attempts is
considered a failed attempt. In this example, the master unit has a 100% success rate, while the backup unit
succeeds only 50% of the time.
Note: In this example, the interface bound to the Untrust zone is assumed to be ethernet6, although this is not
necessarily the interface you might use for your configuration.

Web Servers
Solid lines = successful ping
attempts
Broken lines = failed ping attempts Internet
216.115.105.6
Master
HA Link 209.125.198.2
Backup
208.158.245.146
207.46.230.229
:HE8,
1. Configure >> HA >> New Track IP: Enter the following, and then click OK:
Track IP: 216.115.105.6
Interval (sec): 10
Threshold: 3
Interface: Ethernet6

Track IP: 209.125.198.2
Interval (sec): 10
Threshold: 3
Track IP: 208.158.245.146
Interval (sec): 10
Threshold: 3
Track IP: 207.46.230.229
Interval (sec): 10
Threshold: 3
5. Configure >> HA: Select Track IP, and then click Apply.
&/,
1. set ha track ip 216.115.105.6 interface Ethernet6
2. set ha track ip 216.115.105.6 interval 10
3. set ha track ip 216.115.105.6 threshold 3


13. set ha track ip
14. save


$SSHQGL[$
61030,%)LOHV
$
NetScreen provides MIB files to support SNMP communication between your organization’s applications and the
SNMP Agent in the NetScreen device. To obtain the latest MIB files, download them from www.netscreen.support.
The MIB files for this ScreenOS version are fully compatible with SNMP agents in previous versions of ScreenOS.
7KH3ULPDU\/HYHO0,%)LOH)ROGHUV
The MIB files are arranged in a hierarchical folder structure. The primary-level MIB folders are as follows.
1HW6FUHHQ&RQFHSWV ([DPSOHV $,

$SSHQGL[$61030,%)LOHV
Each folder contains a category of MIB files.
netscreenProducts Assigns Object Identifiers (OIDs) to different NetScreen product series.

netscreenTrapInfo Defines enterprise traps sent by the NetScreen device.
netscreenIDS Defines the NetScreen device intrusion detection service (IDS) configuration.
netscreenVpn Defines NetScreen device VPN configuration and runtime information.
netscreenQos Defines NetScreen device Quality of Service configuration.
netscreenSetting Defines miscellaneous NetScreen device configuration settings, such as DHCP,
email, authentication, and administrator.
netscreenZone Defines zone information residing in the NetScreen Device.
netscreenInterface Defines the NetScreen device’s interface configuration, including the virtual
interface.
netscreenPolicy Defines the outgoing and incoming policy configuration for the NetScreen device.
netscreenNAT Defines NAT configuration, including Map IP, Dynamic IP and Virtual IP.
netscreenAddr Represents the address table on a NetScreen interface.
netscreenService Describes services (including user-defined) recognized by the NetScreen device.
netscreenSchedule Defines NetScreen device task schedule information, configured by the user.
netscreenVsys Defines NetScreen device virtual system (VSYS) configuration.
netscreenResource Accesses information regarding the NetScreen device’s resource utilization.
netscreenIp Accesses NetScreen device private IP-related information.
1HW6FUHHQ&RQFHSWV ([DPSOHV $,,

6HFRQGDU\/HYHO0,%)ROGHUV
Most of the primary-level MIB folders contain secondary-level folders.
QHW6FUHHQ,GV
nsldsProtect IDS service on
NetScreen device
nsldsProtectSetTable IDS service enabled on
NetScreen device
nsldsProtectThreshTable IDS service threshold
configuration
nsldsAttkMonTable Statistical Information
about intrusion attempt
QHWVFUHHQ9SQ
netscreenVpnMon Show SA information of vpn tunnel
nsVpnManualKey Manual key configuration
nsVpnIke IKE configuration
nsVpnGateway VPN tunnel gateway configuration
nsVpnPhaseOneCfg IPSec Phase One configuration
nsVpnPhaseTwoCfg IPSec Phase Two configuration
nsVpnCert Certification configuration
nsVpnL2TP L2TP configuration
nsVpnPool IP pool configuration
nsVpnUser VPN user configuration
1HW6FUHHQ&RQFHSWV ([DPSOHV $,,,

QHWVFUHHQ4RV
nsQosPly QoS configuration on policy
QHWVFUHHQ6HWWLQJ
nsSetGeneral General configuration of NS device
nsSetAuth Authentication method configuration
nsSetDNS DNS server setting
nsSetURLFilter URL filter setting
nsSetDHCP DHCP server setting
nsSetSysTime System time setting
nsSetEmail Email setting
nsSetLog Syslog setting
nsSetSNMP SNMP agent configuration
nsSetGlbMng Global management configuration
nsSetAdminUser Administration user configuration
nsSetWebUI Web UI configuration
QHWVFUHHQ3ROLF\
NsPlyTable Policy configuration
NsPlyMonTable Statistical Information about each policy
1HW6FUHHQ&RQFHSWV ([DPSOHV $,9

QHWVFUHHQ1$7
nsNatMipTable Mapped IP configuration
nsNatDipTable Dynamic IP configuration
nsNatVip Virtual IP Configuration
QHWVFUHHQ6HUYLFH
nsServiceTable Service Information
nsServiceGroupTable Service Group Information
nsServiceGrpMemberTable Service Group Member Info
QHWVFUHHQ6FKHGXOH
nschOnceTable One-time schedule information
nschRecurTable Re-occur schedule information
QHWVFUHHQ5HVRXUFH
nsresCPU CPU utilization
nsresMem Memory utilization
nsresSession Session utilization
QHWVFUHHQ,S
nslpArp ARP table
1HW6FUHHQ&RQFHSWV ([DPSOHV $9

1HW6FUHHQ&RQFHSWV ([DPSOHV $9,

$SSHQGL[%
*ORVVDU\
%
10BaseT. The most common form of Ethernet is called 10BaseT, which denotes a peak transmission speed of 10
Mbps using copper twisted-pair cable. Ethernet is a standard for connecting computers into a local area network
(LAN). The maximum cable distance is 100 meters (325 feet), the maximum devices per segment is 1, and the
maximum devices per network are 1024. See also 100BaseT.
100BaseT. Another term for fast Ethernet, an upgraded standard for connecting computers into a local area network
(LAN). 100BaseT Ethernet works just like regular Ethernet except that it can transfer data at a peak rate of 100
Mbps. It is also more expensive and less common than its slower 10BaseT sibling. See also 10BaseT.
Access Policies. Access Policies provide the initial protection mechanism for the firewall, allowing you to determine
what traffic passes across it based on IP session details. They protect the Trusted network from outsider attacks,
such as the scanning of Trusted servers. Access Policies create an environment in which you set up security
Policies to monitor traffic attempting to cross your firewall.
Authentication Header (AH). See ESP/AH.
Authentication. Authentication ensures that digital data transmissions are delivered to the intended receiver.
Authentication also assures the receiver of the integrity of the message and its source (where or whom it came
from). The simplest form of authentication requires a user name and password to gain access to a particular
account. Authentication protocols can also be based on secret-key encryption, such as DES, or on public-key
systems using digital signatures.
Bridge. A device that forwards traffic between network segments based on data link layer information. These
segments would have a common network layer address.
Circuit-level Proxy. Proxy or Proxy Server is a technique used to cache information on a Web server and acts as
an intermediary between a Web client and that Web server. It basically holds the most commonly and recently used
content from the World Wide Web for users in order to provide quicker access and to increase server security. This
is common for an ISP especially if they have a slow link to the Internet. On the Web, a proxy first attempts to find
data locally, and if it’s not there, fetches it from the remote server where the data resides permanently. Proxy servers
are also constructs that allow direct Internet access from behind a firewall. They open a socket on the server, and
1HW6FUHHQ&RQFHSWV ([DPSOHV %,

$SSHQGL[%*ORVVDU\
allow communication via that socket to the Internet. For example, if your computer is inside a protected network, and
you want to browse the Web using Netscape, you would set up a proxy server on a firewall. The proxy server would
be configured to allow requests from your computer, trying for port 80, to connect to its port 1080, and it would then
redirect all requests to the proper places.
Data Encryption Standard (DES). A 40- and 56-bit encryption algorithm that was developed by the National
Institute of Standards and Technology (NIST). DES is a block encryption method originally developed by IBM. It has
since been certified by the U.S. government for transmission of any data that is not classified top secret. DES uses
an algorithm for private-key encryption. The key consists of 64 bits of data, which are transformed and combined
with the first 64 bits of the message to be sent. To apply the encryption, the message is broken up into 64-bit blocks
so that each can be combined with the key using a complex 16-step process. Although DES is fairly weak, with only
one iteration, repeating it using slightly different keys can provide excellent security.
Data Encryption Standard-Cipher Block Chaining (DES-CBC). Until recently, the most significant use of
triple-DES (3DES) was for the encryption of single DES keys, and there was really no need to consider how one
might implement various block cipher modes when the block cipher in question is actually one derived from multiple
encryption. However, as DES nears the end of its useful lifetime, more thought is being given to an increasingly
widespread use of triple-DES. In particular, there are two obvious ways to implement the CBC mode for triple-DES.
With single-DES in CBC mode, the ciphertext is exclusive-ored with the plaintext before encryption. With triple-DES
however, we might use feedback around all three DES operations from the ciphertext to the plaintext, something
which is called outer-CBC. Alternatively, we might run the feedback around each individual encryption component,
thereby making, in effect, triple-(DES-CBC). This is referred to as inner-CBC, since there are internal feedbacks that
are never seen by the crypto-analyst. Performance-wise, there can be some advantages to use the inner-CBC
option, but research has established that outer-CBC is in fact more secure. Outer-CBC is the recommended way for
using triple-DES in the CBC mode.
De-Militarized Zone (DMZ). From the military term for an area between two opponents where fighting is prevented.
DMZ Ethernets connect networks and computers controlled by different bodies. They may be external or internal.
External DMZ Ethernets link regional networks with routers.
1HW6FUHHQ&RQFHSWV ([DPSOHV %,,

$SSHQGL[%*ORVVDU\
Encryption. Encryption is the process of changing data into a form that can be read only by the intended receiver.
To decipher the message, the receiver of the encrypted data must have the proper decryption key. In traditional
encryption schemes, the sender and the receiver use the same key to encrypt and decrypt data. Public-key
encryption schemes use two keys: a public key, which anyone may use, and a corresponding private key, which is
possessed only by the person who created it. With this method, anyone may send a message encrypted with the
owner’s public key, but only the owner has the private key necessary to decrypt it. PGP (Pretty Good Privacy) and
DES (Data Encryption Standard) are two of the most popular public-key encryption schemes.
ESP/AH. The IP level security headers, AH and ESP, were originally proposed by the Network Working Group
focused on IP security mechanisms, IPSec. The term IPSec is used loosely here to refer to packets, keys, and
routes that are associated with these headers. The IP Authentication Header (AH) is used to provide authentication.
The IP Encapsulating Security Header (ESP) is used to provide confidentiality to IP datagrams.
Ethernet. A local area network technology invented at the Xerox Corporation, Palo Alto Research Center. Ethernet
is a best-effort delivery system that uses CSMA/CD technology. Ethernet can be run over a variety of cable
schemes, including thick coaxial, thin coaxial, twisted pair, and fiber optic cable. Ethernet is a standard for
connecting computers into a local area network (LAN). The most common form of Ethernet is called 10BaseT, which
denotes a peak transmission speed of 10 Mbps using copper twisted-pair cable.
Extranet. The connecting of two or more intranets. If an intranet as a company’s internal Web site which allows
users inside the company to communicate and exchange information, an extranet connects that virtual space with
another company’s intranet, thus allowing these two (or more) companies to share resources and communicate over
the Internet in their own virtual space. This technology greatly enhances business to business communications.
Filtering, dynamic. IP service that can be used within VPN tunnels. Filters are one way the NetScreen-10/100
controls traffic from one network to another. When TCP/IP sends data packets to the firewall, the filtering function in
the firewall looks at the header information in the packets and directs them accordingly. The filters operate on criteria
such as IP source or destination address range, TCP ports, UDP, Internet Control Message Protocol (ICMP), or
TCP responses. See also Tunneling and Virtual Private Network (VPN).
Firewall. A device that protects and controls the connection of one network to another, for traffic both entering and
leaving. Firewalls are used by companies that want to protect any network-connected server from damage
(intentional or otherwise) by those who log in to it. This could be a dedicated computer equipped with security
measures or it could be a software-based protection.
GBIC. A Gigabit Interface Connector (GBIC) is the kind of interface module card used on the NetScreen-500 for
connecting to a fiber optic network.
1HW6FUHHQ&RQFHSWV ([DPSOHV %,,,

$SSHQGL[%*ORVVDU\
Hub. This hardware is used to network computers together (usually over an Ethernet connection). It serves as a
common wiring point so that information can flow through one central location to any other computer on the network
thus enabling centralized management. A hub is a hardware device that repeats signals at the physical Ethernet
layer. A hub retains the behavior of a standard bus type network (such as Thinnet), but produces a star topology with
the hub at the center of the star. This configuration enables centralized management.
Internet Control Message Protocol (ICMP). Occasionally a gateway or destination host will communicate with a
source host, for example, to report an error in datagram processing. For such purposes the protocol, the Internet
Control Message Protocol (ICMP), is used. ICMP uses the basic support of IP as if it were a higher level protocol,
however, ICMP is actually an integral part of IP, and must be implemented by every IP module. ICMP messages are
sent in several situations: for example, when a datagram cannot reach its destination, when the gateway does not
have the buffering capacity to forward a datagram, and when the gateway can direct the host to send traffic on a
shorter route. The Internet Protocol is not designed to be absolutely reliable. The purpose of these control messages
is to provide feedback about problems in the communication environment, not to make IP reliable.
Internet. Also known as “the Net.” Originally designed by the U.S. Defense Department so that a communication
signal could withstand a nuclear war and serve military institutions worldwide. The Internet was first known as the
ARPAnet. A system of linked computer networks, international in scope, that facilitates data communication services
such as remote login, file transfer, electronic mail, and newsgroups. The Internet is a way of connecting existing
computer networks that greatly extends the reach of each participating system.
Internet Key Exchange (IKE). The method for exchanging keys for encryption and authentication over an unsecured
medium, such as the Internet.
Internet Protocol (IP). An Internet standard protocol that defines a basic unit of data called a datagram. A datagram
is used in a connectionless, best-effort, delivery system. The Internet protocol defines how information gets passed
between systems across the Internet.
1HW6FUHHQ&RQFHSWV ([DPSOHV %,9

$SSHQGL[%*ORVVDU\
IP Address. Each node on a TCP/IP network usually has an IP address. The IP address has a network number
portion and a host number portion, as shown in the following table of IP address classes and formats:
Table C-1
Class Number of Nodes Address Format
A > 32,768 nnn.hhh.hhh.hhh
B 256–32,768 nnn.nnn.hhh.hhh
C <256 nnn.nnn.nnn.hhh
This format is called decimal dot format. The “n” represents a digit of a network number and “h” represents a digit of
a host number; for example, 128.11.2.30. If you are sending data outside of your network, such as to the Internet,
you need to obtain the network number from a central authority, currently the Network Information Center. See also
Subnet Mask.
IP Gateway. Also called a router, a gateway is a program or a special-purpose device that transfers IP datagrams
from one network to another until the final destination is reached.
IP Security (IPSec). Security standard produced by the Internet Engineering Task Force (IETF). It is a protocol suite
that provides everything you need for secure communications—authentication, integrity, and confidentiality—and
makes key exchange practical even in larger networks. See also DES-CBC, ESP/AH.
ISAKMP. The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for
Internet key management and provides the specific protocol support for negotiation of security attributes. By itself, it
does not establish session keys, however it can be used with various session key establishment protocols to provide
a complete solution to Internet key management.
Intranet. A play on the word Internet, an intranet is a restricted-access network that works like the Web, but isn't on
it. Usually owned and managed by a corporation, an intranet enables a company to share its resources with its
employees without confidential information being made available to everyone with Internet access.
Key Management, Manual. The only reasonable way to protect the integrity and privacy of information is to rely
upon the use of secret information in the form of private keys for signing and/or encryption. The management and
handling of these pieces of secret information is generally referred to as “key management.” This includes the
activities of selection, exchange, storage, certification, expiration, revocation, changing, and transmission of keys.
Most of the work in managing information security systems lies in the key management.
1HW6FUHHQ&RQFHSWV ([DPSOHV %9

$SSHQGL[%*ORVVDU\
Load balancing. Load balancing is the mapping (or re-mapping) of work to processors, with the intent of improving
the efficiency of a concurrent computation.
Local Area Network (LAN). Any network technology that interconnects resources within an office environment,
usually at high speeds, such as Ethernet. A local area network is a short-distance network used to link a group of
computers together within a building. 10BaseT Ethernet is the most commonly used form of LAN. A hardware device
called a hub serves as the common wiring point, enabling data to be sent from one machine to another over the
network. LANs are typically limited to distances of less than 500 meters and provide low-cost, high-bandwidth
networking capabilities within a small geographical area.
MD5. Message Digest (version) 5, an algorithm that produces a 128-bit message digest (or hash) from a message of
arbitrary length. The resulting hash is used, like a “fingerprint” of the input, to verify authenticity.
Media Access Control (MAC) Address. An address that uniquely identifies the network interface card, such as an
Ethernet adapter. For Ethernet, the MAC address is a 6 octet address assigned by IEEE. On a LAN or other
network, the MAC address is a computer's unique hardware number. (On an Ethernet LAN, it's the same as the
Ethernet address.) When you're connected to the Internet from your computer (or host as the Internet protocol thinks
of it), a correspondence table relates your IP address to your computer's physical (MAC) address on the LAN. The
MAC address is used by the Media Access Control sublayer of the Data-Link Control (DLC) layer of
telecommunication protocols. There is a different MAC sublayer for each physical device type.
Network Address Translation (NAT). A standard for translating secure IP addresses to temporary, external,
registered IP address from the address pool. This allows Trusted networks with privately assigned IP addresses to
have access to the Internet. This also means that you don’t have to get a registered IP address for every machine in
your network.
RJ-45. Resembling a standard phone connector, an RJ-45 connector is twice as wide (with eight wires) and is used
for hooking up computers to local area networks (LANs) or phones with multiple lines.
Router. This hardware device routes data from a local area network (LAN) to a phone line's long distance line.
Routers also act as traffic cops, allowing only authorized machines to transmit data into the local network so that
private information can remain secure. In addition to supporting these dial-in and leased connections, routers also
handle errors, keep network usage statistics, and handle security issues.
Security Association. The combination of a Security Parameters Index and a destination address. Required for
both Authentication Header and Encapsulating Security Payload protocols. See also Security Parameters Index.
1HW6FUHHQ&RQFHSWV ([DPSOHV %9,

$SSHQGL[%*ORVVDU\
Security Parameters Index. (SPI) is a hexadecimal value which uniquely identifies each tunnel. It also tells the
NetScreen device which key to use to decrypt packets.
Server Farm. A server farm is a network where clients install their own computers to run Web servers, e-mail, or any
other TCP/IP based services they require, making use of leased permanent Internet connections with 24-hour
worldwide access. Instead of expensive dedicated-line connections to various offices, servers can be placed on
server farm networks to have them connected to the Internet at high-speed for a fraction of the cost of a leased line.
SHA-1. Secure Hash Algorithm-1, an algorithm that produces a 160-bit hash from a message of arbitrary length. (It
is generally regarded as more secure than MD5 because of the larger hashes it produces.)
Subnet Mask. In larger networks, the subnet mask lets you define subnetworks. For example, if you have a class B
network, a subnet mask of 255.255.255.0 specifies that the first two portions of the decimal dot format are the
network number, while the third portion is a subnet number. The fourth portion is the host number. If you do not want
to have a subnet on a class B network, you would use a subnet mask of 255.255.0.0. A network can be subnetted
into one or more physical networks which form a subset of the main network. The Subnet Mask is the part of the IP
address which is used to represent a subnetwork within a network. Using Subnet Masks allows you to use network
address space which is normally unavailable and ensures that network traffic does not get sent to the whole network
unless intended. Subnet Masks are a complex feature, so great care should be taken when using them. See also IP
address.
Three-Way Handshake. A TCP connection is established with a triple exchange of packets known as a three-way
handshake. The procedure transpires as follows:
1. The initiator sends a SYN (synchronize/start) packet.
2. The recipient replies with a SYN/ACK (synchronize/acknowledge) packet.
3. The initiator responds with an ACK (acknowledge) packet.
4. At this point, the two endpoints of the connection have been established and data transmission can
commence.
1HW6FUHHQ&RQFHSWV ([DPSOHV %9,,

$SSHQGL[%*ORVVDU\
Transmission Control Protocol/Internet Protocol (TCP/IP). A set of communications protocols that support
peer-to-peer connectivity functions for both local and wide area networks. A communications protocol which allows
computers with different operating systems to communicate with each other. Controls how data is transferred
between computers on the Internet.
Trunk Port. A trunk port allows a switch to bundle traffic from several VLANs through a single physical port, sorting
the various packets by the VLAN identifier (VID) in their frame headers.
Tunneling. A method of data encapsulation.With VPN tunneling, a mobile professional dials into a local Internet
Service Provider’s Point of Presence (POP) instead of dialing directly into their corporate network. This means that
no matter where mobile professionals are located, they can dial a local Internet Service Provider that supports VPN
tunneling technology and gain access to their corporate network, incurring only the cost of a local telephone call.
When remote users dial into their corporate network using an Internet Service Provider that supports VPN tunneling,
the remote user as well as the organization knows that it is a secure connection. All remote dial-in users are
authenticated by an authenticating server at the Internet Service Provider’s site and then again by another
authenticating server on the corporate network. This means that only authorized remote users can access their
corporate network, and can access only the hosts that they are authorized to use.
User Datagram Protocol (UDP). A protocol in the TCP/IP protocol suite, the User Datagram Protocol or UDP
allows an application program to send datagrams to other application programs on a remote machine. Basically
UDP is a protocol that provides an unreliable and connectionless datagram service where delivery and duplicate
detection are not guaranteed. It does not use acknowledgments, or control the order of arrival.
1HW6FUHHQ&RQFHSWV ([DPSOHV %9,,,

$SSHQGL[%*ORVVDU\
Universal Resource Locator (URL). A standard way developed to specify the location of a resource available
electronically.Also referred to as a location or address, URLs specify the location of files on servers. A general URL
has the syntax protocol://address. For example, http://www.srl.rmit.edu.au/pd/index.html specifies that the protocol
is http and the address is www.srl.rmit.edu.au/pd/index.html.
Unshielded Twisted Pair (UTP). Also known as 10BaseT. This is the standard cabling used for telephone lines. It is
also used for Ethernet connections.
Virtual Local Area Network (VLAN). A logical rather than physical grouping of devices that constitute a single
broadcast domain. VLAN members are not identified by their location on a physical subnetwork but through the use
of tags in the frame headers of their transmitted data. VLANs are described in the IEEE 802.1Q standard.
Virtual Private Network (VPN). A VPN is an easy, cost-effective and secure way for corporations to provide
telecommuters and mobile professionals local dial-up access to their corporate network or to another Internet
Service Provider (ISP). Secure private connections over the Internet are more cost-effective than dedicated private
lines. VPNs are possible because of technologies and standards such as tunneling, screening, encryption, and
IPSec.
Virtual System. A feature unique to the NetScreen-1000, a Virtual System is a subdivision of the main system that
appears to the user to be a stand-alone entity. Virtual Systems reside separately from each other in the same
NetScreen-1000 device. Each one can be managed by its own Virtual System Administrator.
Windows Internet Naming Service (WINS). WINS is a service for mapping IP addresses to NetBIOS computer
names on Windows NT server-based networks. A WINS server maps a NetBIOS name used in a Windows network
environment to an IP address used on an IP-based network.
1HW6FUHHQ&RQFHSWV ([DPSOHV %,;

$SSHQGL[%*ORVVDU\
1HW6FUHHQ&RQFHSWV ([DPSOHV %;

,QGH[
,QGH[
1XPHULFV tunnel 246 traffic alarm traps 151
3DES 270, 454 viewing 251 types 151
VPN dialup user groups 245 Attacks
$ ACL 7, 14, 242, 278 Address Sweep 68
access control list Address 68 block Java/ActiveX/.zip/.exe component 68
See ACL Address book Denial of Service 67
Access Policies 3, 7, 241 adding addresses 183 filter IP source route 68
ACL 242 editing group entries 188 ICMP flood 70
actions in 246 entries 183 IP spoofing 67
address groups 245 groups 185 Land Attack 68
addresses in 245 modifying addresses 184 Malicious URL 69
alarms 248 removing addresses 188 Ping of Death 67
authenticate 247 address groups 185, 245 Port Scan 67
authentication 204 creating 187 Replay 276
bidirectional VPNs 246, 252, 380 editing 188 SYN flood 67
changing 260 options 186 Tear Drop 68
counting 248 removing entries 188 Trojan horse 68
deny 246 Addresses UDP flood 67
functions of 241, 463 defined 245 WinNuke 68
icons 251 in Access Policies 245 Authentication 247
L2TP 247 Administration failure trap 151
location 254 users 196, 204
CLI (Command Line Interface) 117
management 251 authentication
restricting 130, 131
order 261
WebUI 112 users 104–109
order of 260
Administrative traffic 134 Authentication Header
permit 246
AES (Advanced Encryption Standard) 270 See AH
removing 261
Aggressive Mode 274, 454 Authentication users 198, 199
root system 242
root-level 506 AH 265, 269 AutoKey IKE VPN 137, 271
schedules 249 Alarms 161 management 271
service book 215 clearing 161
service groups 232 E-mail alert 161 %
services in 214, 245 event 161 Bandwidth 249
size restrictions 187 thresholds 248 guaranteed 249, 478
traffic logging 248 traffic 161 managing 478
1HW6FUHHQ&RQFHSWV ([DPSOHV ,

,QGH[
maximum 249 MIP addresses 471 server 94

maximum specification 478 multiple-type users 200 status table 78
unlimited maximum 478 new users 197 Domain name system
Browser requirements 113 service groups 233 See DNS
CRL (Certificate Revocation List) 290, 302
Download
& configuring server settings 297
to file 157
CA (certificate authority) 298 default settings 297
DS Codepoint Marking 486
CA certificates 288, 292 loading 290
Cables DSL 91, 94
serial 120 ' Dynamic IP pools 246
Certificates 272 Data Encryption Standard
CA 288, 292 See DES (
loading 295 Defining Editing
local 292 new user dialup groups 209, 212 address groups 188
requesting 293 subinterface 498 VIP configuration 194
revocation 291, 302 DES 270
E-mail alert notification 149, 163
via e-mail 292 DHCP 56, 61, 93
Encapsulating Security Payload
CLI 117, 136 client 80
See ESP
conventions xix HA 81
save 101 relay agent 80 ESP 265, 269, 270, 454
set HA 519, 520 server 80 Event alarms 161
Client-server protocol 207 Dialup groups
clock 110 creating 209, 212 )
Cold start trap 151 deleting a group 211 Facility 150
Command line interface moving a member 210 FIPS xiii
See CLI removing a member 210 Firewalls xiii, 67, 515
Configuration Diffie-Hellman exchange 275
Function Zone Interfaces 41
browser requirements 113 Diffie-Hellman groups 275
HA Interface 41
Configuration settings DiffServ 250
Management Interface 41
downloading 99 See DS Codepoint Marking
uploading 99 digital signature 286
conventions DIP 59 *
gatekeeper devices 218
CLI xix See also Dynamic IP pools
WebUI xix PAT 465 Graphs, historical 248
Counting 248 Directory server 207 Group
Creating DN (distinguished name) 211 addresses 185
address groups 187 DNS 76 services 232
keys 115 lookup 77 user dialup 209, 212
1HW6FUHHQ&RQFHSWV ([DPSOHV ,,

,QGH[
+ physical 3 /
H.323 protocol 218 subinterface 496 L2TP
HA system 132 Access Policies 247
CLI 519, 520 Tunnel 42, 178 L2TP-only on Windows 2000 441
DHCP 81 Virtual HA 41 operational mode 441
disabling 520 interfaces Users 196, 198, 199
link-up-on-slave 516 tunnel 178 Windows 2000 459
path monitoring 522 Internal database 204 L2TP-over-IPSec 266
redundant groups 515 Internet Key Exchange LDAP 108, 207
secondary path 516 See IKE Lightweight directory access protocol
split-brain 516 IP addresses See LDAP
status LEDs 515 defining for each port 183 Local certificate 292
synchronizing files 516 Manage 132, 515 Logging 248
HA Interface non-routable 190
Logging on 504
Virtual HA Interface 41 system 132
Hash-based message authentication code Virtual System 502
virtual 190
Logs
See HMAC IP Security
High Availability traffic 159
See IPSec
See HA IPSec 265
Historical graphs 248 AH 264
0
MAC address 515
HMAC 269 digital signature 286
Main Mode 274
HTTP 114 ESP 264, 454
Manage IP 132, 515
HTTP packets 69 SAs 264, 272, 273, 275
Hypertext Transfer Protocol SPI 264 Management client IP addresses 130
See HTTP transport mode 266, 441, 454 Management information base II
tunnel 264 See MIB II
, tunnel mode 267 Management interface 134
Icons tunnel negotiation 273 See MGT interface
access policy 251 Management methods
defined 251 - CLI 117
single computer 182 Java/ActiveX blocking 68 Manual Key 317, 379
IEEE 802.1Q VLAN standard 491 management 271
IETF 207 . User 196, 199, 200
IKE 271, 328, 388, 411 Keep Alive 451 VPNs 137
Users 196, 198, 199 keepalive frequency, NAT-T 281 Mapped IP
interface Keys See MIP
MGT creating 115 MD5 269
1HW6FUHHQ&RQFHSWV ([DPSOHV ,,,

,QGH[
Message Digest version 5 NetScreen-Global PRO Pre-Shared Key 271

See MD5 encryption 137 Preshared secret 411
Messages NetScreen-Remote proposals
critical 148 NAT-T option 279 Phase 1 273, 275
debug 148 Network Public key infrastructure
error 148 bandwidth 478 See PKI
info 148 topology 190 Public/private key pair 289
notice 148 Network Address Translation Mode 52
warning 148 4
WebTrends 150 2 QoS xiii, 478
MGT 134 Operating system 117 Quality-of-service
MGT interface 41 See QoS
MIB II 65, 122, 151 3
MIP 468 packet flow 13–14 5
creating addresses 471 Password 504 RADIUS 105, 128, 205
NAT 246 forgetting 128 redundant groups 515
virtual system 493 PAT 465 Remote
MIPs 14 path monitoring 522 computing 205
modulus 275 PC card 99, 101 dialup users 205, 208
Phase 1 273 Remote authentication dial in user service
1 proposals 273, 275 See RADIUS
NAT Phase 2 275 Removing
IPSec and NAT 279 proposals 275 dialup group members 210
NAT servers 279 Ping 155 VIP 195
NAT mode 52–53, 54–57, 190, 493 PKI 288 replay protection 276
interface settings 54 key 115 Reset, scheduled 121
NAT, policy-based 58, 246 policy-based NAT 58, 246 Restricting, administration 130
NAT-T 279 Port Address Translation Route Mode 58, 58–62
enabling 283 See PAT Route mode
keepalive frequency 281 Ports interface settings 59
NAT-Traversal switch 492 policy-based NAT 58
See NAT-T trunk 492 route priority 172
NetInfo 80 ports Route table 171
netmasks 245 port numbers 194 metric statement 172
NetScreen-Global Manager PPPoE 56, 61, 93 static routes 171
encryption 137 defined 93 Tunnel interface 178
1HW6FUHHQ&RQFHSWV ([DPSOHV ,9

,QGH[
routing ScreenOS xiv deleting 236

route exporting 170 updating 101 modifying 234
route redistribution 169 SCS 122 Services 214
route table 171 SCS (Secure Command Shell) 118 defined 245
tunnel interfaces 178 Secure Hash Algorithm-1 in Access Policies 245
See SHA-1 Settings
6 Secure Sockets Layer downloading 99
SAs 272, 273, 275 See SSL importing 99
Scalability 190 SecurID 106, 206 saving 99
SCEP (Simple Certificate Enrollment security association uploading 99
Protocol) 298 See SAs SHA-1 269, 454
Scheduled reset 121 Security facility 150 SMTP server IP 163
Schedules 237, 249 Security Zone Interfaces 40 SNMP 122, 151, 511
Screen Options Physical 40 configuration 153
Address Sweep Attack 68 Subinterface 40 encryption 137, 152
Bad IP Option 69 security zones 2 implementation 152
Filter IP Source Route Option 68 destination zone determination 14 VPN monitoring 154–155
FIN Bit With No ACK Bit 71 global 2 SNMP community
ICMP Flood 70 interfaces 3 private 153
IP Security Option 69 predefined 2 public 153
IP spoofing 67 source zone determination 14 SNMP traps 151
IP Stream Option 70 Server cold start trap 151
IP Strict Source Route Option 70 virtual IP 193 Software
IP Timestamp Option 69 Service book
key 102
Land Attack 68 adding service 216 updating 101
Loose Source Route Option 69 custom service 215 Software, uploading and downloading 101
Malicious Java or ActiveX components 68 custom service (CLI) 216
SSH (Secure Shell) 118
Malicious URL Protection 69 deleting service group 235
SSL 115
Ping of Death 67 modifying entries (CLI) 217
modifying entries (Web UI) 234 SSL Handshake Protocol
Port Scan Attack 67
Record Route Option 69 pre-configured services 215 See SSLHP
SYN Attack 67 removing entries (CLI) 218 SSLHP 115
TCP Packet Without Flag 71 service groups (Web UI) 232 subinterface 496
Tear Drop Attack 68 viewing (CLI) 215 defining 496, 498
UDP Flood 67 Service drop-down list 215 Trusted 491
Unknown Protocol 70 Service groups 232 subinterfaces 4
WinNuke Attack 68 creating 233 Switch port 492
1HW6FUHHQ&RQFHSWV ([DPSOHV 9

,QGH[
syslog traffic alarms 151 USGA

encryption 137, 148 types 151 access policies 3, 7
host 148 Triple DES function zones 37
host name 149 See 3DES global zone 33
host port 149 Trunk port 492 interface, physical 3
messages 148 defined 492 overview 1–14
System manually setting 492 packet flow 13–14
IP address 132, 267, 314, 376 Tunnel interface 42, 178 security zone interfaces 3
parameters 75 Tunnel Interfaces 42 security zones 2, 33, 168
traps 151 security zones, global 2
tunnel mode 267
security zones, predefined 2
Tunnel to Trusted interface 137
7 subinterfaces 4
Tear drop attack 68 tunnel interfaces 427
Telnet 117, 122 8 tunnel zones 34, 425, 427
UDP virtual systems 10–12
TFTP server 99, 101
checksum 281 virtual systems, interfaces 11
Traffic 159
NAT-T encapsulation 279 virtual systems, VRs 12
alarms 161
Universal Security Gateway Architecture virtual systems, zones 11
counting 248
See USGA VPNs 8
flow 159
Update now 157 zones 31–37
log 159
logging 248 URL filtering
logs 159 Blocked URL message type 98 9
priority 249 blocking or permitting all 98 VIP 190
routing 471 Communication timeout 97 configuring 193
shaping xiii, 478 NetScreen blocked URL message 98 editing 194
shaping, automatic 478 Server status 98 removing 195
Transparent Mode 45 Websense server name 97 required information 192
Transparent mode 45–51 Websense server port 97 virtual system 493
transport mode 266, 441, 447, 454 Users VIPs 14
Traps 151 authentication 198, 199, 204 Virtual HA interface 41
100, hardware problems 151 dialup groups 208, 209, 212 Virtual IP
200, firewall problems 151 IKE 196, 198, 199 See VIP
300, software problems 151 L2TP 196, 198, 199 Virtual LAN
400, traffic problems 151 Manual Key 196, 199, 200 See VLAN
500, VPN problems 151 multiple administrative users 123 Virtual private network
allow or deny 152 multiple-type users 200 See VPNs
authentication failure trap 151 new user 197 virtual routers
system alarms 151 profiles 207 See VRs
1HW6FUHHQ&RQFHSWV ([DPSOHV 9,

,QGH[
Virtual system 10–12, 491–509 voice-over IP communication 218 modifying 167

administrators 124 VPNs xiii, 8, 118 route exporting 170
creating 494 Access Policies 246 route redistribution 6, 169
defined 124 Aggressive mode 274 routing tables 6
establishing 493 AutoKey IKE 137, 271
interfaces 11 Diffie-Hellman exchange 275 :
overlapping subnets 497 Diffie-Hellman groups 275 Web browser requirements 113
Transparent mode 492 Main mode 274 Web user interface
VRs 12 Manual Key 137 See WebUI
zones 11 monitoring 163 Websense 97
Virtual System Administrator 491 Phase 1 273 WebTrends 149
changing password 504 Phase 2 275 encryption 137, 149
VLAN 491 policy-based NAT 425 messages 150
communicating with another VLAN 506 replay protection 276 WebUI 135
subinterface 496 SAs 272 conventions xix
tag 492, 497 tunnel interfaces 178, 427
VLAN1 Tunnel to Trusted interface 137 =
Interface 46 tunnel zones 34, 425 zones 31–37
Interfaces 47 virtual systems 493 function 37
Zones 46 VRs 165–179 global 33
VLANs creating 166 security 33
tags 4 deleting 168 tunnel 34, 425, 427
trunking 11 introduction 5–6 VR binding 168
1HW6FUHHQ&RQFHSWV ([DPSOHV 9,,

,QGH[
1HW6FUHHQ&RQFHSWV ([DPSOHV 9,,,

Netscreen Ce VPN

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Netscreen Ce VPN

Uploaded by

Copyright:

Available Formats

1HW6FUHHQ&RQFHSW

1HW6FUHHQ&RQFHSWV ([DPSOHV

&RS\ULJKW1RWLFH Caution: Changes or modifications to this product could void the

1HW6FUHHQ&RQFHSWV ([DPSOHV LL

1HW6FUHHQ&RQFHSWV ([DPSOHV LLL

1HW6FUHHQ&RQFHSWV ([DPSOHV LY

1HW6FUHHQ&RQFHSWV ([DPSOHV Y

,QWHUIDFH6HWWLQJV ([DPSOH1HW6FUHHQ'HYLFHDV'+&3&OLHQW  

1HW6FUHHQ&RQFHSWV ([DPSOHV YL

6HFXUH6KHOO 9LUWXDO3ULYDWH1HWZRUNV 

1HW6FUHHQ&RQFHSWV ([DPSOHV YLL

&KDQJLQJ=RQHWR9LUWXDO5RXWHU%LQGLQJV  6HFXU,' 

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHV *URXS,.(,'  

1HW6FUHHQ&RQFHSWV ([DPSOHV YLLL

&KDSWHU$FFHVV3ROLFLHV  0RGHV  

1HW6FUHHQ&RQFHSWV ([DPSOHV L[

([DPSOH/RDGLQJ&HUWLILFDWHV  %DFNWR%DFN931V

1HW6FUHHQ&RQFHSWV ([DPSOHV [

&KDSWHU3ROLF\%DVHG1$7  ([DPSOH([SRUWLQJD3K\VLFDO,QWHUIDFH

1HW6FUHHQ&RQFHSWV ([DPSOHV [L

QHWVFUHHQ6FKHGXOH 9 $SSHQGL[%*ORVVDU\  ,

1HW6FUHHQ&RQFHSWV ([DPSOHV [LL

1HW6FUHHQ&RQFHSWV ([DPSOHV [LLL

Firewall: Screening traffic

Traffic Shaping: Efficient

1HW6FUHHQ&RQFHSWV ([DPSOHV [LY

1HW6FUHHQ&RQFHSWV ([DPSOHV [Y

1HW6FUHHQ&RQFHSWV ([DPSOHV [YL

1HW6FUHHQ&RQFHSWV ([DPSOHV [YLL

1HW6FUHHQ&RQFHSWV ([DPSOHV [YLLL

1HW6FUHHQ&RQFHSWV ([DPSOHV [L[

1HW6FUHHQ&RQFHSWV ([DPSOHV [[

1HW6FUHHQ&RQFHSWV ([DPSOHV 

A network configured with 5 security Finance

Traffic (indicated by black lines)

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Physical Interface Assignments

1/1 1/2 3/1 3/2

2/1 2/2 4/1 4/2

1HW6FUHHQ&RQFHSWV ([DPSOHV 

1/1 1/2 3/1 3/2

2/1 2/2 4/1 4/2

2/1.1 2/2.1 4/1.1 4/2.1

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Trust-VR Routing Domain VR1 Untrust-VR Routing Domain

Eng DMZ Note: The castle icon represents an

1HW6FUHHQ&RQFHSWV ([DPSOHV 

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Trust-VR Routing Domain Untrust-VR Routing Domain

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Source Zone Policy Tunnel VPN tunnel Destination Zone

1HW6FUHHQ&RQFHSWV ([DPSOHV 

VR1: Untrust Virtual Router

VR2: Trust Virtual Router VPN Tunnel

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Note: The castle icon represents

shared interface for

Untrust subinterface vsys1

1HW6FUHHQ&RQFHSWV ([DPSOHV 

1HW6FUHHQ&RQFHSWV ([DPSOHV 

1HW6FUHHQ&RQFHSWV ([DPSOHV 

Incoming Route Table ACL

If VPN traffic to tunnel

,QWHUIDFH6HWWLQJV ([DPSOH1HW6FUHHQ'HYLFHDV'+&3&OLHQW

6HFXUH6KHOO 9LUWXDO3ULYDWH1HWZRUNV

&KDQJLQJ=RQHWR9LUWXDO5RXWHU%LQGLQJV 6HFXU,'

&KDSWHU%XLOGLQJ%ORFNVIRU$FFHVV3ROLFLHV *URXS,.(,'

&KDSWHU$FFHVV3ROLFLHV 0RGHV

([DPSOH/RDGLQJ&HUWLILFDWHV %DFNWR%DFN931V

&KDSWHU3ROLF\%DVHG1$7 ([DPSOH([SRUWLQJD3K\VLFDO,QWHUIDFH

QHWVFUHHQ6FKHGXOH 9 $SSHQGL[%*ORVVDU\ ,

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

([DPSOH3DUW(QWHUSULVHZLWK6L[=RQHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

([DPSOH3DUW,QWHUIDFHVIRU6L[=RQHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

([DPSOH3DUW(QWHUSULVHZLWK7ZR5RXWLQJ'RPDLQV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

([DPSOH3DUW$FFHVV3ROLFLHVIRUDQ(QWHUSULVHZLWK6L[=RQHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV

1HW6FUHHQ&RQFHSWV ([DPSOHV