RadiSys SEG-100 Administration Manual

Security gateway

Table of Contents

Quick Links

Administration Guide

SECURITY GATEWAY

SEG-100

SOFTWARE RELEASE 1.1

February 2012

007-03416-0003

Table of Contents

Need help?

Do you have a question about the SEG-100 and is the answer not in the manual?

Questions and answers

Summary of Contents for RadiSys SEG-100

Page 1 Administration Guide SECURITY GATEWAY SEG-100 SOFTWARE RELEASE 1.1 February 2012 007-03416-0003...
Page 2: Revision History
Added IPv6 information. Made other corrections and clarifications. -0003 February 2012 Fourth edition. Updated for the 1.1.2 software release. See What’s new in this manual on page 6 for a description of changes in this edition. © 2011‐2012 by RadiSys Corporation. All rights reserved. Radisys is a registered trademark of RadiSys Corporation. AdvancedTCA, ATCA, and PIGMG are registered trademarks of PCI Industrial Computer Manufacturers Group. All other trademarks, registered trademarks, service marks, and trade names are the property of their respective owners.
Page 3: Table Of Contents
Table of Contents Preface ..............................6 About this manual............................6 What’s new in this manual...........................6 Where to get more product information .......................6 Related documents............................7 Notational conventions ..........................7 Chapter 1: Overview........................... 8 SEG overview..............................8 SEG architecture ............................8 Chapter 2: Management........................12 Management access ..........................12 Date and time ............................33 Licensing ..............................37 Backup and restore ...........................39...
Page 4 Chapter 6: Firewall ........................... 96 IP rules ..............................96 Services..............................103 Access rules ............................107 Internet access ............................110 Chapter 7: IPsec VPN ........................113 Overview..............................113 IPsec components ...........................117 Setting up IPsec tunnels .........................135 NAT traversal............................138 CA server access ............................140 IPsec troubleshooting ..........................143 Chapter 8: Authentication......................153 Authentication profiles ..........................153 RADIUS authentication ...........................154 The radiussnoop command ........................156...
Page 5 Support for multiple GGSNs ........................184 I-WLAN use case ............................184 Appendix A: Glossary of Terms....................185 Appendix B: OSI Model........................197 Overview ..............................197...
Page 6: Preface
Preface About this manual This manual describes the Radisys SEG, a highly scalable security gateway optimized for Long Term Evolution (LTE) deployments. This manual introduces SEG software concepts and serves as a reference for procedural and usage information. The target audience for this manual is administrators who are responsible for configuring and managing the SEG and its operating system. It is assumed that the administrators have basic knowledge of networks and network security. What’s new in this manual • Added troubleshooting with ICMP on page 25. ping • Changed the types of authentication available on page 153. • Updated verifying HA synchronization on page 165. Where to get more product information Visit the Radisys web site at www.radisys.com for product information and other resources. Downloads (manuals, release notes, software, etc.) are available at www.radisys.com/downloads. See the following resources for information on the SEG not described in this manual: • The SEG‐100 Getting Started Guide describes how to set up the SEG‐100 modules and the SEG‐11002 system, and how to configure the SEG software for initial use. • The SEG‐100 Command Line Interface Reference describes the SEG command line interface and serves as a reference for command syntax and options. • The SEG‐100 Log Reference describes all log messages generated by the SEG.
Page 7: Related Documents
Preface Related documents RFC 791, Internet Protocol, IETF, September 1981. RFC 1191, Path MTU Discovery, IETF, November 1990. RFC 1305, Network Time Protocol (Version 3), IETF, March 1992. RFC 1321, The MD5 Message‐Digest Algorithm, IETF, April 1992. RFC 1777, Lightweight Directory Access Protocol, IETF, March 1995. RFC 1918, Address Allocation for Private Internets, IETF, February 1996. RFC 2030, Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, IETF, October 1996. RFC 2138, Remote Authentication Dial In User Service (RADIUS), IETF, April 1997. RFC 2139, RADIUS Accounting, IETF, April 1997. RFC 2251, Lightweight Directory Access Protocol (v3), IETF, December 1997. RFC 2401, Security Architecture for the Internet Protocol, IETF, November 1998. RFC 2406, IP Encapsulating Security Payload (ESP), IETF, November 1998. RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, IETF, December 1998. RFC 3947, Negotiation of NAT‐Traversal in the IKE, IETF, January 2005. RFC 4306, Internet Key Exchange (IKEv2) Protocol, IETF, December 2005. RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification, IETF, June 2010. Notational conventions This manual uses the following conventions ItalicText File, function, and utility names. Screen text and syntax strings. MonoText BoldMonoText A command to enter. Variable parameters. ItalicMonoText Brackets [ ] Command options. Curly braces { } A grouped list of parameters. Vertical line | An “OR” in the syntax. Indicates a choice of parameters. All numbers are decimal unless otherwise stated.
Page 8: Chapter 1: Overview
Chapter Overview SEG overview The Radisys SEG is a robust telecom security gateway based on Network Domain Security (NDS) standards that provides stateful firewalling and IPsec tunneling in a single platform. The SEG can be used to secure any large IP based network. In its first release, the SEG is targeted for use as a security gateway between infrastructure elements in LTE Access/Backhaul and LTE Evolved Packet Core networks. In subsequent releases, the SEG will support current generation (2G/3G) wireless offload applications like I‐WLAN, UMA/GAN and Femtocell that are evolving to LTE. It is also ideally suited for high performance and next‐gen firewalling scenarios. The Radisys SEG is built around the carrier‐grade Advanced Telecommunications Computing Architecture (ATCA), and offers world‐class security features with multi‐gigabit throughput and performance. The main component of the Radisys SEG is the SEG‐100 security module, a fully contained security gateway residing on an ATCA module. The SEG‐100 can be deployed in a standalone SEG‐11002 system, or integrated into other ATCA based network elements. Both standalone and integrated configurations support carrier grade high availability with redundant hardware and sophisticated fault tolerant software. The SEG‐11002 is a 2U, 2‐slot ATCA system, ideally suited for initial trials and small‐to‐ medium size deployments. It contains one or two SEG‐100 modules, and can be configured as a high availability system, with active and passive SEG‐100s providing full stateful redundancy for IPsec tunnels and packet flows. The SEG security software is based on a proprietary operating core with a small attack surface, making the application processing highly secure and efficient. The software processes millions of concurrent IP packet flows in real time, while applying a rich set of firewalling rules and routing policies. It also sets up VPN/IPsec tunnels, using secure keys and applying advanced data integrity and encryption techniques. SEG architecture The SEG architecture is centered on the concept of flows. Traditional IP routers or switches commonly inspect all packets and then perform forwarding decisions based on information found in the packet headers. With this approach, packets are forwarded without any sense of context, which eliminates any possibility to detect and analyze complex protocols and enforce corresponding security policies. ...
Page 9: Stateful Inspection
Overview Stateful inspection The SEG employs a technique called stateful inspection which means that it inspects and forwards traffic on a per‐flow basis. The SEG detects when a new flow between a source and destination is being established, and keeps information about the flow over its lifetime. By doing this, the SEG is able to understand the context of network traffic, enabling it to perform a variety of important functions. The stateful inspection approach additionally provides high throughput performance with the added advantage of a design that is highly scalable. The SEG subsystem that implements stateful inspection is sometimes referred to as the SEG state‐engine. All flows have a specified idle lifetime, after which they are removed from the flow table. Basic building blocks From the administrator’s viewpoint, the basic SEG building blocks are: • Interfaces such as physical Ethernet interfaces or logical VPN tunnels. • Logical objects that are individual logical definitions within the SEG. For example, Address objects can be defined in the Address Book to give logical names to IP and other types of addresses. • Rule sets that make up the security policies that you want to implement. These include IP rules. These three types of building blocks are discussed next. Interfaces Interfaces are the doorways through which network traffic enters or leaves the security gateway. Without interfaces, an SEG system has no means for receiving or sending traffic. The following types of interface are supported in the SEG: • Physical interfaces These correspond to the actual physical Ethernet interface ports through which traffic arrives and leaves the hardware platform running the SEG. • Tunnel interfaces Used for receiving and sending traffic through VPN tunnels. These are treated as logically equivalent to physical interfaces when you configure the SEG. For example, a route in an SEG routing table could specify either a physical or tunnel interface as the destination for a particular network. The SEG interface design is symmetric, meaning that the interfaces of the device are not fixed ...
Page 10 Overview Logical objects You can consider logical objects to be predefined building blocks for use in rule sets. For example, the address book contains named objects representing host and network addresses. Another example of logical objects are services that represent specific protocol and port combinations. SEG rule sets Finally, rules which are defined by the administrator in the various rule sets are used for actually implementing SEG security policies. The most fundamental set of rules are the IP Rules, which are used to define Layer 3 IP filtering policies. Basic packet flow This section outlines the basic flow for packets received and forwarded by the SEG. The following description is simplified and might not be fully applicable in all scenarios, however, the basic principles will be valid for all SEG deployments. 1. An Ethernet frame is received on one of the Ethernet interfaces in the system. Basic Ethernet frame validation is performed and the packet is dropped if the frame is invalid. 2. The IP datagram within the packet is passed on to the SEG consistency checker. The checker performs a number of consistency checks on the packet, including validation of checksums, protocol flags, packet length and so on. If the consistency checks fail, the packet gets dropped and the event is logged. 3. The SEG now tries to look up an existing flow by matching parameters from the incoming packet. A number of parameters are used in the match attempt, including the source interface, source and destination IP addresses, and IP protocol. If a match cannot be found, a flow establishment process starts. 4. The Access Rules are evaluated to find out if the source IP address of the new flow is allowed on the received interface. If no Access Rule matches then a reverse route lookup will be done in the routing tables. In other words, by default, an interface will only accept source IP addresses that belong to networks routed over that interface. A reverse lookup means that a lookup is done in the routing tables to confirm that a route exists that would route traffic destined for the IP address over that interface. If the Access Rule lookup determines that the source IP is invalid, the packet is dropped ...
Page 11 Overview 6. The IP rules are now searched for a rule that matches the packet. The following parameters are part of the matching process: • Source and destination interfaces • Source and destination network • IP protocol (for example TCP, UDP, ICMP) • TCP/UDP ports • ICMP types • Point in time in reference to a predefined schedule If a match cannot be found, the packet is dropped. If a rule is found that matches the new flow, the Action property of the rule is used to decide what the SEG should do with the flow. If the action is Drop, the packet is dropped and the event is logged according to the log settings for the rule. 7. If the action is Allow, the packet is allowed through the system. A corresponding flow will be noted by the SEG for matching subsequent packets belonging to the same flow. The allowed traffic is also bidirectional so that the same IP rule also permits packets to return from the destination network. Finally, the opening of the new flow will be logged according to the log settings of the rule. The default is for logging to be enabled. 8. Eventually, the packet will be forwarded out on the destination interface according to the flow. If the destination interface is a tunnel interface, additional processing such as encryption or encapsulation might occur. ...
Page 12: Chapter 2: Management
Chapter Management Management access This section provides details of how to work with the SEG management interfaces. The following interfaces are available: • Command line interface (CLI) The Command Line Interface (CLI) is accessible either locally via a computer’s serial console port or remotely using the Secure Shell (SSH) protocol. It provides fine‐grained control over all parameters in the SEG. This feature is described further in Command line interface on page 15. • SNMP A Secure Network Management Protocol (SNMP) client can connect to the SEG and provide read‐only access to the current SEG configuration. This feature is described further in SNMP monitoring on page 31. File transfer with secure copy Secure Copy (SCP) is a widely used communication protocol for file transfer. SCP is a complement to the CLI and provides a secure means of file transfer between the administrator's external management workstation and the SEG. Various files used by the SEG, such as configuration backups, can be both uploaded and downloaded using SCP. No specific SCP client is provided with SEG distributions. However, there is a wide selection of third‐party SCP clients for nearly all workstation platforms. This feature is described further in Secure copy on page 30. Local user databases By default, the SEG provides a default LocalUserDatabase object that is used to authenticate management logins. This database contains, at minimum, one predefined user account:  Username: admin Password: admin This account has full administrative read/write privileges to all configuration data and is always the account used for initial SSH login (console access does not require login in the default configuration). Important: ...
Page 13 Management Displaying local user databases With the SEG CLI, the name of the predefined local user database can be displayed with the command: Device:/> show LocalUserDatabase Name ‐‐‐‐‐‐‐‐‐‐ AdminUsers The contents of this can be displayed by first changing the CLI context to be the database: Device:/> cc LocalUserDatabase AdminUsers The CLI prompt will change to indicate the new context and the database contents can be displayed: Device:/LocalUserDatabase/AdminUsers> show User Name Groups Comments ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ admin Administrators <empty> Here, the Group membership is significant since this determines the privileges that a user has. Finally, return to the default context: Device:/LocalUserDatabase/AdminUsers> cc Device:/> Creating Auditor accounts Extra user accounts in the local user database can be created as required with arbitrary usernames and passwords. If the group is specified as Administrators, it has full access privileges. If, however, the group is specified as the text string Auditors, the user will only have read‐only privileges and will not be able to make configuration changes. The following commands create an auditor account with a username of audit and a password of audit: Device:/> cc LocalUserDatabase AdminUsers Device:/LocalUserDatabase/AdminUsers> add User audit Password=audit Groups=Auditors...
Page 14 Management A complete listing of this database will show the new account: Device:/LocalUserDatabase/AdminUsers> show User Name Groups Comments ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ admin Administrators <empty> + audit Auditors <empty> Device:/LocalUserDatabase/AdminUsers> cc Device:/> Here, the group name Auditors is a text string and its meaning is predefined in the SEG. The plus sign “+” next to the new user audit indicates that this object has not yet been committed to the configuration. Linking logins to the database The local user database is referred to during a login because the relevant access object points to an AuthenticationProfile, which then points to the database that stores the credentials. For example, SSH logins are controlled by a RemoteMgmtSSH object. This object refers to an AuthenticationProfile object that then refers to the database to be used for authentication. AuthenticationProfile objects are discussed further in Authentication on page 153. The diagram below illustrates the relationship between the various components. Figure 1. Local user database usage with SSH...
Page 15: Command Line Interface
Management Command line interface The CLI provides a comprehensive set of commands that allow the display and modification of a SEG configuration. This section provides only a summary for using the CLI. For a complete reference for all CLI commands, see the SEG‐100 Command Line Interface Reference. CLI access methods The CLI is accessible in one of two ways: • Remotely through a network connection to an Ethernet interface on the hardware platform, using the Secure Shell (SSH) protocol from an SSH client. SSH access is controlled by a predefined RemoteMgmtSSH configuration object. • Locally through the RS232 serial console connection port of a SEG, using a console or console emulator. Access is controlled by a predefined ComPortAccess configuration object called COM1. Controlling SSH access The Secure Shell (SSH) protocol can be used to access the CLI over a network from a remote host via one of the Ethernet interfaces. SSH is enabled by default on the default management Ethernet interface. SSH is a protocol primarily used for secure communication over insecure networks, providing strong authentication and data integrity. SSH clients are freely available for almost all hardware platforms. The SEG supports version 2 of the SSH protocol. A predefined RemoteMgmtSSH object controls initial SSH access on the default management interface. A single RemoteMgmtSSH object exists by default in a SEG configuration and can be displayed with the CLI command: Device:/> show RemoteManagement RemoteMgmtSSH The following output confirms that SSH access has be enabled on the sfp1 interface from the sfp1_net network. Name Interface Network ‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ ssh_mgmt sfp1 sfp1_net Authentication for SSH access is controlled by the AuthProfile property of the RemoteMgmtSSH object. By default this is set to a predefined AuthenticationProfile object called MgmtAuthProfile. This profile points to the predefined local user database that contains a default administrator account with the credentials: •...
Page 16 Management To add back the original authentication: Device:/> set RemoteManagement RemoteMgmtSSH ssh_mgmt AuthProfile=MgmtAuthProfile The Source property of the MgmtAuthProfile will be assigned the name of the local user database to use for authentication. Troubleshooting SSH access problems If the SSH console is timing out when attempting SSH access, there are a number of possible reasons: • Use the local console CLI to check that the SEG SSH server is running: Device:/> sshserver SSH Server Port Connected clients Status ‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ssh_allnets 22 1 Running In the output shown, the server is clearly running. If the status was not Running or if the command returned a new CLI prompt with no output, there was most likely a problem with the initial configuration of the SSH server. • Check the configuration of the RemoteMgmtSSH object. If this object is incorrectly specified on initial startup, the SSH server may not run. Check that the RemoteMgmtSSH is enabled and that a valid authentication profile has been specified and that the profile points to a valid database containing a user with the login credentials expected. A RemoteMgmtSSH object with an example name of ssh_allnets can be displayed with the command: Device:/> show RemoteManagement RemoteMgmtSSH ssh_allnets Controlling console access to the CLI The CLI can also be accessed using a console terminal connected directly to an RS232 port on the security gateway hardware. Access through a console port is controlled by a predefined COMPortAccess configuration object named COM1. This can be displayed with the command: show COMPortAccess Port Bps Data bits Parity Stop bits Flow control Rows Cols ‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐ ‐‐‐‐...
Page 17 Management Frequently used commands The following commands will probably be the most often used with the CLI to manipulate different SEG objects: • add: Adds an object, such as an IP address or a rule, to a SEG configuration along with a set of required properties for the object. • set: Sets one or more configuration object properties to given values. For example, setting the source interface for a given IP rule. • show: Displays the current values of a particular object or set of configuration objects. • delete: Deletes a specific configuration object. CLI command structure CLI commands commonly have the structure: <command> <object_category> <object_type> <object_name> For example, to display an IP address object called my_address, enter: Device:/> show Address IPAddress my_address The object category in this case is Address and the type within this category is IPAddress. If the object type is unique, its category can be omitted. The same example as above could be shortened to: Device:> show IPAddress my_address In this case, the object category Address is omitted since IPAddress is a unique object type. Note: Tab completion will not work until the entire object type is entered when omitting the object category. The same object name could be used within two different categories or types, although this is best avoided in order to avoid ambiguity when reading configurations. Note: The term category is also sometimes referred to as the context of an object. A command such as add can also include object properties. To add a new IPAddress object with an IPv4 address of 10.49.02.01, the command would be: Device:/> add Address IPAddress my_address Address=10.49.02.01 ...
Page 18 Management Tab completion displays allowed properties only There are some important principles to understand when using tab completion for object properties: • The properties of an object are either required or optional. When using tab completion, optional properties are not displayed until all required properties have been assigned a value. • An optional property’s use can depend on the value specified for another property. For example, in an IPsecTunnel object, the optional ProxyARP property can be used only when the AddRouteToRemoteNetwork property has been set to Yes. The tab completion feature is aware of these dependencies and will not display a property if it is dependent on another property that has not yet been assigned a value. Looking at the IPsecTunnel example again, tab completion will display the ProxyARP property only if the AddRouteToRemoteNetwork property has been already been assigned a value of Yes. CLI help The CLI help command will show all available command options. Typing help followed by a command name will show help information for that command, providing details about the command's function and its options. For example: Device:/> help time COMMAND time (t). Display and set current system time. " " Typing this CLI command provides information about the help command itself: Device:/> help help Configuration object help A second help command, helpconfig, provides information about a particular object type or category of objects. CLI command history Just like a command console in many versions of Microsoft Windows™, the up and down ...
Page 19 Management Tab completion Remembering as well as typing commands and their options can be demanding. The SEG provides a feature called tab completion, which means that pressing the Tab key will cause automatic completion of the current part of the command. If completion is not possible, pressing the Tab key will display the available command options. Tab completion displays the required object properties first, and then shows any optional properties when all the mandatory ones have been completed. Specifying the default value The period (.) character before a tab can be used to automatically fill in the default value for an object property. For example: add LogReceiver LogReceiverSyslog log_example Address=example_ip LogSeverity=. (tab) Will fill in the default value for LogSeverity: add LogReceiver LogReceiverSyslog log_example Address=example_ip LogSeverity=Emergency,Alert,Critical,Error,Warning,Notice,Info This severity list can then be edited with the back arrow and backspace keys. A default value is not always available. For example, the Action of an IP rule has no default. Another use of the period character before a tab is to automatically fill in the current value of an object property in a command line. For example, you might type the unfinished command: set Address IPAddress InterfaceAddresses/sfp1_ip= If you now type “.” followed by a tab, the SEG will display the current value for the Address property. For example, if the value is 10.6.58.10, the unfinished command line will automatically become: set Address IPAddress InterfaceAddresses/sfp1_ip=10.6.58.10 The SEG automatically inserts the current value of 10.6.58.10, which can then be changed with the backspace or back arrow keys before completing the command. Object categories and tab completion As mentioned above, objects are grouped by type, for example, IPAddress. Types themselves are grouped by category. The type IPAddress belongs to the category Address. Categories are used by tab completion when searching for the right object type to use. If you enter a command such as add and press the Tab key, the SEG displays all the available categories. By choosing a category and then pressing the Tab key again, all the object types for ...
Page 20 Management Selecting object categories With some categories, it is necessary to first choose a member of that category with the cc (change category or context) command before individual objects can be manipulated. This is the case, for example, with routes. There can be more than one routing table, so when adding or manipulating a route, you must first use the cc command to identify which routing table you are interested in. Suppose a route is to be added to the routing table main. The first command would be: Device:/> cc RoutingTable main Device:/RoutingTable/main> Notice that the command prompt changes to indicate the current category. You can now add the route: Device:/RoutingTable/main> add Route Interface=sfp1 Network=sfp1_net Name=new_route1 To deselect the category, the command is cc on its own: Device:/RoutingTable/main> cc Device:/> The categories that require an initial cc command before object manipulation have a “/” character following their names when displayed by a show command. For example: RoutingTable/. Inserting into rule lists Rule lists such as the IP rule set have an ordering that is important. With the add command, the default is to add a new rule to the end of a list. When placement at a particular position is crucial, the add command can include the Index= property as an option. Inserting at the first position in a list is specified with Index=1 in an add command, the second position with Index=2 and so on. Referencing by name You can optionally name some objects using the Name= property with the add command. An object, such as an IP rule, will always have an Index value that indicates its position in the rule list but can optionally be allocated a name as well. Subsequent manipulation of such a rule can be done either by referring to it by its index (list position) or by using its assigned name. The SEG‐100 Command Line Interface Reference lists the options available for each SEG object, including Name= and Index=. To make reading configurations easier, it is strongly advised to always add a unique name to ...
Page 21 Management SSH CLI login After access to the CLI has been established to the SEG through SSH, you must log on to the system to execute any CLI commands. This authentication step ensures that only trusted users can access the system, as well as provides user information for auditing purposes. After communication is established, the SEG will respond with a login prompt. Enter the username followed by the Enter key, and then type the password followed by the Enter key again. After the first startup, the SEG will allow you to log in with the username admin and the password admin. This default password should be changed as soon as possible. If you are accessing the CLI through an RS232 console connection, authentication will only be required if an AuthenticationProfile is associated with the console’s COMPortAccess object. After a successful logon, the SEG CLI command prompt will appear: Device:/> The default welcome message will also be displayed directly after the logon. This SSH welcome message can be removed with the CLI command: Device:/> set RemoteManagement RemoteMgmtSSH ssh Banner= Where ssh is the name of the RemoteMgmtSSH object. To reset the message, enter: Device:/> set RemoteManagement RemoteMgmtSSH ssh Banner="Welcome!" SSH connection timeout When connecting to the SEG with SSH, there is a default inactivity timeout of 30 minutes. To increase this timeout to a higher value, use the following CLI command: Device:/> set RemoteManagement RemoteMgmtSSH  ssh_allnets SessionIdleTime=1000000 Changing the admin user password Change the default password of the admin account from admin to another password as soon as possible after initial startup. User passwords can be any combination of characters and cannot be greater than 256 characters in length. It is recommended to use only printable characters. For example, to change the password to my‐password, the following CLI commands are used. First, change the current CLI context to be the relevant LocalUserDatabase object: Device:/> cc LocalUserDatabase AdminUsers The password of the admin user can now be changed: Device:/LocalUserDatabase/AdminUsers> set User admin Password="my‐password"...
Page 22 Management Activating and committing changes If any changes are made to the current configuration through the CLI, those changes will not become active until you issue the following command: Device:/> activate To make the changes permanent, this should be immediately followed by: Device:/> commit Uncommitted changes in CLI listings of configuration objects are indicated by a plus “+” or “*” symbol appearing to the left of the object. If the commit command is not issued within 30 seconds (the default time period), the activated changes are automatically undone and the old configuration restored. Symbols indicating object status When configuration objects are displayed with a show command, a symbol to the left of the object’s output indicates a change of status that has not yet been committed. Two symbols are mentioned above. The complete list is: ‐ means the object has been deleted. o means the object has been disabled. ! means the object has errors. + means the object has been newly created. * means the object has been modified. Checking configuration integrity After changing an SEG configuration and before issuing the activate and commit commands, you can explicitly check for any problems in a configuration using the command: Device:/> show ‐errors This will cause the SEG to scan the configuration about to be activated and list any problems. For example, a possible problem might be a reference to an IP object in the address book does not exist in a restored configuration backup. All the changes made to a configuration can be shown before activation with the command: Device:/> show ‐changes ...
Page 23 Management Viewing the configuration log Major SEG system events, such as new configuration deployments and system starts, are recorded in the configuration log. Use the command to view the configuration log, as cfglog shown in the following example: Device:/> cfglog ‐all Notice vsinit/Configure:1805 2011‐06‐17 13:53:40 ‐ Beginning system reconfigure. System starting. Notice vsinit/Configure:1805 2011‐06‐17 15:59:30 ‐ Beginning system reconfigure. Activating new configuration. Notice vsinit/Configure:2033 2011‐06‐17 15:59:31 ‐ Reconfigure completed successfully. If the command is used without the option, only major system events that cfglog ‐all occurred since the last system start or reconfigure are shown. The output from this command also shows if the SEG is running in demonstration mode, without a valid license. System performance commands The following commands give a real‐time snapshot of overall system performance: • The command for CPU utilization. Device:/> top Load avg: 0.94, 0.51, 0.35 CPU usage: 24.8% CPUs: 1 Name Time CPU(%) ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐ statd 14:04 6.3 mdpd 12:52 5.1 vsinit 07:17 2.7 "...
Page 24 Management Multiple administration logins The SEG allows more than one user from the Administrators group to be logged in at the same time and change the configuration simultaneously. A change made by one such user is visible immediately to all others. For example, if one user deletes a configuration object, another user who tries to change it will receive a message to say that the operation is invalid. Logging off from the CLI After you finish working with the CLI, log off in order to prevent anyone from getting unauthorized access to the system.This is done with the command: Device:/> exit Changing the command view There are four command views: • Default • Advanced • Debug • All In normal operation the Default view is sufficient. However, some situations may require the use of commands that should be used cautiously and for that reason they are hidden in alternate command views. For example, to turn on the Advanced view, enter the command: Device:/> cmdview ADVANCED Entering the command will now show that an additional set of commands are available Help to the administrator in addition to the default set. These additional commands include, for example, , which provides a technically detailed listing of the current IP rules.
Page 25 Management Troubleshooting with ICMP ping For troubleshooting communication problems with external devices, one of the most useful tools is the CLI command. This command sends an ICMP ping message to an external ping IPv4 address and reports if the device replies. For example, to send an ICMP ping message to the IPv4 address 10.4.0.2, the CLI command would be: Device:/> ping 10.4.0.2 The sending interface is not specified because the SEG derives it by looking up the destination IP in the relevant routing table. By default, the routing table used is main but can be specified in the command using the option. ‐pbr=<table> Note: The command cannot send ICMP messages to IPv6 addresses in the current SEG ping version. The command options enable the ICMP message to be modified. For example, to send a ping UDP ping message, the above command becomes: Device:/> ping 10.4.0.2 ‐udp If the ICMP message is to come from the IPv4 address 192.168.0.5, the command would be: Device:/> ping 10.4.0.2 ‐srcip=192.168.0.5 When the option is used, the source IP address must be one of the IP addresses ‐srcip= configured on the sending interface. When ICMP ping messages are sent by external devices to SEG interfaces, both IPv4 and IPv6 messages will be responded to. CLI scripting To allow the administrator to easily store and execute sets of CLI commands, the SEG provides a feature called CLI scripting. A CLI script is a predefined sequence of CLI commands that can be executed after they are saved to a file that is then uploaded to the SEG. The steps for creating a CLI script are as follows: 1.
Page 26 Management The CLI script command is the tool used for script management and execution. The complete syntax of the command is described in the SEG‐100 Command Line Interface Reference and specific examples of usage are detailed in the following sections. See also Command line interface on page 15. Note: Uploaded CLI script files are not held in permanent memory and will disappear after system restarts. All CLI commands are allowed in scripts There are no restrictions on which CLI commands can appear in an SEG script. Any valid command can be used. Executing scripts As mentioned above, the command launches a named script file that has been script ‐run previously uploaded to the SEG. For example, to execute the script file my_script.sgs that has already been uploaded, the CLI command would be: Device:/> script ‐run ‐name=my_script.sgs Script variables A script file can contain any number of script variables that are called: $1, $2, $3, $4..$n The values substituted for these variable names are specified as a list at the end of the script command line. The number n in the variable name indicates the variable value’s position ‐run in this list. $1 comes first, $2 comes second, and so on. Note: The name of the first variable is $1. The variable $0 is reserved and is always replaced before execution by the name of the script file itself. For example, a script called my_script.sgs is to be executed. The IPv4 address 126.12.11.01 is to replace all occurrences of $1 in the script file and the string sfp1 address is to replace all occurrences of $2. The file my_script.sgs contains the single CLI command line: add Address IPAddress sfp1_ip Address=$1 Comments=$2 To run this script file after uploading to the SEG with the given substitutions, the CLI command ...
Page 27 Management Script validation and command ordering CLI scripts are not, by default, validated and the ordering of the commands does not matter. There can be a reference to a configuration object at the beginning of a script that is created only at the end of the script. Although this might seem illogical, it is done to improve the readability of scripts. If something always has to be created before it is referred to, this can result in a confused and disjointed script file. In long scripts it is often preferable to group together similar CLI commands. Error handling If an executing CLI script file encounters an error condition, the default behavior is for the script to terminate. This behavior can be overridden by using the option. To run a ‐force script file called my_script2.sgs in this way, the CLI command is: Device:/> script ‐run ‐name=my_script2.sgs ‐force If is used, the script will continue to execute even if errors are returned by a command ‐force in the script file. Script output Any output from script execution will appear at the CLI console. Normally this output consists only of any error messages that occur during execution. To see the confirmation of each command completing, the option should be used: ‐verbose Device:/> script ‐run ‐name=my_script2.sgs ‐verbose Scripts are lost after restart When a script file is uploaded to the SEG, it is kept in temporary memory. If the SEG restarts, any uploaded scripts will be lost from memory and must be uploaded again before they can run. To move the example my_script.sgs to non‐volatile memory, the command would be: Device:/> script ‐store ‐name=my_script.sgs Alternatively, all scripts can be moved to non‐volatile memory with the command:...
Page 28 Management Listing scripts The script command without any parameters lists all the scripts currently available and indicates the size of each script as well as the type of memory where it resides (residence in non‐volatile memory is indicated by the word “Disk” in the Memory column). Device:/> script Name Storage Size (bytes) ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ my_script.sgs RAM 8 my_script2.sgs Disk 10 To list the content of a specific uploaded script file, for example, my_script.sgs, the command would be: Device:/> script ‐show ‐name=my_script.sgs Creating scripts automatically When the same configuration objects needs to be copied between multiple SEGs, one way to do this with the CLI is to create a script file that creates the required objects and then upload to and run the same script on each device. If a SEG installation already has the objects configured that need to be copied, running the command on that installation provides a way to automatically create the script ‐create required script file. This script file can then be downloaded to the local management workstation and then uploaded to and executed on other SEGs to duplicate the objects. For example, suppose the requirement is to create the same set of IPAddress objects on several SEGs that already exist on a single security gateway. The administrator would connect to the single gateway with the CLI and issue the command: Device:/> script ‐create Address IPAddress ‐name new_script.sgs This creates a script file called new_script_sgs that contains all the CLI commands necessary to create all IPAddress objects in that gateway’s configuration. The created file’s contents might, for example, be: add IPAddress sfp1_ip Address=10.6.60.10 add IPAddress sfp1_net Address=10.6.60.0/24 add IPAddress sfp1_br Address=10.6.60.255 add IPAddress sfp1_dns1 Address=141.1.1.1 " " "...
Page 29 Management The file new_script_sgs can then be downloaded with SCP to the local management workstation computer and then uploaded and executed on the other SEGs. The end result is that all units will have the same IPAddress objects in their address book. Note: In the created script example above, adding an IP address is done with the command: add IPAddress... This is instead of the usual way of qualifying the object with its group name: add Address IPAddress... Both are valid forms of the command. If an object type can be uniquely identified with its name, its object category does not need to be specified. This is always the case with automatically‐generated scripts. This shortened form can also be used when typing the entire command in a CLI console, although tab completion will always include the object category. Objects excluded from script files Certain aspects of a configuration that are hardware dependent cannot have a script file entry created when using the option. This is true when the CLI node/object type in the ‐create command is one of: script ‐create • COMPortDevice • EthernetDevice These node types are skipped when the script file is created and the SEG displays the message: No objects of selected category or type. Commenting script files Any line in a script file that begins with the # character is treated as a comment. For example: # The following line defines the sfp1 IPv4 address add Address IPAddress sfp1_ip Address=10.6.60.10 Scripts running other scripts It is possible for one script to run another script. For example, the script my_script.sgs could ...
Page 30 Management Secure copy To upload and download files to or from the SEG, the Secure Copy (SCP) protocol can be used. SCP is based on the SSH protocol and many freely available SCP clients exist for almost all platforms. The command line examples below are based on the most common command format found with SCP client software. Some SCP clients might use different syntax. SCP command format SCP command syntax is straightforward for most console based clients. The basic command used here is scp followed by the source and destination for the file transfer. Upload is performed with the command: > scp <local_filename> <destination_gateway> Download is performed with the command: > scp <source_gateway> <local_filename> The source or destination SEG is specified using the format: <user_name>@<gateway_ip_address>:<filepath> For example: admin@10.62.11.10:config.bak. The <user_name> must be a defined SEG user belonging to the administrator user group. Note: SCP will normally prompt for the user password after the command line but that prompt is not shown in the examples in this manual. Examples of SCP uploading and downloading In some cases, a file is located in the SEG root. In other cases, it is located within a particular folder. For example, all backup files are located in a subfolder called storage/backup. Uploading/downloading backup files If an administrator username is admin1 and the IPv4 address of the SEG is 10.5.62.11, to upload a configuration backup file called config.bak from the local disk, the SCP command would be: > scp config.bak admin1@10.5.62.11:backup/ To download a configuration backup to the current local directory, the command would be: > scp admin1@10.5.62.11:backup/config.bak ./ If a backup file is not uploaded to the backup folder, it becomes unusable but will be deleted after a system restart.
Page 31 Management Uploading certificate files The following command lines show how a typical SCP utility might upload a host certificate consisting of two files called cert‐1.cer and cert‐1.key to a security gateway that has the management IP address 192.168.3.1: > scp C:\cert‐1.cer admin@192.168.3.1: > scp C:\cert‐1.key admin@192.168.3.1: In each case, the uploaded file will retain its original file name. Uploaded certificate files are stored in volatile memory and must be associated with a SEG object to become a non‐volatile part of the configuration. For details, refer to Creating certificate configuration objects on page 130. Using wildcards with SCP The SEG supports the use of the wildcard asterisk (“*”) with SCP. For example, to download all the files with a file type of .MIB, the following command can be used: > scp admin@192.168.3.1:*.mib . To download all the downloadable files: > scp admin@192.168.3.1:* . Wildcards can also be used when uploading. For example, to upload all the backup files in the current directory: > scp *.bak admin@192.168.3.1:backup/ SNMP monitoring Simple Network Management Protocol (SNMP) is a standardized protocol for management of network devices. An SNMP compliant client can connect to a network device that supports the SNMP protocol in order to query and control it. The SEG supports SNMP version 1 and version 2. Connection can be made by any SNMP compliant clients to the SEG. However, only query operations are permitted for security reasons. Specifically, the SEG supports the following SNMP request operations by an SNMP client: • GET REQUEST • GET NEXT REQUEST • GET BULK REQUEST (SNMP Version 2c only) SEG MIB The Management Information Base (MIB) is a database, in the form of a text file, which ...
Page 32 Management These MIB file should be transferred to the hard disk of the workstation that will run the SNMP client so they can be imported by the client software. When the SNMP client runs, the MIB files are read and tell the client which values can be queried on an SEG device. Each entry in the MIB includes a textual explanation of what the value is. A complete list is not reproduced in this guide. A typical MIB file entry for the total number of packets transmitted by an interface is shown below: clvIfPktsTotCnt OBJECT‐TYPE SYNTAX Counter32 MAX‐ACCESS read‐only STATUS current DESCRIPTION "Total number of packets transmited by the interface" ::= { clvIfStatsEntry 10 } All SEG statistical values that can be accessed by SNMP are listed in the SEG‐100 Statistics Reference, which provides all available information for each. This includes the description of the values along with the MIB IOD, MIB name and MIB type. All retrievable statistics are part of a hierarchy. Identifying a particular statistic involves constructing a path, which is also described in the Statistics Reference. Defining SNMP access SNMP access is defined through the definition of an SEG Remote object with a Mode value of SNMP. The Remote object requires the entry of: • Source interface – The SEG interface on which SNMP requests will arrive. • Source network – The IP address or network from which SNMP requests will come. • Destination interface – The SEG interface to which SNMP requests are sent. By default, this is core. • Destination network – The IP address or network from which SNMP requests are sent. By default, this is all‐nets. • Community – The community string which provides password security for the accesses. Defining community strings Security for SNMP Versions 1 and 2c is handled by the Community String, which is the same as a password for SNMP access. The Community String should be difficult to guess and should ...
Page 33: Date And Time
Management Remote access encryption For SNMP version 1 or 2c, the community string will be sent as plain text over a network. This is clearly not secure if a remote client is communicating over the public Internet. If this is the case, it is recommended to have remote access take place over an encrypted VPN tunnel or similarly secure means of communication. Preventing SNMP overload The advanced setting SNMP Request Limit restricts the number of SNMP requests allowed per second. This can help prevent attacks through SNMP overload. Optional SNMP settings You can also set the following SNMP parameters: • SNMPSysContact – The contact person for this managed node. • SNMPSysName – The name of this managed node. • SNMPSysLocation – The physical location of this node. Example: Enabling SNMP monitoring This example enables SNMP access through the internal lan interface from the network mgmt‐net using the community string Mg1RQqR. Device:/> add RemoteManagement RemoteMgmtSNMP my_snmp SourceInterface=lan  SourceNetwork=mgmt‐net SNMPGetCommunity=Mg1RQqR Date and time Correctly setting the date and time is important for the SEG to operate properly. For example, certificates used in certificate‐based VPN tunnels depend on the system clock being accurately set. In addition, log messages are tagged with timestamps in order to indicate when a specific event occurred. Not only does this assume a working clock, but also that the clock is correctly synchronized with other equipment in the network. You can set the date and time manually, which is recommended when a new SEG installation ...
Page 34 Management Automatic time synchronization The SEG supports the optional use of a Time Synchronization Protocol. This protocol allows the current time to be automatically retrieved from a time server over the public Internet. Updating the system clock in this way can be done automatically on SEG startup, removing the need for a battery backup. This feature is discussed further in Time servers on page 35. Example: Setting the current date and time To adjust the current date and time, enter: Device:/> time ‐set YYYY‐mm‐DD HH:MM:SS Where YYYY‐mm‐DD HH:MM:SS is the new date and time. Note that the date order is year, then month and then day. For example, to set the date and time to 9:25 in the morning on April 27th, 2011 the command would be: Device:/> time ‐set 2011‐04‐27 09:25:00 Note: A new date and time will be applied by the SEG as soon as it is set. There is no requirement to reconfigure or restart the system. Time zones The world is divided up into a number of time zones, with Greenwich Mean Time (GMT) in London at zero longitude the base time zone. All other time zones going east and west from zero longitude are GMT plus or minus a given period of time. All locations counted as being inside a given time zone will then have the same local time and this will be one of the integer offsets from GMT. The SEG time zone setting reflects the time zone where the security gateway is physically located. Example: Setting the time zone To modify the SEG time zone to be GMT plus 1 hour, enter: Device:/> set DateTime Timezone=GMTplus1 Tab completion can present a list of all time zones.
Page 35 Management Time servers The hardware clock that the SEG uses can sometimes become fast or slow after a period of operation. This is normal behavior in most network and computer equipment and is solved by using Time Servers. The SEG is able to adjust the clock automatically based on information received from one or more time servers which provide a highly accurate time, usually using atomic clocks. Using time servers is highly recommended as it ensures the SEG will have its date and time aligned with other network devices. For hardware platforms without battery backup of the system clock, using time servers is a useful way to automatically set the correct time after initial startup. SNTP protocol Time Synchronization Protocols are standardized methods for retrieving time information from external time servers.The SEG supports the Simple Network Time Protocol (SNTP) as defined by RFC 5905 (SNTPv4). Configuring time servers More than one time server can be configured to query for time information. Using more than a single server prevents the time synchronization process from failing due to an unreachable server. The SEG always queries all configured servers and then computes an average time based on all responses. To configure servers, the steps are: 1. Set the TimeSyncEnable option on the DateTime object to Yes. 2. Add each configured server as a new TimeServer object to the DateTime object. Example: Enabling time synchronization using SNTP In this example, time synchronization will be enabled and two time servers will be configured with IPv4 addresses 10.5.4.36 and 10.5.4.76. The created TimeServer objects will be given the names my_tsrv1 and my_tsrv2. 1. Change the context to be DateTime: Device:/> cc DateTime 2.
Page 36 Management Manually triggering time synchronization If there is a need to manually force the system clock to be updated, use the CLI time ‐sync command. Example: Manually triggering time synchronization Time synchronization can be triggered from the CLI. Device:/> time ‐sync Time synchronization requested Device:/> Maximum time adjustment To avoid situations where a faulty Time Server causes the clock to be updated with an extremely inaccurate time, a Maximum Adjustment value (in seconds) can be set. If the difference between the current SEG time and the time received from a Time Server is greater than this Maximum Adjustment value, the Time Server response will be discarded. For example, assume that the maximum adjustment value is set to 60 seconds and the current SEG time is 16:42:35. If a Time Server responds with a time of 16:43:38 then the difference is 63 seconds. This is greater than the maximum adjustment value so no update occurs for this response. The default value for the maximum adjustment is 600 seconds (ten minutes). Example 1: Modifying the maximum adjustment value Sometimes it might be necessary to override the maximum adjustment parameter. For example, you may want to manually force a synchronization and disregard the maximum adjustment if time synchronization has just been enabled and the initial time difference is greater than the maximum adjust value.
Page 37: Licensing
Management Licensing To use the SEG in a live environment, a license file must be deployed to the SEG and associated with the configuration. The purpose of the license file is to define the capabilities and limitations that the SEG installation has. A license file is a plain text file that defines all the capabilities allowed by the license plus a digital signature to ensure the file cannot be altered. The file can be opened and read in a normal text editor. It is generated and supplied by Radisys. For instructions on installing a license, refer to the SEG‐100 Getting Started Guide. Local lockdown mode Without correct licensing, the SEG operates in Lockdown Mode, which means that it has extremely limited functionality. The following features are available in lockdown mode. • The only access permitted to the SEG is management access by an administrator. • The SEG can be configured, including uploading and activating a license. • In addition to access using the CLI, access is also possible using SCP and SNMP. Log event and console messages indicate when lockdown mode goes into effect and when it ends. Managing license files A number of license files can be present in local SEG temporary storage; however, only one can be active at any time. The SEG CLI provides the license command to manage the active license. The options for this command are: • Activate: The activate command causes a previously uploaded license to become the current license associated with the SEG. A copy of the license selected is made by the SEG and saved in non‐volatile storage. It is this copy that is used during SEG execution and it is not lost after a system reboot. • Remove: This command deactivates the currently activated license file: Device:/> license remove After deactivation, the SEG enters lockdown mode. Previously uploaded license files are unaffected by this command and remain available for activation (although they will be lost after a system reboot). • No options: If the license command is used without any options, it provides a summary of ...
Page 38 Management Some typical output from this command is shown below: Device:/> license Property Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ IsValid: Yes OS: 1 RegisteredTo: Radisys QA RegistrationKey: 1654‐5761‐8527‐1384 OEMId: 0 DisplayModel: Generic RegistrationDate: 2011‐11‐12 00:00:00 LastModified: 2011‐11‐12 00:00:00 IssuedDate: 2011‐11‐12 00:00:00 UpgradesValidUntil: 2014‐11‐12 00:00:00 MACAddress: 01‐91‐FB‐2A‐A0‐30 IKETunnels: 2 GTP: Yes The MAC address is for one of the Ethernet interfaces on the processor running the SEG. The GTP property should be enabled for I‐WLAN deployments. Licenses do not expire There is no expiration date for SEG licenses. Instead, there is a Upgrades Valid Until date. When this date has passed, the SEG will continue to function as usual but software upgrades will not be available. Binding to a MAC address When a license file is created, it is bound to the MAC address specified in the license. This means that the license is valid only if the SEG can detect that the MAC address of one of the hardware’s Ethernet addresses is the same as the MAC address of the license. For this reason, a license is not portable between different hardware units. If hardware is replaced so that the license Ethernet MAC address is no longer present, a new license must be generated.
Page 39: Backup And Restore
Management Backup and restore The administrator has the ability to take a snapshot of an SEG system at a given point in time and restore it if necessary. The snapshot taken is known as a configuration backup. This is a backup of the entire current SEG configuration but does not include a copy of the SEG itself. Creating a backup Backups are created in two steps: Step 1: A configuration backup is first created as a single file in local volatile SEG memory. This is done with the CLI command: Device:/> backup ‐create The file created will be placed in the logical SEG folder called “backup” and will have the default name config‐YYYYMMDD.bak, where YYYYMMDD indicates the current date. To specify a filename for the backup file, the command is: Device:/> backup ‐create <filename> Step 2: Once created, backup files are transferred to an external computer by downloading the files from the security gateway using SCP (Secure Copy). As stated above, all backup files are saved in an SEG logical folder called backup and this folder needs to be specified in SCP commands. It is important to note which SEG hardware the backup file came from so that it can be restored to a processor that has the same logical interface names. SCP usage is described further in Secure copy on page 30. Note: Backups are temporarily kept in the backup folder. They are not held in permanent memory and will disappear after system restarts. Restoring a backup Restoring a backup is also a two step process: Step 1: Use SCP to upload the backup file to the target security gateway. It is uploaded to the SEG logical folder called backup and this must be specified in the SCP command. SCP usage is described further in Secure copy on page 30. ...
Page 40: Restoring The Default Configuration
Management Step 2: To make the uploaded configuration the current configuration, the following CLI command is used: Device:/> backup ‐restore <filename> Where filename is the name of the file in the backup folder. To list all files in /storage, use the CLI command: Device:/> backup ‐list When a restore begins, the selected file is validated before it replaces the current configuration. For the new configuration to become active, the CLI commands activate followed by commit are required after the restore is complete. Important: Do not perform a restore operation with live traffic flowing through the security gateway. Any traffic flows will be disrupted. Reverting a backup After performing a restore operation, the SEG retains a copy of the original configuration (that is to say, the configuration that the restore replaced). This copy can be reactivated at any time with the CLI command: Device:/> backup ‐revert A revert operation always uses the configuration in effect previous to the last restore if there was one. If no restore has been performed, a revert operation will have no effect. Restoring the default configuration A special case of backup command usage for configuration restoration is: Device:/> backup ‐reset This restores the default configuration for the security gateway. The current configuration is saved when this command is used so that the reset can be undone by using the command: Device:/> backup ‐revert Restoring to a dissimilar processor Important: Restore a backup to the SEG that uses the same interface names as those used on the original hardware from which the backup was taken. The reason for this is that the backup may refer to logical interface names that do not exist on the new hardware. On the SEG‐100, there are two processors on each module (DPB1 and DPB2). These are ...
Page 41 Management The restore will be successful; however, the processors use different logical names for their Ethernet interfaces. For example, the interface sfp1 on the DPB1 processor corresponds to the sfp4 interface on the DPB2 processor. The restored configuration will continue to use original interface names such as sfp1 after the restore, but these will no longer match the interface text labels on the module’s exterior. This interface renaming can cause confusion and should therefore be avoided. Restoring the default configuration A special case for using the command for restoring a configuration is: backup Device:/> backup ‐reset This restores the default configuration for the security gateway. The following points should be noted about a reset: • Since the default configuration will be restored, the option should be issued only ‐reset from an SSH client that is connected to the default management interface using the default management IP address, or from a console that is connected to the RS232 serial console interface. Otherwise, the connection to the CLI will be lost after the command is issued. • The current SEG configuration will be lost after a reset and cannot be recovered. For this reason, this command option should be used with caution. To remind the administrator that the command is irreversible, a prompt appears to ask if the SEG should proceed: Device:/> backup ‐reset This will reset the current configuration to the system's default configuration and reboot the system. This change is not reversible. Are you sure you want to continue? [yes/no]: yes Resetting configuration to system default... Reset configuration to default successful. Restarting the SGW:done. In CLI scripts, the option must be used with ‐force ...
Page 42: Crashdumps
Management Crashdumps In the event of a serious system malfunction, the SEG generates a Crashdump and stores it in non‐volatile system memory as a set of files. The files generated by a crashdump consist of critical data that can assist in troubleshooting the cause of the malfunction. Send crashdumps to Technical Support The files generated by crashdumps are not intended to be read and interpreted by the administrator. Instead, crashdumps should be sent to Radisys Technical Support and all relevant files should be sent. Downloading crashdump files Any of the files generated by a crashdump can be downloaded using SCP. All files are kept in the storage folder called crashdumps. A typical SCP command to download a single file would take the form: scp <user>@<seg‐address>:/crashdumps/<crashdump‐file> To download all files in one operation, a typical SCP command would be: scp ‐r <user>@<seg‐address>:crashdumps Listing crashdump files The SEG command line interface provides the command to manage the crashdump crashdump files stored in non‐volatile memory. The option provides a list of all files currently stored ‐list along with their sizes in bytes plus the total memory used and available. For example, a typical listing might be: Device:/> crashdump ‐list Size Name ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 46142 2011‐01‐01_00.00.36_rtbld.dump 886 2011‐01‐01_00.00.52_dpcore.dump Used space: 47028 Bytes Free space: 24211456 Bytes Note: The default option is ...
Page 43 Management Crashdump file naming Every crashdump file has a file type of .dump. The complete filename follows the format: <date><time><module>.dump Where <module> identifies the SEG module that is the source of the crashdump, preceded by the date and time of when the crash occurred. For example: 2011‐01‐01_00.00.36_rtbld.dump Note: The date and times used in crashdump timestamps are based on GMT. They are not based on local time. Displaying file contents Crashdump files can contain a readable text portion, combined with any binary dump information. The option prints out only the readable portion of a crashdump file. ‐cat For example, to list the readable contents of the file 2011‐01‐01_00.00.52_dpcore.dump, use the CLI command: Device:/> crashdump ‐cat=2011‐01‐01_00.00.52_dpcore.dump ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Date: 2011‐01‐01 00:00:52 Version: 1.0.0.3‐1095 TP Uptime: 50s Dump Record: 022 Event: Exception Reason: Unhandled exception=>TLB exception (load/instruction fetch) CPU (core‐0) state: r0 ($00): 0x0000000000000000 s0 ($16): 0x00000000163ffe70 at ($01): 0x0000000000ffff80 s1 ($17): 0xffffffff800cfaa0 v0 ($02): 0x0000000000000000 s2 ($18): 0xffffffff8004af40 v1 ($03): 0x000000001018f83c s3 ($19): 0xffffffffffffffff a0 ($04): 0x00000000102e22f8 s4 ($20): 0xffffffff800d0a30 " " " If the same command is applied to another type of crashdump file, the output might be shorter and similar to the example below: Device:/> crashdump ‐cat=2011‐01‐01_00.00.36_rtbld.dump Date: 2011‐01‐01 00:00:36 Version: 1.0.0.3‐1095 TP Application: rtbld...
Page 44: Statistics
Management Deleting a single file The option can be used to delete files from permanent storage. For example, to remove ‐rm the file 2011‐01‐01_00.00.52_dpcore.dump, the command would be: Device:/> crashdump ‐rm=2011‐01‐01_00.00.52_dpcore.dump Deleting all files All crashdump files stored in memory can be deleted with the command: Device:/> crashdump ‐rm=all Instead of all, the asterisk character (*) can also be used as a wildcard: Device:/> crashdump ‐rm=* Important: The size of non‐volatile memory available for crashdump file storage is limited, so it is important to delete crashdump files as soon they have been downloaded. Statistics The SEG maintains a large number of counters in memory that keep track of system activity. This information is kept only in memory and is mostly made up of single numerical values. The purpose of this is to be able to give the administrator an overview of the tasks being performed by the system. The counters are collectively known as SEG statistics. A separate document called the SEG‐100 Statistics Reference provides a detailed listing of all available statistical values. This section is designed to give a short introduction to their structure and use. Accessing statistics There are two methods for the administrator to view SEG statistics: • By using the statistics command in a CLI console. • Using an SNMP client in conjunction with the Clavister MIB file. This section describes examining statistics through the CLI. SNMP access to the SEG is described in SNMP monitoring on page 31. Hierarchical statistics structure All statistics are part of a hierarchical tree structure that divides them into related values. This structure can be clearly seen in the contents of the Statistics Reference.
Page 45 Management For example, the bytes_in statistic associated with the sfp1 interface is identified with the path: /ifaces/sfp1/bytes_in These variable references in paths are indicated in the Statistics Reference using the [..n] notation. Types of statistic Not all statistics are pure counters. The possible types are: • Counter – The value is positive and only increments. • Momentaneous – The value can vary arbitrarily. • Min – Retains the smallest observed value. • Max – Retains the largest observed value. • None – Not a numerical value. Typically, this is a string value. As described in the introduction to the Statistics Reference, the numerical values can vary from 8 bit unsigned integer up to a 64 bit signed integer, depending on the expected range of the statistic. All values are reset between system restarts so that statistics are not carried over. Using the statistics command The CLI command is used to display the value of one or more statistics at a statistics moment in time or at a regular interval. Entering this command without options will initially give the following response: Device:/> statistics The list of polled values is empty The command maintains a list of statistics that can be polled. It is necessary to first add to the list using the option. Suppose that there is a requirement to see the number of active ‐add system users every 10 seconds. The command to add this to the list is: Device:/> statistics ‐add /authentication/system/active_users_system The new contents of the list can now be displayed. At the same time, all statistics on the list ...
Page 46 Management Starting and stopping regular polling To begin polling all values in the list at a regular interval, an additional command is required: Device:/> statistics ‐poll ‐interval=10 This turns on regular polling with the same output as before and it will appear every 10 seconds on the console. In the example output below, another user has appeared: Device:/> statistics Name Value Unit ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐ /authentication/system/active_users_system 2 users To stop regular polling use the command: Device:/> statistics ‐stop If an interval time period is not specified, the interval defaults to zero and the polling is continuous. Using wildcards When you add statistics to the polling list, the asterisk “*” character can be used to specify all statistics within a particular category. For example, the statistic bytes_in for the Ethernet interface sfp1 can be polled with the command: Device:/> statistics ‐add /ifaces/sfp1/bytes_in To poll all interfaces, the command would be: Device:/> statistics ‐add /ifaces/*/bytes_in Also notice that the interface name is specified as part of the path and this can vary from platform to platform. Removing polled statistics The option can remove individual statistics from the polled list: ‐remove Device:/> statistics ‐add /authentication/system/active_users_system If everything on the polled list is to be removed, this can be done with the wildcard character: Device:/> statistics ‐remove * To remove specific groups of statistics, the wildcard character can be used with the ‐remove option in the same way as it is used with the ...
Page 47: Events And Logging
Management Statistics and High Availability Statistics are not correctly mirrored in inactive unit of an HA cluster. This topic is discussed further in HA issues on page 166. Events and logging The ability to log and analyze system activities is an essential feature of the SEG. Logging enables monitoring of the SEG status and health, allows auditing of network usage, and assists in troubleshooting. Log message generation The SEG defines a large number of different log event messages, which are generated as a result of associated system events. Examples of such events are the establishment and ending of flows, receipt of malformed packets, and the dropping of traffic according to filtering policies. Log events are always generated for certain aspects of the SEG, such as buffer usage, DHCP clients, high availability, and IPsec. The generation of events for other SEG subsystems such as DHCP relay, DHCP servers, and IP rules can be enabled as needed. Event types The SEG defines several hundred events for which log messages can be generated. The events range from high‐level, customizable, user events to low‐level and mandatory system events. For example, the flow_open event is a typical high‐level event that generates an event message whenever a new flow is established, given that a matching security policy rule exists that specifies that event messages should be generated for that flow. An example of a low‐level event would be the startup_normal event, which generates a mandatory event message as soon as the system starts up. Message format All event messages have a common format with attributes that include category, severity, and recommended actions. These attributes enable easy filtering of messages, either within the SEG prior to sending to an event receiver, or as part of the analysis after logging and storing messages on an external log server. A list of all event messages can be found in the SEG‐100 Log Reference. That guide also describes the design of event messages, the meaning of severity levels, and the various attributes available. ...
Page 48 Management Event severity The severity of each event is predefined and it can be, in order of severity, one of: • Emergency • Alert • Critical • Error • Warning • Notice • Info • Debug By default, the SEG sends all messages of level Info and above to configured log servers. The Debug category is not sent by default and is intended for troubleshooting. It should be turned on only if you are trying to solve a problem. All log messages of all severity levels are found listed in the SEG‐100 Log Reference. Log receivers To distribute and log the event messages generated by the SEG, it is necessary to define one or more event receivers that specify what events to capture, and where to send them. The SEG can be configured to distribute log event messages in different ways: • Real‐time display in the CLI console The CLI can act as a log receiver, displaying new log messages as they are generated in real time. The feature can be turned on using the CLI log command. This receiver type is discussed further in Real‐time display in the CLI. • Syslog receivers Syslog is the de‐facto standard for logging events from network devices. If other network devices are already logging to Syslog servers, using Syslog with SEG messages can simplify overall administration. This receiver type is discussed further in Logging to Syslog servers on page 50. •...
Page 49 Management Real-time display in the CLI Log event messages can be displayed in real time on a CLI console by entering the command: Device:/> log ‐on All messages are then displayed as they are generated as well as being sent to any configured log servers. To switch off logging, use the command: Device:/> log ‐off The key combination Ctrl‐C can also be used to terminate message display at the console. A typical sequence of turning on and then turning off logging is shown below with one intervening log message: Device:/> log ‐on Logging on LOG: Jun 17 00:22:20 RULE: prio=Warning id=00000 event=no_route_to_source  iface=wan srcip=172.22.0.5 pkt_flowdir=n/a  pkt_srchw=00:1b:11:5a:0e:c9 pkt_ipver=4 pkt_proto=IGMP pkt_recvif=wan  pkt_srcip=172.22.0.5 pkt_destip=239.255.255.100  pkt_srcport=0 pkt_destport=65178 action=drop logtrace=02404889 Device:/> log ‐off Logging off Device:/> Each new log message is preceded by the text “LOG:”. Limiting message display With large numbers of log messages being generated, it can be useful to limit the number of messages displayed. The option of the command restricts the number of messages ‐rate per second that are displayed with the excess being discarded. For example, to limit the displayed rate to one message per second, enter the command: Device:/> log ‐on ‐rate=1 Another way to limit the total number of log messages displayed is by using the option. ‐num For example, if only one log message is to be displayed before logging is disabled, the ...
Page 50 Management Logging to Syslog servers Syslog is a standardized protocol for sending log data although there is no standardized format for the log messages themselves. The format used by the SEG is well suited to automated processing, filtering and searching. Although the exact format of each log entry depends on how a Syslog receiver works, most are very much alike. The way in which logs are read is also dependent on how the syslog receiver works. Syslog daemons on UNIX servers usually log to text files, line by line. Message format Most Syslog recipients preface each log entry with a timestamp and the IP address of the machine that sent the log data: Feb 5 2000 09:45:23 gateway.ourcompany.com This is followed by the text the sender has chosen to send. Feb 5 2000 09:45:23 gateway.ourcompany.com EFW: DROP: Subsequent text is dependent on the event that has occurred. To facilitate automated processing of all messages, the SEG writes all log data to a single line of text. All data following the initial text is presented in the format name=value. This enables automatic filters to easily find the values they are looking for without assuming that a specific piece of data is in a specific location in the log entry. Note: The Prio= field in SysLog messages contains the same information as the Severity field for SEG Logger messages. However, the ordering of the numbering is reversed. Example: Enable logging to a Syslog host In this example, logging will be enabled for all events with a severity greater than or equal to Notice to a Syslog server with IPv4 address 195.11.22.55. The logical name for the receiver in the SEG will be My_Syslog. Device:/> add LogReceiver LogReceiverSyslog My_Syslog IPAddress=195.11.22.55 Note: The Syslog server may have to be configured to receive log messages from the SEG. Please see the documentation for your specific Syslog server software in order to correctly configure it. Limiting the sending rate The CLI configuration of a Syslog server can also include the parameter LogSendRateLimit. ...
Page 51 Management Filtering severity and message exceptions For each log receiver, it is possible to impose rules on what log message categories and severities are sent to that receiver. It also possible to lower or raise the severity of specific events. Filtering severity The Severity Filter is a means of specifying what severities, if any, are sent to a log receiver. By default, all log messages except those with a Debug severity are sent. However, an administrator may only want more important messages sent. For example, it might only be desirable to send Emergency, Alert and Critical messages to a log server. Example: Configuring the severity filter In this example, it is assumed that a Syslog server has already been configured in the SEG with the logical name My_Syslog. The aim is to have only the log messages with a severity of Emergency or Alert sent to this server. Device:/> set LogReceiver LogReceiverSyslog My_Syslog Severity=Emergency,Alert Log message exceptions After the severity filter is applied, any Log Message Exceptions are applied to generated messages. There can be more than one message exception for a log receiver and each consists of the following: • Category and ID This specifies the log messages that will be affected by the exception. If the ID number of the log message is not specified, all log messages for the specified category will be included. The ID of specific log messages can be found in the Log Reference Guide. • Type This can be one the following: • Exclude – This will exclude the specified log messages even if they are allowed by the severity filter. ...
Page 52: Snmp Traps
Management Example: Adding a message exception In this example, it is assumed that a Syslog server has already been configured in the SEG with the logical name My_Syslog. It is required to change the severity of the log message 161 (“Failed to Rekey IKE SA”) in the category IKE from the default of Warning to become Alert. 1. Change the current context to be the log receiver object: Device:/> cc LogReceiver LogReceiverSyslog My_Syslog 2. Add the message exception: Device:/LogReceiverSyslog/My_Syslog> add LogReceiverMessageException  LogCategory=IKE LogID=161  Action=INCLUDE  LogSeverity=Alert All the message exceptions can be listed for this receiver: Device:/LogReceiverSyslog/My_Syslog> show LogReceiverMessageException # Category Log Message ID Action LogSeverity Comments ‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ + 1 IKE 161 INCLUDE Alert (1) Alert <empty> Notice the exception gets a unique index number to identify it. In this case, it is 1. 3. Change the context back to the default: Device:/LogReceiverSyslog/My_Syslog> cc Device:/> SNMP traps SNMP protocol Simple Network Management Protocol (SNMP) is a means for communicating between a Network Management System (NMS) and a managed device. SNMP defines 3 types of messages: a Read command for an NMS to examine a managed device, a Write command to alter the state of a managed device, and a Trap that is used by managed devices to send messages asynchronously to an NMS about a change of state. SNMP traps in the SEG The SEG’s implementation of SNMP allows any log event message to be sent as an SNMP trap ...
Page 53 Management SNMP MIB File The file Clavister‐TRAP.MIB, which is included in the SEG distribution, defines the SNMP objects and data types that are used to describe an SNMP trap message received from the SEG. SNMP trap object All SEG generated SNMP traps, regardless of severity, use a common trap object called OSGenericTrap. The trap object includes the following parameters: • System – The SEG system generating the message. • Severity – The severity of the message. • Category – The SEG subsystem that is generating the message. • ID – A unique identifier for the message. • Description – A short textual description of the condition. • Action – The action that is being taken by the SEG, if any. This trap information can be cross‐referenced in the SEG‐100 Log Reference. Example: Sending SNMP traps to a trap receiver In this example, the generation of SNMP traps will occur for all events with a severity greater than or equal to Alert. All traps will be sent to an SNMP trap receiver with an IP address of 195.11.22.55. Device:/> add LogReceiver EventReceiverSNMP2c my_traps  IPAddress=195.11.22.55...
Page 54: Chapter 3: Addressing
Chapter Addressing Interfaces An Interface is an important logical building block in the SEG. All network traffic that transits through, originates from or is terminated in a security gateway, does so through one or more interfaces. Source and destination interfaces An interface can be thought of as a doorway through which network traffic passes to or from the SEG. An SEG interface has one of two functions: • Source interface: When traffic arrives through an interface, that interface is referred to in the SEG as the source interface (also sometimes known as the receiving or incoming interface). • Destination interface: When traffic leaves after being checked against the SEG’s security policies, the interface used to send the traffic is referred to in the SEG as the destination interface (also sometimes known as the sending interface). All traffic passing through the SEG has both a source and destination interface. As explained in more depth later, the special logical interface core is used when the SEG itself is the source or destination for traffic. Interface types The SEG supports a number of interface types, which can be divided into the following groups: • Ethernet interfaces: Each Ethernet interface represents a physical Ethernet port on an SEG‐based product. All network traffic that originates from or enters a security gateway will pass through one of the physical interfaces. The SEG currently supports Ethernet as the only physical interface type. • Tunnel interfaces: Tunnel interfaces are used when network traffic is being tunneled between the system and another tunnel endpoint in the network before it gets routed to its final destination. An example of a tunnel interface is an IPsec tunnel object, which is described further in IPsec components on page 117. To accomplish tunneling, additional headers are added to the traffic that is to be tunneled. Furthermore, various transformations can be applied to the network traffic depending on the type of tunnel interface. For example, when routing traffic over an IPsec interface, the payload is usually encrypted to achieve confidentiality. ...
Page 55: Ethernet Interfaces
Addressing All interfaces are logically equivalent Even though the different types of interfaces may be very different in the way they function, the SEG treats all interfaces as logically equivalent. This is an important and powerful concept and means that all types of interfaces can be used almost interchangeably in the various SEG rule sets and other configuration objects. This results in a high degree of flexibility in how traffic can be examined, controlled and routed. An extension of this equivalency concept is that no interface is assumed to be connected to trusted “inside” networks or to untrusted “outside” networks. The administrator makes these decisions and implements security policies accordingly. Interfaces have unique names Each interface in the SEG is given a unique name to be able to identify and select it for use with other SEG objects in a configuration. Some interface types, such as physical Ethernet interfaces, are already provided by the SEG with relevant default names that are possible to modify if required. any and core interfaces In addition, the SEG provides two special logical interfaces that are named any and core. The meaning of these are: • any represents all possible interfaces, including the core interface. • core indicates that the SEG itself will deal with traffic to and from this interface. An example of the use of core is when the SEG responds to ICMP “Ping” requests. When the destination interface of an IP rule or route is specified as core, the SEG itself is the ultimate destination of the traffic. Ethernet interfaces The SEG supports Ethernet, Fast Ethernet, Gigabit Ethernet and 10 Gigabit Ethernet interfaces as defined by the IEEE 802.3 standards. Ethernet frames With Ethernet, devices send data as Ethernet frames and other devices “listen” to determine ...
Page 56 Addressing EthernetInterface and EthernetDevice object types In the SEG there are two types of configuration objects that are used to manage Ethernet interface operation: EthernetInterface and EthernetDevice. The EthernetInterface object is used to configure the logical properties of Ethernet operation such as IP address. The EthernetDevice object is used to specify low level, driver‐related properties such as link‐ speed and duplex. The following section covers the EthernetInterface object type. Ethernet interface properties The principal properties for an EthernetInterface object are: • Interface name The names of the Ethernet interfaces are predefined by the system, and are mapped to the names of the physical ports. For example, a system with a wan port will have an Ethernet interface named wan. The names of the Ethernet interfaces can be changed to better reflect their usage. For example, if an interface named dmz is connected to a wireless LAN, you might change the interface name to wireless. For maintenance and troubleshooting, it is recommended to tag the corresponding physical port with the new name. • IP addresses Each Ethernet interface is required to have an Interface IP Address. The interface IP address is used as the primary address for communicating with the system through the specific Ethernet interface. More than one IP address can be allocated to an Ethernet interface. SEG IPAddress objects are usually used to define the IP addresses of Ethernet interfaces. Those objects are normally auto‐generated by the system. For more information, see Auto‐generated address objects on page 65. When the SEG is first started, all unconfigured Ethernet interfaces will be assigned default addresses from the localhost subnetwork (127.0.0.0/8). • MTU This determines the maximum size of packets in bytes that can be sent on this interface. By default, the interface uses the maximum size supported. • HACritical/Sync For HA cluster nodes, it is important to identify those interfaces that are critical and those ...
Page 57 Addressing Listing Ethernet interfaces To list all Ethernet interfaces, the CLI command is: Device:/> show Interface EthernetInterface Interface Name IP Addresses Routing Table ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐ sfp1 10.1.50.102 main sfp2 10.6.58.100 main The listing shows there are two interfaces. The IP address allocated to each is shown along with the routing table that is associated with them. Changing the IP address of an Ethernet interface To change the IP address on an interface, there are two methods: • If the IP address for an object is used by other SEG objects, such as IP rules, change the IP address for the object in the SEG address book. For example, to change the IPv4 address of the sfp1_ip object in the address book, use the CLI command: Device:/> set Address IPAddress sfp1_ip Address=10.1.1.2 • Change the IP address directly on the interface. For example, to change the IP address of the sfp1_ip interface, use the CLI command: Device:/> set Interface EthernetInterface sfp1 IPaddress=10.1.1.2 Assigning multiple IP addresses to an Ethernet interface Multiple IP addresses can be assigned to a single Ethernet interface by adding addresses to the Ethernet interface object. The addresses can be a mixture of IPv4 and IPv6 addresses: Device:/> set Address IPAddress sfp1_ip_2 Address=2001:DB8::1 Device:/> set Interface EthernetInterface sfp1 IPAddress=sfp1_ip,sfp1_ip_2 A maximum of six IPv4 plus six IPv6 addresses can be assigned to a single Ethernet interface. ...
Page 58: Arp
Addressing Address Resolution Protocol (ARP) allows the mapping of a network layer protocol (OSI Layer 3) address to a data link layer hardware address (OSI Layer 2). In data networks it is used to resolve an IPv4 address into its corresponding Ethernet address. ARP operates at the OSI Layer 2, data link layer, and is encapsulated by Ethernet headers for transmission. For an overview of the different OSI layers, see OSI Model on page 197. IP addressing over Ethernet A host in an Ethernet network can communicate with another host only if it knows the Ethernet address (MAC address) of that host. Higher level protocols such as IP make use of IPv4 addresses that are fundamentally different from a lower level hardware addressing scheme like the MAC address. ARP is used to retrieve the Ethernet MAC address of a host by using its IP address. ARP resolution When a host needs to resolve an IPv4 address to the corresponding Ethernet address, it broadcasts an ARP request packet. The ARP request packet contains the source MAC address, the source IPv4 address, and the destination IPv4 address. Each host in the local network receives this packet. The host with the specified destination address sends an ARP reply packet to the originating host with its MAC address. SEG ARP cache The ARP cache in network equipment, such as switches and security gateways, is an important component in the implementation of ARP. It consists of a dynamic table that stores the mappings between IPv4 addresses and Ethernet MAC addresses. The SEG uses an ARP cache in exactly the same way as other network equipment. Initially, the cache is empty at SEG startup and becomes populated with entries as traffic flows. The typical contents of a minimal ARP cache table might look similar to the following: Type IPv4 address Ethernet address Expires Dynamic 192.168.0.10 08:00:10:0f:bc:a5 Dynamic 193.13.66.77 0a:46:42:4f:ac:65...
Page 59 Addressing Example: Displaying the ARP cache The contents of the ARP cache can be displayed from within the CLI. This example displays the entries of the sfp1 interface. Device:/> arp ‐show ARP cache of iface sfp1: Dynamic 10.4.0.1 = 1000:0000:4009 Expire=196 Dynamic 10.4.0.165 = 0002:a529:1f65 Expire=506 Expires value The third column in the sample table and CLI output, Expires, is used to indicate for how much longer, in seconds, the ARP entry will be valid. For example, the first entry in the above CLI output has an expiration value of 196, which means that this entry will be rendered invalid and removed from the ARP cache in 196 seconds. If traffic is going to be sent to the 10.4.0.1 IPv4 address after the expiration, the SEG will issue a new ARP request. The default expiration time for dynamic ARP entries is 900 seconds (15 minutes). This can be changed by modifying the advanced setting ARPExpire. Example 1: Changing the ARPExpire setting This example shows how to change the number of seconds for the ARPExpire setting. Device:/> set Settings ARPTableSettings ARPExpire=1800 Modified ARPTableSettings. The advanced setting ARPExpireUnknown specifies how long the SEG will remember addresses that cannot be reached. This limit is needed to ensure that the SEG does not continuously request such addresses. The default value for this setting is 3 seconds. Example 2: Changing the ARPExpireUnknown setting This example shows how to change the number of seconds for the ARPExpireUnknown ...
Page 60 Addressing After the ARP entry expiration time, the SEG will learn the new MAC address of the host but sometimes it may be necessary to manually force the update. The easiest way to achieve this is by flushing the ARP cache. This deletes all dynamic ARP entries from the cache and forces the SEG to issue new ARP queries to discover the MAC/IP address mappings for connected hosts. Flushing can be done with the CLI command arp ‐flush. Example: Flushing the ARP cache This example shows how to flush the ARP cache from within the CLI. Device:/> arp ‐flush ARP cache of all interfaces flushed. Changing the ARP cache size By default, the ARP cache is able to hold 4096 ARP entries at one time. This is adequate for most situations. On rare occasions, such as when there are several very large LANs directly connected to the security gateway, it may be necessary to increase this value. This can be done by modifying the setting ARPCacheSize property in the ARPTableSettings object. Example 1: Changing the ARP cache size This example shows how to change the size of the SEG ARP cache to hold 8192 entries. Device:/> set Settings ARPTableSettings ARPCacheSize=8192 Modified ARPTableSettings. Hash tables are used to rapidly look up entries in the ARP cache. For maximum efficiency, a hash table should be twice as large as the entries it is indexing, so if the largest directly connected network contains 500 IP addresses, the size of the ARP entry hash table should be at least 1000. You can modify the setting ARPHashSize to reflect specific network requirements. The default value of this setting is 512. Example 2: Changing the ARP hash size This example shows how to change the SEG ARP hash size. ...
Page 61 Addressing Creating ARP entries To change the way the SEG handles ARP on an interface, you can create SEG ARP objects, each of which has the following properties: • Mode: The type of ARP object. This can be one of: • Static – Create a fixed mapping in the local ARP cache. • Publish – Publish an IP address on a particular MAC address (or this interface). • Interface: The local physical interface for the ARP object. • IP Address: The IPv4 address for the MAC/IP mapping. • MAC Address: The MAC address for the MAC/IP mapping. Static ARP objects A static ARP object can be used to insert a particular MAC/IP address mapping into the SEG ARP cache. The most frequent use of static ARP objects is in situations where some external network device is not responding to ARP requests correctly and is reporting an incorrect MAC address. Some network devices, such as wireless modems, may have such problems. A frequent source of confusion is that this mode is not for publishing the address for external devices. Instead, static entries allow the administrator to tell the SEG how to reach external devices. The entry tells the SEG that a specific IPv4 address can be reached through a specific interface using a specific MAC address. This means that when the SEG needs to communicate with the address, it consults the ARP table static entries and can determine it can be reached at a specific MAC address on a specific interface. This feature may also be used to lock an IP address to a specific MAC address for increasing security or to avoid denial‐of‐service if there are unauthorized users in a network. However, such protection applies only to packets being sent to that IP address. It does not apply to packets being sent from the IP address since the source MAC address can be forged. Example: Creating a static ARP entry This example will create a static mapping between IPv4 address 192.168.10.15 and MAC ...
Page 62 Addressing ARP publish The SEG supports publishing IP addresses on a particular interface. This can optionally be done along with a specific MAC address instead of the actual interface MAC address. The SEG will then send out these as ARP replies for any ARP requests received on the interface related to the published IP addresses. This can done for a number of reasons: • To give the impression that an interface in the SEG has more than one IP address. This is useful if there are several separate IP spans on a single LAN. The hosts on each IP span may then use a gateway in their own span when these gateway addresses are published on the corresponding SEG interface. • To publish multiple addresses on an external interface, enabling the SEG to use Static Address Translation (SAT) for traffic to these addresses and send it onwards to internal servers with private IPv4 addresses. • A less common purpose is to aid nearby network equipment responding to ARP in an incorrect manner. Example: Publishing an ARP entry This example will create an ARPEntry that publishes the IPv4 address 192.168.10.1 on the sfp1 interface: As in the previous example, change the context to be ARPEntries: Device:/> cc ARPEntries Next, add an ARPEntry object to ARPEntries: Device:/ARPEntries> add ARP Interface=sfp1 IP=192.168.10.1 Mode=Publish Finally, return to the default root context: Device:/ARPEntries> cc Device:/> ...
Page 63: Address Books
Addressing Address books The SEG address book contains named objects representing various types of IP addresses, including single IPv4 and IPv6 addresses and networks, as well as ranges of addresses. Ethernet MAC addresses can also be defined in the address book. Note: In this guide, an IPv6 Prefix will often be referred to as a Network in this guide. This is done to be consistent with the usage of the word Network with IPv4. Address book benefits Using address book objects has a number of important benefits: • They increase understanding of the configuration by referencing meaningful symbolic names. • They enable you to enter address object names instead of numerical addresses, reducing errors. • They enable you to define an address object just once in the address book and then reference this definition, so that changing the definition automatically changes all references to it. Address types The address book can contain objects for two types of addresses: IP addresses and MAC addresses. These are described next. IP addresses IP address objects are used to define symbolic names for various types of IP addresses. Depending on how the address is specified, an IP address object can represent a single IP address (a specific host), a network, a range of IP addresses, and even a DNS name. The following list describes the various types of addresses an IP address object can hold, along with what format that is used to represent that specific type: • Host: A single host is represented simply by its IP address. This can be either an IPv4 or IPv6 address. For example, 192.168.0.14. It also possible to specify a comma‐separated list of addresses. These can be a mixture of IPv4 and IPv6 addresses. For example, 192.168.0.14,10.15.0.50,2001:DB8::1. • IP network: An IPv4 network is represented using the Classless Inter Domain Routing (CIDR) form. CIDR uses a forward slash and a number (0‐32) to denote the size of the ...
Page 64 Addressing • IP ranges: A range of IPv4 addresses is represented with the form a.b.c.d ‐e.f.g.h. Note that ranges are not limited to IPv4 netmask boundaries. They may include any span of IP addresses. For example, 192.168.0.10‐192.168.0.15 represents six IPv4 hosts in consecutive order. A range of IPv6 addresses is specified in the same way. For example, 2001:DB8::1‐ 2001:DB8::6 Example 1: Adding an IP host This example adds the IP host www_srv1 with IPv4 address 192.168.10.16 to the address book: Device:/> add Address IPAddress www_srv1 Address=192.168.10.16 Example 2: Adding an IP network This example adds an IP network named wwwsrvnet with address 192.168.10.0/24 to the address book: Device:/> add Address IPAddress wwwsrvnet Address=192.168.10.0/24 Example 3: Adding an IP range This example adds a range of IPv4 addresses from 192.168.10.16 to 192.168.10.21 and names the range wwwservers: Device:/> add Address IPAddress wwwservers Address=192.168.10.16‐192.168.10.21 Example 4: Deleting an address object This example deletes an object named wwwsrv1 from the address book: Device:/> delete Address IPAddress wwwsrv1 ...
Page 65 Addressing Example: Adding an Ethernet address The following example adds an Ethernet Address object named wwwsrv1_mac with the numerical MAC address 08‐a3‐67‐bc‐2e‐f2. Device:/> add Address EthernetAddress wwwsrv1_mac Address=08‐a3‐67‐bc‐2e‐f2 Auto-generated address objects To simplify the configuration, a number of address objects in the address book are automatically created by the SEG when the system starts for the first time and these objects are used in various parts of the initial configuration. Generated objects The following address objects are auto‐generated: • Interface addresses: For each Ethernet interface in the system, two IPv4 address objects are predefined; one object for the IP address of the actual interface, and one object representing the local network for that interface. Interface IPv4 address objects are named <interface‐name>_ip and network objects are named <interface‐name>_net. For example, an interface named sfp1 will have an associated interface IP object named sfp1_ip, and a network object named sfp1_net. • all‐nets‐ip4: The all‐nets‐ip4 IPv4 address object is initialized to the IPv4 address 0.0.0.0/0, which represents all possible IP4 addresses. The all‐nets‐ip4 IP object is used extensively in the configuration of the SEG and it is important to understand its significance. • all‐nets‐ip6: The all‐nets‐ip6 object performs the same function as all‐nets‐ip4 but for the IP6 address space. • all‐nets: The all‐nets object includes all IP4 and IP6 addresses. The command shows the current address book contents. For example: netobjects Device:/> netobjects all‐nets 0.0.0.0/0, ::/0 all‐nets‐ip4 0.0.0.0/0 all‐nets‐ip6 ::/0 Assigning multiple IP addresses to an interface As discussed in Ethernet interfaces on page 55, it is possible to assign multiple addresses to a ...
Page 66: Ipv6 Support
Addressing IPv6 support The IP address standard IPv6 is designed as a successor to IPv4, with the principal advantage of providing a much larger 128 bit address space. Among many other advantages, the large number of available global IPv6 addresses means that NAT is no longer required to share a limited number of public IPv4 addresses. SEG configuration objects supporting IPv6 The following parts of the SEG provide IPv6 support: • The address book • Routing tables • IP rules (excluding some actions) Enabling IPv6 IPv6 needs to be explicitly enabled in the SEG if it to be used. This is done by setting the value of the setting BlockIPVersions to be None: Device:/> set Settings IPSettings BlockIPVersions=None This allows both IPv4 and IPv6 packets to be recognized. If all IPv6 traffic is to be ignored, the setting is: Device:/> set Settings IPSettings BlockIPVersions=IPv6DropSilent This is the default and causes all IPv6 packets to be ignored. Adding an IPv6 address IPv6 address objects are created in the SEG address book in the same way as for IPv4. For IPv6, only the all‐nets‐ip6 object (IPv6 address ::/0) exists by default in the address book. This means that the IPv6 address and network objects associated with interfaces must first be created. Example: Adding an IPv6 address This example adds a new address object called my_ip6_address to the address book with the ...
Page 67 Addressing Enabling IPv6 on an interface Predefined address book objects already exist for each Ethernet interface. To enable IPv6 on an interface, an IPv6 address and network (prefix) must be added to the associated address book object. This is done specifying a comma‐separated list of the IPv4 address and the IPv6 address for the interface. Note: A maximum of six IPv4 and six IPv6 addresses can be assigned to a single Ethernet interface. Addresses in excess of this will be ignored. The networks configured on an interface for each of the IP addresses can be different from each other (all the IPv4 or IPv6 addresses do not have to come from the same network). If an IPv6 address and network are not assigned, IPv6 packets arriving at the interface are always dropped. Example: Enabling IPv6 on an interface Assume that an IPv6 address and network have to be associated with the sfp1 interface and that interface already has the IPv4 address 10.15.0.50 and network 10.15.0.0/24. Now add the single IPv6 address 2001:DB8::1 from the network 2001:DB8::/32 to the address object. Device:/> set Address IPAddress sfp1_net Address=10.15.0.0/24,2001:DB8::/32 Device:/> set Address IPAddress sfp1_ip Address=10.15.0.50,2001:DB8::1 Tip: When using the CLI command, you can append a new IP address set Address IPAddress value to any existing values. All the existing values can be displayed by typing a period (“.”) followed by a tab after Address=. You can then type a comma (“,”) followed by the new address to be added to the list. Interface routes are added automatically When an IPv6 address and network are assigned to an Ethernet interface (both are required), an IPv6 route for that interface should be added to the main routing table.
Page 68 Addressing Grouping IP addresses Since the IPAddress object can contain any number of explicit IPv4 or IPv6 addresses as well as references to other IPAddress objects, it can be used to create grouping of addresses. There is no special group object in the SEG for IP addresses. The all-nets address object The preconfigured all‐nets‐ip4 address object is a catch‐all object for all IPv4 addresses. Similarly, all‐nets‐ip6 represents all IPv6 addresses and only IPv6 addresses. To represent all IPv4 and IPv6 addresses, all‐nets‐ip4 is combined with all‐nets‐ip6 in the single predefined object all‐nets. Enabling IPv6 router advertisements An additional option for an Ethernet interface is to enable IPv6 Router Advertisement. This means that any external client connected to the interface can solicit and receive IPv6 messages to allow it to perform Stateless Address Auto‐Configuration (SLAAC). The SLAAC process allows the client to create its own unique global IPv6 address based on the MAC address of its interface and the prefix of the IPv6 address for the SEG interface it is connected Enabling router advertisement in the SEG is not done directly on the Ethernet Interface object. Instead, you specify the AdvertiseIP property for a single route in a routing table. This means that advertisements are enabled on the interface specified in the route and only for the host or network specified in the route. Example: Enabling IPv6 advertisements This example enables IPv6 advertisements on the route sfp1_route in the routing table main. 1. Change the current context to be the main routing table: Device:/> cc RoutingTable main 2. Enable router advertisements on the target route: Device:/RoutingTable/main> set sfp1_route AdvertiseIP6=yes 3. Return to the default context: Device:/> cc...
Page 69 Addressing IPv6 Neighbor Discovery IPv6 Neighbor Discovery (ND) is the IPv6 equivalent of the ARP protocol with IPv4 (see ARP on page 58). When IPv6 is enabled for a given Ethernet interface, the SEG will respond to any IPv6 Neighbor Solicitations (NS) sent to that interface with IPv6 Neighbor Advertisements (NA) for the IPv6 address configured for that interface. The SEG will also respond with neighbor advertisements for any networks configured using Proxy Neighbor Discovery. Enabling neighbor discovery for other interfaces can be achieved by adding an NDEntry object to the pre‐existing NDEntries list. The example below demonstrates how to do this. Example: Enabling interface Neighbor Discovery This example will create an NDEntry that publishes the IPv6 address my_ipv6 on the sfp3 interface: 1. Change the context to be NDEntries: Device:/> cc NDEntries 2. Add an NDEntry object to NDEntries: Device:/NDEntries> add NDEntry Interface=sfp3 IP=my_ipv6_net Note that the default value for the Mode property is Publish. 3. Return to the default, root context: Device:/NDEntries> cc Device:/> IPv6 usage restrictions The following is a summary of IPv6 restrictions in the current version of the SEG: • Management access with any SEG management interface is not possible using IPv6. • IP rules using IPv4 and IPv6 addresses can coexist in the same IP rule set and also a single rule using an IPAddressGroup object. • IPv6 addresses are not currently supported in IP rules with the following actions: •...
Page 70: Dns
Addressing IPv6 and High Availability SEG High Availability (HA) does not fully support IPv6. Any IPv6 configuration objects will be mirrored on both the HA master and slave units. However, if a failover occurs, state information will be lost when one unit takes over processing from the other and IPv6 connections will be lost. In an HA configuration where interfaces have IPv6 enabled and IPv6 addresses assigned, there is no private and shared IPv6 IP for each pair of interfaces. Each interface pair will have the same IPv6 IP address on both master and slave. A private IPv6 interface address for each interface in a pair is not possible. A DNS server can resolve a Fully Qualified Domain Name (FQDN) into the corresponding numeric IP address. FQDNs are unambiguous textual domain names that specify a node’s unique position in the Internet's DNS tree hierarchy. FQDN resolution allows the actual physical IP address to change while the FQDN stays the same. A Uniform Resource Locator (URL) differs from an FQDN in that the URL includes the access protocol along with the FQDN. For example, the protocol might be specified  http//: for world wide web pages. DNS servers can exist both on the public Internet for resolution of public IP addresses as well as private servers for the resolution of private IP addresses. FQDNs are used in many aspects of an SEG configuration where IP addresses are unknown or where it makes more sense to use DNS resolution instead of static IP addresses. DNS with the SEG To accomplish DNS resolution, the SEG has a built‐in DNS client that can be configured to use up to eight (8) DNS servers. For DNS to function, at least a single server must be configured. It is recommended that at least two servers are defined so that there is a backup should one be unavailable. Features requiring DNS resolution Having at least one DNS server configured is vital for the functioning of the following modules in the SEG: • Automatic time synchronization. •...
Page 71 Addressing Example: Configuring DNS servers In this example, the DNS client is configured to use a single DNS server with IPv4 address 10.0.0.1. Device:/> set DNS DNSServers=10.0.0.1 To show the configured DNS server: Device:/> show dns Property Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ DNSServers: 10.0.0.1 CacheTTL: 60 CacheNegativeTTL: 30 QueueSize: 1024 RepeatTime: 5 RepeatCount: 3 Comments: <empty> If the IPv4 address 10.0.0.1 is defined in the SEG address book with the name dns1_ip, the command is: Device:/> set DNS DNSServers=dns_ip1 With three multiple alternate DNS servers called dns_ip1, dns_ip2 and dns_ip3, the command Device:/> set DNS DNSServers=dns_ip1,dns_ip2,dns_ip3 To test the DNS lookup, assuming a public Internet DNS is configured, the command is: Device:/> dns www.google.com ip4 info: 209.85.149.99 209.85.149.103 209.85.149.104 209.85.149.105 209.85.149.106 198.41.0.4 TTL: 60...
Page 72 Addressing To list the SEG DNS cache, the command is: Device:/> dns ‐list Name Address Type TTL ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ www.google.com 209.85.149.99 A 49 www.google.com 209.85.149.103 A 49 www.google.com 209.85.149.104 A 49 www.google.com 209.85.149.105 A 49 www.google.com 209.85.149.106 A 49 www.google.com 198.41.0.4 A 49...
Page 73: Chapter 4: Address Translation
Chapter Address Translation Overview The ability of the SEG to modify the source or the destination IP address of packets as they traverse a security gateway is known as Address Translation. The ability to transform one IP address to another can have many benefits. Two of the most important are: • Private IP addresses can be used on a protected network where protected hosts need to have access to the public Internet. There may also be servers with private IP addresses that need to be accessible from the public Internet. • Security is increased by making it more difficult for intruders to understand the topology of the protected network. Address translation hides internal IP addresses, which means that an attack coming from the “outside” is much more difficult. Types of translation The SEG supports two types of translation: • Dynamic Network Address Translation (NAT) • Static Address Translation (SAT) Both types of translation are policy‐based in the SEG, which means that they can be applied to specific traffic based on the source or destination network or interface, as well as based on the type of protocol (the service). Two types of SEG IP rules, NAT rules and SAT rules, are used to configure address translation. This section describes how to configure NAT and SAT rules and provides examples. Dynamic Network Address Translation (NAT) provides a mechanism for translating original source IP addresses to a different address as packets traverse a network device. Outgoing packets from the device then appear to come from a different source IP address. Incoming packets returning to that source address have their IP address translated back to the original one. NAT is configured in the SEG by specifying the NATAction option in an IP rule with an action of Allow. NAT can have two important benefits: • The IP addresses of individual clients and hosts can be “hidden” behind the security gateway’s IP address. The is sometimes referred to as topology hiding. •...
Page 74 Address Translation Many-to-one IP address translation NAT provides many‐to‐one translation. This means that each NAT rule in the IP rule set will translate between several source IP addresses and a single source IP address. To maintain session state information, each NAT flow is translated to a unique combination of port number and IP address for the source. The SEG then performs automatic translation of the source port number as well as the IP address for returning packets. In other words, the actual source IP addresses for flows are all translated to the same IP address and the flows are distinguished from one another by the allocation of a unique port number to each. The diagram below illustrates the concept of NAT. Figure 2. NAT IP address translation In the illustration above, three flows from IP addresses A, B and C are dynamically translated through a single source IP address N. The original port numbers are also changed. The next source port number allocated for a new NAT flow will be the first free port selected randomly by the SEG. Ports are allocated randomly to increase security from external attack. Limitations on the number of flows There is a limitation of approximately 64,500 simultaneous NAT flows where each flow consists of a unique pair of IP addresses. The term IP pair means one IP address on an SEG interface and the IP address of some external host to which a flow is being made. If two different IP addresses on an external host are being connected to from the same NAT address on the security gateway, this will constitute two, unique IP pairs. The 64,500 figure is therefore not a limitation for the entire SEG. ...
Page 75 Address Translation Limitations on the number of NAT Flows Approximately 64,500 simultaneous NAT flows are possible if a “flow” is considered to be a unique pair of IP addresses and different port numbers are not used or the same destination port is used. For example, if a remote server demands that all flows are to a single destination port, this limit will apply. However, since there is a possible range of 64,500 source ports and the same number for destination ports, it is theoretically possible to have over 4 billion flows between two IP addresses if all ports are used. Source IP address used for translation There are two options for how the SEG determines the source IP address that will be used for NAT: • Use the IP address of the interface When a new flow is established, the routing table is consulted to resolve the outbound interface for the flow. The IP address of that resolved interface is then used as the new source IP address when the SEG performs the address translation. This is the default way that the IP address is determined. • Define a specific IP address A specific IP address can be defined as the new source IP address. The specified IP address needs to have a matching ARP Publish entry configured for the outbound interface. Otherwise, the return traffic will not be received by the SEG. This technique might be used when the source IP is different based on the source of the traffic. For example, an ISP that is using NAT might use different IP addresses for different customers. Applying NAT translation The following example illustrates how NAT is applied in practice on a new flow: ...
Page 76 Address Translation 4. The SEG receives the packet and compares it to its list of open flows. Once it finds the flow in question, it restores the original address and forwards the packet. 195.55.66.77:80 => 192.168.1.5:1038 5. The original sender now receives the response. The sequence of these events is illustrated further in the diagram below. Figure 3. A NAT example Example: Adding a NAT rule The following example adds a NAT rule that will perform address translation for all HTTP traffic originating from the internal network sfp1 as it flows out to the public Internet on the wan interface. The IPv4 address of the wan interface will be used as the NATing address for all connections. 1. Change the current category to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create the IP rule: Device:/IPRuleSet/main> add IPRule Action=Allow  SourceInterface=sfp1  SourceNetwork=sfp1net  DestinationInterface=wan  DestinationNetwork=all‐nets  Service=http  SourceTranslation=NAT SetSourceAddress=InterfaceAddress  Name=NAT_HTTP 3. Return to the default CLI context if no more rules are needed: Device:/IPRuleSet/main> cc Device:/> ...
Page 77 Address Translation Specifying the NAT IP Address In the preceding example, the IP address used for NAT is the IPv4 address of the destination interface. The alternative is to specify another IPv4 address that is to be used on the destination interface. This is done by specifying the SetSourceAddress option as AllToOne and using the NewSourceIP4 option to specify the new NAT address for the interface. Example: Specifying the NAT IPv4 address This example is the same as the preceding example except the NAT address used on the wan interface is to be explicitly specified as 10.0.0.1 1. Change the current category to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create the IP rule: Device:/IPRuleSet/main> add IPRule Action=Allow  SourceInterface=sfp1  SourceNetwork=sfp1net  DestinationInterface=wan  DestinationNetwork=all‐nets  Service=http  SourceTranslation=NAT  SetSourceAddress=AllToOne  NewSourceIP4=10.0.0.1  Name=NAT_HTTP 3. Return to the default CLI context if no more rules are needed: Device:/IPRuleSet/main> cc Device:/> The IPv4 address 10.0.0.1 must also be explicitly ARP published on the wan interface if it is not already one of the addresses assigned to that interface. IPv4 and IPv6 NAT addresses In the example above, the option NewSourceIP6 could be used to specify an IPv6 address as ...
Page 78: Sat
Address Translation Protocols handled by NAT Dynamic address translation handles the TCP, UDP, and ICMP protocols with a good level of functionality, since the algorithm knows which values can be adjusted to become unique in the three protocols. For other IP level protocols, unique flows are identified by their sender addresses, destination addresses, and protocol numbers. This means that: • An internal machine can communicate with several external servers using the same IP protocol. • An internal machine can communicate with several external servers using different IP protocols. • Several internal machines can communicate with different external servers using the same IP protocol. • Several internal machines can communicate with the same server using different IP protocols. • Several internal machines can not communicate with the same external server using the same IP protocol. Note: These restrictions apply only to IP level protocols other than TCP, UDP and ICMP, such as OSPF and L2TP. They do not apply to the protocols transported by TCP, UDP and ICMP, such as telnet, FTP, HTTP and SMTP. The SEG can alter port number information in the TCP and UDP headers to make each flow unique, even though such flows have had their sender addresses translated to the same IP. Some protocols, regardless of the method of transportation used, can cause problems during address translation. The SEG can translate entire ranges of IP addresses and port numbers. These translations are transpositions where each address or port is mapped to a corresponding address or port in a new range, rather than translating them all to the same address or port. This functionality is known as Static Address Translation (SAT). SAT is configured in the SEG by setting either the SourceTranslation or DestinationTranslation to the value SAT in an IP rule with an action of Allow. Other SAT options are also added to completely specify the translation required. One-to-one translation (1:1) The simplest form of SAT usage is the translation of a single IP address to another, single IP ...
Page 79 Address Translation Using a DMZ At this point, it is important to understand the role of networks designated as a DMZ as SAT IP rules are of often used with them. The DMZ’s purpose is to act as a network where resources, such as servers, are placed for access by external, untrusted clients, typically across the public Internet. This network, therefore, has the maximum exposure to external threats. By isolating the DMZ network, a clear security separation is created from sensitive internal networks. SEG security policies can then control traffic flows between the DMZ and internal networks, isolating any security problems occurring in the DMZ. The illustration below shows a typical network arrangement with a SEG mediating communications between the public Internet and servers in a DMZ and between the DMZ and local clients on an internal network called LAN. Figure 4. The role of the DMZ...
Page 80 Address Translation Example: Enabling traffic to a protected web server in a DMZ (1:1) This example creates a SAT IP rule that will translate and allow IPv4 flows from the Internet to a web server located in a DMZ. The SEG is connected to the Internet using the wan interface with address object wan_ip (defined as 195.55.66.77) as IPv4 address. The Web server has the private IPv4 address 10.10.10.5 and is on the network connected to the dmz interface. 1. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create a SAT IP rule: Device:/IPRuleSet/main> add IPRule Action=Allow  Service=http  SourceInterface=any  SourceNetwork=all‐nets‐ip4  DestinationInterface=core  DestinationNetwork=wan_ip  DestinationTranslation=SAT  SetDestinationAddress=Offset  NewDestinationIP4=10.10.10.5  Name=SAT_HTTP_To_DMZ 3. Return to the default CLI context if no more rules are needed: Device:/IPRuleSet/main> cc Device:/> Many-to-many translation (M:N) A single SAT rule can be used to translate an entire range of IP addresses (a many‐to‐many ...
Page 81 Address Translation Since the five public IPv4 addresses are being ARP published so these addresses are not routed on core, the SAT destination interface is wan and not core. 1. Create an address object for the public IPv4 addresses: Device:/> add Address IPAddress wwwsrv_pub Address=195.55.66.77‐195.55.66.81 2. Create another object for the base of the Web server IPv4 addresses: Device:/> add Address IPAddress wwwsrv_priv_base Address=10.10.10.5 3. Publish the public IP addresses on the wan interface using ARP publish. A CLI command similar to the following is needed for each IP address: Device:/> add ARPEntry Interface=wan IP=195.55.66.77 mode=Publish Alternatively, you could assign all five addresses to the Ethernet interface since the SEG supports multiple IP addresses on interfaces. 4. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 5. Create a SAT rule for the translation: Device:/IPRuleSet/main> add IPRule Action=Allow  Service=http  SourceInterface=any  SourceNetwork=all‐nets‐ip4  DestinationInterface=wan  DestinationNetwork=wwwsrv_pub  DestinationTranslation=SAT  SetDestinationAddress=Offset  NewDestinationIP4=wwwsrv_priv_base 6. Return to the default CLI context using the command: Device:/IPRuleSet/main> cc Device:/> Example 2: Source address translation (M:N) Suppose there is a network 192.168.0.0/24 called lan_net connected to the lan interface. ...
Page 82 Address Translation The required SAT rule is defined as follows: 1. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create a SAT rule for the translation: Device:/IPRuleSet/main> add IPRule Action=Allow Service=http  SourceInterface=lan  SourceNetwork=lan_net  DestinationInterface=dmz  DestinationNetwork=dmz_net  SourceTranslation=SAT  SetSourceAddress=Offset  NewDestinationIP4=172.16.0.0 3. Return to the default CLI context using the command: Device:/IPRuleSet/main> cc Device:/> Note: In the above examples, IPv4 addresses are used. The option NewDestinationIP6= could be used with or instead of NewDestinationIP4= to perform the same function with IPv6 addresses. A SAT IP rule can combine source and destination translation in the same rule if required. Many-to-one translation (N:1) The SEG can be used to translate ranges and groups into just one IP address. Example: Translating traffic to a single Web server (N:1) This example is similar to the previous many‐to‐many (M:N) example, but this time a SAT IP will translate from five public IPv4 addresses to a single Web server located on a DMZ network. The SEG is connected to the Internet via the wan interface and the public IP ...
Page 83 Address Translation 1. Create an address object for the public IP addresses: Device:/> add Address IPAddress wwwsrv_pub Address=195.55.66.77‐195.55.66.81 2. Create another object for the base of the web server IP addresses: Device:/> add Address IPAddress wwwsrv_priv Address=10.10.10.5 3. Publish the public IP addresses on the wan interface using ARP publish. A CLI command like the following is needed for each IP address: Device:/> add ARPEntry Interface=wan IP=195.55.66.77 mode=Publish Alternatively, you could assign all five addresses to the Ethernet interface since the SEG supports multiple interface IP addresses. 4. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 5. Create a SAT rule for the translation: Device:/IPRuleSet/main> add IPRule Action=Allow Service=http  SourceInterface=wan  SourceNetwork=all‐nets‐ip4  DestinationInterface=dmz  DestinationNetwork=wwwsrv_pub  DestinationTranslation=SAT  SetDestinationAddress=AllToOne  NewDestinationIP4=wwwsrv_priv 6. Return to the default CLI context with the command: Device:/IPRuleSet/main> cc In the above example, the option NewDestinationIP6= could be used with or instead of NewDestinationIP4= to perform the same function with IPv6 addresses. Note: When all‐nets, all‐nets‐ip4, or all‐nets‐ip6 is the destination in a SAT rule, an All‐to‐One mapping is always done. Port translation with SAT Port Translation (also known as Port Address Translation ‐PAT) can be defined in a SAT IP rule to modify either the source or destination port. This is similar to the 1:1 translation specified above but the additional option NewSourcePort= is used. ...
Page 84 Address Translation Example: Port translation with SAT This example is very similar to the 1:1 example near the beginning of this section but the port number will also be changed by the translation. A server’s private IP address is wwwsrv_priv on the DMZ interface. All incoming http connections will be translated to wwwsrv_priv and all ports in the http service object's range 80 ‐85 will be translated to the range 1080 ‐1085. 1. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create a SAT rule for the translation: Device:/IPRuleSet/main> add IPRule Action=Allow Service=http  SourceInterface=wan  SourceNetwork=all‐nets‐ip4  DestinationInterface=core  DestinationNetwork=wan_ip  SourceTranslation=SAT  SetSourceAddress=Offset  NewSourceIP4=wwwsrv_priv  SetSourcePort=Offset  NewSourcePort=1000 3. Return to the default CLI context with the command: Device:/IPRuleSet/main> cc Device:/> Combining SAT with NAT in the same rule Both SAT and NAT translation can be combined into the same Allow IP rule by using the options SourceTranslation=SAT and DestinationTranslation=SAT together. Example: Combining NAT and SAT Assume a number of clients on the internal protected lan_net network are surfing the public ...
Page 85 Address Translation The required IP rule is defined as follows: 1. Change the current CLI context to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create a SAT rule for the translation: Device:/IPRuleSet/main> add IPRule Action=Allow Service=http  SourceInterface=lan  SourceNetwork=lan_net  DestinationInterface=wan  DestinationNetwork=wan_ip  DestinationTranslation=SAT  SetDestinationAddress=Offset  NewDestinationIP4=our_server_ip  SourceTranslation=NAT  SetSourceAddress=AllToOne  NewSourceIP4=dmz_ip 3. Return to the default CLI context with the command: Device:/IPRuleSet/main> cc Device:/> Protocols not handled by SAT SAT can deal with IP‐based protocols that allow address translation to take place. However, there are protocols that can be translated only in special cases, and some protocols that cannot be translated at all. Protocols that cannot be translated using SAT usually cannot be translated using NAT. The reasons for this can include: • The protocol requires that the IP addresses are cryptographically unaltered. This applies to many VPN protocols. • The protocol embeds its IP addresses inside TCP or UDP level data and requires that the addresses visible at the IP level are the same as those embedded in the data. Examples include FTP and NT domain logon via NetBIOS. •...
Page 86: Chapter 5: Routing
Chapter Routing Principles of routing IP routing is one of the most fundamental functions of the SEG. Any IP packet flowing through an SEG will be subjected to at least one routing decision at some point, so properly setting up routing is crucial for the system to function as expected. Routers IP routing is the mechanism used in TCP/IP based networks for delivering IP packets from their source to their ultimate destination through a number of intermediary network devices. These devices are most often referred to as routers since they perform the task of routing packets to their destination. Routing tables In each router, one or more routing tables contain a list of routes, which are used to find out through which interface to send a packet so it can reach its intended destination. In the SEG, there can be one or more routing tables. At minimum, there is a single, default routing table called main. The interfaces of routes in these tables may be a physical Ethernet interface or it might be a configuration object that behaves like an interface such as a VPN tunnel. Example: Listing the routing table main contents This example shows how to list the contents of the default routing table main. First, change the current context to be the main routing table: Device:/> cc RoutingTable main Now, list the contents of the table: Device:/RoutingTable/main> show # Interface Network Gateway Local IP ‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐ 1 sfp2 10.6.0.0/16 <empty> 10.6.58.100 This shows that the main table contains a single route, which says that the network 10.6.0.0/16 can be found on the interface sfp2. The components of a single route in an SEG routing table are discussed next.
Page 87 Routing Components of a route When a route is defined, it consists of the following properties: • Interface This is the interface to forward the packet on in order to reach the destination network. In other words, it is the interface to which the destination IP range is connected, either directly or through a router. The interface can be any logical interface. This includes Ethernet interfaces as well as VPN tunnels. • Network This is the destination network IP address range that is reached via the specified interface. The route chosen from a routing table is the one that has a destination IP range that includes the IP address being sought. If there is more than one such matching route, the route chosen is the one that has the smallest IP address range and lowest metric. The destination network all‐nets‐ip4 is usually always used in the route for public Internet access via an ISP. As its name suggests, all‐nets‐ip4 corresponds to all IP4 Internet addresses, and the route for this address is sometimes referred to as the default route since it is chosen when no other match can be found. • Gateway This is the IP address of the gateway that is the next router in the path to the destination network. This is optional. If the destination network is connected directly to the interface, this is not needed. When a router lies between the SEG and the destination network, a gateway IP must be specified. For example, if the route is for public Internet access via an ISP, the public IP address of the ISP’s gateway router would be specified. • Local IP address This property usually does not need to be specified. If it is, the SEG responds to ARP queries sent to this address. The Local IP Address property on page 89 section explains this property in more depth. • Metric This is a metric value assigned to the route and used as a weight when performing comparisons between alternate routes. If two routes are equivalent but have different metric values then the route with the lowest metric value is taken. ...
Page 88 Routing Typical routing scenario The diagram below illustrates a typical SEG usage scenario. Figure 5. A typical routing scenario In the above diagram, the LAN interface is connected to the network 192.168.0.0/24 and the DMZ interface is connected to the network 10.4.0.0/16. The WAN interface is connected to the network 195.66.77.0/24 and the address of the ISP gateway to the public Internet is 195.66.77.4. The associated routing table for this would be as follows: Route Interface Destination Gateway sfp1 192.168.0.0/24 10.4.0.0/16 195.66.77.0/24 all-nets-ip4 195.66.77.4 The above routing table provides the following information: • Route #1 All packets going to hosts on the 192.168.0.0/24 network should be sent out on the sfp1 interface. As no gateway is specified for the route entry, the host is assumed to be located on the network segment directly reachable from the sfp1 interface. • Route #2 All packets going to hosts on the 10.4.0.0/16 network are to be sent out on the dmz interface. For this route also, no gateway is specified since there is no “hop” via another router to the destination network.
Page 89 Routing • Route #3 All packets going to hosts on the 195.66.77.0/24 network will be sent out on the wan interface. No gateway is required to reach this network. • Route #4 All packets going to any host (the all‐nets‐ip4 network will match all hosts) will be sent out on the wan interface and to the gateway with IPv4 address 195.66.77.4. That gateway will then consult its routing table to find out where to send the packets next. A route with the destination all‐nets‐ip4 is often referred to as the Default Route as it will match all packets for which no specific route has been configured. This route usually specifies the interface that is connected to the public internet via an ISP. Narrowest routing TableMatch is selected When a routing table is evaluated, the ordering of the routes is not important. Instead, all routes in the relevant routing table are evaluated and the most specific route is used. In other words, if two routes have destination networks that overlap, the narrower network definition will be taken before the wider one. This behavior is in contrast to IP rules where the first matching rule is used. In the above example, a packet with a destination IPv4 address 192.168.0.4 will theoretically match both the first route and the last one. However, the first route entry is a narrower, more specific match so the evaluation will end there and the packet will be routed according to that entry. Although routing table ordering is not important, it is still recommended for troubleshooting purposes to try and place narrower routes first and the default route last. Local IP Address property The correct usage of the Local IP Address property can be complex, so additional explanation is provided next. Normally, a physical interface such as sfp1 is connected to a single network and the interface and network are on the same network. In that case, the network is bound to a physical interface and clients on the connected network can automatically find the SEG through ARP queries. ARP works because the clients and the SEG interface are part of the same network. A second network might then be added to the same physical interface via a switch, but with a new network range that doesn't include the physical interface's IP address. In that case, this ...
Page 90 Routing When the Default Gateway of the second network's clients is now set to the same value as the Local IP Address of the above route, the clients will be able to communicate successfully with the interface. The IP address chosen in the second network isn't significant, as long as it is the same value for the Default Gateway of the clients and the Local IP Address. The effect of adding the route with the Local IP Address is that the SEG will act as a gateway with the Local IP Address and respond to, as well as send out, ARP queries as though the interface had that IP address. The following diagram illustrates a scenario where this feature could be used. The network 10.1.1.0/24 is bound to a physical interface that has an IPv4 address within the network of 10.1.1.1. If a second network 10.2.2.0/24 is attached to the interface via the switch, it is unbound since the interface's IP address doesn't belong to it. Figure 6. Using Local IP address with an unbound network This feature is normally used when an additional network is to be added to an interface, without changing the existing IP addresses of the network. From a security standpoint, doing this can present significant risks since different networks will typically be joined together through a switch, which imposes no controls on traffic passing between those networks. Caution should therefore be exercised before using this feature. ...
Page 91: Static Routing
Routing Example: Adding a route with LocalIP This example will show adding a route for the network 10.2.2.0/24 on the interface sfp1 with LocalIP set as 10.2.2.1. Device:/> cc RoutingTable main Device:/RoutingTable/main> add Route Interface=sfp1 Network=10.2.2.0/24 LocalIP=10.2.2.1 Device:/RoutingTable/main> cc Device:/> All traffic must have two associated routes All traffic must have two routes associated with it. Not only must a route be defined for the destination network of a flow, but one must also be defined for the source network. The route that defines the source network simply says that the source network is found on a particular interface. When a new flow is opened, the SEG performs a check known as a reverse route lookup, which looks for this route. The source network route is not used to perform routing but instead is used to verify that the source network is found on the interface where it arrived. If this check fails, the SEG generates a Default Access Rule error log message. Even traffic destined for Core (the SEG itself), such as ICMP ping requests must follow the rule of having two routes associated with it. In this case, the interface of one of the routes is specified as Core. Static routing The most basic form of routing is known as Static Routing. The term “static” is used because most entries in a routing table are part of the SEG system’s static configuration. They usually remain unchanged during long periods of system operation. Due to this manual approach, static routing is most appropriate to use in network deployments where addresses are fairly fixed and where the amount of connected networks are limited to a few. This section describes how to configure static routing and also explains how routing is implemented in the SEG.
Page 92 Routing When an IP packet is received on any of the interfaces, the list of active flows is consulted to see if there is an already a flow for which the received packet belongs. If an existing flow is found, the flow information includes where to route the packet so there is no need for lookups in the routing table. This is far more efficient than traditional routing table lookups, and is one reason for the high forwarding performance of the SEG. If an established flow cannot be found, then the routing table is consulted. Note that the route lookup is performed before any of the various policy rules get evaluated (for example, IP rules). Consequently, the destination interface is known at the time the SEG decides if the flow should be allowed or dropped. This design allows for a more fine‐grained control in security policies. SEG route notation The SEG uses a slightly different way to describe routes than most other systems, which simplifies its use and makes errors less likely. Many other products do not use the specific interface in the routing table, but specify the IP address of the interface instead. The routing table below is from a Microsoft Windows XP workstation: =================================================================== Interface List 0x1 ...... MS TCP Loopback interface 0x10003 ...00 13 d4 51 8d dd .. Intel(R) PRO/1000 CT Network 0x20004 ...00 53 45 00 00 00 .. WAN (PPP/SLIP) Interface =================================================================== Active Routes: Network Destination Netmask Gateway Interface Metric 0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.10 20 10.0.0.0 5.0.0.0 10.4.2.143 10.4.2.143 1 10.4.2.143 255.255.255.255 127.0.0.1 127.0.0.1 50 10.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 50 85.11.194.33 255.255.255.255 192.168.0.1 192.168.0.10 20 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1 192.168.0.0 255.255.255.0 192.168.0.10 192.168.0.10 20 192.168.0.10 255.255.255.255 127.0.0.1 127.0.0.1 20 192.168.0.255 255.255.255.255 192.168.0.10 192.168.0.10 20 224.0.0.0 240.0.0.0 10.4.2.143 10.4.2.143 50 224.0.0.0 240.0.0.0 192.168.0.10 192.168.0.10 20 255.255.255.255 255.255.255.255 10.4.2.143 10.4.2.143 1 255.255.255.255 255.255.255.255 192.168.0.10 192.168.0.10 1 Default Gateway: 192.168.0.1 =================================================================== Persistent Routes:...
Page 93 Routing The corresponding routing table in the SEG will be similar to the following: Flags Network Iface Gateway Local IP Metric ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ 192.168.0.0/24 sfp1 20 10.0.0.0/8 wan 1 0.0.0.0/0 wan 192.168.0.1 20 Note that multicast routes have not been included in the SEG list but are displayed in the Microsoft listing. SEG route definition advantages The SEG method of defining routes makes it easier to read and understand routing information. A further advantage with the SEG approach is that you can directly specify a gateway for a particular route and the following is true: • A separate route that includes the gateway IP address doesn’t need to be defined. • It doesn't matter even if there is a separate route that includes the gateway IP address and routes traffic to a different interface. Composite subnets can be specified Another advantage with the SEG approach to route definition is that it allows you to specify routes for destinations that are not aligned with traditional subnet masks. For example, it is perfectly legal to define one route for the destination IPv4 address range 192.168.0.5 to 192.168.0.17 and another route for IP addresses 192.168.0.18 to 192.168.0.254. This is a feature that makes SEG highly suitable for routing in highly complex network topologies. Displaying routing tables It is important to note that routing tables that are initially configured by the administrator can have routes added, deleted, and changed automatically during live operation and these changes will appear when the routing table contents are displayed. These routing table changes can take place for different reasons. For example, if dynamic routing with OSPF has been enabled, routing tables will become populated with new routes ...
Page 94 Routing Example 1: Displaying the main routing table This example illustrates how to display the contents of the default main routing table. To display the configured routing table, enter: Device:/> cc RoutingTable main Device:/RoutingTable/main> show Route # Interface Network Gateway Local IP ‐ ‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ 1 wan all‐nets 213.124.165.1 (none) 2 sfp1 sfp1net (none) (none) 3 wan wannet (none) (none) To display the active routing table, enter: Device:/> routes Routing table: main Flags Network Iface Gateway Local IP Metric ‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ 192.168.0.0/24 sfp1 0 213.124.165.0/24 wan 0 0.0.0.0/0 wan 213.124.165.1 0 Tip: In the CLI example above, it was necessary to first select the name of a specific routing table with the cc command (meaning change category or change context) before manipulating individual routes. This is necessary for any category that could contain more than one named group of objects. all-nets route The most important route that should be defined is the route to all‐nets, which usually corresponds to your ISP for public Internet access. Throughout this manual, the all‐nets‐ip4 address object is used in most cases, which is a subset of all‐nets. Core routes The SEG automatically populates the active routing table with Core Routes. These routes are present for the system to understand where to route traffic that is destined for the system itself. There is one route added for each interface in the system. For example, two interfaces named sfp1 and wan, with IPv4 addresses 192.168.0.10 and 193.55.66.77, respectively, will ...
Page 95 Routing When the system receives an IP packet whose destination address is one of the interface IPs, the packet will be routed to the core interface. In other words, it is processed by the SEG itself. There is also a core route added for all multicast addresses: Route Interface Destination Gateway core 224.0.0.0/4...
Page 96: Chapter 6: Firewall
Chapter Firewall IP rules Before examining IP rule sets in detail, it is useful to first look at the general concept of security polices to which IP rule sets belong. Security policies SEG security policies are configured by the administrator to regulate the way in which traffic can flow through the SEG. Such policies are described by the rules defined in various SEG rule sets. These rule sets share a uniform means of specifying filtering criteria that determine the type of traffic to which they will apply. Usually, the filtering criteria consist of the following rule properties: An interface where the packet is received on the SEG. This could also be Source interface a physical Ethernet interface but might be a configuration object that acts as an interface, such as a VPN tunnel. The network that contains the source IP address of the packet. This is Source network usually an SEG IP address object, which defines a single IP address, a range of addresses, or a network.  Destination interface An interface from which the packet would leave the SEG. This could also be a physical Ethernet interface or a configuration object that acts as an interface, such as a VPN tunnel.  Destination network The network to which the destination IP address of the packet belongs. This is usually an SEG IP address object which defines a single IP address, a range of addresses, or a network. The protocol type to which the packet belongs. SEG service objects Service define different protocols. Examples are HTTP and ICMP communication. The SEG provides a large number of predefined service objects but you can also create custom services. Existing service objects can also be collected together into Service Groups so that a group can be specified in a policy rule instead of a single service. ...
Page 97 Firewall IP rules and default main rule set IP rule sets are the most important of the SEG’s security policy rule sets. They determine the critical packet filtering function of the SEG, regulating what is allowed or not allowed to pass between different interfaces and between interfaces and the SEG. By default, one SEG IP rule set called main always exists. There are two possible approaches to how traffic traversing the SEG could be dealt with: • Everything is denied unless specifically permitted. • Or everything is permitted unless specifically denied. To provide optimal security from the outset, the SEG uses the first of these approaches. This means that when started for the first time, the SEG has no IP rules defined in the main IP rule set and all traffic arriving at all interfaces is therefore dropped. To permit any traffic to traverse the SEG (as well as allowing the SEG to respond to ICMP Ping requests), some initial IP rules must be added to the configuration. Each IP rule that you add will define the following basic filtering criteria: • From what interface to what interface traffic flows (the Source Interface and Destination Interface). • From what network to what network the traffic flows (the Source Network and Destination Network). • What kind of protocol is affected (the Service). • What action the rule will take when a match on all the criteria is triggered (the Action). Specifying any interface or network When specifying the filtering criteria in any of the rule sets specified above there are a number of useful predefined filtering parameters that can be used: •...
Page 98 Firewall Creating a Deny All IP rule By default, traffic that does not match any rule in the IP rule set is dropped by the SEG. For logging purposes, it is nevertheless recommended that you create an explicit IP rule with an action of Deny for all source/destination networks/interfaces, with logging enabled, and place it as the last rule in the IP rule set. This is often referred to as a Deny all rule. Example: Adding a Deny All IP rule This example shows how to create a Deny All rule that explicitly drops any IPv4 or IPv6 traffic not caught by any preceding rules in the main IP rule set. First, change the current context to be the main IP rule set: Device:/> cc IPRuleSet main Now, create the IP rule: Device:/IPRuleSet/main> add IPRule Action=Deny Service=all_services  SourceInterface=any SourceNetwork=all‐nets  DestinationInterface=any  DestinationNetwork=all‐nets  Name=main_da After the rule is added to an empty rule set, the entire rule set can be displayed: Device:/IPRuleSet/main> show IPRule, IPRuleFolder/ # Name Action SrcIf SrcNet DestIf DestNet Service ‐ ‐‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ + 1 main_da Deny any all‐nets any all‐nets all_services The individual rule's properties can be displayed by using its index number: Device:/IPRuleSet/main> show 1 Property Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ Index: 1 Name: main_da SourceInterface: any DestinationInterface: any SourceNetwork: all‐nets...
Page 99 Firewall Now, return to the default root context: Device:/IPRuleSet/main> cc Device:/> Save the configuration changes by issuing the activate command followed by the commit command. Tip: There may be several IP rule sets in use. It is recommended to include the IP rule set name in the name of the deny all rule so it can be easily identified in log messages. In the above example, the deny all rule for the main rule set is given the name main_da. Traffic flow needs an IP rule and a route As stated above, when the SEG is started for the first time, the default IP rules deny all traffic so at least one IP rule must be added to allow traffic to flow. In fact, a number of conditions need to be satisfied: • A route must exist in an SEG routing table that specifies on which interface packets should leave in order to reach their destination. A second route must also exist that indicates the source of the traffic is found on the interface where the packets enter. This satisfies the reverse route lookup check performed by the SEG when a new flow is established. • An IP rule in an SEG IP rule set that specifies the security policy that allows the packets from the source interface and network bound for the destination network to leave the SEG on the interface decided by the route. If the IP rule used is an Allow rule, it is bi‐directional by default. The ordering of these steps is important. The route lookup occurs first to determine the exiting interface and then the SEG looks for an IP rule that allows the traffic to leave on that interface. If a rule allowing the traffic doesn’t exist, the traffic is dropped. Figure 7. Simplified traffic flow...
Page 100 Firewall Before the route lookup is completed, the SEG first checks that traffic from the source network should, in fact, be arriving on the interface where it was received. This is done by the SEG performing a reverse route lookup, which means that the relevant routing table is searched for a route that indicates the network should be found on that interface. This second route should logically exist if a flow is bi‐directional, and it must have a pair of routes associated with it, one for each direction. IP rule evaluation When a new flow, such as a TCP/IP connection, is being established through the SEG, the list of IP rules are evaluated from top to bottom until a rule that matches the parameters of the new flow is found. The first matching rule's Action is then performed. For this reason, the ordering of the IP rules in the rule set is important. If the action in the matching IP rule allows it, the establishment of the new flow will proceed. A new entry representing the new flow will then be added to the SEG internal list of active flows. This list allows monitoring of opened and active flows. If the matching IP rule action is Deny or Reject, the flow is not set up. Tip: It is important to remember that the SEG searches the IP rules from top to bottom, looking for the first matching rule. If an IP rule seems to be ignored, check that some other rule above it isn't being triggered first. Stateful inspection After initial rule evaluation of the opening flow, subsequent packets belonging to that flow will not need to be evaluated individually against the rule set. Instead, a highly efficient algorithm searches the flow table for each packet to determine if it belongs to an established flow. This approach is known as stateful inspection and is applied not only to stateful protocols such as TCP but also to stateless protocols such as UDP and ICMP by means of “pseudo‐ connections.” This approach means that evaluation against the IP rule set is done only in the initial opening phase of a flow. Consequently, the size of the IP rule set has negligible effect on overall throughput. Flows are unidirectional. This means that a typical traffic connection, for example, between a Web browsing client and a Web server, will consist of two flows. This is not the case with the ESP flows used in IPsec where only a single flow is required for the connection. Examining flows All current flows can be shown using the CLI command. Some typical output is shown flow below: Device:/> flow ‐show Proto Source Destination Timeout...
Page 101 Firewall If the option is used, the matching reverse flow for a connection is also shown. The ‐verbose command form is as follows: Device:/> flow ‐show ‐verbose All options for the flow command can be found in the SEG‐100 Command Line Interface Reference. These include filtering parameters to only list certain flows. The use of this command with IPsec tunnels is discussed in IPsec troubleshooting on page 143. First matching principle If several IP rules in an IP rules set match the same filtering parameters, the first matching rule in a scan from top to bottom is the one that decides how the flow will be handled. Non-matching traffic Incoming packets that do not match any rule in the rule set and do not have an already opened matching flow will automatically be subject to a Deny action. To have more precise control over such non‐matching traffic, it is recommended to create an explicit rule called Deny All as the final rule in the rule set, with an action of Deny for source and destination network all‐nets, source and destination interface all, and service all_services. This example allows logging to be turned on for traffic that has no matching IP rule. IP rule actions A rule consists of two parts: the filtering parameters and the action to take if there is a match with those parameters. As described above, the parameters of any SEG rule, including IP rules are: • Source interface • Source network • Destination interface • Destination network • Service ...
Page 102 Firewall When an IP rule is triggered by a match, one of the following Actions can occur: • Allow: The packet is allowed to pass from the specified source to the specified destination interface. As the rule is applied to only the opening of a flow, an entry in the “flow table” is made to record that a flow is open. The remaining packets related to this flow will pass through the SEG “stateful engine” and will not require another rule table lookup. The parameter SourceTranslation can optionally be set to one of the following values: • NAT: This enables dynamic address translation (NAT) for traffic that triggers the rule. Refer to SAT on page 78 for a detailed description. • SAT: This enables static address translation (SAT) for traffic that triggers the rule. Refer to SAT on page 78 for a detailed description. • Deny: This tells the SEG to immediately discard the packet and by default, no reply is sent back to the sending host. A “polite” version of Deny can be created if the optional OnDeny parameter of a Deny rule is set to SendReject. This setting means the rule returns a TCP RST or ICMP Unreachable message for denied traffic, informing the sender that the packet was dropped. Using this option can help to speed up applications that must wait for a reply timeout period. The “impolite” default setting for a Deny rule is OnDeny=DropSilent. Bi-directional connections A common mistake when setting up IP Rules is to define two rules, one rule for traffic in one direction and another rule for traffic coming back in the other direction. In fact, an IP rules with the action defined as Allow will permit bi‐directional traffic flow once the initial flow is set up. The SourceNetwork and SourceInterface in an IP rule with action Allow refers to the source of the initial flow request. If a flow is permitted and then becomes established, traffic can pass in either direction over it. Using Reject The Reject action is recommended instead of Drop in situations where a “polite” reply is required from the SEG. An example of such a situation is when the SEG is responding to the IDENT user identification protocol. Some applications will pause for a timeout if Drop is used, and using Reject can avoid such processing delays. ...
Page 103: Services
Firewall Example: Adding an Allow IP Rule This example shows how to create a simple Allow rule that will allow HTTP flows to be opened from the sfp1net network on the sfp1 interface to any IP4 address (all‐nets‐ip4) on the wan interface. 1. Change the current context to be the main IP rule set: Device:/> cc IPRuleSet main 2. Create the IP rule: Device:/IPRuleSet/main> add IPRule Action=Allow Service=http  SourceInterface=sfp1 SourceNetwork=sfp1net DestinationInterface=wan  DestinationNetwork=all‐nets‐ip4  Name=lan_http 3. Return to the default route: Device:/IPRuleSet/main> cc Configuration changes must be saved by then issuing an activate followed by a commit command. Services A service object provides a way to reference a specific IP protocol. A service object is typically defined using one of the major transport protocols, TCP or UDP, and is associated with a specific source or destination port number. For example, the HTTP service is defined as using the TCP protocol with the associated destination port 80 and any source port. However, service objects are not restricted to just the TCP or UDP protocols. They can be used to encompass ICMP messages as well as a user‐definable IP protocol. A service is passive Service objects are passive SEG objects in that they do not themselves carry out any action in a configuration. Instead, they are used to apply security policy rules in SEG rule sets to a specific type of traffic. For example, an IP rule in an SEG IP rule set might have a service object associated with it that specifies that the rule is to apply to HTTP traffic. Inclusion in IP rules is one the most important usages of service objects. For more information ...
Page 104 Firewall Specifying any protocol An important predefined service is all_services. This service covers all possible protocols and is used in the filtering criteria of a rule when the protocol is not relevant. This is an example of a service group that is discussed later in Service groups on page 107. Other predefined services, such as all_icmp, also provide a means to describe a large number of protocols. Example 1: Listing the available services To produce a listing of the available services in the system, enter: Device:/> show Service The output will look similar to the following listing, with the services grouped by type and the service groups appearing first: ServiceGroup ServiceGroup Name Comments ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ all_tcpudpicmp All ICMP, TCP and UDP services ServiceICMP Name Comments ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ all_icmp All ICMP services ping‐inbound Inbound ping (does not allow tracerouting) " " Example 2: Viewing a specific service To view a specific service in the system, enter: Device:/> show Service ServiceTCPUDP http The output will look similar to the following listing: Property Value Remarks ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐...
Page 105 Firewall ICMP services Another type of custom service that can be created is an ICMP Service. The Internet Control Message Protocol (ICMP) is a protocol that is integrated with IP for reporting errors and transmitting control information. For example, the ICMP Ping feature uses ICMP to test Internet connectivity. ICMP types and codes ICMP messages are delivered in IP packets, and include a Message Type that specifies the format of the ICMP message and a Code that is used to further qualify the message. For example, the message type Destination Unreachable uses the Code parameter to specify the exact reason for the error. Either all ICMP message types can be accepted by a service (there are 256 possible types) or it is possible to filter the types. Specifying codes If a type is selected, the codes for that type can be specified in the same way that port numbers are specified. For example, if the Destination Unreachable type is selected with the comma‐delimited code list 0,1,2,3, this will filter Network unreachable, Host unreachable, Protocol unreachable, and Port unreachable. When a message type is selected but no code values are given, all codes for that type are assumed. ICMP message types The message types that can be selected are as follows: Sent by PING to a destination in order to check connectivity. Echo Request Destination Unreachable The source is told that a problem has occurred during packet delivery. There are codes from 0 to 5 for this type: • Code 0: Net Unreachable • Code 1: Host Unreachable • Code 2: Protocol Unreachable •...
Page 106 Firewall The source is told that there is a better route for a particular packet. Redirect Codes assigned are as follows: • Code 0: Redirect datagrams for the network • Code 1: Redirect datagrams for the host • Code 2: Redirect datagrams for the Type of Service and the network • Code 3: Redirect datagrams for the Type of Service and the host Identifies an incorrect parameter on the datagram. Parameter Problem The reply from the destination that is sent as a result of the Echo Echo Reply Request. The source is sending data too fast for the receiver, and the buffer has Source Quenching filled up. The packet has been discarded as it has taken too long to be delivered. Time Exceeded Custom IP protocol services Services that run over IP and perform application or transport layer functions can be uniquely identified by IP protocol numbers. IP can carry data for a number of different protocols. These protocols are each identified by a unique IP protocol number specified in a field of the IP header. For example, ICMP, IGMP, and EGP have protocol numbers 1, 2, and 8, respectively. Similar to the TCP/UDP port ranges described previously, a range of IP protocol numbers can be used to specify multiple applications for one service. For example, specifying the range 1‐ 4,7 will match the protocols ICMP, IGMP, GGP, IP‐in‐IP, and CBT. IP protocol numbers The currently assigned IP protocol numbers and references are published by the Internet Assigned Numbers Authority (IANA) and can be found at: http://www.iana.org/assignments/protocol‐numbers Example: Adding an IP protocol service This example shows how to add an IP Protocol service with the Virtual Router Redundancy ...
Page 107: Access Rules
Firewall Service groups A service group is an SEG object that consists of a collection of services. Groups are useful when you want to construct security policies that contain multiple services. Advantage of groups For example, there may be a need for a set of IP rules that are identical to each other except for the service property. By defining a service group that contains all the service objects from all the individual rules, you can replace all of them with just one IP rule that uses the group. For example, a service group called email‐services combines the three services objects for SMTP, POP3, and IMAP. Now only one IP rule needs to be defined that uses this group service to allow all e‐mail related traffic to flow. Groups can contain other groups A group can contain individual services as well as other service groups. This ability to have groups within groups should be used with caution since it can increase the complexity of a configuration and decrease the ability to troubleshoot problems. However, the feature allows the easy construction of large and complex sets of service definitions. Access rules One of the principal functions of the SEG is to allow only authorized connections access to protected data resources. Access control is primarily addressed by the SEG IP rule set in which a range of protected LAN addresses are treated as trusted hosts, and traffic flow from untrusted sources is restricted from entering trusted areas. Before a new connection is checked against the IP rule set, the SEG checks the connection source against a set of access rules. Access rules can be used to specify what traffic source is expected on a given interface and also to automatically drop traffic originating from specific sources. Access rules provide an efficient and targeted initial filter of new connection attempts. Default access rule Even if you do not explicitly specify any custom access rules, an access rule known as the Default Access Rule is always in place. This default rule is not a true rule but operates by checking the validity of incoming traffic by performing a reverse lookup in the SEG routing tables. This lookup validates that the incoming ...
Page 108 Firewall Custom access rules are optional For most configurations, the Default Access Rule is sufficient and you do not need to explicitly specify other rules. For example, the default rule can protect against IP spoofing, which is described in the next section. If access rules are explicitly specified, the Default Access Rule is still applied if a new connection does not match any of the custom access rules. The recommendation is to initially configure the SEG without any custom access rules and add them if there is a requirement for stricter checking on new connections. IP spoofing Traffic that pretends it comes from a trusted host can be sent by an attacker to try and get past a gateway's security mechanisms. Such an attack is commonly known as spoofing. IP spoofing is one of the most common spoofing attacks. Trusted IP addresses are used to bypass filtering. The header of an IP packet indicating the source address of the packet is modified by the attacker to be a local host address. The security gateway will believe the packet came from a trusted source. Although the packet source cannot be responded to correctly, there is the potential for unnecessary network congestion to be created and a potential Denial of Service (DoS) condition could occur. Even if the security gateway is able to detect a DoS condition, it is hard to trace or stop because of its nature. VPNs provide one means of avoiding spoofing, but where a VPN is not an appropriate solution, the access rules can provide an anti‐spoofing capability by providing an extra filter for verifying the source address. An access rule can verify that packets arriving at a given interface do not have a source address that is associated with a network of another interface. This means: • Any incoming traffic with a source IP address belonging to a local trusted host is NOT allowed. • Any outgoing traffic with a source IP address belonging to an outside untrusted network is NOT allowed. The first point prevents an outsider from using a local host's address as its source address. The second point prevents any local host from launching the spoof. Access rule settings The configuration of an access rule is similar to other types of rules. It contains filtering fields as well as the action to take. If there is a match, the rule is triggered, and the SEG will carry ...
Page 109 Firewall Access rule actions The access rule actions that can be specified are: • Drop: Discard the packets that match the defined fields. • Accept: Accept the packets that match the defined fields for further inspection in the rule set. Note: Logging can be enabled as required for these actions. Turning off Default Access Rule messages If the Default Access Rule log message is continuously being generated by a particular source and needs to be turned off, specify an access rule for the source with an action of Drop. Troubleshooting access rule-related problems Note that access rules are a first filter of traffic before any other SEG subsystems can see it. Sometimes problems can appear because of this. It is always recommended to check access rules when troubleshooting to see if a rule is preventing some other function, such as VPN tunnel establishment, from working properly. Example: Setting up an access rule Define a rule that ensures no traffic with a source address within the network bad_net is accepted on the sfp1 interface. 1. Create a new access rule set called acr1: Device:/> add AccessRuleSet acr1 2. Change the context to be this access rule set: Device:/> cc AccessRuleSet acr1 ...
Page 110: Internet Access
Firewall Internet access This section describes setting up access to the public Internet using the CLI, with static IP addresses supplied by an ISP. Assumptions The assumption for the examples and descriptions in this chapter is that the hardware platform has two Ethernet interfaces available: interface sfp1 and interface sfp2. The sfp2 interface will be used for connection to the public Internet and the sfp1 interface will be used for connection to a protected, local network. Required IP address objects Before you can set up access to the public network, you must create a number of IP address objects. In this example, the interface used for the Internet connection is sfp2, the ISP gateway IPv4 address is 10.5.4.1, the IPv4 address for the connecting interface is 10.5.4.35, and the network is 10.5.4.0/24. Note: Private IPv4 addresses are used for example only. Each installation's IP addresses will be different from these IP addresses but they are used here only to illustrate how setup is done. Also, these addresses are private IPv4 addresses and in reality an ISP would use public IP addresses instead. In addition, you must add the gateway IP address object, which in this example is called wan_gw: Device:/> add Address IPAddress wan_gw Address=10.5.4.1 This is the address of the ISP’s gateway, which is the first router hop towards the public Internet. If this IP object already exists, it can be given the IP address with the command: Device:/> set Address IPAddress wan_gw Address=10.5.4.1 Defining routes A route must now be defined that specifies that the Internet can be found on the sfp2 interface, along with the IP address of the default gateway that is the ISP’s router. 1. Change the context to be the main routing table: Device:/> cc RoutingTable main The prompt changes to indicate the context has changed. Device:/RoutingTable/main> 2. Add the route to the Internet: Device:/RoutingTable/main> add Route Interface=sfp2  Network=all‐nets‐ip4 ...
Page 111 Firewall 4. Set the IP object sfp2_ip, which will be the IP address of the interface connected to the ISP: Device:/> set IPAddress sfp2_ip Address=10.5.4.35 On initial startup, the SEG automatically creates and fills the SEG address book with the all interface related IP address objects. 5. Set the IP object sfp2_net, which will be the IP network of the connecting interface: Device:/> set IPAddress sfp2_net Address=10.5.4.0/24 6. Verify the properties of the sfp2 interface with the command: Device:/> show Interface EthernetInterface sfp2 The typical output is similar to the following: Property Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Name: sfp2 EthernetAddress: EthernetDevice: sfp2 MTU: 1500 IPAddress: 10.5.4.35 IPv4broadcast: <empty> RTBMembership: main Comments: <empty> Defining IP rules Even though an all‐nets‐ip4 route is automatically added, no traffic can flow without the addition of an IP rule that explicitly allows the flow. For example, to allow web surfing from the protected network sfp1_net on the interface sfp2, define a rule with an Action of Allow. 1. Change the current CLI context to the default IPRuleSet called main using the command: Device:/> cc IPRuleSet main Additional IP rule sets can be defined, which is why we do this, with the rule set main existing by default. Notice that the CLI prompt changes to reflect the current context: Device:/main> 2. Add an IP rule called lan_to_wan to allow the traffic through to the public Internet: Device:/main> add IPRule Name=lan_to_wan  Action=Allow SourceInterface=sfp1  SourceNetwork=sfp1_net ...
Page 112 Firewall 3. To include the DNS protocol to resolve URLs into IP addresses, create a separate IP rule for DNS: Device:/main> add IPRule Name=lan_to_wan_dns  Action=NAT SourceInterface=sfp1  SourceNetwork=sfp1_net  DestinationInterface=sfp2  DestinationNetwork=all‐nets‐ip4  Service=dns‐all Activating and committing changes After any changes are made to an SEG configuration, they will be saved as a new configuration but will not yet be activated. To activate all the configuration changes made since the last activation of a new configuration, the following command must be issued: Device:/> activate Although the new configuration is now activated, it does not become permanently activated until the following command is issued within 30 seconds following the activate: Device:/> commit The reason for two commands is to prevent a configuration accidentally locking out the administrator. If a lockout occurs, the second command will not be received and the SEG will revert back to the original configuration after the 30 second time period. This time period is a setting that can be changed as shown next. Example: Changing the activation revert timeout This example shows how to change the default revert timeout after a configuration is activated to 120 seconds. Device:/> set Settings RemoteMgmtSettings BiDirTimeout=120 Allowing ICMP Ping requests It can be useful to allow ICMP Ping requests to be sent out to external hosts on the Internet. As discussed earlier, the SEG will drop any traffic unless an IP rule explicitly allows it. This example shows how to allow the pinging of external hosts with the ICMP protocol by ...
Page 113: Chapter 7: Ipsec Vpn
Chapter IPsec VPN Overview This section takes a general look at VPNs, what they are, what they can provide, and the typical scenarios where they are used. VPN usage The Internet is increasingly used as a means to connect computers together since it offers efficient and inexpensive communication. The requirement is for data to traverse the Internet to its intended recipient without another party being able to read (confidentiality) or alter it (integrity). It is equally important that the recipient can verify that no one is falsifying data or pretending to be someone else. Virtual Private Networks (VPNs) meet this need, providing a highly cost effective means of establishing secure links between two co‐operating computers so that data can be exchanged in a secure manner. VPN allows the setting up of a tunnel between two devices known as tunnel endpoints. All data flowing through the tunnel is secure. The mechanism that provides tunnel security is encryption.
Page 114 IPsec VPN There are two common scenarios where VPN is used: 1. LAN to LAN connection – Where two internal networks need to be connected together over the Internet. In this case, each network is protected by an individual security gateway and the VPN tunnel is set up between them. 2. Client to LAN connection – Where many remote clients need to connect to an internal network over the Internet. In this case, the internal network is protected by the SEG to which the client connects and the VPN tunnel is set up between them. ...
Page 115 IPsec VPN VPN encryption Encryption of VPN traffic is done using the science of cryptography. Cryptography is an umbrella expression covering 3 techniques and benefits: No one but the intended recipients is able to receive and understand Confidentiality the communication. Confidentiality is accomplished by encryption. Authentication and integrity Proof for the recipient that the communication was actually sent by the expected sender, and that the data has not been modified in transit. This is accomplished by authentication, and is often implemented through the use of cryptographic keyed hashing. Proof that the sender actually sent the data; the sender cannot later Non‐repudiation deny having sent it. Non‐repudiation is usually a side‐effect of authentication. VPNs are typically concerned only with confidentiality and authentication. Non‐repudiation is normally not handled at the network level but rather is usually done at a higher transaction level. VPN planning An attacker targeting a VPN connection typically views VPN traffic as an indication that there is something worth targeting at the other end of the connection. In most cases, mobile clients and branch offices are far more attractive targets than the main corporate network. Once inside those, getting to the corporate network then becomes easier. In designing a VPN there are many issues that need to be addressed that aren't always obvious. These include: • Protecting mobile and home computers. • Restricting access through the VPN to needed services only, since mobile computers are vulnerable. • Creating DMZs for services that need to be shared with other companies through VPNs. • Adapting VPN access policies for different groups of users. • Creating key distribution policies. Endpoint security A common misconception is that VPN‐connections are equivalents to the internal network ...
Page 116: Key Distribution
IPsec VPN It is becoming increasingly common for users on the move to connect directly to their company’s network via VPN from their laptops. However, the laptop itself is often not protected. In other words, an intruder can gain access to the protected network through an unprotected laptop and already‐opened VPN connections. Placement in a DMZ A VPN connection should never be regarded as an integral part of a protected network. The VPN gateway should instead be located in a special DMZ or outside a gateway dedicated to this task. By doing this, you can restrict which services can be accessed via the VPN and ensure that these services are well protected against intruders. In instances where the gateway provides an integrated VPN feature, it is usually possible to dictate the types of communication permitted. The SEG VPN includes this feature. Key distribution If using pre‐shared keys for VPN security, key distribution schemes are best planned in advance. Issues that need to be addressed include: • How will keys be distributed? E‐mail is not a good solution. Phone conversations might be secure enough. • How many different keys should be used? One key per user? One per group of users? One per LAN‐to‐LAN connection? One key for all users and one key for all LAN‐to‐LAN connections? It is probably better to use more keys than is necessary since it will be easier to adjust access per user (group) in the future. • Should the keys be changed? If they are changed, how often? In cases where keys are shared by multiple users, you may want to consider overlapping schemes, so that the old keys work for a short period of time when new keys have been issued. • What happens when an employee in possession of a key leaves the company? If several users are using the same key, it should be changed. • In cases where the key is not directly programmed into a network unit, such as a VPN gateway, how should the key be stored? On a floppy? As a pass phrase to memorize? On a smart card? If it is a physical token, how should it be handled?
Page 117: Ipsec Components
IPsec VPN IPsec components This section covers IPsec standards and describes in general terms the various components, techniques, and algorithms that are used in IPsec‐based VPNs. IPsec overview Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to provide IP security at the network layer. An IPsec‐based VPN is made up of two parts: • Internet Key Exchange protocol (IKE) • IPsec protocols (AH or ESP or both) The first part, IKE, is the initial negotiation phase, where the two VPN endpoints agree on which methods will be used to provide security for the underlying IP traffic. In addition, IKE is used to manage connections using a set of Security Associations, SAs, for each connection. SAs are unidirectional, so there are usually at least two for each IPsec connection. The second part is the actual IP data being transferred, using the encryption and authentication methods agreed upon in the IKE negotiation. This can be accomplished by using IPsec protocols ESP or AH, or a combination of both. Currently, only ESP is supported in the SEG. The flow of events can be briefly described as follows: • IKE negotiates how IKE should be protected • IKE negotiates how IPsec should be protected • IPsec moves data in the VPN The following sections will describe each of these stages in detail. Internet Key Exchange (IKE) Encrypting and authenticating data is fairly straightforward: the only things needed are encryption and authentication algorithms, and the keys used with them. The Internet Key Exchange (IKE) protocol is used as a method for distributing these “session keys,” and provides a way for the VPN endpoints to agree on how the data should be protected. IKE has three main tasks: •...
Page 118 IPsec VPN An SA is unidirectional and relates to traffic flow in one direction only. For the bidirectional traffic that is usually found in a VPN, more than one SA is required per connection. Typically, when only ESP or AH is used, two SAs will be created for each connection, one describing the incoming traffic, and the other the outgoing. When ESP and AH are used in conjunction, four SAs will be created. IKE proposals An IKE algorithm proposal list is a suggestion of how to protect IPsec data flows. The VPN device initiating an IPsec connection will send a list of the algorithms combinations it supports for protecting the connection. It is then up to the device at the other end of the connection to say which proposal is acceptable. The responding VPN device, upon receiving the list of supported algorithms, will choose the algorithm combination that best matches its own security policies, and reply by specifying which member of the list it has chosen. If no mutually acceptable proposal can be found, the responder will reply by saying that nothing on the list was acceptable, and possibly also provide a textual explanation for diagnostic purposes. This negotiation to find a mutually acceptable algorithm combination is done not just to find the best way to protect the IPsec connection but also to find the best way to protect the IKE negotiation itself. Algorithm proposal lists also contain other IKE related parameters. Further details of the IKE negotiation and the other IKE parameters are described next. IKE negotiation An IKE negotiation consists of two phases: • IKE Phase 1: Negotiate how IKE should be protected. • IKE Phase 2: Negotiate how IPsec should be protected. These phases are described in detail next. IKE phase 1: IKE security negotiation An IKE negotiation is performed in two phases. The first phase, phase 1, is used to authenticate the two VPN gateways or VPN clients to each other, by confirming that the remote device has a matching pre‐shared key. Since publishing details of the negotiation in plain text is undesirable, IKE first agrees upon a ...
Page 119 IPsec VPN Authentication can be accomplished through using pre‐shared keys (PSK) or certificates. Using pre‐shared keys is the most common authentication method. Both PSK and certificates‐based VPNs are supported by the SEG. IKE phase 2: IPsec security negotiation In phase 2, another negotiation is performed, detailing the parameters for the IPsec connection. During phase 2 new keying material from the Diffie‐Hellman key exchange in phase 1 in extracted in order to provide session keys to use in protecting the VPN data flow. If perfect forwarding secrecy (PFS) is used, a new Diffie‐Hellman exchange is performed for each phase 2 negotiation. While this method is slower, it ensures that no keys are dependent on any other previously used keys, and that no keys are extracted from the same initial keying material. This prevents subsequent keys from being derived from a key that has been compromised (an unlikely event). Once the phase 2 negotiation is finished, the VPN connection is established and ready for traffic to pass through it. IKE parameters There are a number of parameters used in the IKE negotiation process. These are summarized next. Local endpoint identification This is a piece of data representing the identity of the local VPN tunnel endpoint. Local and remote networks/hosts These are the subnets or hosts between which IP traffic will be protected by the VPN. In a LAN‐to‐LAN connection, these will be the network addresses of the respective LANs. Tunnel and transport mode IPsec can be used in two modes, tunnel or transport. Tunnel mode indicates that the traffic will be tunneled to a remote device, which will decrypt/authenticate the data, extract it from its tunnel, and pass it on to its final destination. This way, an eavesdropper will only see encrypted traffic going from one of VPN endpoint to another. In transport mode, traffic is not tunneled. This mode can be used to ...
Page 120 IPsec VPN The remote endpoint (sometimes also referred to as the remote Remote endpoint gateway) is the remote device that performs VPN decryption/authentication and that passes the unencrypted data on to its final destination. The remote endpoint is not used in transport mode. The IPsec protocols describe how the data will be processed. The two IPsec protocols protocols to choose from are AH, Authentication Header, and ESP, Encapsulating Security Payload. ESP provides encryption, authentication, or both. However, it is not recommended to use encryption only, since it will dramatically decrease security. Note that AH provides only authentication and does not support encryption. The difference from ESP with authentication only is that AH also authenticates parts of the outer IP header, for instance source and destination addresses, making certain that the packet really came from who the IP header claims it is from. Since AH protects the outer IP addresses, it does not work with NAT. Note: The SEG does not currently support AH. This specifies the encryption algorithm used in the IKE negotiation, and IKE encryption depending on the algorithm, the size of the encryption key used. This specifies the authentication algorithms used in the IKE negotiation IKE authentication phase This specifies the Diffie‐Hellman group to use for the IKE exchange. The IKE DH group available DH groups are discussed below in the section titled Diffie‐ Hellman Groups. This is the lifetime of the IKE connection. IKE lifetime It is specified in time (seconds). Whenever one of these expires, a new phase‐1 exchange will be performed. If no data was transmitted in the last “incarnation” of the IKE connection, no new connection will be made until someone wants to use the VPN connection again. This value must be set greater than the IPsec SA lifetime. ...
Page 121 IPsec VPN With Perfect Forwarding Secrecy (PFS) disabled, initial keying material is PFS “created” during the key exchange in phase‐1 of the IKE negotiation. In phase‐2 of the IKE negotiation, encryption and authentication session keys will be extracted from this initial keying material. By using PFS, completely new keying material will always be created upon re‐key. Should one key be compromised, no other key can be derived using that information. PFS can be used in two modes: the first is PFS on keys, where a new key exchange will be performed in every phase‐2 negotiation. The other type is PFS on identities, where the identities are also protected, by deleting the phase‐1 SA every time a phase‐2 negotiation has been finished, making sure no more than one phase‐2 negotiation is encrypted using the same key. PFS is generally not needed, since it is very unlikely that any encryption or authentication keys will be compromised. It is enabled in the SEG by specifying one or more DH groups for the IPsec proposal. The encryption algorithm that will be used on the protected IPsec IPsec encryption traffic. This is not needed when AH is used, or when ESP is used without encryption.  IPsec authentication This specifies the authentication algorithm used on the protected traffic. This is not used when ESP is used without authentication, although it is not recommended to use ESP without authentication. This is the lifetime of the VPN connection. It is specified in both time IPsec lifetime (seconds) and data amount (kilobytes). Whenever either of these values is exceeded, a re‐key will be initiated, providing new IPsec encryption and authentication session keys. If the VPN connection has not been used during the last re‐key period, the connection will be terminated, and re‐opened from scratch when the connection is needed again. This value must be set lower than the IKE lifetime. Diffie-Hellman groups Diffie‐Hellman (DH) is a cryptographic protocol that allows two parties that have no prior ...
Page 122 IPsec VPN Diffie‐Hellman is used to establish the shared secret keys for IKE, IPsec and PFS. The Diffie‐Hellman group indicates the degree of security used for DH exchanges. The higher the group number, the greater the security but also the processing overhead. The DH groups supported by the SEG are as follows: • DH group 1 • DH group 2 • DH group 5 • DH group 14 • DH group 15 • DH group 16 • DH group 17 • DH group 18 With the SEG, DH groups are specified in a configuration as part of the IKE proposal list. At least one DH group must be specified in a proposal list. By default, DH groups 2 and 5 are used. IKE and IPsec lifetimes Both the IKE and the IPsec connections have limited lifetimes, described in terms of time. These lifetimes prevent a connection from being used for too long, which is undesirable from a security perspective. The IPsec lifetime must be shorter than the IKE lifetime. The difference between the two must be a minimum of 5 minutes. This allows for the IPsec connection to be re‐keyed simply by performing another phase‐2 negotiation. There is no need to do another phase‐1 negotiation until the IKE lifetime has expired. Default lifetimes The default lifetime values are as follows: • IKE lifetime – 28800 seconds (8 hours) •...
Page 123 IPsec VPN IKE authentication IKE provides a way to securely establish communications between the two ends of an IPsec tunnel. Before examining IKE in detail, the alternative of manually setting up a tunnel is discussed. Manual keying without IKE Without IKE, the “simplest” way of configuring the algorithms used by an IPsec tunnel is by using manual keying. This is a method where the encryption and authentication keys as well as some other parameters are directly configured on both sides of the VPN tunnel. Manual keying is supported by the SEG but only for ESP with tunnel mode. However, it has a number of limitations, such as having to always use the same encryption/authentication keys, no anti‐replay services. There is also no way of assuring that the remote host/security gateway really is the one it says it is. The vulnerability of manual keying to “replay attacks” means that a malicious entity with access to the encrypted traffic can record packets, store them, and send them to its destination at a later time. The destination VPN endpoint will have no way of telling if this packet is a “replayed” packet or not. Using IKE eliminates this vulnerability. PSK-based authentication Using a Pre‐shared Key (PSK) is a method where the endpoints of the VPN “share” a secret key. This is a service provided by IKE, and thus has all the advantages that come with it, making it far more flexible than manual keying. PSK advantages Pre‐Shared Keying has a lot of advantages over manual keying. These include endpoint authentication, which is what the PSKs are really for. It also includes all the benefits of using IKE. Instead of using a fixed set of encryption keys, session keys will be used for a limited period of time, where after a new set of session keys are used. PSK disadvantages One thing that has to be considered when using PSKs is key distribution. How are the Pre‐ Shared Keys distributed to remote VPN end points? This is a major issue, since the security of a PSK system is based on the PSKs being kept secret. Should one PSK be compromised, the configuration will need to be changed to use a new PSK. Certificate-based authentication Each VPN gateway has its own certificate, and one or more trusted root certificates. ...
Page 124 IPsec VPN Advantages of certificates The principal advantage of certificates is the added flexibility. Many VPN clients can be managed without having the same pre‐shared key configured on all of them, which is often the case when using pre‐shared keys and roaming clients. Instead, should a client be compromised, the client's certificate can simply be revoked. No need to reconfigure every client. Disadvantages of certificates The principal disadvantage of certificates is the added complexity. Certificate‐based authentication may be used as part of a larger public key infrastructure, making all VPN clients and gateways dependent on third parties. In other words, there are more aspects that have to be configured, and there is more that can go wrong. Note: IKEv2 does not support self‐signed certificates. IPsec protocols (ESP/AH) The IPsec protocols are the protocols used to protect the actual traffic being passed through the VPN. The actual protocols used and the keys used with those protocols are negotiated by IKE. There are two protocols associated with IPsec, AH and ESP. These are covered in the sections below. AH (Authentication Header) AH is a protocol used for authenticating a data stream. AH is not currently supported by the SEG. Figure 8. The AH protocol AH uses a cryptographic hash function to produce a MAC from the data in the IP packet. This MAC is then transmitted with the packet, allowing the remote endpoint to verify the integrity of the original IP packet, making sure the data has not been tampered with on its way through the Internet. Apart from the IP packet data, AH also authenticates parts of the IP header. The AH protocol inserts an AH header after the original IP header. In tunnel mode, the AH ...
Page 125 IPsec VPN ESP (Encapsulating Security Payload) The ESP protocol inserts an ESP header after the original IP header, in tunnel mode, the ESP header is inserted after the outer header, but before the original, inner IP header. All data after the ESP header is encrypted and/or authenticated. The difference from AH is that ESP also provides encryption of the IP packet whereas AH does not. The authentication phase also differs in that ESP only authenticates the data after the ESP header and the outer IP header is left unprotected. Since AH protects the outer IP addresses, it cannot be used with NAT. The ESP protocol is used for both encryption and authentication of the IP packet. It can also be used to do either encryption only, or authentication only. Figure 9. The ESP protocol Creating and using proposal lists To agree on the VPN flow parameters, a negotiation between tunnel peers is performed. As a result of these negotiations, the IKE and IPsec security associations (SAs) are established. A proposal list of supported algorithms is the starting point for a negotiation. Each entry in the list defines parameters for a supported algorithm that the VPN tunnel end point device is capable of supporting (the shorter term tunnel endpoint will also be used in this manual). The initial negotiation attempts to agree on a set of algorithms that the devices at either end of the tunnel can both support. There are two types of proposal lists, IKE proposal lists and IPsec proposal lists. IKE lists are used during IKE Phase‐1 (IKE Security Negotiation), while IPsec lists are using during IKE Phase‐2 (IPsec Security Negotiation). ...
Page 126 IPsec VPN Supported algorithms The algorithms currently supported by the SEG are: • Encryption algorithms: AES128‐CBC AES192‐CBC AES256‐CBC 3DES Null • Data integrity algorithms: SHA1 MD5 AES‐XCBC • Pseudo‐random function algorithms: This is the same list as for data integrity algorithms above. SEG algorithm sets In the SEG, the various encryption and integrity algorithms are grouped together into sets according to the level of security they provide. These sets, called high, low and all, are then used in the pre‐defined IKE and IPsec proposal lists. The sets are as follows: • High This consists of a set of algorithms to give higher security. This is the default algorithm set for an IPsec tunnel if no proposal lists are explicitly set. The complete list is: 1. 3DES and AES256‐CBC for encryption. 2. MD5 and SHA1 for integrity. • Low This set gives slightly less security. The complete list is: 1. 3DES and AES128‐CBC for encryption. 2. MD5 and SHA1 for integrity. • All This set combines all available algorithms. ...
Page 127 IPsec VPN Creating and using proposal lists There are two object types that define proposal lists and these make use of the High, Low and All algorithm groupings described above: • IKEProposalList This type has three pre‐defined objects: • ike_high – The IPsec tunnel default. • ike_low • ike_all • IPsecProposalList This type has three pre‐defined objects: • ipsec_high – The IPsec tunnel default. • ipsec_low • ipsec_all However, as the example below shows, it is possible to create new custom proposal lists objects with different combinations of algorithms. Example: Creating and using IKE proposal lists This example looks at creating a new IKE proposal list called my_list and adding to an existing IPsecTunnel object called my_tunnel. 1. Create the IKE proposal list: Device:/> add IKEProposalList my_list ...
Page 128 IPsec VPN Pre-shared keys Pre‐shared Keys (PSK) are one of the methods used to authenticate VPN tunnels. The other method is certificates. PSKs are secrets that are shared by the communicating parties before communication takes place. To communicate, both parties prove that they know the secret. The security of a shared secret depends on how “good” a passphrase is. Passphrases that are common words are extremely vulnerable to dictionary attacks. A PSK can be specified as either a hexadecimal or ASCII value. The longer the value used for the PSK, the better the security. Example: Adding an ASCII PSK This example creates a PSK object based on an ASCII string. The object can then be used for authentication with, for example, VPN tunnels. Device:/> add PSK my_psk Type=ASCII PSKAscii="mypasswordstring" Caution: Different encodings on different platforms can cause problems with non‐ASCII characters in a non‐hexadecimal PSK. For example, Microsoft Windows encodes PSKs containing non‐ASCII characters in UTF‐16 while the SEG uses UTF‐8. Even though the same PSK appears to be used at either end of the tunnel, there can be a mismatch because two platforms are encoding differently. For example, this can cause problems when setting up a Windows L2TP client that connects to the SEG. Certificates The SEG supports digital certificates that comply with the ITU‐T X.509 standard. This involves the use of an X.509 certificate hierarchy with public‐key cryptography to accomplish key distribution and entity authentication. References in this manual to a certificate means a X.509 certificate. A certificate is a digital proof of identity. It links an identity to a public key in order to establish whether a public key truly belongs to the supposed owner. By doing this, it prevents data transfer interception by a malicious third‐party who might post a fake key with the name and user ID of an intended recipient. The main usage of certificates in the SEG is to provide VPN tunnel security. Certificates and PSKs The simplest and fastest way to provide security between the ends of a tunnel is to use Pre‐ shared Keys (PSKs). However, as a VPN network grows so does the complexity of using PSKs. ...
Page 129 IPsec VPN Certificate components A certificate consists of the following: • A public key: The “identity” of the user, such as name and user ID. • Digital signatures: A statement that tells the information enclosed in the certificate has been vouched for by a Certificate Authority (CA). By binding the above information together, a certificate is a public key with identification attached, coupled with a stamp of approval by a trusted party. Certificate authorities A certificate authority (CA) is a trusted entity that issues certificates to other entities. The CA digitally signs all certificates it issues. A valid CA signature in a certificate verifies the identity of the certificate holder, and guarantees that the certificate has not been tampered with by a third party. A CA is responsible for making sure that the information issued in every certificate is correct. It also has to make sure that the identity of the certificate matches the identity of the certificate holder. Certificate chains A CA can also issue certificates to other CAs. This leads to a chain‐like certificate hierarchy. The highest certificate is called the Root Certificate and it is signed by the Root CA. Each certificate in the chain is signed by the CA of the certificate directly above it in the chain. However, the root certificate is signed by itself (it is “self‐signed”). Any certificates in the chain between the root certificate and the end certificate are called Intermediate Certificates. A Certification Path refers to the path of certificates from one certificate to another. To verify the validity of a user certificate, the entire path from the user certificate up to the trusted root certificate has to be examined before establishing the validity of the user certificate. In the SEG, the maximum length of a certificate chain is 4. In VPN scenarios with roaming clients, the client’s certificate will be the bottom of a certificate chain. Certificate validity time A certificate is not valid forever. Each certificate contains the dates between which the certificate is valid. When this validity period expires, the certificate can no longer be used, and a new certificate has to be issued. Important: Make sure the SEG date and time are set correctly when using certificates. Using NTP servers is the recommended method of doing this. ...
Page 130 IPsec VPN Trusting certificates When using certificates, the SEG can trust any party whose certificate is signed by a given CA. Before a certificate is accepted, the following steps are taken to verify the validity of the certificate: • Construct a certification path up to the trusted root CA. • Verify the signatures of all certificates in the certification path. • Fetch the CRL for each certificate to verify that none of the certificates have been revoked. Uploading certificates Certificates are uploaded to the SEG using Secure Copy (SCP). When the SEG receives certificates, it recognizes them as certificates and stores them until they are referenced in a CLI command to create a certificate object. The upload process will consist of a Root Certificate and Host Certificate upload plus any intermediate certificates that will be required. The root certificate has 2 parts added: a certificate file and a private key file. Using SCP is described in Secure copy on page 30. Self‐signed certificates cannot be used with the SEG. Creating certificate configuration objects Once the certificate files are uploaded using SCP, Certificate SEG configuration objects have to be created which are associated with these files. Assume that the CA signed certificate file has the filename myfile.cer and the host certificate files have the filenames anotherfile.cer and anotherfile.key. First, the CA signed root certificate is added to the SEG configuration. This consists of only one .cer file that was previously uploaded with SCP: Device:/> add Certificate ca_signed_cert  CertificateData=file://myfile.cer Type=Remote Next, the host certificate is added. This consists of two files, a .cer file and a .key file: scp C:\cert‐1.cer admin@192.168.3.1:MyCert Device:/> add Certificate host_cert  CertificateData=file://anotherfile.cer  Type=Local PrivateKey=file://anotherfile.key Certificates are global SEG objects In the SEG, certificates are global objects that can be reused between VPN tunnels. Even ...
Page 131 IPsec VPN Association with tunnels The association between a tunnel and certificates is created using the LocalID property of the IPsec tunnel. The tunnel’s LocalAuthMethod property should be set to Certificate (by default, this also becomes the value for RemoteAuthMethod, although the two could be set differently). The LocalID value specified for a tunnel is matched with the Subject or Subject Alternative Name fields in the available certificates. If more than one certificate provide a LocalID match, the first matching certificate is used. Manually creating Windows CA server requests To request certificates from a CA server or CA company, the best method is to send a CA Certificate Request which is a file that contains a request for a certificate in a well known, predefined format. It is possible to manually create the required files for a Windows CA server using the following stages. • Create a gateway certificate on the Windows CA server and export it as a file in the .pfx format. • Convert the .pfx file into the .pem format. • Take out the relevant parts of the .pem file to form the required .cer and .key files. The detailed steps for the above stages are as follows: 1. Create the gateway certificate on the Windows CA server and export it to a .pfx file on the local SEG management workstation disk. 2. Now convert the local .pfx file to a .pem file. This can be done with the OpenSSL utility using the CLI: > openssl pkcs12 ‐in gateway.pfx ‐out gateway.pem ‐nodes In this command line example, the file exported from the CA server is assumed to be called gateway.pfx and it is assumed to be in the same local directory as the OpenSSL executable. ...
Page 132 IPsec VPN 5. Mark and copy into the system clipboard that line and everything under it, up to and including the line: ‐‐‐‐‐END RSA PRIVATE KEY‐‐‐‐ 6. Now paste the copied text into the .key file and save it. 7. Back in the .pem file, locate the line that begins: ‐‐‐‐‐BEGIN CERTIFICATE‐‐‐‐ and copy into the system clipboard that line and everything under it, up to and including: ‐‐‐‐‐END CERTIFICATE‐‐‐‐ 8. Now paste this copied text into the .cer file and save it. The saved .key and .cer files are now ready for upload into the SEG. IPsec with the SEG This section looks more closely at IPsec tunnels usage with the SEG. An IPsecTunnel object in the SEG defines an endpoint of an encrypted VPN tunnel. Each IPsec tunnel is interpreted as a logical interface by the SEG, with the same filtering, traffic shaping and configuration capabilities as a physical Ethernet interfaces. Remote initiation of tunnel establishment When another security gateway or another IPsec compliant networking product (also known as the remote endpoint) tries to establish an IPsec VPN tunnel to a local security gateway, the list of currently defined IPsec tunnels in the SEG configuration is examined. If a matching tunnel definition is found, that tunnel is opened. The associated IKE and IPsec negotiations then take place, resulting in the tunnel becoming established to the remote endpoint. IP rules control decrypted traffic Note that an established IPsec tunnel does not automatically mean that all the traffic flowing from the tunnel is trusted. On the contrary, network traffic that has been decrypted will be ...
Page 133 IPsec VPN However, the IPsec tunnel itself does not need any IP rules defined. These rules are hidden, and created automatically by the SEG so that IKE negotiations and tunnel establishment can take place. Dead Peer Detection After the establishment of an IPsec tunnel to a client, the SEG uses an Informational message sent through the tunnel to the client as a Dead Peer Detection (DPD) mechanism. This message contains an empty encrypted payload. If the client doesn’t respond, six more DPD messages are sent by the SEG at progressively longer intervals before DPD is triggered, the client is considered unreachable, and the tunnel’s SAs are torn down. DPD is unidirectional, concerned only with incoming tunnel traffic. The basic interval for DPD message sending is determined by the IPsecTunnel property IKEDPDInterval. This has a default value of 90 seconds, which is recommended for most I‐WLAN scenarios. If it is set to zero, DPD is disabled. IPsec connection using two IPsec tunnel objects As discussed in IPsec troubleshooting on page 143, a potential problem can occur when a single IPsec VPN tunnel is set up referencing two IPsec tunnel objects. Consider the situation of an IPsec client sending a request to open a tunnel to the SEG. The client begins by sending an IKE_INIT request that includes a proposal list, key information and a notification payload. The SEG then scans the list of IPsec tunnel objects looking for the closest match and uses the tunnel object it finds. However, the tunnel chosen may not be the “right” tunnel since not all information needed for a correct match is available yet to the SEG. In the next IKE_AUTH stage of the setup process, the client sends the remainder of the required information and this may result in the SEG needing to find another IPsec tunnel object for the connection. An example of this is two tunnels A and B with the following characteristics: • Tunnel A has: • AES‐128 in its proposal list. • Authentication with PSK using ID id_a@somecompany.com •...
Page 134 IPsec VPN Now consider the following sequence: 1. A client with IPv4 address 177.22.0.47 initiates an IPsec negotiation with an IKE_INIT message. 2. Assuming that the client’s proposal list can match either tunnel, the IPsec tunnel object B is chosen for the connection because its remote endpoint is a narrower match to the client's IP address. 3. The IKE_AUTH phase now begins and the SEG finds out that the client wants to use PSK for authentication with an ID of id_a@somecompany.com. 4. Tunnel B no longer matches the client’s authentication requirements. The SEG will therefore search the IPsec tunnel object list looking for another tunnel that can match and finds tunnel definition A. The end result of these steps is that an IPsec tunnel is established but it uses the IKA SA established with tunnel B and the authentication established with tunnel A. This may not be the intended result so the administrator should take care when defining IPsec tunnel objects. IPsec rekeying The SEG supports IPsec rekeying. This means that a rekey of the IKE and IPsec Security Associations (SAs) will be initiated based upon the configured values in the proposal lists for IKE and IPsec. The lifetimes of the IKA SAs and IPsec SAs can be limited based on the time since they were created. The SEG will respond to re‐keying requests initiated by the MS as described by the IKEv2 specification. Important: The administrator should be aware of the effect of uploading a new SEG configuration to an security gateway that is supporting live IPsec tunnels. If any changes to the IPsec configuration are made as part of a new SEG configuration, then any live IPsec tunnel connections will be terminated and must be re‐established. This next section covers the steps for IPsec tunnel setup with the SEG in more detail. ...
Page 135: Setting Up Ipsec Tunnels
IPsec VPN Setting up IPsec tunnels Other sections explore IPsec components in detail. This section provides a summary of the essential steps needed for IPsec setup. It outlines the individual steps in setting up IPsec for the following scenarios: • IPsec LAN to LAN with Pre‐shared Keys • IPsec LAN to LAN with Certificates Note: VPN tunnels themselves do not require IP rules as explained in IPsec with the SEG on page 132, IP rules do not need to be defined in the SEG for VPN tunnel establishment. It is the data passing through a tunnel that requires IP rules which allow it to flow. Common tunnel setup requirements Before looking at each of these scenarios separately, it is useful to summarize the common SEG requirements when setting up any VPN tunnel, regardless of the type. • Define the tunnel First, you must define the tunnel itself. The SEG has various tunnel object types which are used to do this, such as an IPsec Tunnel object. • A route must exist Before any traffic can flow into the tunnel, a route must be defined in an SEG routing table. This route tells the SEG which network can be found at the other end of the tunnel so it knows which traffic to send into the tunnel. In most cases, this route is created automatically when the tunnel is defined and this can be checked by examining the routing tables. If a route is defined manually, the tunnel is treated exactly like a physical interface in the route properties, as it is in other aspects of the SEG. In other words, the route is saying to the SEG that a certain network is found at the other end of the tunnel. • Define an IP rule to allow VPN traffic An IP rule must be defined that explicitly allows traffic to flow between a network and the tunnel. As with route definitions, the tunnel is treated exactly like a physical interface when defining the IP rule. ...
Page 136 IPsec VPN IPsec LAN to LAN with pre-shared keys 1. Create a new IPsecPSK object. This will contain the key as well as a unique combination of LocalID and RemoteID. It is this combination of local and remote ID that is used to associate the key with the tunnel. Both local and remote ID can take on any string value such as an IP address or e‐mail address. They can also incorporate the wildcard asterisk (“*”) character. Note: If the wildcard character is used in an e‐mail address, it must not be combined with other characters. For example, *.user@somename.com cannot be used but *.somename.com can. 2. Optionally create an IKEProposalList and/or IPsecProposalList object if the default proposal lists do not provide a set of algorithms that are acceptable to the tunnel remote end point. The ike_high and ipsec_high lists are the defaults. An IKEProposalList object must contain at least one IKEProposal object. Similarly, an IPsecProposalList object must contain at least one IPsecProposal object. If PFS is required the IPsec proposal must have DH groups specified otherwise PFS is disabled (the default). 3. In the Address Book create IP objects for: • The remote VPN gateway that is the IP address of the network device at the other end of the tunnel (remote_gw). • The remote network which lies behind the remote VPN gateway (remote_net). • The local network behind the SEG that will communicate across the tunnel. Assume that this is the predefined address sfp1net and this network is attached to the SEG sfp1 interface that has the IP address sfp1_ip. 4. Create an IPsecTunnel object (ipsec_tunnel). Specify the following tunnel properties: • Set the IPaddress property of the tunnel. In most cases this can be set to something arbitrary such as 127.0.0.1. If NAT is being used on outgoing traffic, this should be set ...
Page 137 IPsec VPN • If not using the default ipsec_high list, set IPsecProposalList to the proposal list to be used for the tunnel. • Specify a LocalID for the tunnel. The combination of this and the RemoteID will identify the IPsecPSK object to use. • Specify a RemoteID for the tunnel. This can be specified using the asterisk (“*”) as a wildcard character. • Specify the LocalAuthMethod to be PSK. By default, this also becomes the value for RemoteAuthMethod, although you could set the local and remote method to different values. The IPsec Tunnel object can be treated exactly like any SEG Interface object in later steps. 5. Set up two IP rules in the IP rule set for the tunnel: • An Allow rule for outbound traffic that has the previously defined ipsec_tunnel object as the Destination Interface. The rule's Destination Network is the remote network remote_net. • An Allow rule for inbound traffic that has the previously defined ipsec_tunnel object as the Source Interface. The Source Network is remote_net. Action Src Interface Src Network Dest Interface Dest Network Service Allow sfp1 sfp1net ipsec_tunnel remote_net Allow ipsec_tunnel remote_net...
Page 138: Nat Traversal
IPsec VPN The setup steps are as follows: 1. Connect to the management interface for the SEG at one end of the tunnel. 2. Upload the Root Certificate and Host Certificate into the SEG using SSH. The root certificate needs to have 2 parts added: a certificate file and a private key file. The gateway certificate needs just the certificate file added. Associate the certificates with a LocalID. 3. Set up the IPsecTunnel object in the same way as for pre‐shared keys with the following differences: • Set LocalAuthMethod to Certificate (by default, RemoteAuthMethod assumes the same value). • The LocalID must match the value associated with at least one certificate in the system. 4. Connect to the management interface for the SEG at the other side of the tunnel and repeat the above steps with a different set of certificates. Note: The SEG date and time should be set correctly since certificates have an expiration date and time. Review CA server access on page 140, which describes important considerations for certificate validation. NAT traversal Both IKE and IPsec protocols present a problem in the functioning of NAT. Both protocols were not designed to work through NATs and because of this, a technique called NAT traversal (NAT‐ T) has evolved. This is an add‐on to the IKE and IPsec protocols and it allows them to function while undergoing NAT. The SEG supports the following standards for NAT traversal with IKE: • RFC 4306 for IKEv2. NAT traversal is divided into two parts: • Additions to IKE that lets IPsec peers tell each other that they support NAT traversal and the specific versions supported. • Changes to the ESP encapsulation. If NAT traversal is used, ESP is encapsulated in UDP, which allows for more flexible NATing.
Page 139 IPsec VPN NAT detection mechanism To achieve NAT detection, both IPsec peers send hashes of their own IP addresses along with the source UDP port used in the IKE negotiations. This information is used to see whether the IP address and source port each peer uses is the same as that which the other peer sees. If the source address and port have not changed, the traffic has not undergone NAT along the way, and NAT traversal is not necessary. If the source address and/or port has changed, then the traffic has undergone NAT, and NAT traversal is used. Changing ports Once the IPsec peers have decided that NAT traversal is necessary, the IKE negotiation is moved away from UDP port 500 to port 4500. This is necessary since certain NAT devices treat UDP packet on port 500 differently from other UDP packets in an effort to work around the NAT problems with IKE. The problem is that this special handling of IKE packets may in fact break the IKE negotiations, which is why the UDP port used by IKE has changed. UDP encapsulation Another problem that NAT traversal resolves is that the ESP protocol is an IP protocol. There is no port information as in TCP and UDP, which makes it impossible to have more than one NAT client connected to the same remote gateway at the same time. Because of this, ESP packets are encapsulated in UDP. ESP‐UDP traffic is sent on port 4500, the same port as IKE when NAT traversal is used. Once the port has been changed, all following IKE communication is done over port 4500. Keep‐alive packets are also sent periodically to keep the NAT mapping alive. NAT traversal configuration Most NAT traversal functionality is completely automatic and in the initiating gateway no special configuration is needed. However, for responding gateways two points should be noted: • On responding gateways, the Remote Endpoint field is used as a filter on the source IP of received IKE packets. This should be set to allow the translated IP address of the initiator. • When individual pre‐shared keys are used with multiple tunnels connecting to one remote gateway that are translated out through the same address, it is important to make sure the Local ID is unique for every tunnel. The Local ID can be one of: •...
Page 140: Ca Server Access
IPsec VPN CA server access Certificate validation can be performed by accessing a separate Certificate Server (CA) server. For example, the two sides of an IPsec tunnel exchange their certificates during the tunnel setup negotiation and either may then try to validate the received certificate. A certificate contains a Fully Qualified Domain Name (FQDN), which specifies the textual address of the validating CA server as well as the protocol used for accessing the server. For example, server access could require an HTTP request or possibly an LDAP request. CA server types CA servers are of two types: • A commercial CA server operated by one of the commercial certificate issuing companies. These are accessible over the public Internet and their FQDNs are resolvable through the public Internet DNS server system. • A private CA server operated by the same organization setting up the VPN tunnels. The IPv4 address of a private server will not be known to the public DNS system unless it is explicitly registered. It also will not be known to an internal network unless it is registered on an internal DNS server. For LTE scenarios in a telecom environment, a private CA server is most often used with server requests sent using the LDAP protocol. However, the protocol used is determined by the settings within the certificate. Access considerations Consider the following when planning for successful CA server access: • Either side of a VPN tunnel may issue a validation request to a CA server. • For a certificate validation request to be issued, the FQDN of the certificate's CA server must first be resolved into an IP address. The following scenarios are possible: 1. The CA server is a private server behind the SEG and the tunnels are set up over the public Internet to clients that will not try to validate the certificate sent by the SEG. In this case, the IPv4 address of the private server needs to be registered only on a private DNS server so the FQDN can be resolved. This private DNS server will also have to be configured in the SEG so it can be found when the SEG issues a validation ...
Page 141 IPsec VPN 2. The CA server is a private server with tunnels set up over the public Internet and with clients that will try to validate the certificate received from the SEG. In this case, the following must be done: a. A private DNS server must be configured so that the SEG can locate the private CA server to validate the certificates coming from clients. b. The external IP address of the SEG needs to be registered in the public DNS system so that the FQDN reference to the private CA server in certificates sent to clients can be resolved. For example, the SEG may send a certificate to a client with an FQDN of ca.company.com. This will need to be resolvable by the client to a public external IP address of the SEG through the public DNS system. The same steps should be followed if the other side of the tunnel is another security gateway instead of being many clients. 3. The CA server is a commercial server on the public Internet. In this, the simplest case, public DNS servers will resolve the FQDN. The only requirement is that the SEG will need to have at least one public DNS server address configured to resolve the FQDNs in the certificates it receives. • It must be also possible for a server request to pass from the validation request source (either the SEG or a client) to the CA server and the reply to be received. If the request is going to pass through the SEG, the appropriate rules in the SEG IP rule set need to be defined to allow this traffic through. The Service object used in the IP rules should be chosen to match the protocols that may be used for the request. IP rules are not required if the SEG itself is issuing the request to the CA server. Actions taken by the SEG are trusted by default. This is the case when the SEG must validate certificates in an LTE telecom scenario and is a general rule that also applies to DNS resolution requests issued by the SEG. • If LDAP requests are going to be sent to a CA server, the server must be configured to accept anonymous LDAP requests. Microsoft documentation may refer to this as Anonymous LDAP Binding. For example, the default setting for some Windows Active Directory servers is to reject anonymous LDAP requests, so this must be changed. The SEG always queries LDAP servers with anonymous requests. If the server is not configured to accept them, authentication will fail.
Page 142 IPsec VPN Placement of private CA servers The simplest solution for placement of a private CA server is to have it on the unprotected side of the SEG. However, this is not recommended from a security viewpoint. It is better to place it on the inside (or preferably in the DMZ if available) and to have the SEG control access to it. As explained previously, the FQDN address of the private CA server must be resolvable through public DNS servers for certificate validation requests coming from the public Internet. If the certificate queries are coming only from the SEG and the CA server is on the internal side of the security gateway, the IP address of the internal DNS server must be configured in the SEG so that these requests can be resolved and this is the case in the LTE telecom scenario. CA server access with LTE configuration is described further in the SEG‐100 Getting Started Guide. Figure 10. Certificate validation components...
Page 143: Ipsec Troubleshooting
IPsec VPN Turning off certificate validation One of the ways to troubleshoot problems with CA server access is to turn off the requirement to validate certificates. By default, checking is always enabled. Attempts to access CA servers by the SEG can be disabled by setting the CRL option for a certificate object to No (the default is Yes). For example: Device:/> set Certificate my_cert CRL=No This means that checking against the CA server's revocation list (CRL) will be turned off and access to the server will not be attempted. When switching off CRL checking, it may not be necessary to apply the CRL=No option to all certificates. This option follows the chain of certificate dependency. If it is applied to the root certificate of the chain, it is automatically applied to all dependent certificates. IPsec troubleshooting This section deals with how to troubleshoot the common problems that are found with VPN. General troubleshooting In all types of VPNs some basic troubleshooting checks can be made: • Check that all IP addresses have been specified correctly. • Check that all pre‐shared keys and usernames/passwords are correctly entered. • Use ICMP Ping to confirm that the tunnel is working. With roaming clients this is best done by “Pinging” the internal IP address of the local network interface on the SEG from a client (in LAN to LAN setups pinging could be done in any direction). If the SEG is to respond to a Ping then the following rule must exist in the IP rule set: Action Src Interface Src Network Dest Interface Dest Network Service Allow vpn_tunnel...
Page 144 IPsec VPN • Try and avoid duplication of IP addresses between the remote network being accessed by a client and the internal network to which a roaming client belongs. If a roaming client becomes temporarily part of a network such as a Wi‐Fi network at an airport, the client will get an IP address from the Wi‐Fi network's DHCP server. If that IP also belongs to the network behind the SEG accessible through a tunnel, then Windows will still continue to assume that the IP address is to be found on the client's local network. Windows therefore will not correctly route packets bound for the remote network through the tunnel but instead route them to the local network. The solution to this problem of local/remote IP address duplication is to create a new route in the client's Windows routing table that explicitly routes the IP address to the tunnel. For example, suppose 192.168.99.2 is the server to be reached, 192.168.0.0/24 is the remote network and 192.168.99.2 is assigned by L2TP or PPTP to the Windows computer. The Windows command line to add a route would be: C:\> route add 192.168.0.2 mask 255.255.255.255 192.168.99.2 • Verify that the correct tunnel is being selected. When an external client connects, the SEG makes a decision about which IPsec tunnel object to use by choosing the tunnel that has the parameters that most closely match the incoming connection. However, the tunnel object selected in the initial exchange between client and the SEG may have to change because a mismatch is discovered in a later phase. This can result, for example, in a situation where the proposal list matches one IPsec tunnel object but authentication matches another tunnel object. The administrator should be aware this can happen so that unexpected behavior can be understood. This topic is discussed with more depth in IPsec with the SEG on page 132. Troubleshooting certificate problems If certificates have been used in a VPN solution then the following should be looked at as a source of potential problems: • Check that the correct certificates have been used for the correct purposes. • Check that the certificate .cer and .key files have the same filename. For example, my_cert.key and my_cert.cer. • Check that the certificates have not expired. Certificates have a specific lifetime and when this expires they cannot be used and new certificates must be issued. •...
Page 145 IPsec VPN The SEG uses the certificate version that is in the cache if it is there. If there has been a change to a certificate either locally of remotely, the cache may need to be updated. The contents of the cache can be examined using only ‐cert option on its own. Some example output is given below: Device:/> ike ‐cert IKEv2 Certificates # Subject ‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ 1 C=SE, O=Clavister, OU=R&D, CN=TTG 2 C=SE, O=Clavister, OU=R&D, CN=TTG2 3 C=SE, O=Clavister, OU=R&D, CN=GGSN 4 DC=local, DC=devlab, CN=labsrv The abbreviations found in this output have the following meanings for each cached certificate: • C – ISO3166 two character country code. • ST – State or province. • L – Locality. Usually a city. • O – Organization. Usually a company name. • OU – The organization unit. Typically, the certificate type. • CN – The common name. Typically a product name. • DC – The domain component. The ‐verbose option with the ‐cert option can provide more detailed information about the cache contents: Device:/> ike ‐cert ‐verbose IKEv2 Certificates # Subject Issuer Valid From Valid To Status ‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐ 1 C=SE, DC=local, 2011‐05‐09 2012‐05‐09 Valid O=Clavister, DC=lab, 06:37:00 06:47:00 OU=R&D, CN=TTG CN=labsrv 2 C=SE, DC=local, 2011‐06‐28 2012‐06‐28 Valid O=Clavister, DC=lab, 08:34:49 08:44:49 OU=R&D, CN=TTG2 CN=labsrv 3 C=SE, DC=local, 2010‐07‐28 2011‐07‐28 Valid...
Page 146 IPsec VPN IPsec troubleshooting commands A number of commands can be used to diagnose IPsec tunnel issues: Using the flow CLI command SEG IPsec traffic consists of ESP flows. A flow is unidirectional and ESP traffic consists of a single, unidirectional flow. ESP flows can be examined using the flow CLI command. For example, all flows could be examined using the command: Device:/> flow ‐show Proto Source Destination Timeout ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ESP core:53.0.0.1 ext:53.0.1.2:0x757d8003 125 ICMP ipsec‐1:192.100.1.9:2048 gtp‐1:192.200.0.1:17683 7 ESP ext:53.0.1.2 core:53.0.0.1:0x608f21ad 129 UDP core:53.10.0.2:2152 int:53.10.0.1:2152 129 UDP core:53.10.0.2:2123 int:53.10.0.1:2123 113 ESP ext:53.0.1.2 core:53.0.0.1:0x42c5fd04 75 UDP core:172.22.53.101:514 mgm:172.22.53.1:514 125 Caution: It is important to be aware that instead of decimal port numbers in the flow command output for ESP, the values displayed are SPI numbers and these are specified using hexadecimal. The reverse flows for the above can be displayed using the ‐verbose option: Device:/> flow ‐show ‐verbose Proto Source Destination Timeout ‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐ ESP core(0):53.0.0.1 ext:53.0.1.2:0x757d8003 126 ...rev: core(0):53.0.0.1 ext:53.0.1.2:0x757d8003 126 ICMP ipsec‐1(33):192.100.1.9:2048 gtp‐1:192.200.0.1:17683 7 ...rev: ipsec‐1(33):192.100.1.9:17683 gtp‐1:192.200.0.1:0 7 ESP ext(0):53.0.1.2 core:53.0.0.1:0x608f21ad 129 ...rev: ext(0):53.0.1.2 core:53.0.0.1:0x608f21ad 129 UDP core(0):53.10.0.2:2152 int:53.10.0.1:2152 129 ...rev: core(0):53.10.0.2:2152 int:53.10.0.1:2152 129 UDP core(0):53.10.0.2:2123 int:53.10.0.1:2123 110 ...rev: core(0):53.10.0.2:2123 int:53.10.0.1:2123 110 ESP ext(0):53.0.1.2 core:53.0.0.1:0x42c5fd04 72 ...rev: ext(0):53.0.1.2 core:53.0.0.1:0x42c5fd04 72...
Page 147 IPsec VPN The displayed list can be filtered using any of a number of filtering parameters. For example, all flows that have a destination of the IPsec tunnel called my_tunnel could be examined with the command: Device:/> flow ‐show ‐destiface=my_tunnel All options for the flow command can be found in the SEG‐100 Command Line Interface Reference. The ike -stat CLI command The following command can provide a snapshot of the current state of negotiated tunnels: Device:/> ike ‐stat This can be used to show that IPsec tunnels have correctly established. A typical example of output from this command is shown below: Device:/> ike ‐stat IKEv2 Statistics Statistic Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐ IKE SAs active 2 IKE SA negotiations active 0 IKE SA negotiations done 3 IKE SA negotiations failed 1 IKE SA rekeys active 0 IKE SA rekeys done 0 IKE SA rekeys failed 0 IPsec SAs active 2 IPsec SA negotiations active 0 IPsec SA negotiations done 2 IPsec SA negotiations failed 0 IPsec SA rekeys active 0 IPsec SA rekeys done 0 IPsec SA rekeys failed 0 The ike ‐stat command provide a static view of IPsec tunnels. To see what is happening during the IKE negotiation of tunnel setup, the ‐snoop option should be used and this is discussed next. ...
Page 148 IPsec VPN Using ike -snoop VPN tunnel negotiation When setting up IPsec tunnels, problems can arise because the initial negotiation fails when the network devices at either end of a VPN tunnel try but fail to agree on which protocols and encryption methods will be used. The CLI command ike ‐snoop is a tool that can be used to identify such problems by showing the details of the exchanges that occur when the peers at either end of the IPsec tunnel try to agree on a mutually acceptable set of algorithms. The algorithm lists they exchange are often referred to as proposal lists. Using ike -snoop The ike ‐snoop command is entered via a CLI console. To begin monitoring with basic, summarized output, the full CLI command is: Device:/> ike ‐snoop ‐brief This causes diagnostic output to be continuously sent to the console for all VPN tunnel IKE negotiations that takes place, regardless of interface. To turn off monitoring, the command is: Device:/> ike ‐snoop ‐off Presented below is some typical ike ‐snoop output (the formatting has been changed slightly to fit the page). The tunnel negotiation considered is based on pre‐shared Keys. A negotiation based on certificates is not discussed here but the principles are the same. SNOOP: IKEv2: 2010‐05‐31 12:30:09 172.22.53.18:500 <‐172.22.53.23:500  IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] SNOOP: IKEv2: 2010‐05‐31 12:30:09 172.22.53.18:500 ‐> 172.22.53.23:500  IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ] SNOOP: IKEv2: 2010‐05‐31 12:30:09 172.22.53.18:500 <‐172.22.53.23:500  IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N)  N(NON_FIRST_FRAG) ] SNOOP: IKEv2: 2010‐05‐31 12:30:09 172.22.53.18:500 ‐> 172.22.53.23:500  IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) ] In these listings the direction of packet movement is indicated by the <‐and ‐> symbols. The IPv4 address and port number given on the left side of these symbols is local. The address and port number given on the right side is remote. Each packet movement is preceded by a timestamp. ...
Page 149 IPsec VPN Consider the first part: 172.22.53.18:500 <‐172.22.53.23:500 Indicates that an initial request to set up a security association was made and originates from remote IPv4 address 172.22.53.23, port 500, which will be the remote tunnel endpoint. This was received at local IPv4 address 172.22.53.18, port 500 on the local security gateway and this will be the local tunnel endpoint. The nature of this request is described next: IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ] It is a security association (SA) initialization and the various abbreviations describe the details: • KE ‐Key Exchange • No ‐NONCE • N ‐Notify The notification payloads in this case are NATD_S_IP and NATD_D_IP. The second part of the output shows the local security gateway sending the IKE response back to IPv4 address 172.22.53.23: 172.22.53.18:500 ‐> 172.22.53.23:500 The third part of the output (IKE_AUTH request 1) is a request from the remote tunnel endpoint172.22.53.23 to try and agree algorithms: IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N (NON_FIRST_FRAG) The actual algorithms in the proposal lists sent by each tunnel peer are not shown in this summary version of the ike command. However, the sequence of steps leading to success or failure are shown. Complete ike command options and abbreviation descriptions can be found in the SEG‐100 Command Line Interface Reference. Management interface failure with VPN If a VPN tunnel is set up and then the SEG management interface stops operating, it is likely a problem with the management traffic being routed back through the VPN tunnel instead of the correct interface. This happens when a route is established in the main routing table which routes any traffic for all‐nets through the VPN tunnel. If the management interface is not reached by the VPN tunnel then the administrator needs to create a specific route that routes management interface traffic leaving the SEG back to the management sub‐network. ...
Page 150 IPsec VPN Specific error messages This section will deal with specific error messages that can appear with VPN and what they indicate. The messages discussed are: • Could not find acceptable proposal / no proposal chosen. • Incorrect pre‐shared key. • Ike_invalid_payload, Ike_invalid_cookie. • Payload_Malformed. • No public key found. Could not find acceptable proposal / no proposal chosen This is the most common IPsec related error message. It means that depending on which side initiates tunnel setup, the negotiations in either the IKE or the IPSec phase of setup failed since they were unable to find a matching proposal that both sides could agree on. Troubleshooting this error message can be involved since the reasons for this message can be multiple depending on where in the negotiation it occurred. • If the negotiation fails during phase‐1 – IKE The IKE proposal list does not match. Double check that the IKE proposal list matches that of the remote side. A good idea is to use the ike ‐snoop ‐full command in the console and get the tunnel to initiate the tunnel from the remote side. You will be able to then see what proposals the remote side is sending and then compare the results with your own IKE proposal list. At least one proposal has to match in order for it to pass phase‐1. Don't forget that the lifetimes are also important. • If the negotiation fails during phase‐2 – IPsec The IPsec proposal list does not match. Double check that the IPsec proposal list matches ...
Page 151 IPsec VPN Incorrect pre-shared key A problem with the pre‐shared key on either side has caused the tunnel negotiation to fail. This is perhaps the easiest of all the error messages to troubleshoot since it can be only one thing, and that is incorrect pre‐shared key. Double‐check that the pre‐shared key is of the same type (Passphrase or Hex‐key) and correctly added on both sides of the tunnel. Another reason for why the SEG detects that the pre‐shared key is incorrect could be because the wrong tunnel is triggering during tunnel negotiations. IPsec tunnels are processed from the top to the bottom of the SEG tunnel list and are initially matched against the remote gateway. An example is if there is a roaming tunnel that uses all‐nets as its remote gateway. This tunnel will trigger before your defined tunnel if it is above it in the tunnel list. Ike_invalid_payload, Ike_invalid_cookie In this case the IPsec engine in the SEG receives an IPsec IKE packet but is unable to match it against an existing IKE. If a VPN tunnel is only established on one side, this can be the resulting error message when traffic arrives from a tunnel that does not exist. An example would be if, for some reason, the tunnel has only gone down from the initiator side but the terminator still sees it as up. It then tries to send packets through the tunnel but when they arrive at the initiator it will drop them since no matching tunnel can be found. Simply remove the tunnel from the side that believes it is still up to solve the immediate problem. An investigation as to why the tunnel only went down from one side is recommended. It could be that DPD and/or Keep‐Alive is only used on one side. Another possible cause could be that even though it has received a DELETE packet, it has not deleted/removed the tunnel. Payload_Malformed This problem is very similar to the Incorrect pre‐shared key problem described above. A possible reason is that the PSK is of the wrong TYPE on either side (Passphrase or Hex key). Verify that you are using the same type on both sides of the IPsec tunnel. If one side is using Hex and the other Passphrase, this is most likely the error message that you will receive. No public key found This is a very common error message when dealing with tunnels that use certificates for authentication. Troubleshooting this error message can be very difficult. It is very important to keep in mind that when dealing with certificates it may be required to combine the output from ike ‐snoop ...
Page 152 IPsec VPN The possible causes are as follows: • The certificate on either side is not signed by the same CA server. • The certificate's validity time has expired or it has not yet started to be valid. The latter can happen if the clock is set incorrectly on either the CA server or the SEG or they are in different time zones. • The SEG is unable to reach the Certificate Revocation List (CRL) on the CA server in order to verify if the certificate is valid or not. Double‐check that the CRL path is valid in the certificate’s properties. (Using the CRL feature could be turned off.) Make sure also that there is a DNS client configured in the SEG in order for it to be able to correctly resolve the path to the CRL. Specific symptoms The tunnel can only be initiated from one side This is a common problem and is due to a mismatch of the size in local or remote network and/or the lifetime settings on the proposal list(s). To troubleshoot this, the settings for the local network, remote network, IKE proposal list and IPsec proposal list on both sides need to be examined to try to identify a miss‐match. For example, suppose there are the following IPsec settings at either end of a tunnel: • Side A Local Network = 192.168.10.0/24 Remote Network = 10.10.10.0/24 • Side B Local Network = 10.10.10.0/24 Remote Network = 192.168.10.0/16 In this scenario, the defined remote network on Side B is larger than that defined for Side A’s local network. This means that Side A can only initiate the tunnel successfully towards Site B ...
Page 153: Chapter 8: Authentication
Chapter Authentication Authentication profiles Authentication refers to the process of checking and verifying credentials of external users before allowing them access to requested resources through the SEG. The resources could be public Internet access from an internal network, access to an internal server from an external user via VPN, or perhaps administrator access to the SEG itself. The SEG objects that control authentication are Authentication Profiles. Each profile defines a set of parameters for performing authentication. In particular, a profile defines the Authentication Source, which could be an internal SEG database or an external database such as a RADIUS server. To be useful, authentication profiles must be associated with other objects. For example, an IPsec interface can have a profile associated with it so that roaming clients that connect through the IPsec tunnel trigger the authentication described by the profile. An authentication profile has the following properties: • Agent Type This is the type of authentication that will be used. The choices are: • BASIC: This is the default and indicates standard username/password authentication. For example, the profile associated with the RemoteMgmtSSH object to allow administration SSH access should have this type. • EAP: This option is used in I‐WLAN scenarios with IKEv2 IPsec tunnels. • Authentication Source This database used for authentication. The choices are: • Local user database(s) • RADIUS server When using multiple sources, there are further options. The choices are: • Continue on no response from the source and try the next source in the profile. • Continue on failed validation and try validation with the next source in the profile. By default, this option is deactivated. • Load balance using round‐robin. Each authentication source will be used sequentially by sequential triggers. By default, this option is deactivated.
Page 154: Radius Authentication
Authentication • Timeouts A number of timeout values can be set for the profile: • Idle timeout • Session timeout • Use timeouts sent by the authentication source • Brute Force Attack Prevention This option can be activated to control the following: • Login attempts – This is the maximum number of login attempts for a given username before a lockout occurs for that username. • Lockout time – After a lockout occurs, this is the time that must elapse before further login attempts are allowed for the locked out username. Example 1: Creating an authentication profile with a local user database This example creates an authentication profile called int_auth that will reference a local user database that has already been defined called int_users. Device:/> add AuthenticationProfile int_auth  AuthSource=Local  LocalUserDB=int_users Example 2: Creating an authentication profile with RADIUS servers This example creates an authentication profile called ext_auth that will reference two RADIUS ...
Page 155 Authentication RADIUS architecture The RADIUS protocol is based on a client/server architecture. The SEG acts as the client of the RADIUS server, creating and sending requests to a dedicated server(s). In RADIUS terminology the security gateway acts as the Network Access Server (NAS). For user authentication, the RADIUS server receives authentication requests and then verifies the user’s credentials by consulting its database. It then returns either an “accept” or “reject” reply to the requesting client. Configuring RADIUS servers RADIUS servers are configured as separate objects in the SEG. A RADIUS server object’s properties are: • Name A suitable logical name for the object. • IPAddress The IP address of the server. This could be an IP address object from the SEG address book. • Port The port used for the connection by the SEG. This default value is 1812. • RetryTimeout This is the length of time in milliseconds after which a RADIUS request will have assumed to fail and a retry is attempted. This value cannot be less that 500 with no upper limit. The default value is 2000. • NumRetries When a RADIUS request times out, the request is retried. This happens for NumRetries times. The retry minimum is 1 and the maximum is 10. The default is 3. • Shared Secret To provide request security, a common Shared Secret is configured on both the RADIUS client and the server. This secret enables encryption of the messages sent from the RADIUS client to the server and is commonly configured as a relatively long text string. The string can contain up to 100 characters and is case sensitive. RADIUS uses PPP to transfer username/password requests between client and RADIUS server, as well as using PPP authentication schemes such as PAP and CHAP. RADIUS ...
Page 156: The Radiussnoop Command
Authentication The RADIUS Vendor ID When configuring the RADIUS server itself to receive requests from the SEG, it is important to enter a value for the Vendor ID (vid). This value should be specified as 5089. Example: Configuring a RADIUS server In this example, a RADIUS server will be configured with an IPv4 address of 198.10.2.1 and the shared secret specified as mysecret. Device:/> add RadiusServer IPAddress=198.10.2.1 SharedSecret=mysecret Using RADIUS Authentication A RADIUS server is used for authentication with the following steps: 1. Create a RADIUS server object as described above. 2. Create an Authentication Profile object that uses the RADIUS server as its Authentication Source. 3. Associate the profile with an IP rule. When the IP rule triggers, authentication of user credentials will then be required to set up the traffic flow. The radiussnoop command To troubleshoot problems, the SEG provides the ability to examine the interactions that take place between the SEG and RADIUS servers. This is done using the CLI command radiussnoop. The command works in a similar way to the ike ‐snoop command. It is enabled from the CLI console and while it is enabled, any interactions with RADIUS servers is shown in console output messages. The amount of detail in this output can be adjusted. ...
Page 157: Chapter 9: High Availability
Chapter High Availability Overview HA clusters The SEG High Availability (HA) feature provides hardware redundancy for SEG installations. HA works by adding a backup slave security gateway to an existing master security gateway. The master and slave are connected together and make up a logical HA cluster. One of the units in a cluster will be active while the other unit is inactive and on standby. The master and slave are also referred to as cluster nodes or cluster peers. Initially, the cluster slave will be inactive and will only monitor the activity of the master. If the slave detects that the master has a malfunction, an HA failover takes place and the slave becomes active, assuming processing responsibility for all traffic. If the master later becomes operative again, the slave will continue to be active but the master will now monitor the slave with a failover only taking place if the slave malfunctions. This is sometimes known as an active‐passive implementation. Master and active units When reading this section on HA, it should be kept in mind that the master unit in a cluster is not always the same as the active unit in a cluster. The active unit is the security gateway that is actually processing all traffic at a given point in time. This could be the slave if a failover has occurred. Interconnection of cluster peers In a cluster, the master and slave must be directly connected to each other by one or more synchronization connections that are known as the sync interfaces. One or more of the interfaces on the master and the slave can be dedicated for this purpose and are directly connected together using a crossover cable. Although this connection could be made via a switch, it is not recommended. The primary purpose of a sync interface is to carry state synchronization traffic between the cluster peers. Sync interfaces must not be used for normal traffic. Special Ethernet frames, known as heartbeats, are continually sent by the SEG between the peers in the cluster across the sync interfaces and any other interfaces marked as critical. These frames allow the health of both units to be monitored. Heartbeats are sent in both directions so that the passive unit knows about the health of the active unit and the active unit knows about the health of the passive. ...
Page 158 High Availability Interfaces that are not set as critical in the configuration do not have heartbeats sent over them and will not cause an HA failover if they fail. Failure of a critical interface will cause a failover to occur once the cluster has identified the failed interface. The heartbeat mechanism is discussed in more depth later in Section 14.2, “HA Mechanisms”. Cluster management When managing the individual hardware units in a cluster, you must administer them separately using management interfaces. Configuration changes are not automatically duplicated between the cluster peers unless the advanced setting AutoSyncCfg is enabled. It is possible to use the following command to manually send the configuration to the other cluster peer: Device:/> ha ‐sendconf To manually have one peer retrieve the configuration from the other cluster peer, use the command: Device:/> ha ‐recvconf Load-sharing SEG HA clusters do not provide load‐sharing since only one unit will be active at a time, and only two security gateways, the master and the slave, can exist in a single cluster. The only processing role that the inactive unit plays is to replicate the state of the active unit and to take over all traffic processing after a failover if it determines the active unit has experienced a failure. Hardware duplication SEG HA will operate only between two security gateways. As the internal operation of different security gateway manufacturer's software is completely dissimilar, there is no common method available to communicating state information to a dissimilar device. It is also strongly recommended that the security gateways used in cluster have identical configurations. Where applicable, they must also have identical licenses that allow identical capabilities including the ability to run in an HA cluster. With the SEG‐100 module, which has two individual security gateways on one blade (DPB1 and DPB2), it is not recommended to have the module be a self‐contained cluster. Instead, the corresponding processor on a separate SEG‐100 should be the cluster peer. In other words, the DPB1 processor on one module should be the peer to the DPB1 processor on another, identical module. The two blades are typically in the same chassis and use the chassis backplane to communicate.
Page 159: Ha Mechanisms
High Availability Extending redundancy Implementing an HA cluster will eliminate one of the points of failure in a network. Routers, switches, and Internet connections can remain as potential points of failure, and redundancy for these should also be considered. HA mechanisms This section discusses in depth the mechanisms the SEG uses to implement the HA feature. Basic principles The SEG HA provides a redundant, state‐synchronized hardware configuration. The state of the active unit, which includes the flow table and other vital information, is continuously copied to the inactive unit via one or more sync interfaces. When cluster failover occurs, the inactive unit knows which connections are active, and traffic can continue to flow after the failover with negligible disruption. The inactive system detects that the active system is not operational when it no longer detects sufficient Cluster Heartbeats. Heartbeats are sent over all interfaces marked as Critical (the interface default) which always includes the sync interfaces. Heartbeats have the following characteristics: • Heartbeats are Ethernet frames and not IP packets. • Heartbeats cannot be forwarded by a router since they do not contain an IP header. • The Ethernet source and destination address is based on the cluster ID and the role of the sending and receiving unit. • The Ethernet frame type is set as 0xC14B. Heartbeat frequency The SEG sends 10 heartbeats per second (every tenth of a second) on each critical interface. Both peers send these to each other and both monitor any missed heartbeats in the following way: • If either cluster node misses 2 heartbeats (no heartbeats over 0.2 seconds) on any critical interface (which includes sync interfaces), that node enters a state known as Early Interface Failure Detection. This state means that the node will send out ARP queries on the suspect interface for previously resolved ARP entries in its ARP cache. This allows the node to determine if the failure is a failure associated with the local interface or if the ...
Page 160 High Availability Increasing heartbeat frequency Heartbeats are not sent at smaller intervals than a tenth of a second because such delays may occur during normal operation. An operation, for example, opening a file, could result in delays long enough to cause the inactive system to go active, even though the other is still active. Failover time The time for failover is typically within seconds, which means that clients may experience a failover as a slight burst of packet loss. In the case of TCP, the failover time is well within the range of normal retransmit timeouts so TCP will retransmit the lost packets within a very short space of time and continue communication. UDP does not allow retransmission since it is inherently an unreliable protocol. Shared IP addresses and ARP Both master and slave units in a cluster are aware of the shared IP addresses. However, ARP queries for the shared IP address, or any other IP address published via ARP configuration or through Proxy ARP, are answered by the active unit only. The hardware address of the shared IP address and other published addresses are not related to the actual MAC addresses of the Ethernet interfaces. Instead, a new MAC address is constructed by the SEG. The first part of the constructed address is always 10:00:00. The second part is based on the configuration and contains the cluster ID. As the shared IP address always has the same hardware address, there will be no latency time in updating ARP caches of units attached to the same LAN as the cluster when a failover occurs. When a cluster member discovers that its peer is not operational, it broadcasts gratuitous ARP queries on all interfaces using the shared MAC address as the sender. This allows switches to re‐learn within milliseconds where to send packets destined for the shared address. Therefore, the only failover delay is in detecting that the active unit is down. ARP queries are also broadcast periodically to ensure that switches do not forget where to send packets destined for the shared hardware address. ...
Page 161: Setting Up Ha
High Availability Setting up HA Preconditions for creating an HA cluster When setting up an SEG HA cluster, the following is required: 1. Two security gateways with identical hardware configurations running the same version of the SEG. For module‐based platforms, these should be two separate modules in the same or different shelf. One should be designated the master node, the other designated the slave node. 2. The interfaces of both cluster nodes are connected via a common switch as shown in the illustration below. The interface names on both security gateways must be identical. The sync interfaces do not need to be connected via a switch since shelf‐based platforms often provide backplane connection. Figure 11. HA cluster setup...
Page 162 High Availability Setup steps The steps necessary for cluster setup can be summarized as: 1. Ensure the EthernetDevice settings are correct. 2. Set the interface shared and private IP addresses of all interface pairs for both master and slave. 3. Set the interface type of all interface pairs for both master and slave. 4. Activate HA on both master and slave. How to perform these steps is explained next. Checking EthernetDevice settings The EthernetDevice:0 and EthernetDevice:1 properties for each interface on both master and slave should be the same and set to the Ethernet device name of the interface. The current values of these settings can be checked with the command: Device:/> show Interface EthernetInterface sfp1 Property Value ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐ Name: sfp1 EthernetAddress: <empty> PrivateIP: 0:<empty> 1:<empty> HAType: Critical EthernetDevice: 0:sfp1 1:<empty> MTU: 1500 IPAddress: sfp1_ip IP4Broadcast: <empty> RTBMembership: main Comments: <empty> In the example above, EthernetDevice:1 is incorrectly set to <empty>. To fix this, use the command: Device:/> set Interface EthernetInterface sfp1 EthernetDevice:1=sfp1 The device name can be the same as the interface name, as is the case here, but this is not always true. Note that the EthernetAddress value is <Empty> because the actual MAC address is being used.
Page 163 High Availability Setting interface IP addresses Each interface on both the master and slave units has two IP addresses associated with it: 1. The shared IP address The shared IP address is the address that is used during general operation of the HA cluster and is the address used in constructing configuration security policies. It is always the same for each of the interfaces in a matching pair on master and slave. If the interface sfp1 is to have the shared IPv4 address 10.6.12.1, the CLI command to set this is: Device:/> set Interface EthernetInterface sfp1 IPaddress=10.6.12.1 This command is repeated for both the master and slave. 2. The private IP address A private IPv4 address is also assigned to each interface but it is not the same for a pair of interfaces. Each interface gets a unique address so that it is possible to connect to a specific interface on a specific node in the cluster. Connection to this address could be for the purpose of SEG management or to ping the interface. For allocating the private IP, each interface has two properties associated with it: PrivateIP:0 and PrivateIP:1. PrivateIP:0 is the private IPv4 address of the master interface in an interface pair and PrivateIP:1 is the private address of the corresponding slave interface in a pair. For example, if 10.6.12.10 is the private IPv4 address of the interface sfp1 on the master and 10.6.12.11 is the private IP of interface sfp1 on the slave, the following command should be issued: Device:/> set Interface EthernetInterface sfp1  PrivateIP:0=10.6.12.10 PrivateIP:1=10.6.12.11 This command is repeated for both the master and slave and can be combined with the command for setting the shared IPv4 address. As seen in this example, it is usual to use private and shared IPv4 addresses from the same network. It may seem redundant that the private IP of both master and slave are set on both cluster nodes. However, like other elements of a configuration, these private IPv4 addresses are mirrored between master and slave. If a management interface is connected to the master and the private address PrivateIP:1 for the slave is changed only on the master, it allows the address to be automatically copied over to the slave's configuration. All interfaces in a cluster will require a shared IP but it is not necessary that every interface has a private IP. The private IP is used for SSH management access as a source IP for log messages and to allow pinging of the interface on one node in the cluster.
Page 164 High Availability Setting the interface type The HAType for each interface should be set to either Critical, NonCritical or Sync, and this setting must agree between master/slave interface pairs. At least one interface must be set as Sync. The default is Critical. Setting the interface type can be done with the same CLI command that sets the interface IP addresses. For example: Device:/> Set Interface EthernetInterface update HAType=Sync This command should be repeated for both the master and slave. Activating HA on the Master node To activate HA on the master, the following SEG properties must be set: • Role: Master. • ClusterID: A unique ID between 1 and 63. • AutoSyncCfg: Yes/No depending on if resynchronization should be automatic after reconfiguration. • Enabled: Yes This is done using the CLI command: Device:/> set HighAvailability Role=Master ClusterID=1  AutoSyncCfg=Yes Enabled=Yes The changed master configuration should finally be activated and committed. Activating HA on the Slave node To activate HA on the slave, the following SEG properties must be set: •...
Page 165 High Availability Verifying synchronization Once the slave configuration is activated, synchronization between the cluster nodes will take place. The CLI command ha will indicate that both systems are running in HA mode and that the nodes are alive. If a security gateway is not part of a HA cluster, the output when CLI command ha is applied to it will be: Device:/> ha This device is a standalone system (HA not configured) If it is the master node in an HA cluster, the output will be similar to the following: Device:/> ha This device is a HA MASTER This device is currently Active (for 48s) HA cluster peer is ALIVE HA object sync: 100% The time shown in parentheses is the length of time that the cluster node has been in its current active or inactive state. When the state changes, this time counter is reset to zero. The HA object sync percentage indicates whether the system objects are fully synchronized between the peers. Similarly, when the same CLI command is applied to the slave, the output could be something similar to: Device:/> ha This device is a HA SLAVE This device is currently Inactive (for 47s) HA cluster peer is ALIVE HA object sync: 100% When setting up HA between two SEG processor modules located in the same ATCA shelf, the recommendation is to use the Update Channel in the shelf backplane for the HA Sync connection. To do this, the master and slave modules should be arranged in pairs so that the master module of the first HA cluster and the slave for that cluster are inserted into slots linked by an update channel connection. These slot pairings are usually indicated by lines printed on the ATCA shelf exterior. Using the Update Channel in this way frees up the interface connections on the front of modules for other purposes.
Page 166: Ha Issues
High Availability HA issues The following points should be kept in mind when managing and configuring an HA cluster. All cluster interfaces need IP addresses All interfaces on both HA cluster units should have a valid private IP address object assigned to them. The predefined IP object local host could be assigned for this purpose. The requirement to assign an address is true even if an interface has been disabled. SNMP SNMP statistics are not shared between master and slave. SNMP managers have no failover capabilities. Therefore both security gateways in a cluster need to be polled separately. Logging Log data will be coming from both master and slave. This means that the log receiver will have to be configured to receive logs from both. It also means that all log queries will likely have to include both master and slave as sources which will give all the log data in one result view. Normally, the inactive unit will not be sending log entries about live traffic so the output should look similar to that from a single security gateway. Using private individual IP addresses The unique individual IP addresses of the master and slave cannot safely be used for anything but management. Using them for anything else, such as for source IPs in dynamically address translated connections or publishing services on them, will inevitably cause problems since unique IPs will disappear when the security gateway they belong to does. Changing the cluster ID Changing the cluster ID in a live environment is not recommended for two reasons. First, this will change the hardware address of the shared IPs and will cause problems for all units attached to the local LAN, as they will keep the old hardware address in their ARP caches until it times out. Such units would have to have their ARP caches flushed. Second, this breaks the connection between the security gateways in the cluster for as long as ...
Page 167 High Availability HA limitations with statistics SEG statistics are not mirrored in both the master and slave units of an HA cluster since they relate only to the individual cluster units. This means that some statistics will not reflect the values of the failed system after the failover.
Page 168: Chapter 10: Advanced Settings
Chapter Advanced Settings Flow timeout settings The settings in this section specify how long a different types of flow can remain idle before being automatically closed. A flow is idle if no data being sent through it. Please note that each flow has two timeout values: one for each direction. A connection is closed if either of the two values reaches zero. Idle TCP SYN Flow Lifetime Specifies in seconds how long a TCP flow that is not yet fully established is allowed to idle before being closed. Device:/> set Settings FlowTimeoutSettings FlowLifetimeTCPSync=60 Default: 60 Idle Established TCP Flow Lifetime Specifies in seconds how long a fully established TCP flow may idle before being closed. Flows become fully established once packets with their SYN flags off have travelled in both directions. Device:/> set Settings FlowTimeoutSettings FlowLifetimeEstablished=262144 Default: 262,144 Idle Closing TCP Flow Lifetime Specifies in seconds how long a closing TCP flow may remain idle before finally being closed. Flows reach this state when a packet with its FIN flag on has passed in any direction. Device:/> set Settings FlowTimeoutSettings FlowLifetimeTCPClosing=80 Default: 80 Idle UDP Flow Lifetime Specifies in seconds how long UDP flows may idle before being closed. This timeout value is ...
Page 169: Length Limit Settings
Advanced Settings Other Idle Lifetime Specifies in seconds how long flows using an unknown protocol can remain idle before they are closed. Device:/> set Settings FlowTimeoutSettings FlowLifetimeOther=130 Default: 130 Length limit settings This section contains information about the size limits imposed on the protocols directly under IP level, such as TCP, UDP, and ICMP. The values specified here apply to the IP data contained in packets. In the case of Ethernet, a single packet can contain up to 1,480 bytes of IP data without fragmentation. In addition to that, there are 20 bytes of IP header and 14 bytes of Ethernet header, which totals the maximum media transmission unit on Ethernet networks of 1,514 bytes. Max TCP Length Specifies the maximum size of a TCP packet including the header. This value usually correlates with the amount of IP data that can be accommodated in an unfragmented packet, since TCP usually adapts the segments it sends to fit the maximum packet size. However, this value may need to be increased by 20–50 bytes on some less common VPN systems. Device:/> set Settings LengthLimSettings MaxTCPLen=1480 Default: 1,480 Max UDP Length Specifies in bytes the maximum size of a UDP packet including the header. This value may well need to be quite high, since many real‐time applications use large, fragmented UDP packets. If no such protocols are used, the size limit imposed on UDP packets can probably be lowered to 1,480 bytes. Device:/> set Settings LengthLimSettings MAxUDPLen=60000 Default: 60,000 Max ICMP Length Specifies in bytes the maximum size of an ICMP packet. ICMP error messages should never exceed 600 bytes, although Ping packets can be larger if so requested. This value may be ...
Page 170 Advanced Settings Max GRE Length Specifies in bytes the maximum size of a GRE packet. GRE, Generic Routing Encapsulation, has various uses, including the transportation of PPTP, Point to Point Tunneling Protocol, data. This value should be set at the size of the largest packet allowed to pass through the VPN connections, regardless of its original protocol, plus approximately 50 bytes. Device:/> set Settings LengthLimSettings MaxGRELen=2000 Default: 2,000 Max ESP Length Specifies in bytes the maximum size of an ESP packet. ESP, Encapsulation Security Payload, is used by IPsec where encryption is applied. This value should be set at the size of the largest packet allowed to pass through the VPN connections, regardless of its original protocol, plus approximately 50 bytes. Device:/> set Settings LengthLimSettings MaxESPLen=2000 Default: 2,000 Max AH Length Specifies in bytes the maximum size of an AH packet. AH, Authentication Header, is used by IPsec where only authentication is applied. This value should be set at the size of the largest packet allowed to pass through the VPN connections, regardless of its original protocol, plus approximately 50 bytes. Device:/> set Settings LengthLimSettings MaxAHLen=2000 Default: 2,000 Max SKIP Length Specifies in bytes the maximum size of a SKIP packet. Device:/> set Settings LengthLimSettings MaxSKIPLen=2000 Default: 2,000 MaxOSPF Len Specifies the maximum size of an OSPF packet. OSPF is a routing protocol mainly used in larger LANs. Device:/> set Settings LengthLimSettings MaxOSPFLen=1480 Default: 1,480 ...
Page 171: Fragmentation Settings
Advanced Settings Max IPIP/FWZ Length Specifies in bytes the maximum size of an IP‐in‐IP packet. IP‐in‐IP is used by Checkpoint Firewall‐1 VPN connections when IPsec is not used. This value should be set at the size of the largest packet allowed to pass through the VPN connections, regardless of its original protocol, plus approximately 50 bytes. Device:/> set Settings LengthLimSettings MaxIPIPLen=2000 Default: 2,000 Max IPsec IPComp Length Specifies in bytes the maximum size of an IPComp packet. Device:/> set Settings LengthLimSettings MaxIPCompLen=2000 Default: 2,000 Max L2TP Length Specifies in bytes the maximum size of a Layer 2 Tunneling Protocol packet. Device:/> set Settings LengthLimSettings MaxL2TPLen=2000 Default: 2,000 Max Other Length Specifies in bytes the maximum size of packets belonging to protocols that are not specified above. Device:/> set Settings LengthLimSettings MaxOtherSubIPLen Default: 1,480 Log Oversized Packets Specifies if the SEG will log occurrences of oversized packets. Device:/> set Settings LengthLimSettings LogOversizedPackets=Yes Default: Yes Fragmentation settings IP is able to transport up to 65,536 bytes of data. However, most media, such as Ethernet, cannot carry such huge packets. To compensate, the IP stack fragments the data to be sent ...
Page 172 Advanced Settings Pseudo Reass Max Concurrent Maximum number of concurrent fragment reassemblies. To drop all fragmented packets, set PseudoReass_MaxConcurrent to 0. Device:/> set Settings FragSettings PseudoReass_MaxConcurrent=1024 Default: 1024 Illegal Fragments Determines how the SEG will handle incorrectly constructed fragments. Examples of incorrectly constructed fragments are overlapping fragments, duplicate fragments with different data, and incorrect fragment sizes. Device:/> set Settings FragSettings IllegalFrags=Drop Default: DropLog Possible settings include: • Drop – Discards the illegal fragment without logging it. Also remembers that the packet that is being reassembled is “suspect,” which can be used for logging at a later time. • DropLog – Discards and logs the illegal fragment. Also remembers that the packet that is being reassembled is “suspect”, which can be used for logging at a later time. • DropPacket – Discards the illegal fragment and all previously stored fragments. Will not allow further fragments of this packet to pass through during ReassIllegalLinger seconds. • DropLogPacket – As DropPacket, but also logs the event. • DropLogAll – As DropLogPacket, but also logs additional fragments belonging to this packet that arrive during ReassIllegalLinger seconds. The choice of whether to discard individual fragments or disallow the entire packet is governed by two factors: • It is safer to discard the whole packet. • If, as the result of receiving an illegal fragment, you choose to discard the whole packet, attackers will be able to disrupt communication by sending illegal fragments during a reassembly, and in this way block almost all communication. Duplicated Fragment Data Compares the data components of a fragment if the same fragment arrives mores than once.
Page 173 Advanced Settings Failed Fragment Reassembly Specifies logging for failed reassembly attempts. Device:/> set Settings FragSettings FragReassemblyFail=LogSuspectSubseq Default: LogSuspectSubseq Reassemblies may fail due to one of the following causes: • Some of the fragments did not arrive within the time stipulated by the ReassTimeout or ReassTimeLimit settings. This may mean that one or more fragments were lost on their way across the Internet, which is a common occurrence. • The SEG was forced to interrupt the reassembly procedure due to new fragmented packets arriving and the system temporarily running out of resources. In situations such as these, old reassembly attempts are either discarded or marked as “failed.” • An attacker has attempted to send an incorrectly fragmented packet. Under normal circumstances, you would not want to log failures as they occur frequently. However, it may be useful to log failures involving “suspect” fragments. Such failures may arise if, for example, the IllegalFrags setting has been set to Drop rather than DropPacket. The following settings are available for FragReassemblyFail: • NoLog – No logging is done when a reassembly attempt fails. • LogSuspect – Logs failed reassembly attempts only if “suspect” fragments have been involved. • LogSuspectSubseq – As LogSuspect, but also logs subsequent fragments of the packet as and when they arrive • LogAll – Logs all failed reassembly attempts. • LogAllSubseq – As LogAll, but also logs subsequent fragments of the packet as and when they arrive. Dropped Fragments Specifies how the SEG will act if a packet is denied entry to the system as the result of the settings in the Rules section. Device:/> set Settings FragSettings DroppedFrags=LogSuspect ...
Page 174 Advanced Settings Duplicate Fragments Determines whether a fragment that arrives more than once should be logged. Device:/> set Settings FragSettings DuplicateFrags=LogSuspect Default: LogSuspect If a duplicate fragment arrives, this can mean either that it has been duplicated at some point on its journey to the recipient or that an attacker is trying to disrupt the reassembly of the packet. Note that DuplicateFragData can also cause such fragments to be logged if the data contained in them does not match up. Possible settings are as follows: • NoLog – No logging is carried out under normal circumstances. • LogSuspect – Logs duplicated fragments if the reassembly procedure has been affected by “suspect” fragments. • LogAll – Always logs duplicated fragments. Fragmented ICMP Determines the action taken when the SEG receives fragmented ICMP messages that are not either ICMP ECHO or ECHOREPLY. Device:/> set Settings FragSettings FragmentedICMP=DropLog Default: DropLog Other than ICMP ECHO (Ping), ICMP messages should not normally be fragmented as they contain so little data that fragmentation should never be necessary. Minimum Fragment Length Determines how small all fragments, with the exception of the final fragment, of a packet can be expressed in bytes. Device:/> set Settings FragSettings MinimumFragLength=8 Default: 8 Although the arrival of too many fragments that are too small may cause problems for IP stacks, it is usually not possible to set this limit too high. It is rare that senders create very small fragments. However, a sender may send 1480 byte fragments and a router or VPN tunnel on the route to the recipient subsequently reduces the effective MTU to 1440 bytes. This would result in the creation of a number of 1440 byte fragments and an equal number of 40 byte fragments. Because of the potential problems this can cause, the default settings in the SEG has been ...
Page 175 Advanced Settings Reassembly Timeout The number of seconds after the previous fragment in which no further fragments arrive before a reassembly attempt will be interrupted. Device:/> set Settings FragSettings ReassTimeout=65 Default: 65 Max Reassembly Time Limit The number of seconds after the first received fragment arrived before a reassembly attempt will always be interrupted. Device:/> set Settings FragSettings ReassTimeLimit=90 Default: 90 Reassembly Done Linger Limit The number of seconds after a packet has been reassembled that the SEG is able to remember reassembly. This prevents additional fragments of that packet from arriving, for example, old duplicate fragments. Device:/> set Settings FragSettings ReassDoneLinger=20 Default: 20 Reassembly Illegal Linger Limit The number of seconds the SEG is able to remember that a whole packet has been marked as illegal. This prevents additional fragments of that packet from arriving. Device:/> set Settings FragSettings ReassIllegalLinger=60 Default: 60 Reject Minimal Fragment Sends an ICMP parameter problem message when the non‐last fragment is smaller than the minimum allowed length, which is specified by IPv6MinNonFinalFragment. Device:/> set Settings FragSettings RejectMinimalFrag=No Default: No IPv6 Minimum Non-final Fragment The minimum allowed length of non‐last IPv6 fragments. ...
Page 176: Local Fragment Reassembly Settings
Advanced Settings IPv6 Nop Fragments Whether to ignore fragments when the packet is the first and last fragment at the same time (and by definition not a fragment, though it has a fragment header). Note that these packets are legal, and serves a purpose as an non‐IPv6 to IPv6 connection mechanism (see RFC 2460 for more details). Device:/> set Settings FragSettings IPv6NopFrags=Ignore Default: Ignore Local fragment reassembly settings Max Concurrent Maximum number of concurrent local reassemblies. Device:/> set Settings LocalReassSettings LocalReass_MaxConcurrent=256 Default: 256 Max Size Maximum size of a locally reassembled packet. Device:/> set Settings LocalReassSettings LocalReass_MaxSize=10000 Default: 10,000 Large Buffers Number of large (over 2,000) local reassembly buffers. Device:/> set Settings LocalReassSettings LocalReass_NumLarge=32 Default: 32 ...
Page 177: Chapter 11: I-Wlan
Chapter I-WLAN I-WLAN overview An Interworking Wireless Access Network (I‐WLAN) is a wireless data access solution that allows data traffic to flow between WLANs and 3GPP systems. Clients accessing such a WLAN might, for example, be mobile computing devices requiring public Internet access. A SEG can facilitate this by providing interworking between the clients and a GPRS backbone. All of the backbone’s existing facilities can then be utilized including charging for data traffic flows using standard mobile billing methods. The overall solution, illustrated below, is known as I‐WLAN. Figure 12. A typical I-WLAN configuration The security gateway acts as a Tunnel Terminating Gateway (TTG) in this I‐WLAN solution, with the SEG providing interworking through its support for VPN tunneling on the client side and the GPRS Tunneling Protocol (GTP) on the GPRS backbone side. GTP is used by the SEG to communicate with a GPRS Service Support Node (GGSN) within the GPRS backbone network. GTP handles both signalling and data transfer in the network and is implemented as a layer on top of the UDP protocol. SEG GTP support means that the security gateway behaves like a Serving GPRS Support Node (SGSN), allowing traffic flows between the GPRS Backbone and the clients connected to the Access Network (usually the public Internet). As explained in more depth later, the SEG uses a feature called Stitched Interfaces to facilitate these flows. I‐WLAN clients connect to the security gateway via a VPN tunnel using IKEv2 security negotiation and IPsec encryption. Authentication of the client is by EAP‐SIM or EAP‐AKA via the security gateway to an AAA server. Authentication of the security gateway is by certificates sent to the client. ...
Page 178: Gtp Tunnels
I-WLAN Authentication of the security gateway with certificates is done without referencing a CRL on a CA server. The gateway sends the appropriate Host Certificate to the client which then validates it against its own, preinstalled CA signed root certificate. This may require the use of Intermediate Certificates that are also sent to the client by the security gateway. The sequence of steps in this process is described later. I-WLAN components The SEG components for I‐WLAN are: • An IPsec Tunnel for remote, roaming client access to the security gateway. This is tightly coupled to a GTP tunnel using SEG Interface Stitching. • A GTP Tunnel for access to the GPRS backbone network from the security gateway. This is tightly coupled to an IPsec tunnel using SEG Interface Stitching. • The SEG should have a license installed that has GTP enabled. The current license capabilities can be examined with the CLI command. If GTP is not enabled, the license GTP tunnels, the interface stitching, and the stitched IPsec tunnels will not function. • At least one DNS server IP address must be configured in the SEG for DNS lookup. This may be located in the GPRS backbone network. GTP tunnels The principal properties for defining a GTP tunnel are listed below. Not all the available properties are included. The ones that are omitted are usually rarely changed from their defaults but can be if required. General settings • LocalEndpoint The logical IP address of the GTP interface. This is the address that will be used as the source address for GTP‐C and GTP‐U. The IP Address must be unique amongst GTP interfaces if there is more than one. • EndUserDNS If a DNS is configured for the GTP interface, this IP address will be passed back to the client. If no DNS is configured for the GTP interface, the configured DNS client for the security gateway will be used instead. ...
Page 179 I-WLAN • ResponseTimeout This parameter is a timer that specifies how soon a response is expected to be received from a GTP peer before retransmission will take place over a path for a given GTP request. If a response is not received within the specified time for a given request, the T3 response timer will expire and a retransmission of the request message will take place. The default value is 10. • TunnelLimit This parameter specifies the maximum number of allowed GTP Tunnels for the interface. The default value is 100,000. • FailedTimeout This parameter specifies how long, in seconds, a non‐responsive connection to a GGSN is kept in memory. While the connection is in memory it cannot be allocated to other clients. After the specified timeout expires, the connection becomes available again for allocation to clients. This parameter should only be used if there are multiple GGSNs sharing the same APN. The minimum value is 0. The maximum value is 65535 seconds. The default value is 0 (disabled). • PathCheck This parameter is a timer frequency that specifies when GTP interface paths should be checked to verify the functioning of GTP peers. The default value is 60. • UsePreferredIP Negotiate the end user address using the IP address proposed by the client. The default value is No. • ResolveAPN This parameter specifies how often an APN is resolved in seconds. If this parameter is set, the GTP interface will resend DNS queries for the APNs used by the connected clients at the specified interval. A value of 0 (the default) specifies that resending is not done and the setting is ignored. The minimum value is 0. The maximum value is 65535 seconds. The default value is 0 (disabled). This settings should not be too low because the DNS servers will be bombarded with queries. It should also not be too high otherwise clients will not receive updated IP addresses from APN resolution in time. Normally, this feature is turned off (a setting of 0). It should be enabled if the IP addresses ...
Page 180 I-WLAN • SeqNumberCheck This option enables the sequence number check method to determine if received PDUs are valid. The default value is No. • GGSNDynIP This specifies whether an IP address will be passed to a GGSN when establishing GTP Tunnels requesting an IP to be used for the client, or if an IP address will be dynamically assigned to the client by the GGSN. The default value is No. • ShortAPNDNS If enabled, this option specifies that only the first label of the APN in the tunnel establishment is to be used for DNS resolution of the GGSN’s IP addresses. The default value is No. • ShortAPNGGSN If enabled, send only the first label in the APN to the GGSN. The default value is No. • InterceptDHCPInform When this option is enabled, the GTP interface will intercept DHCPINFORM messages from the client and respond with the P‐CSCF address received during the PDP context activation process. • SelectionMode This option indicates the origin of the APN. The possible settings are: • 0 – MS or network provided APN, subscription verified. • 1 – MS provided APN, subscription not verified (the default). • 2 – Network provided APN, subscription not verified. Quality of Service (QoS) settings • TrafficClass This option specifies the requested Traffic Class to send to a GGSN when establishing GTP Tunnels. ...
Page 181: Interface Stitching
I-WLAN Charging This is a set of 16 vendor‐specific flags that specify vendor‐specific triggers to send to a GGSN when establishing GTP Tunnels. In practice, many of the above settings don’t need to be changed for many I‐WLAN deployments since the default values are appropriate. Interface selection for GTP tunnels The Ethernet interface where a GTP tunnel starts is not specified in the GTP tunnel definition. The interface is determined by the SEG as follows: • The LocalID of the IPsec tunnel is resolved to the IP address of the GGSN using the configured DNS server. • The GGSN IP address is then looked up in the routing table to determine which Ethernet interface will be used. • The defined interface stitching between the IPsec tunnel and the GTP tunnel causes the SEG to set up a new GTP tunnel on that Ethernet interface. If the IPsec tunnel LocalID is not specified in the tunnel definition, the IDr sent by the client is instead resolved on its own by the DNS server to obtain the GGSN IP address. If both are available, the logical intersection of the two is used. Interface stitching The SEG feature of Interface Stitching is important to implementing I‐WLAN. It involves tightly coupling together a pair of SEG interfaces so that they have the following characteristics: • Arriving traffic at one interface becomes the exiting traffic at the other in the pair without reference to routing tables. • Traffic flows are still subject to normal rule sets such as IP rules. • One interface in the pair cannot function without the other. When the interface pair consists of an I‐WLAN IPsec tunnel and a GTP tunnel (a tunnel is a type of interface in the SEG), one cannot function without the other. Should the IPsec tunnel be taken down, the stitched GTP tunnel will also not function. If multiple I‐WLAN tunnels are configured there needs to be a GTP tunnel for every I‐ WLAN IPsec tunnel as these can only be stitched together on a one‐to‐one basis. ...
Page 182: Using Ip Rules
I-WLAN To set up a stitched interface pair, the StitchedInterface= property for each interface is set to the other interface in the pair. With I‐WLAN for example, a GTP tunnel may be set up as follows: Device:/> add Interface GTPInterface Gn  LocalEndpoint=gn_ip InterceptDHCPInform=Yes  StitchedInterface=MS The IPsec tunnel in the pair is then defined as: Device:/> add Interface IPsecTunnel MS  "  "  StitchedInterface=Gn Using IP rules It is important in an I‐WLAN setup to create the appropriate IP rules in the main SEG IP rule set. These rules consist of Deny rules that prevent traffic flowing between particular components of the network, as well as Allow rules which explicitly permit traffic flow. At minimum, IP rules should perform the following functions for I‐WLAN: 1. Prevents communication between external clients. 2. Allow DNS lookup to be performed by clients. 3. Allow HTTP traffic to flow from clients to the public Internet. Adding client routing As clients connect in a I‐WLAN solution, there has to be a route for the client in the relevant SEG routing table (usually the main table). This routes the IP address handed out to the client by the GGSN through the IPsec tunnel to the client. There are two ways this route can exist: • A separate route can be added automatically every time a client connects by enabling the IPsec tunnel option AddRouteToRemoteNetwork. • A single static route is added manually. This routes the entire network range used for client IP addresses on the IPsec tunnel object (which is treated like an interface in the SEG). The number of connected clients can usually become large with I‐WLAN, so the second option of manually adding a static route is recommended. This avoids the processing overhead of ...
Page 183: Certificates With I-Wlan
I-WLAN Certificates with I-WLAN In I‐WLAN scenarios, certificates are used so that the roaming clients can authenticate the SEG when communications are established. This can involve certificate chains so any intermediate certificates that are required to complete the validation chain should be uploaded to the SEG. There is no requirement for the client to contact a CA server as a Certificate Revocation List (CRL) is not used. Authentication of the security gateway occurs as follows: • The connecting client calculates and sends a hash of its root certificate to the SEG. At this point the client only has a CA signed root certificate. • Using the hash, the SEG scans all the certificates used with its IPsec tunnels until it finds a host certificate that can be validated by the client. • This certificate is now sent to the client and is also referred to as the Host Certificate. Any intermediate certificates that are needed to form a chain between the host certificate and the client's root certificate are also sent. • The client then authenticates the sender by creating a signing chain to its own CA signed root certificate. The use of intermediate certificates in these steps means that it will always be possible for a client to authenticate the host certificate even though the clients root certificate cannot be changed. Two cryptographic suites must be specified For proposal lists for IKE and IPsec with I‐WLAN, the 3GPP standard specifies that two different cryptographic suites must be specified for each. This means that the IPsec tunnel IKE and IPsec proposal lists must each contain two different proposals and these proposals should not have any algorithms in common. Recommended algorithm combinations can be found in the SEG‐100 Getting Started Guide. End User DNS server lookup The SEG provides an End User DNS server address to clients. This can either be received ...
Page 184: Support For Multiple Ggsns
I-WLAN Sending the P-CSCF address Following completion of an IKE negotiation, clients send a DHCP request to the SEG through the now established IPsec tunnel. The SEG will respond to this with the P‐CSCF (SIP server) address. The option exists for the SEG to either intercept and respond to the client DHCP requests it receives or to ignore them. The recommendation is to intercept them by enabling the setting Intercept DHCPINFORM messages from clients that request P‐CSCF information. When this intercept option is enabled, it is also required to supply a Fake DHCP Server address. This IP address is then used in two instances: • It is sent to clients during the IKE negotiation of the tunnel. Clients therefore know the address to which to send their DHCPINFORM messages and therefore only unicast their DHCPINFORM messages. The SEG will only intercept DHCPINFORM messages destined for the fake DHCP Server address. • It will be sent by the SEG in the response packet when responding to a client DHCPINFORM message. If the GGSN does not supply a P‐CSCF address then it responds with a 0.0.0.0 address. Support for multiple GGSNs It is possible to use multiple GGSNs networked through a single SEG. This can be implemented in the following ways: • Using DNS Round‐robin It is possible to have a different GGSN IP handed out in a round‐robin fashion. This is done with the following steps: 1. Enable the option RoundRobinDNS on the GTP tunnel object. 2. Have the multiple GGSN IP addresses configured on the DNS server. This option is provides a way load balancing between the GGSN servers. • Using Multiple IPsec/GTP Pairs It is also possible to have multiple pairs of IPsec/GTP tunnels, where each pair uses a different GGSN. Since the APN must be different for each GGSN, the Subject Alternative Name field of the ...
Page 185: Appendix A: Glossary Of Terms
Appendix Glossary of Terms The IEEE 802.3 specification for 10 Mbps Ethernet over two pairs of Cat 10BaseT 3 or better UTP (unshielded twisted‐pair) cable, up to 200 m. A set of media specifications, which include 100Base‐TX, 100Base‐T4 100BaseT and 100Base‐FX. Also known as Fast Ethernet. The IEEE 802.3 specification for Gigabit Ethernet over four pairs of Cat 1000BaseT 5E or better UTP cable, up to 100 m length. Triple‐DES and Triple Data Encryption Algorithm or TDEA. 3DES Area Border Router. ABR Access Control List. ACL An ActiveX object is HTTP component, which is downloaded and ActiveX executed on the client computer. Advanced Encryption Standard. A 128 block size with key lengths of 128‐ 256 bits. Application Layer Gateway. ALG Address Resolution Protocol. A protocol for mapping an IP address to a ARP physical machine address e.g. MAC‐addresses. Autonomous System. AS Autonomous System Boundary Routers. ASBRs Backup Designated Router. BDR  Blowfish (40‐448 bits) A 64‐bit block cipher with key length variable between 32 and 448 bits. Bootstrap Protocol. BOOTP For symmetric‐key ciphers, a brute force attack typically means a brute‐...
Page 186 Glossary of Terms A certificate is a digital proof of identity. Certificate Challenge Handshake Authentication Protocol. CHAP Cipher is a method of encrypting text (to produce cipher text) in which Cipher a cryptographic key and algorithm are applied to a block of data (for example, 64 contiguous bits) at once as a group rather than to one bit at a time. Certificate Revocation Lists. A certificate revocation list (CRL) contains a CRL list of all certificates that has been cancelled before their expiration date. Data Encryption Standard. DES is a US Federal Information Processing DES Standard (FIPS) that defines the Data Encryption Algorithm (DEA). The term DES is also commonly used when referring to the algorithm. The algorithm itself is a symmetric block cipher with a block size of 64 bits and a key length of 64 bits (of which 8 are parity bits). Diffie‐Hellman key exchange  A method for key exchange between two parties. This method can be used to generate an unbiased secret key over an insecure medium. The method has many variants. A well known attack called the man‐in‐the‐ middle attack forces the use of digital signatures or other means of authentication with the Diffie‐Hellman protocol. A dictionary attack is a method of breaking into a password‐protected Dictionary attack computer or server by systematically entering every word in a dictionary as a password. A dictionary attack can also be used in an attempt to find the key necessary to decrypt an encrypted message or document. Differentiated Services. Differentiated Services (DiffServ, or DS) is a Diff‐Serv protocol for specifying and controlling network traffic by class so that certain types of traffic get precedence ‐ for example, voice traffic, which requires a relatively uninterrupted flow of data, might get precedence over other kinds of traffic. Denial of service (DoS) ...
Page 187 Glossary of Terms By encrypting a digest of a message with the private key, authentication Digital signature can later be performed by applying the public key to an encrypted digest (digital signature) and comparing the result to the digest of the message.  Digital Signature Algorithm (DSA) DSA is a public‐key algorithm for digital signatures. The DSA algorithm was invented by the U.S. National Security Agency (NSA) and it is defined by NIST in FIPS 186‐2. Digital Signature Standard (DSS) The U.S. digital signature standard defined by National Institute of Standards and Technology (NIST). It is a standard for digital signatures using the DSA public‐key algorithm and the SHA‐1 hash algorithm.  Distinguished Encoding Rules (DER) The Distinguished Encoding Rules, defined in ITU‐T X.690, describe a way of converting structures of ASN.1 into binary data. DER is a subset of BER and guarantees unique representation in binary for every ASN.1 structure. Demilitarized zone. In computer networks, a DMZ (demilitarized zone) DMZ is a computer host or small network inserted as a “neutral zone” between a company's private network and the outside public network. It prevents outside users from getting direct access to a server that has company data. Distinguished Name (DN)  A distinguished name belongs to the X.500 Directory terminology. It declares a name that can be distinguished from other names in the directory. In that sense that name does not have to be unique. Often these names are seen encoded using the LDAP format for example “CN=John Doe, O=Some Organization, C=US”, however, the actual names are ASN.1 objects. Dead Peer Detection. Method to check if peer is alive for an IPsec flow. DPD Daylight Saving Time is the practice of turning the clock ahead as DST warmer weather approaches and back as it becomes colder again so ...
Page 188 Glossary of Terms Extensible Authentication Protocol/Subscriber Identity Module; EAP/SIM utilizing IKEv2. A security mechanism used for the transformation of data from an Encryption intelligible form (plaintext) into an unintelligible form (ciphertext), to provide confidentiality. The inverse transformation process is called decryption. A human user or an application to whom a certificate is issued. The end End entity entity has also the private key counterpart of the public key in the certificate. Encapsulating Security Payload. An upper level IP header that denotes ESP that the contents of the payload are encrypted and possibly also otherwise protected. An ESP may appear after the IP header, after an ESP header or theoretically also elsewhere within an IP packet. An ESP only protects the contents of the payload, not any associated header. Therefore it is possible, for example, to change any field in the header of the IP packet carrying an ESP without causing a security violation. The contents of the ESP header are unknown to anyone not possessing information about the transformation and SA needed to recover the protected data. An ESP may also contain integrity protection. The ESP protocol is defined in RFC 2406. A node located on the perimeter of an administrative domain that Firewall implements the security policy of the domain. A firewall usually performs address and port‐based packet filtering and usually has proxy servers for e‐mail and other services. Generic Access Network. GAN Gateway GPRS Support Node. GGSN A family of IEEE 802.3 standards capable of transmitting data at 1 Gbps Gigabit Ethernet (1000 Mbps). See 1000BaseT. Generic Routing Encapsulation. A tunneling protocol which GRE ...
Page 189 Glossary of Terms In a packet‐switching network, a hop is the trip a data packet takes from Hop one router or intermediate point to another in the network. On the Internet (or a network that uses TCP/IP), the number of hops a packet has taken toward its destination (called the “hop count”) is kept in the packet header. A packet with an exceedingly large hop count is discarded. HTTP Poster is a function to enable automatic client login, or domain HTTP Poster names and IP addresses update for DynDNS. When the firewall has parsed its configuration, the HTTP Poster posts all configured URLs in turn, and will wait a configurable delay time to re‐post the URLs. Authentication via secure web browsing. Similar to HTTP agent except HTTPS that Host and Root Certificates are used to establish SSL flow to the security gateway. Identification Lists (ID Lists)  When X.509 certificates are used as authentication method, the SEG will accept all remote end points or IPsec clients that are capable of presenting a certificate signed by any of the trusted Certificate Authorities (CAs). Intrusion Detection System. Intrusion detection is a type of security IDS management system for computers and networks. An ID system gathers and analyzes information from various areas within a computer or a network to identify possible security breaches, which include both intrusions (attacks from outside the organization) and misuse (attacks from within the organization). Internet Key Exchange. This is an IPsec (Internet Protocol Security) IKE standard protocol used to ensure security for virtual private network (VPN) negotiation and remote host or network access. International Mobile station Equipment Identity. IMEI International Mobile Subscriber Identity. IMSI The 32‐bit host address defined by the Internet Protocol in RFC 791. It IPv4 address ...
Page 190 Glossary of Terms IP Security. With IPsec the data traffic can be protected on IP level. IPsec IPsec is a vendor independent security architecture from the standardization organization IETF. An IP sub‐network (or sub‐net is a division of network elements in a IP sub‐network network, based on their IP address and subnet mask. IP spoofing, also known as IP address forgery or a host file hijack, is a IP spoofing hijacking technique in which a cracker masquerades as a trusted host to conceal his identity, spoof a Web site, hijack browsers, or gain access to a network. Here's how it works: The hijacker obtains the IP address of a legitimate host and alters packet headers so that the legitimate host appears to be the source. Tunneling means repackaging of information in form of normal TCP/IP IP tunneling packets, inside and then routing them through the Internet within a VPN (Virtual Private Network). In this way you can make up an inexpensive global private network. Layer Two Tunneling Protocol (L2TP) is an extension of the Point‐to‐ L2TP Point Tunneling Protocol (PPTP) used by an Internet service provider (ISP) to enable the operation of a virtual private network (VPN) over the Internet. In the Point‐to‐Point Protocol (PPP), the Link Control Protocol (LCP) LCP establishes, configures, and tests data‐link Internet connections. Lightweight Directory Access Protocol (LDAP). LDAP is a directory access LDAP protocol defined in RFC 2251 and RFC 1777 for accessing directories that support the X.500 Directory model, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). Long Term Evolution (LTE) is the trademarked project name of a high LTE performance air interface for cellular mobile telephony. Man‐in‐the‐middle‐attack  In cryptography, a man‐in‐the‐middle attack (MITM) is an attack in which an attacker is able to read, insert and modify at will, messages ...
Page 191 Glossary of Terms Message Digest 5. A message‐digest algorithm developed by Ron Rivest MD5 of RSA Security. It computes a secure, irreversible, cryptographically strong 128‐bit hash value for a document. The algorithm is documented in RFC 1321. Microsoft Challenge Handshake Authentication Protocol version 1. MS‐CHAP v1 Authentication for PPP connections between a computer using a Microsoft Windows operating system and a network access server (NAS). See MS‐CHAP v1. MS‐CHAP v2 Microsoft Point‐to‐Point Encryption. Protocol which provides MPPE confidentiality to the tunneling. MPPE may be used with PPTP to support an encrypted data tunnel.MPPE uses the RSA RC4 algorithm for encryption and supports 40‐bit, 56‐bit and 128‐bit session keys, which are changed frequently to ensure security. IPsec and NAT do not normally work together, as IPsec consider the NAT‐T NAT‐Traversal packet processing of NAT as a violation of communications integrity. NAT‐Traversal works by encapsulating the IPsec packets into UDP envelopes that contain information on recreating the IPsec packet. The UDP traffic follows the same route as the IKE negotiation. Network Control Protocols. (NCPs) can be used to transport traffic for a NCP particular protocol suite, so that multiple protocols can interoperate on the same link, for example, both IP and IPX traffic can share a PPP link. Password Authentication Protocol. PAP is a plaintext authentication PAP scheme by requesting and sending user name and password in plaintext. Path Maximum Transfer Unit. Different from the MTU in the sense that Path MTU Path MTU is bound to the source and destination addresses of the network. Path MTU discovery is discussed in RFC 1191. Policy Based Routing is an extension to normal routing which offers PBR ...
Page 192 Glossary of Terms PFS Perfect Forward Secrecy  Refers to the notion that any single key being compromised will permit access to only data protected by that single key. In order for PFS to exist, the key used to protect transmission of data must not be used to derive any additional keys. If the key used to protect transmission of data was derived from some other keying material, that material must not be used to derive any more keys. Also referred to as public‐key forward secrecy (PFS). A Pipe is a central concept in the traffic shaping functionality of the SEG Pipe and is the basis for all bandwidth control. Pipes are fairly simplistic in that they do not know much about the types of traffic that pass through them, and they know nothing about the direction either. A pipe simply measures the amount of traffic that passes through it and applies the configured limits in each precedence and/or user group. The task of traffic filtering, categorizing, and prioritizing is done by Pipe Rules covered in the next section. Public‐Key Cryptography Standards. The PKCS standards are a PKCS document series from RSA Laboratories. Some of the most important PKCS standards include PKCS #1 for RSA encryption and signature formats, PKCS #7 for cryptographic message encapsulation, PKCS #10 for certification requests, and PKCS #11 for a cryptographic token interface commonly used with smart cards. Public‐Key Infrastructure (X.509); a collective name for an architecture PKIX and set of protocols based on X.509, drafted by an IETF working group of the same name. Point‐to‐Point Tunneling Protocol (PPTP) is a protocol (set of PPTP communication rules) that allows corporations to extend their own corporate network through private “tunnels” over the public Internet. In public‐key cryptography the private key is only known to the holder, Private key and it can be used to sign and decrypt messages. Proxy ARP is the process in which one system responds to the ARP Proxy ARP request for another system. For example, host A sends an ARP request ...
Page 193 Glossary of Terms Pre‐Shared Key. With pre‐shared key authentication, an identical PSK symmetric key must be manually configured on both systems. The shared key is a secret passphrase, normally a string of ASCII characters or a set of random Hexadecimal numbers. Both endpoints need to have the same key defined and the key must be kept secret. The pre‐shared key is used only for the primary authentication; the two negotiating entities then generate dynamic shared session keys for the IKE SAs and IPsec SAs. In public‐key cryptography the public key, which is included in the Public key certificate, can be used to verify signatures and encrypt messages. Public‐key cryptography  In contrast to symmetric (secret‐key) cryptography with just one cipher key, in public‐key cryptography each person or host has two keys. One is the private key, which is used for signing outgoing messages and decrypting incoming messages, the other is the public key, which is used by others to confirm the authenticity of a signed message coming from that person and for encrypting messages addressed to that person. The private key must not be available to anyone but its owner, but the public key is spread via trusted channels to anyone. Remote Authentication for Dial in User Service. An Internet protocol RADIUS providing authentication, authorization and accounting. It is primarily used for dial access. RADIUS is defined in RFC 2138 and RFC 2139. Designed by Joan Daemen and Vincent Rijmen, Rijndael is a symmetric Rijndael block cipher with a variable block size of 128, 192, or 256 bits and a variable key length of 128, 192, or 256 bits. Rijndael is the algorithm used in the U.S. Advanced Encryption Standard (AES), however, in AES only the 128‐bit block size is used. A round robin is an arrangement of choosing all elements in a group Round‐Robin equally in some rational order, usually from the top to the bottom of a list and then starting again at the top of the list and so on. A simple way to think of round robin is that it is about “taking turns.” Used as an adjective, round robin becomes “round‐robin.” The route failover feature can be used when there is two or more routes ...
Page 194 Glossary of Terms A routing table is a set of rules, often viewed in table format, that is used Routing Table to determine where data packets traveling over an Internet Protocol (IP) network will be directed. All IP‐enabled devices, including routers and switches, use routing tables. A public‐key encryption and digital signature algorithm, invented by RSA Ron Rivest, Adi Shamir, and Leonard Adleman. Security Association. A unidirectional connection created for security SA purposes. All traffic traversing an SA is provided the same security processing. In the IPsec context, an SA is an Internet layer abstraction implemented through the use of an AH or ESP. It contains data controlling how a transformation is applied to an IP packet. The data is determined using specially defined SA management mechanisms. The data may be a result of an automated SA and key negotiation or it may be defined manually. This term is defined in RFC 2401. Static Address Translation (SAT). SAT is a type of address translation in SAT which a public IP address is statically mapped to a private IP address. Dynamic NAT is normally used for outgoing traffic, while SAT is used for incoming traffic. Security Gateway. An intermediate system that acts as the SEG communications interface between two networks. The internal sub networks and hosts served by a security gateway are presumed to be trusted because of shared local security administration. A United States standard for a cryptographically strong hash algorithm, SHA designed by National Security Agency (NSA) and defined by National Institute of Standards and Technology (NIST). Server Load balancing. SLB is a mechanism dealing with distributing the SLB traffic load across multiple servers to scale beyond the capacity of one single server, and to tolerate a server failure. This technology is integrated in the SEG to enable high performance and throughput of the network. Defined by RFC 2030, The Simple Network Time Protocol (SNTP) is a ...
Page 195 Glossary of Terms Sender Policy Framework (SPF) is an anti‐spam approach in which the SPF Internet domain of an e‐mail sender can be authenticated for that sender, thereby discouraging spam mailers, who routinely disguise the origin of their e‐mail, a practice known as e‐mail spoofing. SPF and other anti‐spoofing initiatives, such as Domain Keys, work by making it easier for a mail server to determine when a message came from a domain other than the one claimed. Clever attackers make tricks to fool the firewall by pretending the Spoofing identity of a trust host, which is the so called Spoofing technique. To reduce the flooding traffic of external routes advertisement, a Stub area special area called “stub area” can be configured. When a stub area is configured, the ABR will automatically advertise a default route so that routers in the stub area can reach destinations outside the area. The default route becomes the single exit point of the stub area, and the area will not accept broadcasts of external routes. SYN flooding is a method that the user of a hostile client program can SYN flooding use to conduct a denial‐of‐service (DoS) attack on a computer server. The hostile client repeatedly sends SYN (synchronization) packets to every port on the server, using fake IP addresses. Transport Layer Security (TLS)  Transport Layer Security is a protocol providing confidentiality, authentication, and integrity for stream‐like connections. It is typically used to secure HTTP connections. The protocol is being standardized by a working group of the IETF. In Transparent Mode, the SEG will be completely invisible for hosts in Transparent mode the network, with the exception that packets that are not allowed by the firewall rule set will be dropped. A strong and fast block cipher designed by Bruce Schneier. Twofish was Twofish one of the five final candidates for the United States government's new cipher standard, AES (Advanced Encryption Standard). Twofish uses a block size of 128 bits and a key length of up to 256 bits. Traffic Shaping is a mechanism that alters the traffic characteristics of a ...
Page 196 Glossary of Terms Unlicensed Mobile Access. UMA UMA Network Controller. UNC Virtual Private Network. Secure communication between multiple VPN networks or network devices using insecure public networks, such as the Internet. A connection over the Internet between a user connected on a remote VPN tunnel site and a security gateway. A VPN provides privacy only so to ensure security all IP packets are encrypted and sometimes encapsulated into another IP packet. Virtual Link. VLink The family of joint ITU‐T/ISO standards defining the X.500 Directory. X.500 The directory can be used for many applications, such as storing certificates, or information about people. LDAP is often used to access the X.500 Directory. The ITU‐T X.509 recommendation defines the formats for X.509 X.509 certificates and X.509 CRLs. Different X.509 applications are further defined by the PKIX Working Group of the IETF. These include X.509 version 3 public‐key certificates and X.509 version 2 CRLs. EXtended Ciphertext Block Chaining. XCBC ...
Page 197: Appendix B: Osi Model
Appendix OSI Model Overview The Open Systems Interconnection (OSI) model defines a framework for inter‐computer communications. It categorizes different protocols for a great variety of network applications into seven smaller, more manageable layers. The model describes how data from an application in one computer can be transferred through a network medium to an application on another computer. Control of data traffic is passed from one layer to the next, starting at the application layer in one computer, proceeding to the bottom layer, traversing over the medium to another computer and then delivering up to the top of the hierarchy. Each layer handles a certain set of protocols, so that the tasks for achieving an application can be distributed to different layers and be implemented independently. The model is relevant to understanding many aspects of the SEG, such as ARP and services. Table 1. The 7 layers of the OSI model Layer number Layer purpose Layer 7 Application Layer 6 Presentation Layer 5 Session Layer 4 Transport Layer 3 Network Layer 2...
Page 198 OSI Model  Layer 4 – Transport Layer Controls data flow and provides error‐handling. Protocols: TCP, UDP and similar.  Layer 3 – Network Layer Performs addressing and routing. Protocols: IP, OSPF, ICMP, IGMP and similar.  Layer 2 – Data‐Link Layer Creates frames of data for transmission over the physical layer and includes error checking/correction. Protocols: Ethernet, PPP and similar. ARP operates at this level.  Layer 1 – Physical Layer Defines the physical hardware connection. ...

RadiSys SEG-100 Administration Manual

Preface

Chapter 1: Overview

Chapter 2: Management

Chapter 3: Addressing

Chapter 4: Address Translation

Chapter 5: Routing

Chapter 6: Firewall

Chapter 7: Ipsec VPN

Chapter 8: Authentication

Chapter 9: High Availability

Chapter 10: Advanced Settings

Chapter 11: I-WLAN

Appendix A: Glossary of Terms

Appendix B: OSI Model

Quick Links

Need help?

Questions and answers

Related Manuals for RadiSys SEG-100

Summary of Contents for RadiSys SEG-100

Table of Contents