You need to configure the time on the firewall.

Manually set the time using the CLI:

	FIREWALL-A-> set clock 07/13/2007 01:51:00
	FIREWALL-A->set clock dst recurring start-weekday 2 0 3 02:00
	    end-weekday 1 0 11 02:00

When initially setting up a firewall, it is recommended that you set the clock to the current time. For small, localized networks, local time is usually appropriate, but for large networks spanning multiple time zones, UTC may prove more useful. Although setting the date and time manually on firewalls is the least accurate way to maintain the system clock, in a small environment with just one or a few firewalls, such as one’s home, using the system clock may be acceptable. Even in large environments, manually setting the clock can be useful. For example, when generating a certificate request on the device, if the clock is off, the certificate could show up as being issued in the future, which would render it invalid. As such, it is a good practice to set the date manually, even if you plan to use NTP down the road.

In ScreenOS, setting the date and time is simple: just use the set clock command. The date format is in mm/dd/yyyy; the time format is in hh:mm:ss and follows a 24-hour clock. You also can configure Daylight Saving Time (DST) settings for manually set clocks. In ScreenOS 6.0, the capability to configure DST parameters was added so that regions outside the United States could set the start and end times for DST, either using the actual date on which DST starts, such as March 9, or, as in this recipe, by defining the week of the month, day of the week, month of the year, and time. In our example, 2 0 3 02:00 represents the second week of the month, Sunday (represented by 0), and the third month of the year at 2:00 a.m. This translates to the second Sunday in March. The recurring keyword indicates that this setting should be used for every year. Likewise, the end-weekday portion of the command specifies when DST ends in the same format. The get clock command shows the current time settings for the device:

	FIREWALL-A-> get clock
	Date 07/13/2007 14:25:04, Daylight Saving Time enabled
	The Network Time Protocol is Disabled
	Up 374 hours 53 minutes 2 seconds Since 27June2007:23:32:02
	1184336704.693643 seconds since 1/1/1970 0:0:0 GMT
	GMT time zone area -5:00
	GMT time zone offset 4:00

Recipe 6.2

You need to configure your firewalls to receive their time via NTP.

Configure NTP on the firewall:

	FIREWALL-A-> set ntp server time.mynetwork.com
	FIREWALL-A-> set ntp timezone -5
	FIREWALL-A-> set ntp server key-id 1 preshare-key iamakey
	FIREWALL-A-> set ntp auth preferred
	FIREWALL-A-> set ntp no-ha-sync
	FIREWALL-A->set clock ntp

Using NTP on the firewall is strongly recommended to ensure a consistent view of time across the network. When troubleshooting, or when analyzing security events in firewall logs, the log correlation process is greatly simplified when there is a common view of the time across the network. Enabling NTP on the firewall is straight-forward. By using a hostname for the NTP server, you can use a Global Server Load Balancer to ensure that the NTP server is always reachable. Alternatively, you can configure up to two backup NTP servers, using the backup1 and backup2 <server name> options in the set ntp server command. Typically, the time zone is set to display the local time on the firewall. This setting is made with respect to offset from Greenwich Mean Time (GMT). The value -5 in the timezone command indicates that the time is GMT minus five hours, which corresponds to Eastern Standard Time in the United States. Some administrators prefer to use a common time zone for all of their global devices to further ease event correlation. Either practice is fine.

For security reasons, authentication is specified for NTP. This ensures that the fire-wall receives the time from the correct server, and not from a rogue server. ScreenOS uses Message Digest 5 (MD5) authentication with a preshared key to accomplish this. Once you enter the set ntp server key-id 1 preshare-key command, the key is not visible to the administrator:

	FIREWALL-A-> get config | include key-id
	set ntp server key-id 1 preshare-key
	    "7m6T/ZnvNj1KtSsptXCbWsuKHRnLLll1Sw=="

After configuring the key, configure NTP authentication to be either preferred or required. In this recipe, we chose preferred, indicating that authentication should be used, if possible. The set ntp no-ha-sync command is used to disable the synchronization of clocks among NetScreen Redundancy Protocol (NSRP)members. Instead, each cluster member will independently update its clock from the NTP server. This command is recommended for NSRP environments. Finally, the clock is configured to update using NTP as opposed to using the locally configured time.

Recipe 6.1

You need to verify the status of NTP.

Use get commands to examine the status:

	FIREWALL-A-> get event type 00531
	Total event entries = 1
	Date       Time     Module Level  Type Description
	2007-07-13 14:23:57 system notif 00531 The system clock was updated
	                                       from primary NTP server type
	                                       10.3.1.1 with an adjustment
	                                       of -153 ms. Authentication
	                                       was None. Update mode was
	                                       Automatic
	FIREWALL-A-> get ntp
	NTP is Enabled

	Primary server: 10.3.1.1
	Backup1 server:
	Backup2 server:
	Authentication Mode: Preferred
	Max Allowed Adjustment: 3 second(s)
	Request Interval: 10 minute(s).
	Sync NTP time to peer: Disabled
	Update Status: Idle
	Last Update at: 07/13/2007 14:24:16

	FIREWALL-A-> get clock
	Date 07/13/2007 15:46:33, Daylight Saving Time enabled
	The Network Time Protocol is Enabled
	Up 376 hours 14 minutes 31 seconds Since 27June2007:23:32:02
	1184341593.166653 seconds since 1/1/1970 0:0:0 GMT
	GMT time zone area -5:00
	GMT time zone offset 4:00

You can examine NTP status using get commands. Each update from an NTP server appears in the event log as event type 00531. If the NTP servers cannot be contacted, this will also appear in the event log:

	FIREWALL-A-> get event type 00531
	Total event entries = 1
	Date       Time    Module Level Type Description
	2007-07-13 15:42:21 system notif 00531 No NTP server could be
	    contacted.

This update message should appear as frequently as the request interval that appears in the output of the get ntp command. The request interval used here is set to 10 minutes, which is the default. This is a configurable parameter, and you can set it from 1–1440 minutes, using the set ntp interval command. As you can see from the output of get ntp, up to three servers can be configured: one primary server and two backups. Authentication is set to preferred, as per the configuration. When the key is modified, the results are viewable in the output of get event id 00531:

	2007-07-13 15:58:12 system notif 00531 Authentication failed for
	                                       Network Time Protocol server
	                                       primary 10.3.1.1 because
	                                       Invalid key-id received from
	                                       server

Although authentication is configured to be preferred, this does not stop the update process from occurring; it merely fails authentication. To ensure authentication at all times, the required keyword should be set in the set ntp auth command.

The next line of the output from get ntp shows the maximum allowable adjustment from an NTP server. If the delta between the local system time and the server time exceeds three seconds, the time will not be updated. If this occurs, the clock must be reset manually, as in Recipe 6.1. Again, get event id 00531 has this information:

	2007-07-13 15:58:12 system notif 00531 No acceptable time could be
	                                       obtained from any NTP server.
	2007-07-13 15:58:12 system notif 00531 Network Time Protocol adjustment
	                                       of -17152 ms from NTP server
	                                       primary exceeds the allowed
	                                       adjustment of 3000 ms.

Here, notice that two log messages are generated—one detailing the difference between the NTP server’s time and the local system time, and one stating that there is no acceptable time from any NTP server. Correcting the time to be within the adjustment range, we see the following in the get event output:

	2007-07-13 16:08:32 system notif 00531 The system clock was updated
	                                       from primary NTP server type
	                                       10.3.1.1 with an adjustment
	                                       of 1873 ms. Authentication
	                                       was Preferred. Update mode
	                                       was Automatic
	2007-07-13 16:08:32 system notif 00531 Authentication failed for
	                                       Network Time Protocol server
	                                       primary 10.3.1.1
	                                       because Invalid key-id
	                                       received from server

Although the authentication fails with the wrong key, an update is still performed.

You need to configure DNS settings on the firewall.

Configure the hostname, domain name, and DNS servers:

	ssg20-> set hostname FIREWALL-A
	FIREWALL-A-> set domain oreilly.com
	FIREWALL-A-> set dns host dns1 68.87.64.146
	FIREWALL-A->set dns host dns2 68.87.75.194

During initial firewall installation, it is recommended that you change the firewall’s hostname to something meaningful, typically according to your organization’s naming convention. By default, Juniper firewalls ship with a default name that is the same as the name of the product. In this example, an SSG20 is being configured with a new hostname, FIREWALL-A. Note that once the hostname is set, the prompt changes to reflect the hostname. In an NSRP environment, the hostname is not a synchronized portion of the configuration, so this step must be performed on each member of an NSRP cluster. Next, the domain name of the local device is set.

Finally, the primary and secondary DNS servers’ IPs are configured. In cases where the DNS servers are on the other end of a tunnel, you can specify the source interface for DNS requests using the src-interface keyword at the end of the set dns host command. This allows the head-end VPN device to route DNS replies through the tunnel. ScreenOS supports up to three DNS servers that can be used for name resolution. You can use this resolution for different purposes. One of the primary purposes for name resolution is for troubleshooting: it’s easier to troubleshoot network issues when names are used. Once DNS servers have been configured in ScreenOS, you can use hostnames in the ping and trace-route commands:

	FIREWALL-A-> ping www.oreilly.com
	Type escape sequence to abort

	Sending 5, 100-byte ICMP Echos to www.oreilly.com [208.201.239.36],
	    timeout is 1 seconds
	!!!!!
	Success Rate is 100 percent (5/5),
	    round-trip time min/avg/max=93/100/117 ms

Using hostnames simplifies troubleshooting, as the IP addresses of test hosts do not need to be known.

You can also use DNS to create address book entries, and to build policies for those entries:

	FIREWALL-A-> set address untrust www.oreilly.com www.oreilly.com
	Domain name "www.oreilly.com" has been looked up successfully.
	FIREWALL-A-> set policy top from trust to untrust any www.oreilly.com
	ping deny log
	policy id = 11

DNS is another method of simplifying policy creation. By specifying an FQDN as opposed to an IP address in address book entry creation, you can deploy more comprehensive policies more easily, as all IPs matching the FQDN are used for the policy. Use the get dns name command to verify the IP addresses associated with the address book entry:

	FIREWALL-A-> get dns name www.oreilly.com
	Host name: www.oreilly.com
	IPv4 Addresses:
	        208.201.239.36
	        208.201.239.37

When the policy is applied to the device, it blocks the ping to both addresses returned by the DNS server and cached by the firewall. You can verify this with debug flow basic:

	$ ping 208.201.239.36

	Pinging 208.201.239.36 with 32 bytes of data:

	Request timed out.

	Ping statistics for 208.201.239.36:
	   Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
	Control-C

	$ ping 208.201.239.37

	Pinging 208.201.239.37 with 32 bytes of data:

	Request timed out.

	Ping statistics for 208.201.239.37:
	    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
	Control-C

	FIREWALL-A-> get db str
	****** 411161.0: <Trust/wireless2> packet received [60]******
	  ipid = 64686(fcae), @01c27894
	  packet passed sanity check.
	  wireless2:192.168.2.33/8704->208.201.239.36/512,1(8/0)<Root>
	  no session found
	  flow_first_sanity_check: in <wireless2>, out <N/A>
	  chose interface wireless2 as incoming nat if.
	  flow_first_routing: in <wireless2>, out <N/A>
	  search route to (wireless2, 192.168.2.33->208.201.239.36) in vr
	    trust-vr for vsd-0/flag-0/ifp-null
	  [ Dest] 21.route 208.201.239.36->68.38.120.1, to ethernet3
	  routed (x_dst_ip 208.201.239.36) from wireless2 (wireless2 in 0)
	    to ethernet3

	  policy search from zone 2-> zone 1
	 policy_flow_search policy search nat_crt from zone 2-> zone 1
	  RPC Mapping Table search returned 0 matched service(s) for
	    (vsys Root, ip 208.201.239.36, port 10588, proto 1)
	  No SW RPC rule match, search HW rule
	  log this session (pid=11)
	   packet dropped, denied by policy
	****** 411169.0: <Trust/wireless2> packet received [60]******
	  ipid = 64692(fcb4), @01c29494
	  packet passed sanity check.
	  wireless2:192.168.2.33/8960->208.201.239.37/512,1(8/0)<Root>
	  no session found
	  flow_first_sanity_check: in <wireless2>, out <N/A>
	  chose interface wireless2 as incoming nat if.
	  flow_first_routing: in <wireless2>, out <N/A>
	  search route to (wireless2, 192.168.2.33->208.201.239.37) in vr
	    trust-vr for vsd-0/flag-0/ifp-null
	  [ Dest] 21.route 208.201.239.37->68.38.120.1, to ethernet3
	  routed (x_dst_ip 208.201.239.37) from wireless2 (wireless2 in 0)
	    to ethernet3

	  policy search from zone 2-> zone 1
	 policy_flow_search policy search nat_crt from zone 2-> zone 1
	  RPC Mapping Table search returned 0 matched service(s) for
	    (vsys Root, ip 208.201.239.37, port 10332, proto 1)

	No SW RPC rule match, search HW rulelog this session (pid=11)
	packet dropped, denied by policy

Notice in the preceding debug output that when the client attempts to ping either address contained in the www.oreilly.com address object, the ping fails, as it is denied by policy ID 11.

	FIREWALL-A-> get address untrust name www.oreilly.com
	Name                    Address/Prefix-length           Flag Comments
	www.oreilly.com         www.oreilly.com                 0201

	FIREWALL-A-> get policy id 11
	name:"none" (id 11), zone Trust -> Untrust,action Deny, status
	    "enabled"
	src "Any", dst "www.oreilly.com", serv "PING"
	Policies on this vpn tunnel: 0
	nat off, Web filtering : disabled
	vpn unknown vpn, policy flag 00010000, session backup: on, idle
	    reset: on
	traffic shapping off, scheduler n/a, serv flag 00
	log close, log count 11, alert no, counter no(0) byte rate(sec/min)
	    0/0
	total octets 814, counter(session/packet/octet) 0/0/0
	priority 7, diffserv marking Off
	tadapter: state off, gbw/mbw 0/0 policing (no)
	No Authentication
	No User, User Group or Group expression set

When DNS is configured on the device, you also can configure an IKE gateway using an FQDN:

	FIREWALL-A-> set ike gateway www.oreilly.com address www.oreilly.com
	    main preshare screenosckbk sec-level standard
	FIREWALL-A-> get ike gateway
	 Id Name             Gateway Address Gateway ID      Mode Proposals
	---- --------------- --------------- --------------- ---- ---------
	   0 www.oreilly.com         208.201.239.37             Main
	    pre-g2-3des-sha,pre-g2
	-aes128-sha
	  Total Gateways: 1 (1 including dynamic peers)
	user with ASN1_DN type ID sort list:

You can use this capability to create tunnels between devices that have dynamic addresses, but well-known domain names. A common use case for this would be where the IKE gateway’s name is defined on a Global Server Load Balancer that performs health checking and uses DNS to provide a known “good” IP address to the requesting devices.

Recipe 6.5

You need to view the DNS entries on a device.

Use the get dns host cache command:

	FIREWALL-A-> get dns host cache
	DNS Server:
	  Primary :      68.87.64.146, Src Interface: Null
	  Secondary:     68.87.75.194, Src Interface: Null
	  Ternary :             0.0.0.0, Src Interface: Null
	DNS Cache (Static):
	DNS Cache (Dynamic):
	 Host name:         www.oreilly.com IP: 208.201.239.36 TTL= 18059s
	 Host name:         www.oreilly.com IP: 208.201.239.37 TTL= 18059s
	DNS Cache (Unresolved):
	DNS Cache (Freed):

When troubleshooting a DNS-related issue, it is often helpful to view the firewall’s DNS cache. The get dns host cache command shows all of the DNS information with respect to resolution, which is on the firewall. It provides the DNS server information as well as cache information.

The first two categories of cached information are the most common ones. The static cache is used in a similar capacity to a host file on a computer. Administrators can configure static hostnames on the firewall, and these entries appear in this section of the cache output. The Dynamic section contains all dynamically learned DNS information, and includes the hostname and IP address for each entry.

In cases where multiple entries are returned from a lookup, each IP address is displayed as a separate entry. Additionally, the TTL is inherited from the DNS lookup. When the TTL expires, the entry will be removed from the cache, and a new lookup will be performed the next time the device needs to access the object.

ScreenOS can also perform name lookups on demand. The get dns name command allows an administrator to look up an IP address much as he would by using the nslookup command:

	FIREWALL-A-> get dns name www.juniper.net
	Host name: www.juniper.net
	IPv4 Addresses:
	        207.17.137.229

	FIREWALL-A-> get dns host cache
	DNS Server:
	  Primary :             68.87.64.146, Src Interface: Null
	  Secondary:            68.87.75.194, Src Interface: Null
	  Ternary :                  0.0.0.0, Src Interface: Null
	DNS Cache (Static):
	DNS Cache (Dynamic):
	 Host name:             www.oreilly.com IP: 208.201.239.36 TTL= 10201s
	 Host name:             www.oreilly.com IP: 208.201.239.37 TTL= 10201s
	 Host name:            www.juniper.net IP: 207.17.137.229 TTL= 83600s
	DNS Cache (Unresolved):
	DNS Cache (Freed):

As expected, now the host is included in the output of get dns host cache.

To view the lookups for address book entries, and the values for IP addresses that each hostname resolves to, use the get dns host report command:

	FIREWALL-A-> get dns host report
	       Name                    Status               Last Lookup
	  www.oreilly.com          Lookup successful       08/03/2007
	    12:16:22
	    208.201.239.36
	    208.201.239.37

This command also tells you when the last lookup was performed. When the FQDN defines address book entries, the IP addresses comprising the object are refreshed on a configurable interval. You use the set dns host schedule command to modify the frequency of address book lookups; you can set it to a minimum of four hours and a maximum of never refreshing the values. The get dns host settings command shows the lookup settings:

	FIREWALL-A-> get dns host settings
	DNS Server:
	  Primary :             68.87.64.146, Src Interface: Null
	  Secondary:            68.87.75.194, Src Interface: Null
	  Ternary :                  0.0.0.0, Src Interface: Null

	Refresh domain name IP Addresses:
	  Every day at:           12:00 o'clock
	  Last performed look-up: 08/03/2007 11:52:47
	  Next scheduled look-up: 08/03/2007 20:14:07

	Normal UDP session: 0

Recipe 6.4

You need to configure static DNS entries so that one policy with one object set can apply to multiple devices.

Use static DNS entries on the firewalls to provide a single name across devices that point to a unique resource per device:

	FIREWALL-A-> set dns host name dataserver 10.1.1.1

	FIREWALL-B->set dns host name dataserver 10.2.1.1

Create address book entries on each firewall referencing the hostname:

	FIREWALL-A-> set address trust dataserver dataserver
	Domain name "dataserver" has been looked up successfully.

	FIREWALL-B-> set address trust dataserver dataserver
	Domain name "dataserver" has been looked up successfully.

Create a policy allowing traffic to the web server on each device:

	FIREWALL-A-> set policy from untrust to trust any dataserver http
	    permit log
	policy id = 13

	FIREWALL-B-> set policy from untrust to trust any dataserver http
	    permit log
	policy id = 13

When a centralized policy structure is used, via either the NetScreen Security Manager (NSM) or another tool, there is often a desire to share a common policy across devices. Although there is much interest in this method of rule base management, there are problems associated with it. The primary issue is that to have a common policy across devices, the devices must protect the same resources, or have rules that permit traffic which should not traverse them, as shown in the topology in Figure 6-1.

In Figure 6-1, there are two sites, each protected by a firewall and each with a data server. The site administrators want to permit HyperText Transfer Protocol (HTTP) traffic only to the data server at each site. They have a few options: (1) create a separate policy for each site, and define the data server objects differently; (2) create one policy that allows traffic to both servers, and assign this policy to both devices; or (3) create separate object definitions on each device, and create a single policy to apply to the firewalls.

Figure 6-1. Two sites, one policy

The first option is perhaps the most common, and it allows for considerable granularity. However, the cost of this granularity is that each device requires its own policy. This factor can be troublesome from an audit perspective, and it can create operational challenges. However, choosing this option also provides a straightforward and secure environment.

The second option is less optimal, although it does provide a single policy across devices. The major problem here concerns the fact that traffic which should not be accessible via the firewall is allowed through. In Figure 6-1, the administrators do not want external connections to the data server to traverse their backbone. If a single policy allows traffic to both data servers, however, an end-user may be able to insert her public traffic on the private network. To prevent this from occurring, while maintaining a single policy for devices, you can use the third option, which we describe in this recipe.

When a common policy is applied to a group of firewalls, it is typically performed using NSM. However, NSM and most object management tools allow for a single-named object to be represented only once. To create unique object definitions per device, static DNS is used to create locally significant values for the data server object. When the address book entry is created, instead of pointing to the IP address, it points to the FQDN, which, when locally resolved, translates to a separate IP per device. This allows for a single policy referencing a single object to achieve local significance. Using an external DNS server, which has locally significant entries per data center, can create the same effect with greater scalability. To do this, simply point each firewall at the local DNS server using the set dns host dns1 <ip address> command.

You need to provide internal DNS servers for internal resolution, and public servers for external resolution.

Configure the DNS proxy:

	FIREWALL-A-> set dns proxy
	FIREWALL-A-> set dns proxy enable
	FIREWALL-A-> set interface wireless1 proxy dns
	FIREWALL-A-> set dns server-select domain juniper.net primary-server
	    10.1.1.1
	FIREWALL-A->set dns server-select domain * primary-server
	    68.87.64.146 secondary-server 68.87.75.194

You can use the DNS proxy functionality in ScreenOS to enable split DNS. Figure 6-2 shows a typical DNS proxy solution.

Figure 6-2 illustrates a traditional Small Office/Home Office (SOHO)environment. A firewall is deployed in the remote office, and an IPSec tunnel is built to headquarters. The administrators have deployed a “split tunneling” environment in which all traffic bound for corporate headquarters is sent to the IPSec tunnel, whereas external traffic is sent directly to the Internet Service Provider (ISP).

The need for “split DNS” arises for internal hosts that resolve to private addresses (that cannot be resolved publicly or that resolve to different addresses if they are using private DNS versus public DNS). When the DNS proxy is enabled on an interface, the firewall will act as the DNS resolver for the clients. You can use either static configuration on the client or DHCP to assign the firewall as the client DNS server.

Figure 6-2. A typical DNS proxy example

When a client needs to do a DNS lookup, it will send the request to the firewall, and the firewall will then relay the request to the appropriate DNS server based on the domain in the request.

The administrator can configure up to 32 domains that can each point to a separate DNS server, if required. To enable the DNS proxy, configure the DNS proxy and, on a per-interface basis, enable proxy functionality for all interfaces with clients that need split DNS functionality. Next, create a list of domains and the servers to which they will resolve. The get dns server-select command shows the mapping of domain names to servers:

	FIREWALL-A-> get dns server-select
	usage: 2/32
	---------------------------------------------------------------------
	juniper.net
	      [static]
	    Server IP:            Interface: null                 Failover :
	    [disabled]
	       |--> 10.1.1.1                     [static]
	       |--> 68.87.64.146
	       |--> 68.87.75.194
	*

	[static]
	Server IP: Interface: null Failover :
	[disabled]
	   |--> 68.87.64.146 [static]
	   |--> 0.0.0.0
	   |--> 0.0.0.0
	----------------------------------------------------------------------

The get dns server-select command shows how many domain mappings have been defined, as well as the domains, the source interface that the domains should use, and the IPs of the DNS servers to which each domain resolves. In this example, you’ll see that the juniper.net domain resolves to an internal DNS server, whereas all other domains, as indicated by the * in the output, will resolve to the ISP’s DNS.

You can see the DNS proxy functionality in action using the debug dns proxy command:

	my-computer:~ me$ nslookup
	> server 192.168.4.1
	Default server: 192.168.4.1
	Address: 192.168.4.1#53
	> www.oreilly.com
	Server:          192.168.4.1
	Address:         192.168.4.1#53

	Non-authoritative answer:
	Name:   www.oreilly.com
	Address: 208.201.239.36
	Name:   www.oreilly.com
	Address: 208.201.239.37
	> www.juniper.net
	Server:         192.168.4.1
	Address:        192.168.4.1#53

	Name:    www.juniper.net
	Address:  207.17.137.229

	FIREWALL-A-> get db str
	## 2007-08-06 17:20:10 : Proxy: Processing request from client
	    192.168.4.34
	    port 53043
	## 2007-08-06 17:20:10 : Proxy: Host name for lookup is www.oreilly.com
	    type 1
	## 2007-08-06 17:20:10 : Proxy: Looking up best match
	## 2007-08-06 17:20:10 : Proxy: New best match len id 1
	## 2007-08-06 17:20:10 : Proxy: Selecting primary
	## 2007-08-06 17:20:10 : Proxy: DNS socket send returned 0 for server
	    68.87.64.146
	## 2007-08-06 17:20:10 : Proxy: new socket being set 151 to server
	    68.87.64.146
	## 2007-08-06 17:20:10 : Proxy: DNS socket receive 65 bytes from server
	## 2007-08-06 17:20:10 : Proxy: Processing response for client
	    192.168.4.34 port 53043
	## 2007-08-06 17:20:10 : Proxy: Updating cache for www.oreilly.com type
	    1 from the proxy
	## 2007-08-06 17:20:10 : Proxy: Extract data returned 0
	## 2007-08-06 17:20:10 : Proxy: Sending out a response to the client
	## 2007-08-06 17:20:10 : Proxy: DNS socket send returned 0
	## 2007-08-06 17:20:13 : Proxy: Processing request from client
	    192.168.4.34 port 53044
	## 2007-08-06 17:20:13 : Proxy: Host name for lookup is www.juniper.
	     net type 1
	## 2007-08-06 17:20:13 : Proxy: Looking up best match
	## 2007-08-06 17:20:13 : Proxy: New best match len id 11
	## 2007-08-06 17:20:13 : Proxy: Selecting primary
	## 2007-08-06 17:20:13 : Proxy: DNS socket send returned 0 for server
	    10.1.1.1
	## 2007-08-06 17:20:13 : Proxy: new socket being set 152 to server
	    10.1.1.1
	## 2007-08-06 17:20:13 : Proxy: DNS socket receive 255 bytes from
	    server
	## 2007-08-06 17:20:13 : Proxy: Processing response for client
	    192.168.4.34 port 53044
	## 2007-08-06 17:20:13 : Proxy: Updating cache for www.juniper.net
	    type 1 from the proxy
	## 2007-08-06 17:20:13 : Proxy: Extract data returned 0
	## 2007-08-06 17:20:13 : Proxy: Sending out a response to the client
	## 2007-08-06 17:20:13 : Proxy: DNS socket send returned 0

The resolution seen here for www.oreilly.com is sent to the default DNS server at 68.87.64.146. Likewise, www.juniper.net is resolved by 10.1.1.1. When using the DNS proxy, the firewall will use the best match so that more specific domains can be used to resolve against different servers. Also, as expected, the reply is cached:

	FIREWALL-A-> get dns host cache
	DNS Server:
	  Primary :             68.87.64.146, Src Interface: Null
	  Secondary:            68.87.75.194, Src Interface: Null
	  Ternary :                  0.0.0.0, Src Interface: Null
	DNS Cache (Static):
	DNS Cache (Dynamic):
	 Host name:         www.oreilly.com IP: 208.201.239.36 TTL= 15799s
	 Host name:         www.oreilly.com IP: 208.201.239.37 TTL= 15799s
	 Host name:         www.juniper.net IP: 207.17.137.229 TTL= 86307s
	DNS Cache (Unresolved):
	DNS Cache (Freed):

Recipe 6.5

You want to use DDNS to create a VPN tunnel to a device with a dynamic IP address.

Use DDNS and define the IKE gateway using an FQDN. First, register with a DDNS service such as dyndns.com. Then, on the firewall, configure DDNS:

	FIREWALL-A-> set dns ddns
	FIREWALL-A-> set dns ddns id 1 server members.dyndns.org server-type
	    dyndns
	FIREWALL-A-> set dns ddns id 1 username screenosckbk password
	aS4k21zvNI+TCUsoG7CISNgK8HnXHa92Qg==
	FIREWALL-A->set dns ddns enable

Create the IKE gateway using the FQDN of the remote end as the IP address in the set ike gateway command:

	FIREWALL-A-> set ike gateway screenosckbk address
	    screenosckbk.dyndns.org main preshare iamakey sec-level standard
	FIREWALL-A-> set vpn screenosckbk gateway screenosckbk tunnel
	    sec-level standard
	FIREWALL-A-> set vpn screenosckbk bind interface tunnel.1
	FIREWALL-A->set vpn screenosckbk monitor optimized rekey

ScreenOS can act as a DDNS client for devices with dynamic IP addresses. These devices are typically SSG series devices that are deployed in SOHO environments and are often connected to cable modems or Digital Subscriber Line (DSL) links where the users do not know their IP addresses. By acting as a DDNS client, the firewall registers its Untrust IP address with a DDNS service such as dyndns.com. In doing so, the firewall can actively receive inbound connections, such as for use with a VIP, or as an IKE endpoint.

When acting as an IKE endpoint, an additional benefit is realized. Although aggressive mode IKE addresses the problems associated with forming a tunnel to a device with a dynamic address, there is an associated cost from a security perspective—the IKE ID (in an aggressive mode)negotiation is sent in the clear. Main mode solves this, but works only with dynamic endpoints if using digital certificates for authentication.

Because the DNS resolver component within ScreenOS is used prior to the IKE component in establishing a security association, from the IKE process’s point of view, using an FQDN in the IKE gateway definition is equivalent to using an IP address. For this reason, you can use main mode IKE in association with preshared keys even when the devices have dynamic IP addresses. For example, look at the output of get ike gateway:

	FIREWALL-A-> get ike gateway
	 Id Name             Gateway Address Gateway ID      Mode Proposals
	---- --------------- --------------- --------------- ---- ---------
	   0 screenosckbk    72.76.163.251                   Main
	    pre-g2-3des-sha,pre-g2-aes128-sha
	  Total Gateways: 1 (1 including dynamic peers)
	user with ASN1_DN type ID sort list:

Upon entering the set ike gateway command, a DNS lookup is performed, and the IP address that is returned is used for IKE transmissions. To further reinforce this notion, the get sa command in turn shows only the IP address for the remote gateway:

	FIREWALL-A-> get sa
	total configured sa: 1
	HEX ID    Gateway          Port Algorithm      SPI     Life:sec kb Sta
	    PID vsys
	00000001<   72.76.163.251   500 esp:3des/sha1 bb2e570c 3389 unlim A/U
	      -1 0
	00000001>   72.76.163.251   500 esp:3des/sha1 4e66cf52 3389 unlim A/U
	      -1 0

Examining the DNS cache, the TTL can be verified:

	FIREWALL-A-> get dns host cache
	DNS Server:
	  Primary :             68.87.64.146, Src Interface: Null
	  Secondary:            68.87.75.194, Src Interface: Null
	  Ternary :                  0.0.0.0, Src Interface: Null
	DNS Cache (Static):
	 DNS Cache (Dynamic):
	 Host name:  screenosckbk.dyndns.org IP: 72.76.163.251 TTL= 24s
	DNS Cache (Unresolved):
	DNS Cache (Freed):

Notice that the TTL for the domain is only 24 seconds in the preceding code snippet. After 24 seconds, the firewall will requery for the address of screenosckbk.dyndns.org.

Using DDNS for IKE gateway definition solves a key problem with maintaining a VPN. Namely, it solves the problem of location. Without the use of Autoconnect VPN, it is impossible to reliably define an IKE gateway if the device has a dynamic IP address on its Untrusted interface. Because the DNS resolver is invoked immediately upon definition of an IKE gateway in ScreenOS, using the FQDN to establish a gateway provides the address for the gateway, which is a necessary component for using main mode IKE and preshared keys. DDNS and gateway definition via FQDN provide a way to have dynamically addressed devices as VPN gateways without sacrificing the security benefits of main mode IKE, and without the overhead of running a PKI.

Recipe 6.5; Recipe 6.9

You need to firewall an environment with a dynamic public IP address.

Configure the firewall’s Untrust interface as a DHCP client:

	FIREWALL-A-> set interface ethernet3 zone Untrust
	FIREWALL-A->set interface ethernet3 dhcp client enable

Lower-end firewalls, such as the SSG series, have the capability to act as DHCP clients. This is useful in environments where a static IP address is not available, such as in a SOHO environment with a broadband Internet connection. The configuration is straightforward. The get interface <interface name> command returns the DHCP client status, as well as the IP address and gateway, once obtained:

	FIREWALL-A-> get int e3
	Interface ethernet3:
	  description ethernet3
	  number 1, if_info 88, if_index 0, mode route
	  link up, phy-link up/full-duplex
	  vsys Root, zone Untrust, vr trust-vr
	  dhcp client enabled
	  PPPoE disabled
	  admin mtu 0, operating mtu 1500, default mtu 1500
	  *ip 68.38.120.27/24 mac 0010.db7f.5e81
	  gateway 68.38.120.1
	  *manage ip 68.38.120.27, mac 0010.db7f.5e81
	  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
	  bandwidth: physical 100000kbps, configured egress
	    [gbw 0kbps mbw 0kbps]
	             configured ingress mbw 0kbps, current bw 3kbps
	              total allocated gbw 0kbps
	  DHCP-Relay disabled
	  DHCP-server disabled
	Number of SW session: 4046, hw sess err cnt 0

Once configured, the DHCP client will attempt to obtain an address for the interface until it is successful. To refresh the IP address, use the exec dhcp client renew command:

	FIREWALL-A-> exec dhcp client ethernet3 renew
	FIREWALL-A-> get event
	2007-08-13 22:59:44 system info 00530 DHCP server 68.87.64.13
	                                      assigned interface ethernet3
	                                      with IP address 68.38.120.27
	                                      (lease time 5269 minutes).

Using DHCP to obtain firewall interface information provides a simple, easy-to-use provision method of IP assignment, and allows for integration into environments where static IP addresses are not available.

You need the firewall to provide DHCP services to computers on the trusted interface.

Configure the firewall as a DHCP server:

	FIREWALL-A> set interface ethernet1 dhcp server service
	FIREWALL-A> set interface ethernet1 dhcp server auto
	FIREWALL-A> set interface ethernet1 dhcp server ip 192.168.3.33 to
	    192.168.3.126
	FIREWALL-A> set interface ethernet1 dhcp server option gateway
	    192.168.3.1
	FIREWALL-A> set interface ethernet1 dhcp server option netmask
	    255.255.255.0
	FIREWALL-A> set interface ethernet1 dhcp server option domainname screenosckbk.
	oreilly.com
	FIREWALL-A> set interface ethernet1 dhcp server option dns1 10.1.1.1
	FIREWALL-A>set interface ethernet1 dhcp server option dns2 10.2.1.1

The SSG series devices have the capability to operate as DHCP servers. This functionality is typically deployed in a branch or SOHO environment. DHCP is configured on a per-interface basis, and is actually enabled by default on lower-end devices in the trusted zone for ease of deployment.

The first step in configuring DHCP server functionality is to enable the DHCP service on the interface. You should apply the set interface ethernet1 dhcp server auto command before you configure the IP pool. This command starts the server in auto-probing mode.

When auto-probing mode is configured, the firewall will first send out its own DHCP Discover packets to ensure that there are no other DHCP servers on the LAN. If a DHCP Offer is received, the server will not activate. This prevents incorrect IP ranges from being given out, or worse, overlapping IP addresses from being handed out by different servers. If no DHCP servers on the LAN reply to the Discover messages, the server on the firewall will consider itself to be active, and will begin the process of handing out IP information to attached clients.

Next, the IP range is defined along with the option statements, which provide enough for basic connectivity. The options shown in this recipe are the standard option values. In many cases, additional information is passed to the client via the DHCP process. ScreenOS provides a number of predefined DHCP options, as listed here:

	FIREWALL-A-> set interface ethernet1 dhcp server option ?
	custom               custom option
	dns1                 dns
	dns2                 dns
	dns3                 dns
	domainname           domain name
	gateway              client gateway
	lease                lease
	netmask              netmask
	news                 news
	nis1                 net info server
	nis2                 net info server
	nistag               net info tag
	pop3                 pop3
	smtp                 smtp
	wins1                wins
	wins2                wins

In some cases, you may need to provide options that are not predefined. A common example of this is option 66, the Trivial File Transfer Protocol (TFTP) server name. To accomplish this, create a custom option:

	FIREWALL-A-> set interface ethernet1 dhcp server option custom 66
	    string 10.3.1.1

This command will send the IP address 10.3.1.1 to the clients as their TFTP server. This is commonly used for IP phones. Three types of options are supported: integer, IP address, and string. You can find a full list of standard DHCP options in RFC 2132.

For simplified deployment, ScreenOS provides a full-featured DHCP server on the SSG series and older appliance products.

Recipe 6.9; Recipe 6.11

You need to configure the firewall to provide DHCP option information to DHCP clients, but the values for the options aren’t known ahead of time.

Configure an automatic DHCP setting update:

	FIREWALL-A-> set interface ethernet3 dhcp client settings
	    update-dhcpserver

In scenarios where the Untrusted interface is acting as a DHCP client, the values for the domain name, DNS servers, and other DHCP options are often not known ahead of time. Using the set interface <Untrusted interface> dhcp client settings update-dhcpserver command allows the administrator to automatically populate these option fields with the values learned by the DHCP client.

Recipe 6.9; Recipe 6.10

You need to provide DHCP services on the system products.

Configure DHCP relay on the interface for which you want to provide DHCP services:

	FIREWALL-A-> set interface ethernet2 dhcp relay service
	FIREWALL-A-> set interface ethernet2 dhcp relay server-name 10.3.1.1
	FIREWALL-A-> set address untrust DHCP_SVR_10.3.1.1 10.3.1.1/32
	FIREWALL-A->set policy from untrust to trust DHCP_SVR_10.3.1.1 any
	dhcp-relay permit log

Juniper Networks’ firewall system products, which include the NS5000 Series and the ISG Series, do not have DHCP server functionality built-in. As these devices are typically used to protect large-scale environments, they are frequently sandwiched in between pairs of routers. Furthermore, DHCP servers are often already available and installed elsewhere in the network. Occasionally, however, hosts requiring DHCP services are directly connected to the firewall.

To accommodate DHCP services for hosts that connect to the firewall as their gateway, you can set up DHCP relay. To configure DHCP relay, simply enable the DHCP relay service on the interface, and configure the server address to forward the DHCP messages.

If you want to send these messages across a tunnel, use the set interface <interface name> dhcp relay vpn command. Additionally, a policy which permits dhcp-relay from the server to the client side—in this case, from untrust to trust—is required.

You can verify that DHCP relay is enabled on the interface by using the get interface command:

	FIREWALL-A-> get int eth2
	Interface ethernet2:
	  description ethernet2
	  number 7, if_info 616, if_index 0, mode route
	  link up, phy-link up/full-duplex
	  vsys Root, zone DMZ, vr trust-vr
	  dhcp client disabled
	  PPPoE disabled
	  admin mtu 0, operating mtu 1500, default mtu 1500
	  *ip 192.168.5.1/24 mac 0010.db7f.5e87
	  *manage ip 192.168.5.1, mac 0010.db7f.5e87
	  route-deny disable
	  pmtu-v4 disabled
	  ping enabled, 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 enabled BGP disabled RIP disabled RIPng disabled mtrace
	     disabled
	  PIM: not configured IGMP not configured
	  bandwidth: physical 100000kbps, configured egress
	    [gbw 0kbps mbw 0kbps]
	             configured ingress mbw 0kbps, current bw 0kbps
	              total allocated gbw 0kbps
	  DHCP-Relay enabled, server 10.3.1.1
	  DHCP-server disabled
	Number of SW session: 4055, hw sess err cnt 0

For more concise output, use the get interface <interface name> dhcp relay command:

	FIREWALL-A-> get int eth2 dhcp relay
	DHCP Server(s): "10.3.1.1"
	VPN encryption is disabled

You need to view and maintain the DHCP server operations.

Use get commands:

	FIREWALL-A-> get interface wireless2 dhcp server
	Mode: ENABLED
	State: ON
	DHCP send zero next server ip value.
	Allow server information update from any dhcp upstream interface.
	FIREWALL-A-> get interface wireless1 dhcp server ip allocate
	       IP               State        MAC        Lease Time
	 192.168.4.36           COMMIT  *0016ce2c61ce   2442 minutes
	 192.168.4.34           COMMIT  *0019e3dbf490   3474 minutes
	 192.168.4.33           COMMIT  *00904b5d08f5   853 minutes
	FIREWALL-A-> get interface wireless1 dhcp server option
	DHCP Server Options:
	        Lease:          3 days 0 hours 0 minutes
	        IP Range:       192.168.4.33 - 192.168.4.126
	        Netmask:        255.255.255.0
	        Gateway:        192.168.4.1
	        Domain Name:    screenosckbk.oreilly.com.
	        DNS:            10.1.1.1       10.2.1.1    0.0.0.0
	        WINS:           0.0.0.0         0.0.0.0
	        SMTP:           0.0.0.0
	        POP3:           0.0.0.0
	        NEWS:           0.0.0.0
	        NetInfo:        0.0.0.0         0.0.0.0
	        Custom (66):    10.3.1.1

You can use ScreenOS’s get commands to view a feature’s functionality. In the get interface wireless2 dhcp server command, the DHCP server is enabled and on, and is not using the next server option which allows configuration information to be shared among multiple DHCP servers. Also, the DHCP client will update information to the server component, as mentioned in Recipe 6.11.

The get interface <interface name> dhcp server ip allocate command shows the allocated IPs per interface, as well as the Media Access Control (MAC) address and time remaining in the lease. As each interface can have its own DHCP settings, different ranges may be configured on the device. To reset the DHCP leases, use the clear dhcp server <interface name> ip command. You can use this command to clear all leases or just a particular IP address:

	FIREWALL-A-> clear dhcp server wireless1 ip all
	FIREWALL-A-> get db str
	## 2007-08-17 23:15:51 : DHCP: got packet from if <ethernet3>.
	## 2007-08-17 23:15:58 : DHCP: Opened file "flash:dhcpservl.txt" for
		writing
	## 2007-08-17 23:15:58 : DHCP: Wrote 8 bytes
	## 2007-08-17 23:15:58 : DHCP: Saving 1 IPs (ethernet1):
	## 2007-08-17 23:15:58 : DHCP: 0: 192.168.3.33 - 0013101d4b15 - 2344
	## 2007-08-17 23:15:58 : DHCP: Wrote 44 bytes
	## 2007-08-17 23:15:58 : DHCP: Saving 0 IPs (wireless1):
	## 2007-08-17 23:15:58 : DHCP: Saving 1 IPs (wireless2):
	## 2007-08-17 23:15:58 : DHCP: 0: 192.168.2.33 - 00054e44c0ba - 2831
	## 2007-08-17 23:15:58 : DHCP: Wrote 44 bytes
	## 2007-08-17 23:15:58 : DHCP: Saving 0 IPs (wireless4):
	## 2007-08-17 23:15:58 : DHCP: Closed file
	## 2007-08-17 23:15:58 : DHCP: HA (v2) send (NSRP Request) from peer
		(200 bytes)

	## 2007-08-17 23:15:59 : DHCP: got packet from if <ethernet3>.

When the clear dhcp server <interface name> ip all command is issued, the flash: dhcpserv1.txt file is modified. This file is used to store DHCP lease information so that leases can survive a system reboot. When the file is modified, each interface that is not cleared has the lease information for that interface rewritten so as to preserve the information.

The get interface <interface name> dhcp server option command shows all options configured on the DHCP server for that interface, including custom options. When custom options are configured, each option appears in the command output with the name Custom, and the code in parentheses immediately following.

Recipe 6.10