O'Reilly Media | ScreenOS Cookbook

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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.

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

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

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

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 ). For example:

	top-ssg140-> debug ?
	admin                debug admin
	adsl                 adsl debugging
	anti-spam            anti-spam debugging

Figure : Packet flow in ScreenOS

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter will build on and move on to describing how to manage the movement of data onto and off of the firewall. We will also describe some best practice approaches to control access to and manage ScreenOS in your environment.

You are troubleshooting an issue and need to save captured data currently on the firewall to a file, back up the current configuration, and then upload a new version of code, all with the Trivial File Transfer Protocol (TFTP).

Use the "redirect to TFTP" capability in the CLI to copy the information to your TFTP server:

	top-ssg140-> get log event > tftp 10.251.7.113 eventlog.txt
	redirect to 10.251.7.113,eventlog.txt
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	tftp transferred records = 15
	tftp success!
	top-ssg140->

Then, back up the existing configuration:

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

	TFTP Succeeded
	top-ssg140->

Lastly, copy the new version of the ScreenOS software to your firewall and save it:

	top-ssg140-> save software from tftp 10.251.7.113 ssg140.6.0.0r1.0
	    to flash
	Load software from 10.251.7.113/ssg140.6.0.0r1.0 .
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	...
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	tftp received octets = 11141120
	tftp success!

	TFTP Succeeded
	top-ssg140->

One of the challenges with a real-time, in-memory operating system such as ScreenOS (with no additional onboard hard drive for storage) is that you need to carefully manage the available buffers. This is especially true when troubleshooting because ScreenOS will overwrite space when the particular buffer fills up.

Here are some examples of some of these limits from an SSG140 device:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter will build on and move on to describing how to manage the movement of data onto and off of the firewall. We will also describe some best practice approaches to control access to and manage ScreenOS in your environment.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You are troubleshooting an issue and need to save captured data currently on the firewall to a file, back up the current configuration, and then upload a new version of code, all with the Trivial File Transfer Protocol (TFTP).

Use the "redirect to TFTP" capability in the CLI to copy the information to your TFTP server:

	top-ssg140-> get log event > tftp 10.251.7.113 eventlog.txt
	redirect to 10.251.7.113,eventlog.txt
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	tftp transferred records = 15
	tftp success!
	top-ssg140->

Then, back up the existing configuration:

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

	TFTP Succeeded
	top-ssg140->

Lastly, copy the new version of the ScreenOS software to your firewall and save it:

	top-ssg140-> save software from tftp 10.251.7.113 ssg140.6.0.0r1.0
	    to flash
	Load software from 10.251.7.113/ssg140.6.0.0r1.0 .
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	...
	!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
	tftp received octets = 11141120
	tftp success!

	TFTP Succeeded
	top-ssg140->

One of the challenges with a real-time, in-memory operating system such as ScreenOS (with no additional onboard hard drive for storage) is that you need to carefully manage the available buffers. This is especially true when troubleshooting because ScreenOS will overwrite space when the particular buffer fills up.

Here are some examples of some of these limits from an SSG140 device:

	top-ssg140-> get sys-cfg | inc " log"
	dlog session log pool number: 512
	event log entry number: 1024
	packet log entry number: 512
	traffic log entry number: 4096
	top-ssg140-> get sys-cfg | inc dbuf
	dbuf number: 524288
	top-ssg140->

As you can see, finite buffers are defined for numbers of entries or amounts of dedicated memory. During normal operation with appropriate log settings, the logs will be sent off to the NetScreen Security Manager (NSM), or a syslog server, before the buffer wraps around and overwriting begins. However, when troubleshooting, it's easy to exceed these numbers and start to overwrite before you can capture the data you want. The "redirect to TFTP" function can be useful for capturing this data before overwriting begins.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to use Secure Copy (SCP) to save the firewall configuration and then upload a new version of the ScreenOS software.

First, enable the Secure Shell (SSH) server on the firewall:

	top-ssg140-> set ssh enable

Next, enable the SCP server:

	top-ssg140-> set scp enable

Transfer the file to the firewall:

	ddelcourt@ddelcourt-lt2 ~/borderfw1
	$ scp netscreen@192.168.2.254:ns_sys_config
	    ./borderfw1_config_021107_1230.txt
	netscreen@192.168.2.254's password: <password>
	ns_sys_config                         100% 3835     3.8KB/s   00:00
	ddelcourt@ddelcourt-lt2 ~/borderfw1
	$ ls
	borderfw1_config_021107_1230.txt

Finally, copy the software image to the firewall:

$ scp /tftpboot/ssg140.6.0.0r1.0 netscreen@192.168.2.254:image
	netscreen@192.168.2.254's password: <password>
	ssg140.6.0.0r1.0                     100% 10880KB  63.2KB/s   02:48

SCP is really SFTP over an encrypted SSH session. It is inherently more secure than TFTP, and you could even use it to transfer information across the public Internet if required. You can manipulate any file listed under the get file command, including the ScreenOS image that is hidden in this listing.

We begin by enabling the SSH server functionality on the firewall with the set ssh enable command. Use the get ssh command to check that the expected version of SSH is running:

	top-ssg140-> get ssh
	SSH V2 is active
	SSH is enabled
	SSH is ready for connections
	Maximum sessions: 8
	Active sessions: 0

	Admin      Ip Addr         Vsys      Auth Method Service
	--------- --------------- -------- ----------- -------
	top-ssg140->

In ScreenOS 5.1 and later, the default version of SSH will be version 2. If you require that version 1 be used, refer to the Juniper Support site Knowledge Base article at .

get ssh and get scp will show you whether SSH is enabled:

	top-ssg140-> get ssh
	SSH V2 is active
	SSH is NOT enabled
	SSH is NOT ready for connections
	Maximum sessions: 8
	Active sessions: 0

	top-ssg140->

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The firewall must be connected to a dedicated sideband, or out-of-band management network, via the onboard management interface (applicable only to platforms with a dedicated MGT port).

Configure all user traffic security zones to be in the untrust-vr:

	isg1000-> set zone trust vr untrust-vr
	isg1000-> set zone untrust vr untrust-vr

Configure IP addressing on the interfaces:

	isg1000-> set interface e1/1 route
	isg1000-> set interface e1/1 zone trust
	isg1000-> set interface e1/1 ip 10.251.7.99/29
	isg1000-> set interface e1/2 zone untrust
	isg1000-> set interface e1/2 ip 10.10.10.254/24
	isg1000-> set interface mgt ip 10.20.20.1/28

Configure routing in the trust-vr for the MGT interface:

	isg1000-> set vr trust route 0.0.0.0/0 interface mgt gateway
	   10.20.20.14

Configure routing in the untrust-vr for user traffic:

	isg1000-> set vr untrust route 0.0.0.0/0 interface e1/2 gateway
	   64.2.31.249
	isg1000-> set vr untrust route 10.100.0.0/16 interface e3 gateway
	   10.100.1.1

The issue at hand is how to configure the firewall to use the onboard MGT interface connected to a dedicated sideband or out-of-band management network. Another way to solve this problem is to ensure that every management host that the firewall will ever need to communicate with is on the same local IP network subnet as the MGT interface IP. If this is the case, and no routes need to be added, specific or default, for the MGT interface to communicate with the systems required (such as syslog, NSM, the Network Time Protocol [NTP], etc.), nothing more needs to be done.

However, this is not the case in the vast majority of networks, as common services are often on separate network segments to be accessed by users and servers as well as the network devices.

Using this as the basis for discussion, it is important to understand how the MGT interface works and differs from other interfaces on the firewall. The dedicated MGT interface behaves like a "host" interface—in other words, traffic terminates on this interface, and cannot be routed through the firewall to any other interface and vice versa. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Users in different parts of the enterprise, or distributed NOC/SOC centers, must manage the firewall, and they must be able to access common services.

Determine the interface(s) that will accept management traffic, and then configure the management protocols to be accepted:

	top-ssg140-> set interface e0/0 manage ping
	top-ssg140-> set interface e0/0 manage ssh
	top-ssg140-> set interface e0/2 manage ping
	top-ssg140-> set interface e0/0 manage-ip 10.251.7.100

Next, determine how the firewall will reach management services:

	top-ssg140-> set syslog src-interface e0/0
	top-ssg140-> set ntp server src-interface e0/0
	top-ssg140-> set snmp host public 10.251.7.113/32 src-interface e0/0
	top-ssg140-> set tftp source-interface e0/0
	top-ssg140-> set nsmgmt server primary 10.251.7.113 src-interface
	    e0/0

Now, define which network host(s) and/or address(es) can access the firewall:

	top-ssg140-> set admin manager-ip 10.100.41.0/24
	top-ssg140-> set admin manager-ip 10.100.100.200/32
	top-ssg140-> set admin manager-ip 10.100.100.201/32
	top-ssg140-> set admin manager-ip 10.100.29.3/32
	top-ssg140-> set admin manager-ip 10.251.7.96/27
	top-ssg140-> set admin manager-ip 192.168.30.0/24

Change the root admin account, and configure individual admins:

	top-ssg140-> set admin name <root_adminname> password <password>
	top-ssg140-> set admin user name <adminname> password <password>
	    privilege all
	top-ssg140-> set admin user name <adminname> password <password> 
	    privilege read-only

Finally, configure the login banner:

	top-ssg140-> set admin auth banner <string>

Although it is certainly a best practice to lock down management access to the fire-wall, it is easy to overlook all the functions that you can control and fine-tune within ScreenOS. Securing the firewall requires a holistic approach, as described earlier, and each additional knob turned or tuning performed provides another layer of protection against unauthorized users accessing the firewall. A basic primer of these layers of control includes the following:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Remotely managed firewalls require a backup image to ensure an operational state in case of running image corruption.

During the boot sequence, press any key when prompted to "run loader":

	Hit any key to run loader

	Serial Number [0185122006000285]: READ ONLY
	HW Version Number [1010]: READ ONLY
	Self MAC Address [0017-cb47-9400]: READ ONLY
	Boot File Name [ssg140.6.0.0r1.0]: ssg140.5.4.0r4.0
	Self IP Address [192.168.1.1]: 10.251.7.99
	TFTP IP Address [192.168.1.1]: 10.251.7.113

	Save loader config (56 bytes)... Done
	The configured TFTP server is connected to port 0



	Loading file "ssg140.5.4.0r4.0"...
	r
	Receiving data block ...
	#20384

	Loaded Successfully! (size = 10,441,842 bytes)

	Ignore image authentication!

Upon the prompt to save to flash, enter m for multiple image support:

	Save to on-board flash disk? (y/[n]/m) m Yes!

Enter a filename that conforms to the DOS 8.3 naming convention standard:

	Please input multiple system image file name [ssg14054.0]: 140540.r4

	Saving system image to on-board flash disk...
	Done! (size = 10,441,842 bytes)

Enter n when prompted to run the downloaded image:

	Run downloaded system image? ([y]/n) n

Repeat this process for both images desired to be saved to flash memory. Then, set the boot order via the command line, and save the configuration:

	bottom-ssg140-> set envar boot=flash:/140600.R1;140540.R4
	bottom-ssg140-> save
	Save System Configuration ...
	Done

This recipe leverages the onboard flash memory, which on the SSG140 used here is 64 MB. To verify that all the steps are followed, you must examine the filesystem on the flash memory:

	bottom-ssg140-> get file 
	    flash:/$NSBOOT$.BIN            11141120
	    flash:/burnin_log1                40960
	    flash:/burnin_log0                40960
	    flash:/crash.dmp                 131072
	    flash:/envar.rec                    125
	    flash:/ns_sys_config               1433
	    flash:/prngseed.bin                  32
	    flash:/images/
	bottom-ssg140->

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The firewall cannot access a TFTP server as described in and the image or configuration file must be pulled from a Universal Serial Bus (USB) memory stick.

First, ensure that the correct image is on the USB stick:

	ddelcourt@ddelcourt-lt /cygdrive/g
	$ ls
	Customer    Recycled      Dept Stuff  Tools   Misc
	md5sum.exe  ssg140.5.4.0r4.0 ssg140.6.0.0r1.0

	ddelcourt@ddelcourt-lt /cygdrive/g

Safely remove the USB stick from the PC/system and insert it into the USB slot on the SSG, and then verify that ScreenOS recognizes it and can list the files:

	bottom-ssg140->
	LEXAR MEDIA JUMPDRIVE, rev 2.00/30.00, addr 2, SCSI over Bulk-Only

	Mount usb device. Please wait...
	usb device (usb) ready.

	bottom-ssg140-> get file
	    flash:/$NSBOOT$.BIN           11141120
	    flash:/burnin_log1               40960
	    flash:/burnin_log0               40960
	    flash:/crash.dmp                131072
	    flash:/envar.rec                   125
	    flash:/ns_sys_config              1433
	    flash:/prngseed.bin                 32
	    flash:/images/

	USB flash device :
	    usb:/.Trashes/
	    usb:/ssg140.6.0.0r1.0         11141120
	    usb:/ssg140.5.4.0r4.0         10485760
	    usb:/Customer/
	    usb:/Misc/
	    usb:/Tools/
	    usb:/Dept Stuff/
	    usb:/md5sum.exe                  34816
	    usb:/Recycled/
	bottom-ssg140->

Save the desired version of ScreenOS to flash memory:

	bottom-ssg140-> save software from usb ssg140.6.0.0r1.0 to flash
	It will replace current image file with usb image ssg140.6.0.0r1.0.
	Do you want to continue... y/[n] y
	Load image from usb to flash: ssg140.6.0.0r1.0.

	Read ..................................
	Save to flash. It may take a few minutes ...
	platform = 24, cpu = 12, version = 18
	 update new flash image (02555050,11141120)
	platform = 24, cpu = 12, version = 18
	offset = 20, address = 5800000, size = 11032611
	date = 1483, sw_version = 30008000, cksum = 55fe2c90
	Program flash (11141120 bytes) ...
	++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++done
	bottom-ssg140->

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Wireless local area networks (WLANs) provide obvious benefits over wired networks, in that they link network devices without wires. WLAN uses spread-spectrum or Orthogonal Frequency-Division Multiplexing (OFDM) modulation technology (based on radio waves to enable communication between devices in a limited area, also known as the basic service set).

IEEE 802.11 is the standard defined for the WLAN. It uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) as the access method. Multiple standards are defined under the 802.11 umbrella standards; 802.11a was the first standard defined for WLAN, and it uses OFDM at a 5 GHz frequency, providing 54 Mbps throughput (in theory). The most commonly used standards, however, are the 802.11b and 802.11g, and they operate in Direct Sequence Spread Spectrum(DSSS) and OFDM in a 2.4 GHz frequency, providing 11 Mbps and 54 Mbps. 802.11g is backward-compatible with 802.11b; however, 802.11b is not backward-compatible with 802.11a. Therefore, you would see a lot of wireless Access Point (AP) devices that support 802.11b/g on the same radio and 802.11a on a separate radio. The NS-5GT supports only the 802.11b/g standard; the SSG5 and SSG20 support the 802.11a/b/g standards using dual-band radio.

The 802.11b/g is prone to interferences from common household devices, such as microwaves and cordless phones. The channels available for 802.11b/g are 1–13, with the most commonly used channels being 1, 6, and 11, as these are nonoverlapping (all other channels interfere with each other). Extended channels (12 and 13) are not available to North America and some other countries.

You can use the exec wlan find-channel command to find the best channel, and you can either hard-set the channel or leave it at auto. To hard-set the channel, use the set wlan 0 channel command if you have a two-radio device such as the SSG5, or the set wlan channel command for single-radio devices such as the NS-5GT. Here is example output of the find-channel command:

	ssg5->

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Wireless local area networks (WLANs) provide obvious benefits over wired networks, in that they link network devices without wires. WLAN uses spread-spectrum or Orthogonal Frequency-Division Multiplexing (OFDM) modulation technology (based on radio waves to enable communication between devices in a limited area, also known as the basic service set).

IEEE 802.11 is the standard defined for the WLAN. It uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) as the access method. Multiple standards are defined under the 802.11 umbrella standards; 802.11a was the first standard defined for WLAN, and it uses OFDM at a 5 GHz frequency, providing 54 Mbps throughput (in theory). The most commonly used standards, however, are the 802.11b and 802.11g, and they operate in Direct Sequence Spread Spectrum(DSSS) and OFDM in a 2.4 GHz frequency, providing 11 Mbps and 54 Mbps. 802.11g is backward-compatible with 802.11b; however, 802.11b is not backward-compatible with 802.11a. Therefore, you would see a lot of wireless Access Point (AP) devices that support 802.11b/g on the same radio and 802.11a on a separate radio. The NS-5GT supports only the 802.11b/g standard; the SSG5 and SSG20 support the 802.11a/b/g standards using dual-band radio.

The 802.11b/g is prone to interferences from common household devices, such as microwaves and cordless phones. The channels available for 802.11b/g are 1–13, with the most commonly used channels being 1, 6, and 11, as these are nonoverlapping (all other channels interfere with each other). Extended channels (12 and 13) are not available to North America and some other countries.

You can use the exec wlan find-channel command to find the best channel, and you can either hard-set the channel or leave it at auto. To hard-set the channel, use the set wlan 0 channel command if you have a two-radio device such as the SSG5, or the set wlan channel command for single-radio devices such as the NS-5GT. Here is example output of the find-channel command:

	ssg5-> exec wlan find-channel

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to use MAC filtering to restrict user access to your wireless network.

Configure MAC filtering on the WLAN network and set up a strict access control list (ACL) on the WLAN configuration:

	set wlan acl mode strict
	set wlan acl 000f02020202 allow
	set wlan acl 000c01010101 allow

When you enable MAC filtering on the WLAN, the firewall will allow association of only those MAC addresses which are listed in the ACL. Although this is not a very secure way to restrict wireless access, it is one method among other security measures that you can use to deter unwanted users.

There are three modes for MAC filtering:

Disabled: The default mode; no MAC filtering will be done by the firewall
Enabled: Allows any MAC address to associate with the AP and deny the configured Deny MAC address
Strict: Allows only the configured Allow MAC addresses to associate with the AP, and denies everything else

You can view the MAC filtering configuration using the get wlan acl command. The following example shows that the WLAN ACL mode is strict, and it has one Deny MAC address, and two Allow MAC addresses:

	ssg5-> get wlan acl
	wlan acl mode strict

	denied mac address
	1. 000000000001

	allow mac address
	1. 000f00000000
	2. 000c01010101

You can view the event log using the get log event command to verify the MAC filtering. Here, a user with MAC address 00:0f:b5:22:bf:a2 was attempting to associate to the corp SSID and was denied by the ACL:

	2001-10-06 10:20:06 system notif 00564 Wireless station event: Station
	                                 000fb522bfa2 is denied by ACL, SSID:
	                                 corp.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure WEP shared authentication and encryption.

Configure the SSID with an authentication type of shared-key, define the WEP key, and bind the SSID to the wireless interface:

	set ssid name pizza
	set ssid pizza key-id 1 length 40 method asciitext a1b2c default
	set ssid pizza authentication shared-key
	set ssid pizza interface wireless0/0
	exec wlan reactivate

To configure the infrastructure to enable traffic flow through the AP, you must create a zone, attach a wireless interface to the zone, configure the IP address, enable a Dynamic Host Configuration Protocol (DHCP) server service on the wireless interface, configure security policy, and activate the wireless connection:

	set zone name "wzone1"

	set interface "wireless0/0" zone "wzone1"
	set interface wireless0/0 ip 172.16.254.1/24

	set interface wireless0/0 dhcp server service
	set interface wireless0/0 dhcp server auto
	set interface wireless0/0 dhcp server option gateway 172.16.254.1
	set interface wireless0/0 dhcp server option netmask 255.255.255.0
	set interface wireless0/0 dhcp server ip 172.16.254.10 to 172.16.254.15

	set policy from "wzone1" to "Untrust" "Any" "Any" "ANY" nat src permit
	exec wlan reactivate

You must also configure the client for WEP-shared authentication to associate with this AP.

You should configure the minimum of WEP authentication and encryption on your wireless network to deter casual snooping. Although it is very easy to crack WEP encryption, it will deter users from looking for easy access to your wireless network.

In this example, we chose WEP shared-key as the authentication and encryption method to protect the wireless network. For WEP, you can configure three different authentication types:

Open authentication: Requires no authentication key, and anybody specifying the SSID can associate with the AP. You can configure open authentication with or without encryption. The encryption algorithm used for WEP is RC4 for encryption and decryption.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to secure a wireless network using WPA with a preshared key. You don't have the infrastructure for 802.1x authentication, and would like to use WPA with a preshared key.

Define the SSID with the authentication type as WPA-Auto-PSK, and the encryption algorithm as auto, and then bind the SSID to the wireless interface:

	set ssid name Sunnyvale
	set ssid Sunnyvale client-isolation
	set ssid Sunnyvale authentication wpa-auto-psk passphrase JnPr!234
	   encryption auto
	set ssid Sunnyvale interface wireless1

Configure the infrastructure to enable traffic flow through the AP, create the zone, attach the wireless interface to the zone, configure the IP address, enable DHCP server service on the wireless interface, configure the security policy, and activate the wireless connection:

	set zone name "corp-wireless"

	set interface "wireless0/1" zone "corp-wireless"
	set interface wireless0/1 ip 172.17.200.1/24

	set interface wireless0/1 dhcp server service
	set interface wireless0/1 dhcp server auto
	set interface wireless0/1 dhcp server option gateway 172.17.200.1
	set interface wireless0/1 dhcp server option netmask 255.255.255.0
	set interface wireless0/1 dhcp server ip 172.17.200.10 to
	172.17.200.20

	set policy from "corp-wireless" to "trust" "Any" "Any"
	"ANY" permit

	exec wlan reactivate

Configure the client for WPA or WPA2 preshared key authentication to associate with this AP.

WPA is a more secure authentication and encryption method than WEP. It is a good measure to ensure that only trusted users can associate with the wireless AP. ScreenOS firewalls support WPA authentication using 802.1x and the static key (a.k.a. the preshared key).

This recipe uses the WPA-PSK (preshared key) method for wireless protection. You can configure WPA-PSK in three ways:

WPA-PSK authentication: This requires that the users support only WPA with a preshared key. WPA is based on the IEEE 802.11i draft specifications.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to secure a wireless network with WPA using 802.1x with IAS and Microsoft Active Directory.

Configure the auth-server using an account-type of 802.1x, and select Radius as the auth-server type:

	set auth-server "MyServer" server-name "172.24.28.199"
	set auth-server "MyServer" account-type 802.1X
	set auth-server "MyServer" radius secret "RADIUS_SECRET"

Configure the SSID with an authentication type of wpa-auto and an encryption type of auto; associate the 802.1x auth-server, and then bind the SSID to the wireless interface:

	set ssid name Secured
	set ssid Secured client-isolation
	set ssid Secured authentication wpa-auto encryption auto auth-server
	   MyServer
	set ssid Secured interface wireless0

Configure the infrastructure to enable traffic flow through the AP by creating a zone, attaching a wireless interface to the zone, configuring the IP address, enabling DHCP server service on the wireless interface, configuring the security policy, and finally, activating the wireless connection:

	set zone name "wzone1"
	set interface "wireless0/0" zone "wzone1"
	set interface wireless0/0 ip 172.16.254.1/24
	set interface wireless0/0 dhcp server service
	set interface wireless0/0 dhcp server auto
	set interface wireless0/0 dhcp server option gateway 172.16.254.1
	set interface wireless0/0 dhcp server option netmask 255.255.255.0
	set interface wireless0/0 dhcp server ip 172.16.254.10 to
	172.16.254.15

	set policy from "wzone1" to "Untrust" "Any" "Any" "ANY" nat src
	permit

	exec wlan reactivate

Use this link to configure Microsoft Windows to provide the 802.1x authentication service: .

Using WPA with the 802.1x authentication method is considered a better wireless network security method when compared to WPA-PSK and WEP. However, it has dependencies on other network services, such as the 802.1x-aware RADIUS server and its backend infrastructure. Based on your network authentication service, the deployment may be different.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure the Steel-Belted Radius server and Odyssey Access Client for wireless connection.

To configure the firewall as the AP, first you must configure the auth server using an account type of 802.1x and select RADIUS as the auth server type:

	set auth-server "MyServer" server-name "172.24.28.199"
	set auth-server "MyServer" account-type 802.1X
	set auth-server "MyServer" radius secret "RADIUS_SECRET"

Then, configure the SSID with an authentication type of wpa-auto and an encryption type of auto, associate the 802.1x auth server, and bind the SSID to the wireless interface:

	set ssid name Sunnyvale
	set ssid Sunnyvale client-isolation
	set ssid Sunnyvale authentication wpa-auto encryption auto auth-server
	   MyServer
	set ssid Sunnyvale interface wireless0

To configure the infrastructure to enable traffic flow through the AP, create the zone, attach a wireless interface to the zone, configure the IP address, enable the DHCP server service on the wireless interface, configure the security policy, and activate the wireless connection:

	set zone name "wzone1"
	set interface "wireless0/0" zone "wzone1"
	set interface wireless0/0 ip 10.1.1.1/24
	set interface wireless0/0 dhcp server service
	set interface wireless0/0 dhcp server auto
	set interface wireless0/0 dhcp server option gateway 10.1.1.1
	set interface wireless0/0 dhcp server option netmask 255.255.255.0
	set interface wireless0/0 dhcp server ip 10.1.1.10 to 10.1.1.20

	set policy from "wzone1" to "Untrust" "Any" "Any" "ANY" nat src permit

	exec wlan reactivate

To install and configure the Steel-Belted Radius server and Odyssey Access Client, follow these steps (these steps are also outlined in the Getting Started and Administration guides, available from the Steel-Belted Radius support site):

Install the Steel-Belted Radius server on a Windows server that is a member of, or belongs to, a domain that has the trust relationship with the domain where the user credentials are stored.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to provide wireless access for corporate and guest users, but guest users should have access to the Internet only.

Create security zones for each type of user group. For this recipe, we will create a corp zone for corporate users, and a guest zone for guest users:

	set zone name "corp"
	set zone name "guest"

Assign the wireless interfaces wireless0/0 to corp and wireless0/1 to guest; also, configure the wired interfaces ethernet0/0 to the Untrust zone and ethernet0/2 to the Trust zone. Then, configure the IP addresses to each interface:

	set interface "ethernet0/0" zone "Untrust"
	set interface "ethernet0/2" zone "Trust"
	set interface "wireless0/0" zone "corp"
	set interface "wireless0/1" zone "guest"
	set interface ethernet0/0 ip 192.168.1.35/24
	set interface ethernet0/2 ip 192.168.4.1/24
	set interface wireless0/0 ip 192.168.2.1/24
	set interface wireless0/1 ip 192.168.3.1/24

You can use the DHCP server on the wireless network by configuring the DHCP server service on the wireless interfaces:

	set interface wireless0/0 dhcp server service
	set interface wireless0/1 dhcp server service
	set interface wireless0/0 dhcp server option gateway 192.168.2.1
	set interface wireless0/1 dhcp server option gateway 192.168.3.1
	set interface wireless0/0 dhcp server ip 192.168.2.33 to 192.168.2.126
	set interface wireless0/1 dhcp server ip 192.168.3.10 to 192.168.3.20

For the guest users, configure authentication using webauth to prevent unconstrained access, and then define the users on the device:

	set interface "wireless0/1" webauth ssl-only
	set interface "wireless0/1" webauth-ip 192.168.3.5

	set user "guest1" uid 1
	set user "guest1" type auth
	set user "guest1" hash-password "026Q18FGRiRbJOwq93hvV+Mz5Q3qiAguQ="
	set user "guest1" "enable"

	set user "guest2" uid 2
	set user "guest2" type auth
	set user "guest2" hash-password "026Q18FGRiRbJOwq93hvV+Mz5Q3qiAguQ="
	set user "guest2" "enable

Having separated users using zones, we can control the traffic between zones using firewall policies. Enable

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

You want to configure Bridge Groups for wired/wireless networks to share IP addresses and make the networks seamless.

Configure the zone that will contain the wired and wireless network and assign bgroup0 to the zone. Also, assign the wired interface and wireless interface to the bgroup0 interface:

	set zone name Corp
	set interface "bgroup0" zone "Corp"
	set interface bgroup0 port ethernet0/6
	set interface bgroup0 port wireless0/0

Then, configure the IP address for the bgroup0 interface and enable DHCP for automatic IP address allocations:

	set interface bgroup0 ip 10.10.10.1/24
	set interface bgroup0 dhcp server service
	set interface bgroup0 dhcp server enable
	set interface bgroup0 dhcp server option gateway 10.10.10.1
	set interface bgroup0 dhcp server option netmask 255.255.255.0
	set interface bgroup0 dhcp server ip 10.10.10.100 to 10.10.10.130

Configure the SSID for the wireless network, and bind the wireless interface to the SSID. Then, activate the wireless configuration:

	set ssid name Secured
	set ssid Secured client-isolation
	set ssid Secured authentication wpa-auto-psk passphrase Secret
	   encryption auto
	set ssid Secured interface wireless0

	exec wlan reactivate

Finally, configure the security policy to allow traffic across zones:

	set policy from corp to untrust any any any nat src permit

You can use Bridge Groups to combine wired and wireless interfaces at the Layer 2 level and make the network seamless. This feature is supported only in the SSG5 and the SSG20 as of this writing. The traffic between wireless and wired networks is switched by the interface driver, and it is not inspected by the security policy, even if you have client isolation configured on the SSID.

To share the IP subnet between ethernet0/6 and wireless0/0 interfaces, create a zone called Corp which will contain the bgroup0. Then, assign the ethernet0/6 and wireless0/0 interfaces to bgroup0. All the Layer 3 configurations will be done on the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Routing is the most important factor for traffic to flow over the network. Every packet traveling from Host A to Host B needs to have a defined path; otherwise, communication over the network is impossible. The defined path can be a default route, or it can be specific routes for an IP address. The paths can be configured manually using static routing, or they can be established using dynamic methods with the help of routing protocols, such as the Open Shortest Path First (OSPF) protocol, the Border Gateway Protocol (BGP), and the Routing Information Protocol (RIP).

Each path is considered to be a route and has the following elements:

Prefix: The IP address and mask. This is the IP address for which the route is defined.
Next hop: The gateway IP address, and the interface or Virtual Router (VR). This is where the packet should be forwarded for the IP address.
Preferences: The priority for the route.
Metric: The cost associated with the route.
Tag: Used to identify the route for filtering or redistribution into other instances.

The collection of all paths is kept in a database called the routing table.

In ScreenOS software, you can deploy a firewall in three different system modes: Network Address Translation (NAT) mode, route mode, and transparent mode. The routing table is used differently in each mode. When the device is in transparent mode, the device utilizes the Media Access Control (MAC) table to forward packets; while in NAT/route mode, the device uses the route table to make forwarding decisions. You can check in which mode the system is operating with the get system command. This example shows a system operating in NAT/route mode:

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Routing is the most important factor for traffic to flow over the network. Every packet traveling from Host A to Host B needs to have a defined path; otherwise, communication over the network is impossible. The defined path can be a default route, or it can be specific routes for an IP address. The paths can be configured manually using static routing, or they can be established using dynamic methods with the help of routing protocols, such as the Open Shortest Path First (OSPF) protocol, the Border Gateway Protocol (BGP), and the Routing Information Protocol (RIP).

Each path is considered to be a route and has the following elements:

Prefix: The IP address and mask. This is the IP address for which the route is defined.
Next hop: The gateway IP address, and the interface or Virtual Router (VR). This is where the packet should be forwarded for the IP address.
Preferences: The priority for the route.
Metric: The cost associated with the route.

Table of Contents