O'Reilly logo

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

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

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

Start Free Trial

No credit card required

1.1. ScreenOS Architecture

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

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

Virtual Router

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

The relationship between key elements of ScreenOS

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

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

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

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

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

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

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

	Total 5/max entries

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

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

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

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

	Total 5/max entries

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

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

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

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

We will discuss routing in more detail in Chapter 4.

Zones

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

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

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

Security zone

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

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

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

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

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

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

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

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

Functional zones

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

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

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

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

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

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

Interfaces

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

	bottom-ssg140-> get interface

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

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

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

  • Redundant

  • Aggregate

  • Bridge Group

  • VLAN

  • Loopback

  • Tunnel

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

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

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

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

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

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

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

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

Tip

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

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

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

Redundant

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

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

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

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

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

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

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

Aggregate

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

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

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

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

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

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

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

Tip

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

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

Bridge Groups

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

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

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

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

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

Loopback

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

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

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

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

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

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

VLAN

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

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

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

Tunnel

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

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

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

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

Summary

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

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

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

Start Free Trial

No credit card required