O'Reilly logo

ScreenOS Cookbook by Sunil Wadhwa, Joe Kelly, Ken Draper, David Delcourt, Vik Davar, Stefan Brunner

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 1. ScreenOS CLI, Architecture, and Troubleshooting

1.0. Introduction

If you’re a network professional with network OS experience, ScreenOS has a fairly straightforward CLI to get used to. With that being said, it is important to lay the groundwork for how to move around the CLI and understand the troubleshooting capabilities within ScreenOS so that you are prepared to use the information in this book.

Each vendor produces and maintains its own device OS and defines the main keywords used to perform various configuration and information management functions. The keywords in ScreenOS provide the flexibility and structure required to manage the firewall via the CLI. They are:

  • get

  • set/unset

  • save

  • clear

  • exec

  • delete

  • regex support

You can see these upon successful login to the firewall by issuing the “next option” command, better known as ?, at the prompt:

	Login: netscreen
	Password: <netscreen>

	top-ssg140->  ?
	clear clear           dynamic system info
	delete                delete persistent info in flash
	exec                  exec system commands
	exit                  exit command console
	get                   get system information
	mtrace                multicast traceroute from source to destination
	ping                  ping other host
	reset                 reset system
	save                  save command
	set                   configure system parameters
	trace-route           trace route
	unset                 unconfigure system parameters
	top-ssg140->

Unlike some other network OSs, there is a single level of access in ScreenOS, based on the permissions associated with the login credentials. ScreenOS provides the ? as a helper. You can find the same information by pressing the Tab key to either complete a command if it is unique, or provide the user options.

get

Generally, you use the get keyword to show the status or value of some ScreenOS function, such as an interface, log buffer, or routing table. You can filter the output from the get command to provide more concise output and then dump it to the screen (default behavior), or redirect it to a Trivial File Transfer Protocol (TFTP) server and text file for further analysis. Also available is a very rich REGEX filtering function, which we will describe in more detail later in this section.

	top-ssg140-> get ?
	address              show address book
	admin                show admin information
	adsl                 show adsl info
	alarm                show alarm info
	alg                  application layer gateway information
	alg-portnum          get ALG port num
	alias                get alias definitions
	arp                  show ARP entries
	asp                  asp
	attack               show attacks
	auth                 show authentication information
	auth-server          authentication server settings
	chassis              show chassis information
	clock                show system clock
	config               show system configuration
	console              show console parameters
	core-dump            show core dump parameters
	counter              show counters
	di                   get deep inspection parameters
	dialer               get dialer information
	dip                  show all dips in a vsys or root
	dip-in               show incoming dip table info
	--- more ---
	top-ssg140-> get interface e0/0
	Interface ethernet0/0:
	  description ethernet0/0
	  number 0, if_info 0, if_index 0, mode nat
	  link up, phy-link up/full-duplex
	  vsys Root, zone Trust, vr trust-vr
	  dhcp client disabled
	  PPPoE disabled
	  admin mtu 0, operating mtu 1500, default mtu 1500
	  *ip 192.168.1.1/24 mac 0017.cb47.8d00
	  *manage ip 192.168.1.1, mac 0017.cb47.8d00
	  route-deny disable
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	  bandwidth: physical 100000kbps, configured egress [gbw 0kbps mbw
	    0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	             total allocated gbw 0kbps
	  DHCP-Relay disabled at interface level
	  DHCP-server disabled
	Number of SW session: 56063, hw sess err cnt 0
	top-ssg140->

set/unset

The set and unset commands are the primary keywords for effecting change of the firewall configuration. These changes occur in real time and have led many administrators to make a trip to the data center to log in via the console because an IP address or route was misconfigured or accidentally changed.

	top-ssg140-> set interface ethernet0/0 ?
	bandwidth            interface bandwidth
	description          configure interface description
	dhcp                 dhcp server/client/relay setup
	dip                  dynamic ip configuration
	dot1x                enable IEEE802.1X feature
	ext                  extended DIP configuration
	gateway              gateway ip address
	group                group interface into redundant interface
	ip                   set interface ip address
	manage               interface manageability
	manage-ip            interface management ip address
	mip                  mapped ip configuration
	monitor              interface monitoring
	mtu                  set maximum transfer unit
	nat                  private address
	pbr                  Enable interface pbr-policy
	phy                  interface physical feature
	pmtu                 path MTU discovery configuration
	protocol             configure routing protocol parameters
	proxy                enable interface proxy application
	route                public address
	route-deny           deny traffic routing back to this interface
	webauth              webauth for this interface
	webauth-ip           webauth ip for this interface
	zone                 interface zone binding
	top-ssg140->

save

You use the save keyword to manage the configuration stored in flash memory. Any configuration change made via the console or a remote terminal session is not committed to flash memory until save is entered. If you forget this, and you reboot the firewall, those changes are lost.

	top-ssg140-> set interface ethernet0/0 ip 10.100.1.1/24
	top-ssg140-> set interface ethernet0/0 manage-ip 10.100.1.2
	top-ssg140-> get interface | include eth0/0
	eth0/0     10.100.1.1/24       Trust       0017.cb47.8d00    -   U   -
	top-ssg140-> reset
	Configuration modified, save? [y]/n n
	System reset, are you sure? y/[n] y
	In reset ...

	... boot sequence ...

	login: netscreen
	password: <password>
	top-ssg140->
	top-ssg140-> get interface | include eth0/0
	eth0/0     192.168.1.1/24         Trust 0017.cb47.8d00       -   U   -
	top-ssg140->

Notice that ScreenOS provides the administrator an opportunity to bail out of the reset process and save the configuration. Also note that the IP address for ethernet0/0 has reverted back to the ScreenOS default of 192.168.1.1/24.

Another handy capability of save is that it allows you to save your configuration to a TFTP server. For example, you can have an off-box script run occasionally to log in to the device and run this command to back up the configuration:

	top-ssg140->  save config to tftp 10.251.7.113 config.txt
	Read the current config.
	Save configurations (4103 bytes) to config.txt on TFTP server
	    10.251.7.113.
	!!!!!!!!!!!!!!!!!!!!
	tftp transferred records = 9
	tftp success!

	TFTP Succeeded
	top-ssg140->

You can also manage the ScreenOS image via the save keyword. The administrator can save a copy of the image to a TFTP server or from a TFTP server:

	top-ssg140-> save software from flash to tftp 10.251.7.113
	    ssg140.6.0.0r1.0
	Save software to 10.251.7.113 ssg140.6.0.0r1.0
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	...
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	tftp transferred records = 21761
	tftp success!

	TFTP Succeeded
	top-ssg140->

We cover saving the image from a TFTP server later in this chapter, in Recipe 1.1.

clear

You use the clear keyword to erase or purge information from the firewall’s realtime memory, not the onboard flash memory. You can use clear to manage the following:

  • The Address Resolution Protocol (ARP) cache

  • Session table entries

  • Internet Key Exchange (IKE) Security Associations (SAs)

  • IKE cookies

  • Logs

  • Counters

The clear function is particularly useful when troubleshooting problems, as it is very common to be asked to provide Juniper Technical Assistance Center (JTAC) engineers with a current snapshot of information, which requires resetting logs and counters. Another good example is when performing debug or snoop functions. The buffer where the output is stored should be cleared before each run so that maximum buffer space is available, and the troubleshooter knows the information in the buffer is pertinent to the problem at hand.

exec

The exec keyword has a limited but powerful set of options for managing a specific set of functions. The “root” admin is the only account with access to exec functions. Typically, you use the exec command to manually force the device to execute a function that, under normal circumstances, happens automatically. As such, most administrators will rarely use it unless under the direction of JTAC.

	top-ssg140-> exec ?
	admin                 exec ADMIN commands
	alg                   application layer gateway information
	attack-db             perform attack database update or checking
	auth                  user authentication actions
	config                config exec command
	dhcp                  exec dhcp command
	dialer                exec dialer commands
	dns                   refresh all dns entries
	igmp                  IGMP
	ike                   IKE exec commands
	infranet              Infranet Confroller configuration
	interface             Interface configuration
	license-key           set feature configuration
	log                   exec log commands
	nsrp                  exec nsrp commands
	ntp                   exec ntp command
	password              perform password verification
	pki                   PKI exec commands
	policy                policy verify
	pppoa                 maintain pppoa connection
	pppoe                 maintain pppoe connection
	proxy-id              exec proxy id update command
	save                  save command
	script                exec script
	shdsl                 SHDSL pic-mode
	ssh                   exec SSH commands
	syslog                syslog configuration
	usb-device            exec usb command
	vrouter               execute vrouter commands
	top-ssg140->

delete

The delete keyword has a small but effective set of options for managing a specific set of meters mostly regarding information stored in flash memory:

	top-ssg140-> delete
	cluster                 cluster option
	crypto                  delete crypto info
	file                    delete a file
	node_secret             clear SecurID stored node secret
	nsmgmt                  delete nsmgmt private/public keys
	pki                     delete a PKI object
	ssh                     delete SSH
	top-ssg140->

Sometimes it is necessary to delete Secure Shell (SSH) keys or even NetScreen Security Manager (NSM) keys to reestablish communication.

Filtering the Output

ScreenOS provides several ways to filter output. You can use two different keywords after a pipe (|): include and exclude. ScreenOS also supports the POSIX implementation of regular expressions (regexes), although not with every option. Regexes are a powerful way to filter the output of a command to show only what is wanted. It is beyond the scope of this book to fully define how POSIX regexes are implemented, but you can find this information via the Internet or on a Linux station manpage.

This section will cover how to use the different options to make it easier to find information in ScreenOS.

To compare the difference in filtering output, we will examine the routing table. Here is the output for the routes in the trust-vr:

	bottom-ssg140-> get vrouter trust route summary
	trust-vr
	------------------------------------------------------------------
	  Route Source             Networks   Subnets    Supernets
	------------------------------------------------------------------
	 Connected                     0         3          0
	 Host                          0         3          0
	 Static                       95       659          4
	 System Default                0         0          0
	 OSPF                          0         0          0
	  [ OSPF Intra area            0         0          0  ]
	  [ OSPF Inter area            0         0          0  ]
	  [ OSPF External - 1          0         0          0  ]
	  [ OSPF External - 2          0         0          0  ]
	 BGP                           0         0          0
	 RIP                           0         0          0
	 NHRP                          0         0          0
	 Imported                      0         0          0
	 Auto Exported                 0         0          0
	 Auto Discovered               0         0          0

	 Total 764/max entries
	bottom-ssg140->

There are 764 routes, which can take a little while to get through if you’re looking for a specific route or a set of routes. Instead, use the include keyword to find any route in the 159.24.0.0 Class B range:

	bottom-ssg140-> get route | inc 159.24
	*  764  159.24.119.232/32    eth0/2     10.10.10.1   S  20  1  Root
	*  756  159.24.107.242/32    eth0/2     10.10.10.1   S  20  1  Root
	*  390  159.24.200.100/30    eth0/2     10.10.10.1   S  20  1  Root
	*  763  159.24.116.222/32    eth0/2     10.10.10.1   S  20  1 Root
	*  760  159.24.110.217/32    eth0/2     10.10.10.1   S  20  1 Root
	*  387     159.24.76.0/24    eth0/2     10.10.10.1   S  20  1 Root
	*  759  159.24.110.212/30    eth0/2     10.10.10.1   S  20  1 Root
	*  750  159.24.106.169/32    eth0/2     10.10.10.1   S  20  1 Root
	*  749  159.24.106.167/32    eth0/2     10.10.10.1   S  20  1 Root
	*  748  159.24.106.166/32    eth0/2     10.10.10.1   S  20  1 Root
	*  747  159.24.106.162/32    eth0/2     10.10.10.1   S  20  1 Root
	*  762  159.24.116.161/32    eth0/2     10.10.10.1   S  20  1 Root
	*  758  159.24.110.123/32    eth0/2     10.10.10.1   S  20  1 Root
	*  746  159.24.106.122/32    eth0/2     10.10.10.1   S  20  1 Root
	*  755   159.24.107.72/29    eth0/2     10.10.10.1   S  20  1 Root
	*  757   159.24.109.89/32    eth0/2     10.10.10.1   S  20  1 Root
	*  392  159.24.235.212/30    eth0/2     10.10.10.1   S  20  1 Root
	*  389  159.24.181.140/30    eth0/2     10.10.10.1   S  20  1 Root
	*  754  159.24.107.61/32     eth0/2     10.10.10.1   S  20  1 Root
	*  752  159.24.107.48/28     eth0/2     10.10.10.1   S  20  1 Root
	*  753  159.24.107.58/32     eth0/2     10.10.10.1   S  20  1 Root
	*  751  159.24.107.55/32     eth0/2     10.10.10.1   S  20  1 Root
	*  761  159.24.114.46/32     eth0/2     10.10.10.1   S  20  1 Root
	*  391 159.24.217.172/30     eth0/2     10.10.10.1   S  20  1 Root
	*  388    159.24.76.0/26     eth0/2     10.10.10.1   S  20  1 Root
	bottom-ssg140->

You can find the same information using regex commands; however, if you want to see only the /32 routes within the 159.24.0.0 Class B range, regex is the only option:

	bottom-ssg140-> get route | inc "159.24.{1,3}[[:digit:]].{1,3}
	[[:digit:]]\/32"
	*  764  159.24.119.232/32    eth0/2      10.10.10.1   S   20  1  Root
	*  756  159.24.107.242/32    eth0/2      10.10.10.1   S   20  1  Root
	*  763  159.24.116.222/32    eth0/2      10.10.10.1   S   20  1  Root
	*  760  159.24.110.217/32    eth0/2      10.10.10.1   S   20  1  Root
	*  750  159.24.106.169/32    eth0/2      10.10.10.1   S   20  1  Root
	*  749  159.24.106.167/32    eth0/2      10.10.10.1   S   20  1  Root
	*  748  159.24.106.166/32    eth0/2      10.10.10.1   S   20  1  Root
	*  747  159.24.106.162/32    eth0/2      10.10.10.1   S   20  1  Root
	*  762  159.24.116.161/32    eth0/2      10.10.10.1   S   20  1  Root
	*  758  159.24.110.123/32    eth0/2      10.10.10.1   S   20  1  Root
	*  746  159.24.106.122/32    eth0/2      10.10.10.1   S   20  1  Root
	*  757   159.24.109.89/32    eth0/2      10.10.10.1   S   20  1  Root
	*  754   159.24.107.61/32    eth0/2      10.10.10.1   S   20  1  Root
	*  753   159.24.107.58/32    eth0/2      10.10.10.1   S   20  1  Root
	*  751   159.24.107.55/32    eth0/2      10.10.10.1   S   20  1  Root
	*  761   159.24.114.46/32    eth0/2      10.10.10.1   S   20  1  Root
	bottom-ssg140->

The exclude keyword is used more rarely, but a good example of its use is to show the routing table without Host or /32 routes:

	bottom-ssg140-> get route | exclude /32


	IPv4 Dest-Routes for <untrust-vr> (0 entries)
	--------------------------------------------------------------------------------
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	N: NHRP
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2 trailing B: backup route


	IPv4 Dest-Routes for <trust-vr> (764 entries)
	--------------------------------------------------------------------------------
	    ID          IP-Prefix     Interface         Gateway    P  Pref    Mtr   Vsys
	--------------------------------------------------------------------------------
	*    9          0.0.0.0/0        eth0/2      10.10.10.1    S    20      1   Root
	*  668   192.168.151.0/24        eth0/0     10.251.7.97    S    20      1   Root
	*   43       10.11.0.0/16        eth0/0     10.251.7.97    S    20      1   Root
	*  169   137.237.154.0/24        eth0/2      10.10.10.1    S    20      1   Root
	*   10       10.15.0.0/29        eth0/0     10.251.7.97    S    20      1   Root
	*  168   137.237.153.0/24        eth0/2      10.10.10.1    S    20      1   Root

	...

	*  274 152.161.208.164/30        eth0/2      10.10.10.1    S    20      1   Root
	*  374   158.147.188.0/24        eth0/2      10.10.10.1    S    20      1   Root
	Too many matched lines, rest ignored.
	bottom-ssg140->

Filtering can provide many other powerful benefits, such as the ability to filter a large session table. In the following example, we request a session table from the device that includes only IP address 192.168.1.1:

	top-ssg140-> get session | include 192.168.1.1

	if 2(nspflag 801801):192.168.1.100/3703->172.24.18.251/1222,6,
	   000d605ff552,sess token 4,vlan 0,tun 0,vsd 0,route 1
	if 2(nspflag 800601):192.168.1.100/3706->192.168.1.1/23,6,
	   000d605ff552,sess token 4,vlan 0,tun 0,vsd 0,route 1
	if 3(nspflag 0010):192.168.1.100/3706<-192.168.1.1/23,6,000000000000,
	   sess token 8,vlan 0,tun 0,vsd 0,route 0

	top-ssg140->

Tip

You can shorten many of the ScreenOS commands when entering themat the keyboard or in a script, as long as you provide enough characters to make the command unique. For example, get session is the same as get sess.

There are limits to the amount of data that can be filtered; if very large amounts of data must be filtered, it is best to save the data to a text file and use a word processing tool or more traditional *NIX tools.

1.1. ScreenOS Architecture

ScreenOS takes a hierarchical approach with regard to the firewall’s framework configuration. The framework configuration determines how the firewall will communicate on the network fromLayers 1–3, and it consists of routing, security zones, and interfaces.

It is easy to get started with ScreenOS, and the impulse is to immediately put IP addresses on interfaces, add some routes, create Address Book entries, and to start writing policies. However, be careful when dealing with more complex environments. We will address the three key ScreenOS building blocks in the order an administrator should consider them to avoid a lot of rework or, worse, rearchitecting a network design midstream.

Virtual Router

ScreenOS architecture utilizes the Virtual Router (VR), trust-vr, as the parent container and as the first architectural choice to be made when designing ScreenOS into an existing or new network (see Figure 1-1).

The relationship between key elements of ScreenOS
Figure 1-1. The relationship between key elements of ScreenOS

Two VRs are enabled on every platform that runs ScreenOS: trust-vr and untrust-vr:

	bottom-ssg140-> get vrouter
	* indicates default vrouter
	A - AutoExport, R - RIP, N- NHRP, O - OSPF, B - BGP, P - PIM

	   ID Name           Vsys    Owner    Routes    MRoutes     Flags
	    1 untrust-vr     Root    shared     0/max      0/max
	*   2 trust-vr       Root    shared     5/max      0/max

	total 2 vrouters shown and 0 of them defined by user
	bottom-ssg140->

However, trust-vr is the default VR and, therefore, the default container for all the underlying associated zones and interfaces:

	bottom-ssg140-> get vrouter trust-vr
	Routing Table
	---------------------------------------------------------------------
	H: Host C: Connected S: Static A: Auto-Exported
	I: Imported R: RIP P: Permanent D: Auto-Discovered
	N: NHRP
	iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
	E2: OSPF external type 2 trailing B: backup route

	Total 5/max entries

	    ID          IP-Prefix    Interface     Gateway   P Pref Mtr  Vsys
	---------------------------------------------------------------------
	*   1     10.251.7.96/27      eth0/0       0.0.0.0  C    0    0  Root
	*   6      10.100.1.0/24      eth0/2    10.10.10.1  S   20    1  Root
	*   2      10.251.7.99/32     eth0/0       0.0.0.0  H    0    0  Root
	*   4     10.10.10.254/32     eth0/2       0.0.0.0  H    0    0  Root
	*   3       10.10.10.0/24     eth0/2       0.0.0.0  C    0    0  Root
	Interfaces

	---------------------------------------------------------------------
	self, v1-trust, v1-untrust, v1-dmz, l2v, ethernet0/0
	serial1/1, serial1/0, ethernet0/2, ethernet0/1, vlan1, hidden.1
	tunnel

	Auto-exporting:                 Disabled
	Default-vrouter:                Yes
	Shared-vrouter:                 Yes
	nsrp-config-sync:               Yes
	System-Default-route:           Not present
	Advertise-Inactive-Interface:   Disabled
	Source-Based-Routing:           Disabled
	SIBR-Routing:                   Disabled
	SNMP Trap:                      Public
	Ignore-Subnet-Conflict:         Disabled
	ECMP-Routing:                   Disabled
	bottom-ssg140->

You can divide this information into a couple of sections; first, the routing table:

	Total 5/max entries

	   ID          IP-Prefix    Interface    Gateway    P Pref  Mtr  Vsys
	---------------------------------------------------------------------
	*   1     10.251.7.96/27      eth0/0      0.0.0.0   C    0    0  Root
	*   6      10.100.1.0/24      eth0/2   10.10.10.1   S   20    1  Root
	*   2     10.251.7.99/32      eth0/0      0.0.0.0   H    0    0  Root
	*   4    10.10.10.254/32      eth0/2      0.0.0.0   H    0    0  Root
	*   3      10.10.10.0/24      eth0/2      0.0.0.0   C    0    0  Root

Note that ScreenOS creates a /32 Host entry for each directly connected interface, as well as the Network entry. Also, the asterisk (*) at the far left indicates that the route is installed in the Routing Information Base (RIB) and is available and active for use. The ID is the route ID from the RIB, which can be useful when troubleshooting flows, and note that duplicate, equal cost routes are available.

The Interfaces information section provides a visual list so that you can at least verify expected behavior. The interfaces listed here inherit the VR relationship from their zone assignment:

	Interfaces
	---------------------------------------------------------------------
	self, v1-trust, v1-untrust, v1-dmz, l2v, ethernet0/0
	serial1/1, serial1/0, ethernet0/2, ethernet0/1, vlan1, hidden.1
	tunnel

We will discuss routing in more detail in Chapter 4.

Zones

Zones are the foundation of the security architecture within ScreenOS. You can see a simple list of zones by typing get zone at the command prompt:

	bottom-ssg140-> get zone
	Total 14 zones created in vsys Root - 8 are policy configurable.
	Total policy configurable zones for Root is 8.
	--------------------------------------------------------------
	  ID Name           Type    Attr    VR          Default-IF   VSYS
	   0 Null           Null    Shared untrust-vr   hidden       Root
	   1 Untrust        Sec(L3) Shared trust-vr     ethernet0/2  Root
	   2 Trust          Sec(L3)        trust-vr     ethernet0/0  Root
	   3 DMZ            Sec(L3)        trust-vr     ethernet0/1  Root
	   4 Self           Func           trust-vr     self         Root
	   5 MGT            Func           trust-vr     null         Root
	   6 HA             Func           trust-vr     null         Root
	  10 Global         Sec(L3)        trust-vr     null         Root
	  11 V1-Untrust     Sec(L2) Shared trust-vr     v1-untrust   Root
	  12 V1-Trust       Sec(L2) Shared trust-vr     v1-trust     Root
	  13 V1-DMZ         Sec(L2) Shared trust-vr     v1-dmz       Root
	  14 VLAN           Func    Shared trust-vr     vlan1        Root
	  15 V1-Null        Sec(L2) Shared trust-vr     l2v          Root
	  16 Untrust-Tun    Tun            trust-vr     hidden.1     Root
	--------------------------------------------------------------

ScreenOS contains many types of zones, but the two that are most commonly configured and used are the security and functional zones.

Security zone

A security zone (specifically, the Sec(L3) from the preceding output, which is a Layer 3 security zone for firewalls operating in Layer 3 mode) represents a logical area of trust within the firewall. There are differing degrees of trust, represented by creating more zones, and different methods of defining such. Within these areas of trust, Address objects get associated and can then be used to define the security policy within ScreenOS.

Unlike other security operating systems, there is no hierarchy of trust levels when it comes to zones. ScreenOS employs an implicit deny system, and requires the explicit definition of rules to allow communication between hosts in different areas of trust, or zones, and sometimes within the same zone (intra-zone). For example:

	bottom-ssg140-> get zone trust
	Zone name: Trust, id: 2, type: Security(L3), vsys: Root, vrouter:
	   trust-vr
	Intra-zone block: Off, attrib: Non-shared, flag:0x6208
	TCP non SYN send reset: On
	IP/TCP reassembly for ALG on traffic from/to this zone: No
	Asymmetric vpn: Disabled
	Policy Configurable: Yes
	PBR policy: None
	Interfaces bound:1. Designated ifp is ethernet0/0
	interface ethernet0/0(0x3e93844)
	DHCP relay enabled
	bottom-ssg140->

The pertinent details fromthe Trust zone properties shown in the preceding code are as follows:

  • The VR assignment, trust-vr, is where all interfaces associated with the Trust zone will look for routes.

  • The Intra-zoneblock setting dictates whether to allow communication between hosts in the same zone without requiring an explicit rule.

  • The PolicyConfigurable setting indicates whether the trust is policy-configurable (not all are).

  • The Interfaces bound setting indicates whether interfaces are bound to the zone, which is very useful when troubleshooting.

Functional zones

There are several functional zones, and each one performs a specific task within ScreenOS.

The Self zone is used for traffic destined to and generated by the firewall itself. No physical interfaces are associated with, or security policies definable for, this zone. Rather, it is used internally to track this traffic.

The HA (High Availability) zone is where the dedicated HA interfaces on the NS5000 series are placed, and where interfaces to be used for HA on the ISG and SSG systems need to be placed to ensure proper functioning. The interfaces in this zone are not assigned IP addresses because the ScreenOS NetScreen Redundancy Protocol (NSRP) is a Layer 2 protocol.

The MGT zone is for dedicated interfaces to manage the firewall. This is the only functional zone where the interface associated with it can be assigned an IP address. However, traffic cannot pass through this zone to other zones. Details for the MGT zone are as follows:

	bottom-ssg140-> get zone mgt
	Zone name: MGT, id: 5, type: Function, vsys: Root, vrouter:trust-vr
	Intra-zone block: On, attrib: Non-shared, flag:0x00a4
	TCP non SYN send reset: On
	IP/TCP reassembly for ALG on traffic from/to this zone: No
	Policy Configurable: No
	PBR policy: None
	Interfaces bound:0.
	DHCP relay enabled
	bottom-ssg140->

Note that in the preceding code, the MGT zone is not policy-configurable and that intra-zone blocking is enabled, which means that if there are many interfaces in this zone, the firewall will not allow communication between them. This zone tends to cause the most problems, as we will discuss in Recipe 2.3.

Interfaces

We’re discussing interfaces last because they are the final building blocks in this structured relationship of VR →Security Zone →Interface. There are many types of ScreenOS interfaces, and some will be discussed in more detail throughout the book. Here is a list of the default interfaces:

	bottom-ssg140-> get interface

	A - Active, I - Inactive, U - Up, D - Down, R - Ready

	Interfaces in vsys Root:
	Name        IP Address      Zone      MAC            VLAN State VSD
	eth0/0      10.251.7.99/27  Trust     0017.cb47.9400    -   U   -
	eth0/1      0.0.0.0/0       DMZ       0017.cb47.9405    -   D   -
	eth0/2      10.10.10.254/24 Untrust   0017.cb47.9406    -   U   -
	eth0/3      0.0.0.0/0       Null      0017.cb47.9407    -   D   -
	eth0/4      0.0.0.0/0       Null      0017.cb47.9408    -   D   -
	eth0/5      0.0.0.0/0       Null      0017.cb47.9409    -   D   -
	eth0/6      0.0.0.0/0       Null      0017.cb47.940a    -   D   -
	eth0/7      0.0.0.0/0       Null      0017.cb47.940b    -   D   -
	eth0/8      0.0.0.0/0       Null      0017.cb47.940c    -   D   -
	eth0/9      0.0.0.0/0       Null      0017.cb47.940d    -   D   -
	bgroup0/0   0.0.0.0/0       Null      0017.cb47.940e    -   D   -
	bgroup0/1   0.0.0.0/0       Null      0017.cb47.9415    -   D   -
	bgroup0/2   0.0.0.0/0       Null      0017.cb47.9416    -   D   -
	serial1/0   0.0.0.0/0       Untrust   N/A               -   D   -
	serial1/1   0.0.0.0/0       Untrust   N/A               -   D   -
	vlan1       0.0.0.0/0       VLAN      0017.cb47.940f    1   D   -
	null        0.0.0.0/0       Null      N/A               -   U   0
	bottom-ssg140->

Other interface types that must be manually configured are not listed here. These are generally considered "logical” interfaces, and they include:

  • Redundant

  • Aggregate

  • Bridge Group

  • VLAN

  • Loopback

  • Tunnel

Let’s start simply with a physical interface. An example of how the ScreenOS structure dictates configuration is the fact that an IP address cannot be configured if the interface is not associated with a zone:

	bottom-ssg140-> set interface e0/4 ip 10.20.20.1/28
	                                   ^-----unknown keyword ip
	bottom-ssg140-> set int e0/4 zone trust
	bottom-ssg140-> set int e0/4 ip 10.20.20.1/28
	bottom-ssg140->

A new feature in ScreenOS 6.0 is the ability to add a description to the interface to allow you to correlate information regarding how the interface is being utilized. This is a very useful function, especially in wide area network (WAN) environments when it is common to identify remote peers, provider, and other information to help in troubleshooting and fault analysis. You can use up to 31 characters in your interface description; if there are spaces in your description, you must bound your text with double quotation marks:

	bottom-ssg140->
	bottom-ssg140-> set interface e0/3 description "Local LAN -
	    Portsmouth, New Hampshire"
	Interface description "Local LAN - Portsmouth, New Hampshire" is
	    longer than 31 characters
	bottom-ssg140-> set interface e0/3 description "Local LAN -
	    Portsmouth, NH"
	bottom-ssg140->

Using ethernet0/0, eth0/0, as an example, the following output displays the currently assigned IP address, zone association (remember, this dictates which VR to use to find/manage routes), Layer 2 Media Access Control (MAC) address, virtual local area network (VLAN), status, and what virtual security device (VSD) it is associated to if High Availability (HA) is configured:

	bottom-ssg140-> get interface e0/0
	Interface ethernet0/0:
	  description Local LAN - Portsmouth, NH
	  number 0, if_info 0, if_index 0, mode nat
	  link up, phy-link up/full-duplex
	  vsys Root, zone Trust, vr trust-vr
	  dhcp client disabled
	  PPPoE disabled
	  admin mtu 0, operating mtu 1500, default mtu 1500
	  *ip 10.251.7.99/27 mac 0017.cb47.9400
	  *manage ip 10.251.7.99, mac 0017.cb47.9400
	  route-deny disable
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	  bandwidth: physical 100000kbps, configured egress [gbw 0kbps mbw
	    0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	             total allocated gbw 0kbps
	    DHCP-Relay disabled at interface level
	    DHCP-server disabled
	Number of SW session: 56062, hw sess err cnt 0
	bottom-ssg140->

This output illustrates a few key points that dictate how ScreenOS behaves and responds. For example, mode nat is a key setting because it determines how packets traverse the firewall. It is the default setting for interfaces assigned to the Trust zone, and any packet originating from the Trust zone to the Untrust zone will be translated to the interface IP of the outbound interface. This is great for small office/home office use, but it is generally not desirable for data center or enterprise deployment when Network Address Translation (NAT) needs to be tightly administered. You can change it to mode route easily, as shown here, but it is just as easy to overlook it:

	bottom-ssg140-> get interface e0/0 | include mode
	  number 0, if_info 0, if_index 0, mode nat
	bottom-ssg140-> set interface e0/0 route
	bottom-ssg140-> get interface e0/0 | include mode
	  number 0, if_info 0, if_index 0, mode route
	bottom-ssg140->

Tip

All other interfaces default to mode route, and the behavior of mode nat on the interface(s) in the Trust zone is different depending on the out-bound interface zone mapping. The best practice is for all interfaces to be in mode route to ensure consistent, predictable behavior and to perform NAT functions in the security policy.

When an IP address is assigned to an interface, ScreenOS defines the interface manage-ip to be the same address. This is verified in the interface detail output with an asterisk (*) next to the interface IP. You can change this setting to a different IP address, but it must be on the same network as the interface IP:

	bottom-ssg140-> get interface e0/0 | include manage
	  *manage ip 10.251.7.99, mac 0017.cb47.9400
	bottom-ssg140-> set interface e0/0 manage-ip 10.251.7.100
	bottom-ssg140-> get interface e0/0 | include manage
	  manage ip 10.251.7.100, mac 0017.cb47.9400
	bottom-ssg140->

Redundant

The redundant interface allows you to logically group physical interfaces to create Layer 1 resiliency. The physical interfaces must be in the same broadcast domain, but they can be connected to two different switches. Only one interface is active at any given time, and this is controlled by the primary option. Redundant interfaces are supported across the Juniper firewall product line.

	bottom-ssg140-> unset interface ethernet0/0 ip
	bottom-ssg140-> set interface red1 zone trust
	bottom-ssg140-> set int ethernet0/0 group red1
	redundant1 interface change physical state to Up
	bottom-ssg140-> set int ethernet0/1 group red1
	bottom-ssg140-> set interface red1 primary ethernet0/0
	bottom-ssg140-> set interface red1 ip 10.251.7.99/27
	bottom-ssg140-> get interface red1
	Interface redundant1:
	  description redundant1
	  number 64, if_info 64512, if_index 0, mode nat
	  link up, phy-link up/full-duplex
	  Redundant port has 2 members: ethernet0/1; ethernet0/0;
	  Active primary interface: ethernet0/0
	  Configured primary interface: ethernet0/0
	  vsys Root, zone Trust, vr trust-vr
	  dhcp client disabled
	  *ip 10.251.7.99/27 mac 0017.cb30.9705
	  *manage ip 10.251.7.99, mac 0017.cb30.9705
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	Number of SW session: 48063, hw sess err cnt 0
	bottom-ssg140->

The naming convention is very strict; you must use red and then an integer number as the name, or you will get a syntax error. Note that the same controls are in place in terms of IP addressing, zone assignment, and so on (as just discussed); the fundamental difference is that you apply these configurations to the logical interface now instead of to the underlying physical interfaces.

The expected failover trigger is a loss of the physical link that will then force ScreenOS to switch over to the other physical link in the redundant group:

	bottom-ssg140-> ethernet0/0 interface change physical state to Down
	redundant1 interface change physical state to Up

	bottom-ssg140-> get interface red1
	Interface redundant1:
	  description redundant1
	  number 64, if_info 64512, if_index 0, mode nat
	  link up, phy-link up/full-duplex
	  Redundant port has 2 members: ethernet0/1; ethernet0/0;
	  Active primary interface: ethernet0/1
	  Configured primary interface: ethernet0/0
	  vsys Root, zone Trust, vr trust-vr
	  dhcp client disabled
	  *ip 10.251.7.99/27 mac 0017.cb30.9705
	  *manage ip 10.251.7.99, mac 0017.cb30.9705
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	Number of SW session: 48063, hw sess err cnt 0
	bottom-ssg140->

This failure will not cause an NSRP failover unless the physical interface ethernet0/0 was being monitored instead of the redundant interface.

Aggregate

The aggregate interface allows you to logically group physical interfaces to increase bandwidth and create Layer 1 resiliency. Aggregate interfaces are supported on the ISG1000/2000 and NS5200/5400 Juniper firewalls. For example, configuring a twoport aggregate interface to a Cisco 6500 would look like this:

	isg1000-> set interface ethernet1/1 aggregate aggregate1
	isg1000-> set interface ethernet1/2 aggregate aggregate1
	isg1000-> set interface agg1 zone trust
	isg1000-> set interface aggregate1 ip 192.168.4.1/26
	isg1000-> set interface aggregate1 route
	isg1000-> get interface agg1
	Interface aggregate1:
	  description aggregate1
	  number 64, if_info 64512, if_index 0, mode nat
	  link up, phy-link up/full-duplex
	  Aggregate port has 2 members: ethernet1/1; ethernet1/2
	  vsys Root, zone Trust, vr trust-vr
	  dhcp client disabled
	  *ip 192.168.4.1/26 mac 0017.cb30.2101
	  *manage ip 192.168.4.1, mac 0017.cb30.2101
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	  bandwidth: physical 2000000kbps, configured egress [gbw 0kbps mbw
	    0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	             total allocated gbw 0kbps
	Number of SW session: 1000063, hw sess err cnt 0
	isg-1000->

Here’s how it would look on the Cisco side:

	Router# configure terminal
	Router(config)# interface port-channel 1
	Router(config-if)# ip address 192.168.4.5 255.255.255.0
	Router(config-if)# end
	Router(config)# interface range gigethernet 5/6-7
	Router(config-if)# channel-group 1 mode on
	Router(config-if)#end

The naming convention for aggregate interfaces is also very strict; you must use agg and then an integer number as the name, or you will get a syntax error. As with redundant interfaces, the same controls are in place in terms of IP addressing, zone assignment, and such.

Note that there is no aggregation protocol configuration; ScreenOS does not support 802.3ad or any other LACP negotiation protocol. This means you will need to configure the ancillary network device, typically a standalone or chassis-based switch, to group their physical ports statically and disable any LACP protocol. Most switch vendors will support this configuration, and Juniper has tested it with Cisco, Foundry, and Riverstone.

The load-sharing algorithm within ScreenOS is round-robin on a per-packet basis. This has caused out-of-order packets on rare occasions, and most applications are written to account for this through retransmission at the Transport layer. You can configure the other device load-sharing algorithmin any way you want. If one of the physical interfaces fails in the Aggregate group, the bandwidth is reduced, and the number of ports to round-robin the packets will be as well, but the Aggregate port will not fail and trigger an NSRP failure. We cover this in more detail in Recipe 18.4.

Tip

The NS5000 family has two Secure Port Module (SPM) options: an eight-port GE card and a two-port 10GE card. The 10GE cards do not support aggregate port grouping. A maximum of four GE interfaces or eight FE interfaces can be grouped into an aggregate.

There are limits as to which physical ports can be grouped together. The eight-port GE SPM in the NS5000 has two ASICs for forwarding; the first ASIC supports physical ports 1–4 and the second ASIC supports physical ports 5–8. An aggregate port group cannot span the ASIC boundary, and in this case, that means the group cannot span across the ASIC port definition or, in an NS5400, the slot boundary to another SPM, even if it is of the same type. On the ISG family, there is a single ASIC across the entire firewall, so there is no limitation to port combination other than the fact that there is a maximum of four GE interfaces per aggregate grouping, and it is a best practice that they should be at the same negotiated bandwidth.

Bridge Groups

Bridge Groups are new to ScreenOS starting with version 6.0. on the SSG firewall family. These represent a logical Layer 2 switch within the firewall. You can configure any port on an SSG5/20 into a Bridge Group; on the SSG140/300/500 family, only ports added via Universal Port Interface Modules, uPIMs, can be in a Bridge Group and the group cannot span uPIM modules. This is documented on the Juniper Support Site Knowledge Base within KB article number 10747, located at http://kb.juniper.net/KB10747.

	bottom-ssg140-> set interface ethernet1/0 zone null
	bottom-ssg140-> set interface ehternet1/1 zone null
	bottom-ssg140-> set interface bgroup 1 1
	bottom-ssg140-> set interface bgroup1 port ethernet1/0
	bottom-ssg140-> set interface bgroup1 port ethernet1/1
	bottom-ssg140-> set interface bgroup1 zone untrust
	bottom-ssg140-> set interface bgroup1 ip 64.100.7.1/29
	bottom-ssg140-> get interface bgroup1
	Interface bgroup1:
	  description bgroup1
	  number 9, if_info 792, if_index 0, mode route
	  link up, phy-link up/full-duplex
	  vsys Root, zone Untrust, vr trust-vr
	  dhcp client disabled
	  PPPoE disabled
	  admin mtu 0, operating mtu 1500, default mtu 1500
	  *ip 64.100.7.1/29 mac 001b.c046.0909
	  *manage ip 64.100.7.1, mac 001b.c046.0909
	  route-deny disable
	  pmtu-v4 disabled
	  ping disabled, telnet disabled, SSH disabled, SNMP disabled
	  web disabled, ident-reset disabled, SSL disabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured	
	  NHRP disabled
	  bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	             total allocated gbw 0kbps
	  DHCP-Relay disabled at interface level
	  DHCP-server enabled, status on.
	Number of SW session: 48063, hw sess err cnt 0

	  Physical port information:
	    ethernet1/0 is up, full duplex, speed is 100mbps
	    ethernet1/1 is up, full duplex, speed is 100mbps
	bottom-ssg140->

The naming convention for a Bridge Group is also specific. You must use bgroup and then an integer number as the name or you will get a syntax error. As with previous logical interfaces, the same controls are in place in terms of IP addressing, zone assignment, and such.

Bridge Groups are best used when more than a single physical port is required for connectivity, and only a single IP address is needed or available to define the Layer 3 boundary. An example is a small office where three desktops and a printer are connecting to the Internet. Instead of investing in a switch for connectivity, placing all four ports into a Bridge Group on the SSG firewall with a single Layer 3 IP address reduces operational complexity, removes a single point of failure (the switch), and lowers the cost of the remote office implementation.

Loopback

The loopback interface is a container group that has a couple of primary uses. The first is in a dynamic routing configuration where it would be assigned an IP address that will be used as the Router-ID. Since the loopback interface is always up, the Router-ID remains constant, which makes troubleshooting and configuration more predictable. Another use is in complex NAT configurations. Interfaces in the same security zone can be associated to a loopback-group interface and then that interface can be assigned an IP address and associated NAT definitions to be shared across the underlying interfaces.

Here is an example of creating a loopback-group and associating the underlying interfaces which would be the beginning steps of a NAT configuration:

	bottom-ssg140->
	bottom-ssg140-> set int e0/0 ip 12.18.100.1/29
	bottom-ssg140-> set int e0/1 ip 12.18.101.1/29
	bottom-ssg140-> set interface e0/1 loopback-group loop.1 zone Untrust
	bottom-ssg140-> set int loop.1 ip 12.18.101.5/29
	loopback.1 ip change pre-checking failed.
	Interface: Illegal overlapping subnet
	bottom-ssg140-> set int loop.1 ip 12.18.103.33/27
	bottom-ssg140-> et interface loop.1 description "Outbound dynamic
	    NAT Pool"
	bottom-ssg140-> get int loop.1
	Interface loopback.1:
	  description Outbound dynamic NAT Pool
	  number 126, if_info 127016, if_index 1, mode route
	  link up
	  Loopback interface has 2 members:
	  ethernet0/0; ethernet0/1
	  vsys Root, zone Untrust, vr trust-vr
	  admin mtu 1500, operating mtu 1500, default mtu 1500
	  *ip 12.18.103.33/27
	  *manage ip 12.18.103.33
	  pmtu-v4 disabled
	  ping disabled, telnet disabled, SSH disabled, SNMP disabled
	  web disabled, ident-reset disabled, SSL disabled

	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	Number of SW session: 48063, hw sess err cnt 0
	bottom-ssg140->

From here, you would go in and create your NAT definitions and then your security policies. Note that the loopback interface definition has some restrictions; it must be in the same security zone as the interfaces associated to it and it cannot be in the same IP address range of any of the associated interfaces. The naming convention for a loopback group is also specific; you must use loop and then an integer number as the name or you will get a syntax error.

Loopback groups seem quite similar to Bridge Groups, but they differ in that each interface associated to a loopback must already have a unique IP address assigned and routing is required to get between those interfaces, whereas the Bridge Group is really like a small logical switch with a unique IP address assigned to the Bridge Group interface.

VLAN

A VLAN interface is a logical subinterface that can be assigned to a physical, a redundant, or an aggregate interface or to a Bridge Group. This is based on the IEEE 802.1q standard, and each ScreenOS platform will have a limitation as to the number of VLANs that can be defined; that limitation will directly correlate to the VLAN subinterface index that can be assigned to any given port. However, ScreenOS does support an 802.1q VLAN tag value in the range of 1–4094, as defined in the standard.

	bottom-ssg140-> set int red1.150
	Interface redundant1 index 150, should be <0 - 100>
	bottom-ssg140-> set int red1.80
	bottom-ssg140-> set int red1.80 tag 4091 zone trust
	bottom-ssg140-> set interface red1.80 ip 172.31.55.129/25
	bottom-ssg140-> get interface red1.80
	Interface redundant1.80:
	  description redundant1.80
	  number 64, if_info 65152, if_index 80, VLAN tag 4091, mode nat
	  link up, phy-link up/full-duplex
	  Redundant port has 2 members: ethernet0/1; ethernet0/0;
	  Active primary interface: ethernet0/1
	  Configured primary interface: ethernet0/0
	  vsys Root, zone Trust, vr trust-vr
	  *ip 172.31.55.129/25 mac 0017.cb30.9705
	  *manage ip 172.31.55.129, mac 0017.cb30.9705
	  route-deny disable
	  pmtu-v4 disabled
	  ping enabled, telnet enabled, SSH enabled, SNMP enabled
	  web enabled, ident-reset disabled, SSL enabled
	  DNS Proxy disabled, webauth disabled, webauth-ip 0.0.0.0
	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
	    disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	  DHCP-Relay disabled at interface level
	  DHCP-server disabled
	Number of SW session: 48063, hw sess err cnt 0
	bottom-ssg140->

This is a well-proven function, supported on all platforms, and there are no known limitations with other vendor products on the market.

Tunnel

A tunnel interface is used for route-based virtual private networks (VPNs). The concept here is to create a subinterface that will bind to a security zone for the purpose of defining the security policy boundary. Tunnel interfaces differ from other logical interfaces and subinterfaces in that they do get assigned to a physical (or logical) interface until the IKE gateway is defined. Tunnel interfaces by default do not get assigned IP addresses either, unless there is a requirement to NAT traffic within the IP Security (IPSec) VPN tunnel.

	bottom-ssg140-> set zone name vpn
	bottom-ssg140-> set interface tun.1 zone vpn
	bottom-ssg140-> set ike gate vpn2corp address 12.1.100.5 outgoing-
	    interface red1 preshare jun1p3rr0x sec-level standard
	bottom-ssg140-> get interface tun.1
	Interface tunnel.1:
	  description tunnel.1
	  number 20, if_info 20168, if_index 1, mode route
	  link down
	  vsys Root, zone vpn, vr trust-vr
	  admin mtu 1500, operating mtu 1500, default mtu 1500
	  *ip 0.0.0.0/0
	  *manage ip 0.0.0.0
	  pmtu-v4 disabled
	  ping disabled, telnet disabled, SSH disabled, SNMP disabled
	  web disabled, ident-reset disabled, SSL disabled

	  OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace disabled
	  PIM: not configured IGMP not configured
	  NHRP disabled
	  bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	             total allocated gbw 0kbps
	Number of SW session: 48063, hw sess err cnt 0
	bottom-ssg140->

We discuss IPSec route-based VPNs and the various iterations in detail in Chapter 10.

Summary

Current ScreenOS platforms are very flexible and provide you with a multitude of configuration knobs to turn to provide resiliency, added bandwidth, and connectivity. It is very common to use many of these interface types together to create complex customer configurations.

One last point to note about interfaces is that unlike other security devices, no rules need to be created to permit or deny management access to ScreenOS. This is handled on a per-interface basis, be it physical or logical. Each interface is capable of supporting several access protocols, including SSH, Telnet, HTTP, and HTTPS, as well as management protocols such as PING and SNMP. The specific interface default settings depend on the zone to which they are associated. The Trust zone defaults with all protocols enabled, whereas with the Untrust zone they are all disabled. You can override each setting via the CLI, which we will cover in more detail in Recipe 2.4.

1.2. Troubleshoot ScreenOS

ScreenOS features a rich set of troubleshooting functions that can provide the administrator with a daunting amount of detailed information. Let’s cover a subset of the more useful ones and provide insight into how to fine-tune them to be even more useful. Mainly, the troubleshooting functions are:

  • Debug

  • Flow filter

  • Debug buffer

  • Snoop

Although these four functions can provide vast capabilities, note that your experience will differ depending on your platform. For example, on the high-end ASIC-based platforms (the NS5000 and NS-ISG1000/2000), only the packets that are sent to the MGT card/process can be seen with these tools. The ASIC forwards all other packets, and therefore, you cannot view themusing these tools. Generally speaking, this should not be an issue, as problems usually occur during session setup; however, occasionally the entire flow is needed, at which point an external analyzer may be required. Figure 1-2 illustrates how a packet makes its way through the ScreenOS software.

The debug and snoop functions will setely provide very detailed information that the administrator can use while troubleshooting issues. When used together, these functions can illustrate an entire data flow, starting with what the packet looks like entering the firewall, how ScreenOS processes the packet through the firewall, and finally, what the packet looks like when leaving the firewall.

Debug

The debug tool bag is very deep, and it is one of the most useful troubleshooting functions within ScreenOS because it will show you what ScreenOS is doing with the packet as it makes its way through the different ScreenOS processes and functions (shown in Figure 1-2). For example:

	top-ssg140-> debug ?
	admin                debug admin
	adsl                 adsl debugging
	anti-spam            anti-spam debugging
Packet flow in ScreenOS
Figure 1-2. Packet flow in ScreenOS
	apppry                 Application Proxy debugging
	arp                    arp debugging
	asp                    ASP debugging
	asset-recovery         asset recovery debugging
	auth                   user authentication debugging
	autocfg                Auto config debugging
	av                     anti virus scan debugging
	bgp                    bgp debugging
	bgroup                 bgroup debugging
	cav                    cavium debugging
	cluster                command propagated to cluster members
	cpu-limit              CPU limit debugging
	dhcp                   debug dhcp
	dhcp6                  dhcpv6 debugging
	dialer                 dialer debugging
	dip                    dip debugging
	dlog                   dlog debugging
	dns                    dns debugging
	dot1x                  IEEE802.1X debug
	driver                 driver debugging
	emweb                  EmWeb debugging
	filesys                Filesys debugging
	fips                   fips debugging
	flash                  flash operating debugging
	flow                   Flow level debugging
	flow-tunnel            Flow Tunnel debugging
	fr                     Frame-Relay debugging
	fs                     file system debugging
	gc                     gc receive and transmit debug
	gdb                    GDB debugging
	global-pro             global-pro debugging
	gt                     generic tunnel debugging
	gtmac                  gtmac debug
	h323                   h323 debugging
	hdlc                   HDLC debugging
	httpfx                 http-fx debugging
	icap                   ICAP debugging
	icmp                   icmp debugging
	idp                    set idp debug parameters
	ids                    ids debugging
	igmp                   igmp debugging
	ike                    ike debugging
	interface              interface debugging
	intfe                  Intfe debugging
	ip                     ip debugging
	ipacx                  isdn ipacx driver debugging
	ipv6                   ipv6 debugging
	isdn                   isdn debugging
	ixf                    ixf debug
	ixp23xxdrv             ixp23xx driver debugging
	l2tp                   L2TP debugging
	lance                  Lance debugging
	ldap                   ldap debug menu
	logging                logging debugging
	memory                 Memory debugging
	mgcp                   mgcp debugging
	midwayipacx            isdn ipacx driver debugging
	mip                    mip debugging
	ml                     Multilink debugging
	modem                  Moden debugging
	nas                    nas debugging
	nasa                   nasa debugging
	nat                    nat debugging
	ndp                    ndp debugging
	netif                  netif debugging
	nhrp                   nhrp debugging
	npak                   npak debugging
	nrtp                   Reliable Xfer Protocol debugging
	nsgp                   debug nsgp
	nsmgmt                 debug nsmgmt
	nsp                    NSM NSP message content
	nsrd                   NSRD debugging
	nsrp                   debug nsrp
	obj-id                 obj id debugging
	ospf                   ospf debugging
	pbr                    policy-based routing debugging
	pccard                 Pccard debugging
	pim                    pim debugging
	pki                    pki debug menu
	pluto                  Pluto debugging
	policy                 policy debugging
	portnum                portnum debugging
	ppcdrv                 driver debugging
	ppp                    ppp debugging
	pppoa                  pppoa debugging
	pppoe                  pppoe debugging
	proxy                  tcp proxy debugging
	rd                     rd debug info
	registry               system events registry debugging
	report                 report debugging
	rip                    rip debugging
	ripng                  ripng debugging
	rm                     rm debugging
	rms                    rms debug info
	rpc                    rpc debugging
	rs                     rs debug info
	rtsync                 route-synchronization debugging
	sa-mon                 sa monitor debugging
	sccp                   sccp debugging
	script                 script debugging
	sctp                   gprs sctp debugging
	sendmail               sendmail debugging
	session                session debugging
	shaper                 debug shaper
	shdsl                  G.SHDSL debug
	sip                    sip debugging
	snmp                   snmpnew debugging
	socket                 socket debug
	ssh                    debug ssh
	ssl                    ssl debugging
	stflow                 saturn flow debug info
	sw-key                 software key debugging
	syslog                 syslog debugging
	tag                    tag info
	task                   Task debugging
	tcp                    tcp debug
	telnet                 debug telnet	
	time                   device clock time debugging
	timer                  Timer debugging
	trackip                debug trackip
	traffic                traffic control debugging
	udp                    udp debugging
	uf                     UF debugging
	url-blk                url filtering debugging
	usb                    usb debugging
	user                   user/group database debugging
	vip                    vip debugging
	vr                     virtual router debugging
	vrrp                   vrrp debugging
	vsys                   vsys debugging
	vwire                  VWIRE debugging
	web                    WebUI debugging
	webtrends              webtrends debugging
	wlan                   wlan debugging
	zone                   zone debugging
	top-ssg140->

You can debug just about any function, and the amount of information can be stag-gering, so be careful what you ask for. Although it is beyond the scope of this book to detail each debug function, each chapter and recipe in this book may utilize debug to some extent. The most commonly used debug function is debug flow. Here are the specific flow options:

	top-ssg140-> debug flow
	all                  all flow debug
	basic                basic debug
	drop                 drop pak debug
	dynpol               dynamic policy search debug
	illegal              illegal debug
	internal             internal debug
	mcast                flow multicast debug
	mgt                  mgt debug
	mpak                 mp pak message debug
	mpdiff               mp diff message debug
	mperr                mp message error debug
	mpgate               mp gate message debug
	mpmvpn               mng over vpn message debug
	mpsess               mp session message debug
	mpvpn                mp vpn message debug
	pak-poll             packet polling debug
	profiling            flow profiling
	self                 self debug
	session              session debug
	sm-skip              No pak passing to SM
	spinlock             spinlock
	tcp-sequence-check   tcp sequence check debug
	tiny-tcp             tiny tcp debug
	vlan                 vlan debug

Warning

Debug functions are very CPU-intensive, and best practice dictates that you enable them only when you require active data capture.

You can verify whether debug is currently enabled with get debug. You can disable debug by either pressing the Esc key or entering an undebug command:

	top-ssg140-> get debug
	flow: basic
	top-ssg140-> <Esc> All debug off

	top-ssg140-> get debug
	top-ssg140->
	top-ssg140-> debug flow basic
	top-ssg140-> get debug
	flow: basic
	top-ssg140-> undebug flow
	top-ssg140-> get debug
	top-ssg140->

Flow Filter

Although debug is intended to capture detailed information, rarely is a single flow going through the firewall at any given time. Therefore, it is important to be able to restrict the information gathered by debug to ensure that the buffer or CPU is not overloaded, or that other extraneous data is not captured as well, thus confusing the data we need. This is where flow filters come into play:

	top-ssg140-> set ffilter ?
	<return>
	dst-ip               flow filter dst ip
	dst-port             flow filter dst port
	ip-proto             flow filter ip proto
	src-ip               flow filter src ip
	src-port             flow filter src port
	top-ssg140->

Flow filters can be simple or complex. They can also be constructed with “or” or “and” logic. Flow-filter options specified in the same command (on the same line) will be “ANDed” together, which means that all the filters specified need to be matched to qualify. For example, if the data required was for a single flow and the source and destination addresses as well as the destination port are known, a flow filter such as the following would be constructed:

	bottom-ssg140-> set ffilter src-ip 10.251.7.113 dst-ip 10.10.10.1
	    ip-proto 1
	filter added
	bottom-ssg140-> get ffilter
	Flow filter based on:
	id:0 src ip 10.251.7.113 dst ip 10.10.10.1 ip proto 1
	bottom-ssg140->

This flow filter will capture all traffic sourced only from10.251.7.113, and destined to 10.10.10.1 and IP protocol 1, the Internet Control Message Protocol (ICMP).

Flow-filter options specified on separate lines are “ORed” together, which means that a match of any of the filters specified will qualify. For example, if some portion of the flow is unknown, or if all data to a specific host on a variety of ports is to be captured, the following would be constructed:

	bottom-ssg140-> set ffilter dst-ip 10.10.10.1 ip-proto 6 dst-port 22
	filter added
	bottom-ssg140-> set ffilter dst-ip 10.10.10.1 ip-proto 6 dst-port 23
	filter added
	bottom-ssg140-> get ffilter
	Flow filter based on:
	id:0 src ip 10.251.7.113 dst ip 10.10.10.1 ip proto 1
	id:1 dst ip 10.10.10.1 ip proto 6 dst port 22
	id:2 dst ip 10.10.10.1 ip proto 6 dst port 23
	bottom-ssg140->

This set of flow filters will capture the data as described earlier; or traffic sourced from any host and destined to 10.10.10.1 and IP protocol 6, TCP, and destination port 22, SSH; or traffic sourced from any host and destined to 10.10.10.1 and IP protocol 6, TCP, and destination port 23, Telnet.

Often it is desired to capture data to (dst) or from(src) a particular host. You can do this on two sete lines:

	bottom-ssg140-> set ffilter dst-ip 10.251.7.97
	filter added
	bottom-ssg140-> set ffilter src-ip 10.251.7.97
	filter added
	bottom-ssg140-> get ffilter
	Flow filter based on:
	id:0 src ip 10.251.7.113 dst ip 10.10.10.1 ip proto 1
	id:1 dst ip 10.10.10.1 ip proto 6 dst port 22
	id:2 dst ip 10.10.10.1 ip proto 6 dst port 23
	id:3 dst ip 10.251.7.97
	id:4 src ip 10.251.7.97
	bottom-ssg140->

This set of flow filters will filter the data destined to or sourced fromthe 10.251.7.97 host.

To manage the flow filters, you assign each one an identification number starting with 0, using the nomenclature id:n. The administrator can delete an individual flow filter by specifying it in the command or the flow filter with id:0, which is the default behavior when no flow filter ID is specified:

	bottom-ssg140-> unset ffilter 1
	filter 1 removed
	bottom-ssg140-> get ffilter
	Flow filter based on:
	id:0 src ip 10.251.7.113 dst ip 10.10.10.1 ip proto 1
	id:1 dst ip 10.10.10.1 ip proto 6 dst port 23
	id:2 dst ip 10.251.7.97
	id:3 src ip 10.251.7.97
	bottom-ssg140-> unset ffilter
	filter 0 removed
	bottom-ssg140-> get ff
	Flow filter based on:
	id:0 dst ip 10.10.10.1 ip proto 6 dst port 23
	id:1 dst ip 10.251.7.97
	id:2 src ip 10.251.7.97

Debug Buffer

The debug buffer (dbuf or db) is the local buffer of memory on the firewall for trou-bleshooting tools in which to write output. It is possible to dump this data to the console screen, but that is unwise as it may lead to overrunning the console and being unable to break into the flow to stop it and regain console access. You can see the actual size of the debug buffer in bytes by issuing the get sys-cfg or get db info command:

	bottom-ssg140-> get db info
	count: 9816, last index: 9816, cur index: 0, size: 131072
	start: 0, pause: 0
	bottom-ssg140-> get sys-cfg | inc dbuf
	dbuf number: 131072

You can increase this via the CLI. However, you must be careful to ensure that enough resources are available on the system:

	bottom-ssg140-> set db size
	<number>           size in kilobytes of debug buffer[from 32 to 4096]
	bottom-ssg140-> get mem
	Memory: allocated 46520432, left 235763184, frag 8, fail 0
	bottom-ssg140-> set db size 256
	bottom-ssg140-> get db info
	count: 9816, last index: 9816, cur index: 0, size: 262144
	start: 0, pause: 0
	bottom-ssg140-> get mem
	Memory: allocated 46651488, left 235632128, frag 9, fail 0
	bottom-ssg140->

In the preceding code, we have increased the buffer size fromthe default of 128 KB to 256 KB. Note that this decreased the available memory by 128 KB; remember that ScreenOS is a real-time operating system. The SSG140 platform will accept a debug buffer size of up to 4 MB.

It is a good idea to clear the debug buffer, with clear dbuf, before each debug session to ensure that the buffer will capture the data intended based on the flow-filter settings and time of capture. The following is some example output of the most common option, debugflow basic:

	top-ssg140-> get dbuf stream
	****** 88482.0: <Trust/eth0/0> packet received [60]******
	/*Packet received
	  ipid = 53693(d1bd), @d7812070
	/*Create fingerprint for packet/session
	  eth0/0:10.251.7.113/2816->20.20.20.2/512,1(8/0)
	/*Describe packet, src/dst IP, etc
	  IP classification from non-shared src if : vsys none
	/*Determine if part of a VSYS
	  search route to 20.20.20.2 in vr trust-vr for 0/0
	/*Perform route lookup
	  route 20.20.20.2->20.20.20.2, to eth0/1
	/*Describe route
	  routed 20.20.20.2 from eth0/0 (eth0/0 in 0) to eth0/1
	/*Route packet
	  pak loopback to zone Trust
	/*Describe filter set (trust-trust in this case)
	  vsd 0 is active
	/*Describe redundancy status
	  policy id = 13(Permit), tunnel = 0
	/*Which policy matches, which tunnel (13, none)
	  Session created for first pack,
	/*Create session
	  find matched sess id:4722
	/*Describe SessionID
	  core pak
	/*Send to forwarding engine
	  vsd 0 is active
	/*Verify redundancy status
	  flow_ip_send: d1bd:10.251.7.113->20.20.20.2,1 => eth0/1(60)
	/*Queue packet
	  no mac in session
	/*Look up MAC address
	  arp entry found for 20.20.20.2
	/*Find MAC
	  Send to eth0/1 (74)
	/*Send packet
	****** 88482.0: <Trust/ethernet7> packet received [60]******
	/*Packet received
	  ipid = 43579(aa3b), @d78c3070
	/*Create fingerprint
	  eth0/1:20.20.20.2/512->10.251.7.113/2816,1(0/0)
	/*Describe packet, src/dst IP, etc
	  find matched sess id:4722
	/*Find session from above
	  core pak
	/*Send to forwarding engine
	  vsd 0 is active
	/*Verify redundancy status
	  flow_ip_send: aa3b:20.20.20.2->10.251.7.113,1 => eth0/0(60)
	  @d78c3070
	/*Queue packet
	  mac 0010db13cbd0 in session
	/*No MAC lookup necessary, in session from request
	  Send to eth0/0 (74)
	/*Send packet
	top-ssg140->

You can display the output to the console or redirect it to a TFTP server with the following:

	bottom-ssg140-> get db stream > tftp 10.251.7.113 login_debug.txt
	redirect to 10.251.7.113,login_debug.txt
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	!!!!!!!!!!!!!!!!!!!!!!!!!!

	...

	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	!!!!!!!!!!!!!!!!!!!!!!!!
	tftp transferred records = 378
	tftp success!
	bottom-ssg140->

Snoop

Another useful tool is snoop. Snoop differs from the debug tool in that snoop’s primary function is to show what the packet looks like on the wire when it enters or leaves an interface, similar to an external sniffer, but minus the payload. You can view Layer 1–4 information as well as up to 1,514 bytes of hex data. Often, snoop will be used to validate that the device is receiving or sending a packet when debug flow isn’t providing an expected output. You can then apply filtering to tune what is captured, as shown here:

	bottom-ssg140-> snoop info
	Snoop: OFF
	Filters Defined: 0, Active Filters 0
	Detail: OFF, Detail Display length: 96

Snoop does not use flow filters, but it does allow a different filter system that is similar in structure to tcpdump. For example, the following filter will capture traffic between hosts 10.251.7.113 and 10.10.10.1 on port 23:

	bottom-ssg140-> snoop filter ip src-ip 10.251.7.113 dst-port 23
	snoop filter added
	bottom-ssg140-> snoop filter ip src-ip 10.10.10.1 src-port 23
	snoop filter added
	bottom-ssg140-> snoop info
	Snoop: OFF
	Filters Defined: 2, Active Filters 2
	Detail: OFF, Detail Display length: 1
	Snoop filter based on:
	id 1(on): IP src-ip 10.251.7.113 dst-port 23 dir(B)
	id 2(on): IP src-ip 10.10.10.1 src-port 23 dir(B)
	bottom-ssg140->

Just like with debug, it is good to clear the debug buffer before enabling snoop:

	bottom-ssg140-> clear dbuf
	bottom-ssg140-> snoop
	Start Snoop, type ESC or 'snoop off' to stop, continue? [y]/n y
	bottom-ssg140->
	bottom-ssg140-> get dbuf stream
	32616.0: ethernet0/0(i) len=62:00166f027720->0017cb479400/0800
	              10.251.7.113 -> 10.10.10.1/6
	              vhl=45, tos=00, id=45238, frag=0000, ttl=128 tlen=48
	              tcp:ports 4646->23, seq=6684683, ack=0, flag=7002/SYN

	32616.0: ethernet0/2(o) len=62:0017cb479406->0017cb478d06/0800
	              10.251.7.113 -> 10.10.10.1/6
	              vhl=45, tos=00, id=45238, frag=0000, ttl=127 tlen=48
	              tcp:ports 4646->23, seq=6684683, ack=0, flag=7002/SYN

Here is the initial TCP SYN packet, from 10.251.7.113 coming inbound, (i), on inter-face ethernet0/0, being sent outbound, (o), on ethernet0/2:

	32616.0: ethernet0/2(i) len=62:0017cb478d06->0017cb479406/0800
	   10.10.10.1 -> 10.251.7.113/6
	   vhl=45, tos=00, id=1434, frag=0000, ttl=64 tlen=44
	   tcp:ports 23->4646, seq=1569021109, ack=6684684, flag=6012/SYN/ACK

	32616.0: ethernet0/0(o) len=58:0017cb479400->00166f027720/0800
	   10.10.10.1 -> 10.251.7.113/6
	   vhl=45, tos=00, id=1434, frag=0000, ttl=63 tlen=44
	   tcp:ports 23->4646, seq=1569021109, ack=6684684, flag=6012/SYN/ACK

Here is the TCP SYN/ACK sequence acknowledging the SYN and sending its own SYN segment coming inbound, (i),on ethernet0/2 and then being sent outbound, (o), on ethernet0/0:

	32872.0: ethernet0/0(i) len=60:00166f027720->0017cb479400/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46850, frag=0000, ttl=128 tlen=40
	   tcp:ports 4646->23, seq=6684723, ack=1569021177, flag=5011/FIN/ACK

	32872.0: ethernet0/2(o) len=54:0017cb479406->0017cb478d06/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46850, frag=0000, ttl=127 tlen=40
	   tcp:ports 4646->23, seq=6684723, ack=1569021177, flag=5011/FIN/ACK

Last is the TCP ACK to complete the TCP three-way handshake and move the session from an embryonic state to a full connection state. ScreenOS has an internal timer of 20 seconds to complete the three-way handshake or delete the embryonic session from the state table.

	32872.0: ethernet0/0(i) len=60:00166f027720->0017cb479400/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46850, frag=0000, ttl=128 tlen=40
	   tcp:ports 4646->23, seq=6684723, ack=1569021177, flag=5011/FIN/ACK

	32872.0: ethernet0/2(o) len=54:0017cb479406->0017cb478d06/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46850, frag=0000, ttl=127 tlen=40
	   tcp:ports 4646->23, seq=6684723, ack=1569021177, flag=5011/FIN/ACK

The starting TCP FIN/ACK sequence acknowledging the last packet received and start-ing the FIN process looks like this:

	32872.0: ethernet0/2(i) len=60:0017cb478d06->0017cb479406/0800
	   10.10.10.1 -> 10.251.7.113/6
	   vhl=45, tos=00, id=1439, frag=0000, ttl=64 tlen=40
	   tcp:ports 23->4646, seq=1569021177, ack=6684724, flag=5019/FIN/ACK

	32872.0: ethernet0/0(o) len=54:0017cb479400->00166f027720/0800
	   10.10.10.1 -> 10.251.7.113/6
	   vhl=45, tos=00, id=1439, frag=0000, ttl=63 tlen=40
	   tcp:ports 23->4646, seq=1569021177, ack=6684724, flag=5019/FIN/ACK

Then, the TCP FIN/ACK packet coming from the other host acknowledges the FIN and sends its own:

	32872.0: ethernet0/0(i) len=60:00166f027720->0017cb479400/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46851, frag=0000, ttl=128 tlen=40
	   tcp:ports 4646->23, seq=6684724, ack=1569021178, flag=5010/ACK

	32872.0: ethernet0/2(o) len=54:0017cb479406->0017cb478d06/0800
	   10.251.7.113 -> 10.10.10.1/6
	   vhl=45, tos=00, id=46851, frag=0000, ttl=127 tlen=40
	   tcp:ports 4646->23, seq=6684724, ack=1569021178, flag=5010/ACK

Finally, the last TCP ACK packet is received, acknowledging the FIN and closing out the TCP session (this is with default settings on snoop, which shows the entire IP and TCP header information—essential when troubleshooting and you need to know what a packet looked like when entering and leaving the firewall).

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required