HP High-End Firewalls

Transcription

1 HP High-End Firewalls Access Control Configuration Guide Part number: Software version: F1000-A-EI&F1000-S-EI: R3721 F5000: F3210 F1000-E: F3171 Firewall module: F3171 Document version: 6PW

2 Legal and notice information Copyright 2012 Hewlett-Packard Development Company, L.P. No part of this documentation may be reproduced or transmitted in any form or by any means without prior written consent of Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HEWLETT-PACKARD COMPANY MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

3 Contents Configuring ACLs 1 Overview 1 ACL categories 1 ACL numbering and naming 1 Match order 2 ACL rule numbering 3 Implementing time-based ACL rules 3 Fragments filtering with ACLs 3 IPv4 ACL acceleration 3 Configuring an ACL in the Web interface 4 Configuration task list 4 Creating an ACL 4 Configuring a basic ACL rule 5 Configuring an advance ACL rule 7 Configuring an Ethernet frame header ACL rule 9 Configuring ACL acceleration 11 ACL configuration example 11 Configuring an ACL at the CLI 15 ACL configuration task list 15 Configuring a basic ACL 15 Configuring an advanced ACL 17 Configuring an Ethernet frame header ACL 18 Copying an ACL 19 Enabling ACL acceleration for an IPv4 ACL 20 Displaying and maintaining ACLs 20 ACL configuration example 21 Configuring security zones 23 Overview 23 Zone configuration task list 24 Creating a zone 24 Configuring a zone member 25 Zone configuration example 27 Configuring service management 32 Overview 32 Configuring service management 33 Service management configuration examples 34 HTTP configuration example 34 HTTPS configuration example 38 Configuring address resources 44 Address resource overview 44 Configuring an address resource 44 Configuring a host address resource 44 Configuring an address range resource 45 Configuring a subnet address resource 47 Configuring an IP address group resource 48 Configuring a MAC address resource 49 Configuring a MAC address group resource 50 i

4 Exporting and importing configuration 51 Configuring service resources 53 Overview 53 Configuring a service resource 53 Displaying default service resources 53 Configuring a customized service resource 54 Configuring a service group resource 56 Exporting and importing configuration 57 Configuring time range resources 59 Overview 59 Configuring a time range resource in the Web interface 59 Configuring a time range at the CLI 60 Configuration guidelines 61 Interzone policy configuration 62 Interzone policy overview 62 Configuring an interzone policy 63 Configuration task list 63 Configuring an interzone policy rule 63 Configuring an interzone policy group 68 Displaying packet statistics of an interzone policy 69 Querying policies by IP address 70 Interzone policy configuration examples 70 Firewall policy configuration wizard 77 Overview 77 Configuring a firewall policy 77 Managing sessions 84 Overview 84 Session management principle 84 Session management implementation 84 Configuring session management in the web interface 85 Configuration task list 85 Configuring basic session management settings 86 Displaying session table information 89 Displaying global session statistics 90 Enabling and disabling session statistics collection 92 Displaying session statistics per IP address 93 Displaying session statistics based on security zone 94 Configuring session management at the CLI 95 Setting session aging times based on protocol states 95 Configuring session aging timers based on application layer protocol types 96 Enabling checksum verification 96 Specifying the persistent session rule 96 Clearing sessions 97 Displaying and maintaining session management 97 Configuration guidelines 98 Configuring virtual fragment reassembly 99 Overview 99 Configuring virtual fragment reassembly 99 Virtual fragment reassembly configuration example 100 Configuration guidelines 102 ii

5 Configuring ASPF 103 Overview 103 Configuring ASPF 103 ASPF configuration example 104 Configuring connection limits 106 Overview 106 Configuring connection limit in the web interface 106 Configuring connection limit at the CLI 108 Connection limit configuration task list 108 Creating a connection limit policy 108 Configuring the connection limit policy 108 Applying the connection limit policy 109 Displaying and maintaining connection limit 109 Connection limit configuration example 109 Troubleshooting connection limit 111 Configuring portal authentication 112 Feature and hardware compatibility 112 Overview 112 Extended portal functions 112 Portal system components 112 Portal authentication mode 114 Layer 3 portal authentication process 115 Portal configuration task list 117 Configuration prerequisites 117 Specifying a portal server for Layer 3 portal authentication 118 Enabling Layer 3 portal authentication 118 Controlling access of portal users 119 Configuring a portal-free rule 119 Configuring an authentication source subnet 120 Setting the maximum number of online portal users 120 Specifying the authentication domain for portal users 121 Configuring RADIUS related attributes 121 Specifying NAS-Port-Type for an interface 121 Specifying a NAS ID profile for an interface 122 Specifying a source IP address for outgoing portal packets 122 Specifying an auto redirection URL for authenticated portal users 123 Configuring portal detection functions 123 Configuring online Layer 3 portal user detection 123 Configuring the portal server detection function 124 Configuring portal user information synchronization 125 Logging off portal users 126 Displaying and maintaining portal 127 Portal configuration examples 127 Configuring direct portal authentication 127 Configuring re-dhcp portal authentication 132 Configuring cross-subnet portal authentication 135 Configuring direct portal authentication with extended functions 136 Configuring re-dhcp portal authentication with extended functions 138 Configuring cross-subnet portal authentication with extended functions 141 Configuring portal server detection and portal user information synchronization 143 Troubleshooting portal 149 Inconsistent keys on the access device and the portal server 149 Incorrect server port number on the access device 149 iii

6 Configuring AAA 150 Feature and hardware compatibility 150 AAA overview 150 RADIUS 151 HWTACACS 156 Domain-based user management 158 AAA across VPNs 159 Protocols and standards 160 RADIUS attributes 160 AAA configuration considerations and task list 163 Configuring AAA schemes 164 Configuring local users 164 Configuring RADIUS schemes in the web interface 169 RADIUS configuration example in the web interface 176 Configure RADIUS schemes at the CLI 181 RADIUS scheme configuration guidelines 192 Configuring HWTACACS schemes in the web interface 193 HWTACACS configuration example in the web interface 197 Configuring HWTACACS schemes at the CLI 200 HWTACACS scheme configuration guidelines 207 Configuring AAA methods for ISP domains 207 Configuration prerequisites 207 Creating an ISP domain 208 Configuring ISP domain attributes 208 Configuring AAA authentication methods for an ISP domain 209 Configuring AAA authorization methods for an ISP domain 211 Configuring AAA accounting methods for an ISP domain 212 Forcibly tearing down user connections 214 Configuring a NAS ID-VLAN binding 214 Displaying and maintaining AAA 215 AAA configuration examples 215 Authentication and authorization for Telnet and SSH users by a RADIUS server 215 Local authentication and authorization for Telnet and FTP users 220 Level switching authentication for Telnet users by a RADIUS server 222 AAA for portal users by a RADIUS server 226 Troubleshooting AAA 233 Troubleshooting RADIUS 233 Troubleshooting HWTACACS 235 Configuring password control 236 Feature and hardware compatibility 236 Password control overview 236 Password control configuration task list 238 Configuring password control 239 Enabling password control 239 Setting global password control parameters 240 Setting user group password control parameters 241 Setting local user password control parameters 241 Setting super password control parameters 242 Setting a local user password in interactive mode 243 Displaying and maintaining password control 243 Password control configuration example 244 Configuring FIPS 247 Feature and hardware compatibility 247 iv

7 Overview 247 Configuring FIPS 247 Configuration consideration 247 Enabling FIPS mode 248 FIPS self-tests 248 Power-up self-tests 248 Conditional self-tests 249 Triggering a self-test 249 Displaying and maintaining FIPS 250 Support and other resources 251 Contacting HP 251 Subscription service 251 Related information 251 Documents 251 Websites 251 Conventions 252 Index 254 v

8 Configuring ACLs NOTE: The IPv6 ACL configuration is available only at the CLI. Overview An access control list (ACL) is a set of rules (or permit or deny statements) for identifying traffic based on criteria such as source IP address, destination IP address, and port number. You can use ACLs in QoS, firewall, routing, and other technologies for identifying traffic. The packet drop or forwarding decisions varies with modules that use ACLs. See the specific module for information about ACL application. ACL categories Category ACL number IP version Match criteria Basic ACLs 2000 to 2999 Advanced ACLs 3000 to 3999 IPv4 IPv6 IPv4 IPv6 Source IPv4 address Source IPv6 address Source IPv4 address, destination IPv4 address, packet priority, protocols over IPv4, and other Layer 3 and Layer 4 header fields Source IPv6 address, destination IPv6 address, packet priority, protocols over IPv6, and other Layer 3 and Layer 4 header fields Ethernet frame header ACLs 4000 to 4999 IPv4 and IPv6 Layer 2 header fields, such as source and destination MAC addresses, 802.1p priority, and link layer protocol type ACL numbering and naming Each ACL category has a unique range of ACL numbers. When creating an ACL, you must assign it a number for identification. In addition, you can assign the ACL a name for the ease of identification. After creating an ACL with a name, you cannot rename it or delete its name. For an Ethernet frame header ACL, the ACL number and name must be globally unique. For an IPv4 basic or advanced ACLs, its ACL number and name must be unique among all IPv4 ACLs, and for an IPv6 basic or advanced ACL, among all IPv6 ACLs. You can assign an IPv4 ACL the same number and name as an IPv6 ACL. 1

9 Match order The rules in an ACL are sorted in a specific order. When a packet matches a rule, the device stops the match process and performs the action defined in the rule. If an ACL contains overlapping or conflicting rules, the matching result and action to take depend on the rule order. The following ACL match orders are available: config Sorts ACL rules in ascending order of rule ID. A rule with a lower ID is matched before a rule with a higher ID. If you use this approach, carefully check the rule content and order. auto Sorts ACL rules in depth-first order. Depth-first ordering guarantees that any subset of a rule is always matched before the rule. Table 1 lists the sequence of tie breakers that depth-first ordering uses to sort rules for each type of ACL. Table 1 Sort ACL rules in depth-first order ACL category IPv4 basic ACL IPv4 advanced ACL IPv6 basic ACL IPv6 advanced ACL Ethernet frame header ACL Sequence of tie breakers 1. VPN instance 2. More 0s in the source IP address wildcard (more 0s means a narrower IP address range) 3. Smaller rule ID 1. VPN instance 2. Specific protocol type rather than IP (IP represents any protocol over IP) 3. More 0s in the source IP address wildcard mask 4. More 0s in the destination IP address wildcard 5. Narrower TCP/UDP service port number range 6. Smaller rule ID 1. VPN instance 2. Longer prefix for the source IP address (a longer prefix means a narrower IP address range) 3. Smaller rule ID 1. VPN instance 2. Specific protocol type rather than IP (IP represents any protocol over IPv6) 3. Longer prefix for the source IPv6 address 4. Longer prefix for the destination IPv6 address 5. Narrower TCP/UDP service port number range 6. Smaller rule ID 1. More 1s in the source MAC address mask (more 1s means a smaller MAC address) 2. More 1s in the destination MAC address mask 3. Smaller rule ID NOTE: A wildcard mask, also called an inverse mask, is a 32-bit binary and represented in dotted decimal notation. In contrast to a network mask, the 0 bits in a wildcard mask represent 'do care' bits, and the 1 bits represent 'don't care' bits. If the 'do care' bits in an IP address are identical to the 'do care' bits in an IP address criterion, the IP address matches the criterion. All 'don't care' bits are ignored. The 0s and 1s in a wildcard mask can be noncontiguous. For example, is a valid wildcard mask. 2

10 ACL rule numbering What is the ACL rule numbering step If you do not assign an ID to the rule you are creating, the system automatically assigns it a rule ID. The rule numbering step sets the increment by which the system automatically numbers rules. For example, the default ACL rule numbering step is 5. If you do not assign IDs to rules you are creating, they are numbered 0, 5, 10, 15, and so on. The wider the numbering step, the more rules you can insert between two rules. By introducing a gap between rules rather than contiguously numbering rules, you have the flexibility of inserting rules in an ACL. This feature is important for a config order ACL, where ACL rules are matched in ascending order of rule ID. Automatic rule numbering and renumbering The ID automatically assigned to an ACL rule takes the nearest higher multiple of the numbering step to the current highest rule ID, starting with 0. For example, if the numbering step is 5 (the default), and there are five ACL rules numbered 0, 5, 9, 10, and 12, the newly defined rule is numbered 15. If the ACL does not contain any rule, the first rule is numbered 0. Whenever the step changes, the rules are renumbered, starting from 0. For example, if there are five rules numbered 5, 10, 13, 15, and 20, changing the step from 5 to 2 causes the rules to be renumbered 0, 2, 4, 6 and 8. NOTE: The default ACL rule numbering step is 5.The ACL step configuration is not available in the web interface. Implementing time-based ACL rules You can implement ACL rules based on the time of day by applying a time range to them. A time-based ACL rule takes effect only in any time periods specified by the time range. For more information about time ranges, see "Configuring time range resources." Fragments filtering with ACLs Traditional packet filtering matches only first fragments of packets, and allows all subsequent non-first fragments to pass through. Attackers can fabricate non-first fragments to attack networks. To avoids the risks, the HP ACL implementation: Filters all fragments by default, including non-first fragments. Allows for matching criteria modification, for example, filters non-first fragments only. IPv4 ACL acceleration ACL acceleration speeds up ACL lookup. The acceleration effect increases with the number of ACL rules. ACL acceleration uses memory. To achieve the best trade-off between memory and ACL processing performance, HP recommends you enable ACL acceleration for large ACLs. For example, when you use a large ACL for a session-based service, such as NAT or ASPF, you can enable ACL acceleration to avoid session timeouts caused by ACL processing delays. 3

11 Enable ACL acceleration in an ACL after you have finished editing ACL rules. ACL acceleration always uses ACL criteria that have been set before it is enabled for rule matching. It does not synchronize with any subsequent match criterion changes. Configuring an ACL in the Web interface Configuration task list Table 2 ACL configuration task list Task Creating an ACL Configuring a basic ACL rule Configuring an advance ACL rule Configuring an Ethernet frame header ACL rule Remarks Required. The category of the created ACL depends on the ACL number that you specify. Required. Complete one of the three tasks according to the ACL category. IMPORTANT: Within an ACL, the permit or deny statement of each rule must be unique. If the ACL rule you are creating or editing has the same deny or permit statement as another rule in the ACL, your creation or editing attempt will fail. You can edit ACL rules only when the match order is config. Optional. Necessary only when the ACL contains a large number of ACL rules. Configuring ACL acceleration IMPORTANT: Only IPv4 basic ACLs and IPv4 advanced ACLs support ACL acceleration. ACL acceleration is not available for ACLs that contain a non-contiguous wildcard mask, for example, After you modify an IPv4 ACL with ACL acceleration enabled, disable and re-enable ACL acceleration to guarantee correct rule matching. Creating an ACL After you select Firewall > ACL from the navigation tree, all existing ACLs will be displayed in the right pane, as shown in Figure 1. Click Add to enter the ACL configuration page, as shown in Figure 2. 4

12 Figure 1 ACL list Figure 2 ACL configuration page Table 3 Configuration items Item ACL Number Match Order Description Description Enter a number for the ACL. Select a match order for the ACL. Available values are: Config Sorts ACL rules in ascending order of rule ID. Auto Sorts ACL rules in depth-first order. Enter a description for the ACL. Configuring a basic ACL rule Select Firewall > ACL from the navigation tree. Then, select the basic ACL for which you want to configure ACL rules from the ACL list in the right pane and click the corresponding icon in the Operation column to display all existing rules of the ACL, as shown in Figure 3. Click Add to enter the basic ACL rule configuration page, as shown in Table 4. 5

13 Figure 3 List of basic ACL rules Figure 4 Basic ACL rule configuration page Table 4 Configuration items Item Description Select the Rule ID box and enter a number for the rule. Rule ID Operation If you do not specify a rule number, the system automatically assigns one to the rule. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. Select the operation to be performed for packets matching the rule. Permit Allows matching packets to pass. Deny Denies matching packets. Select a time range for the rule. Time Range Non-first Fragments Only If you select None, the rule will always be effective. Available time ranges are configured by selecting Resource > Time Range from the navigation tree. Select this box to apply the rule to only non-first fragments. If you do no select this box, the rule applies to all fragments and non-fragments. Select this box to log matching packets. Logging A log entry contains the ACL rule number, action on the matching packets, protocol that IP carries, source/destination address, source/destination port number, and number of matching packets. 6

14 Item Source IP Address Source Wildcard VPN Instance Description Select the Source IP Address box and enter a source IP address and source wildcard, in dotted decimal notation. Specify the VPN. If you select None, the rule applies to only non-vpn packets. Configuring an advance ACL rule Select Firewall > ACL from the navigation tree. Then, select the advanced ACL for which you want to configure ACL rules from the ACL list in the right pane and click the corresponding icon in the Operation column to list all existing rules of the ACL, as shown in Figure 5. Click Add to enter the advanced ACL rule configuration page, as shown in Figure 6. Figure 5 List of advanced ACL rules 7

15 Figure 6 Advanced ACL rule configuration page Table 5 Configuration items Item Description Select the Rule ID box and enter a number for the rule. Rule ID If you do not specify the rule number, the system will assign one automatically. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. Operation Select the action to be performed for packets matching the rule. Permit Allows matching packets to pass. Deny Denies matching packets. Select a time range for the rule. Time Range Non-first Fragments Only If you select None, the rule will always be effective. Available time ranges are configured by selecting Resource > Time Range from the navigation tree. Select this box to apply the rule to only non-first fragments. If you do no select this box, the rule applies to all fragments and non-fragments. Select this box to log matching IPv4 packets. Logging Source IP Address Source Wildcard A log entry contains the ACL rule number, action on the matching packets, protocol over the IP, source/destination address, source/destination port number, and number of matching packets. Select the Source IP Address box and enter a source IP address and source wildcard, in dotted decimal notation. 8

16 Item Destination IP Address Destination Wildcard VPN Instance Protocol ICMP Message ICMP Type ICMP Code TCP Connection Established Description Select the Destination IP Address box and enter a destination IP address and destination wildcard, in dotted decimal notation. Specify the VPN. If you select None, the rule applies to only non-vpn packets. Select the protocol to be carried over by IP. If you select 1 ICMP, you can configure the ICMP message type and code. If you select 6 TCP or 17 UDP, you can configure the TCP or UDP specific items. Specify the ICMP message type and code. These items are available only when you select 1 ICMP from the Protocol list. If you select Others from the ICMP Message list, you need to enter values in the ICMP Type and ICMP Code fields. Otherwise, the two fields will take the default values, which cannot be changed. If you select this box, the rule matches packets used for establishing and maintaining TCP connections. This item is available only when you select 6 TCP from the Protocol list. On a firewall, a rule with this item configured matches TCP connection packets with the ACK or RST flag. Source Destination Operator Port Operator Port Select the operators and enter the source port numbers and destination port numbers as required. These items are available only when you select 6 TCP or 17 UDP from the Protocol list. Different operators have different configuration requirements for the port number fields: None The following port number fields cannot be configured. inclusive range The following port number fields must be configured to define a port range. Other values The first port number field must be configured and the second must not. ToS Specify the ToS preference. IMPORTANT: Precedence DSCP Specify the IP precedence. Specify the DSCP priority. If you configure the IP precedence or ToS precedence in addition to the DSCP priority, the DSCP priority takes effect. Configuring an Ethernet frame header ACL rule Select Firewall > ACL from the navigation tree. Then, select the Ethernet frame header ACL for which you want to configure ACL rules from the ACL list in the right pane and click the corresponding icon in the Operation column to list all existing rules of the ACL, as shown in Figure 7. Click Add to enter the configuration page for Ethernet frame header ACL rules, as shown in Figure 8. 9

17 Figure 7 List of Ethernet frame header ACL rules Figure 8 Ethernet frame header ACL rule configuration page Table 6 Configuration items Item Description Select the Rule ID box and enter a number for the rule. Rule ID If you do not specify the rule number, the system will assign one automatically. IMPORTANT: If the rule already exists, the configuration overwrites the old rule. Operation Select the operation to be performed for packets matching the rule. Permit Allows matching packets to pass. Deny Denies matching packets. Select a time range for the rule. Time Range Source MAC Address Source Wildcard Destination MAC Address Destination Wildcard If you select None, the rule will always be effective. Available time ranges are configured by selecting Resource > Time Range from the navigation tree. Select the Source MAC Address box and specify the source MAC address and wildcard. Select the Destination MAC Address box and specify the destination MAC address and wildcard. 10

18 Item LSAP Type LSAP Wildcard Protocol Type Protocol Wildcard Description Select the LSAP Type box and specify the DSAP and SSAP fields in the LLC encapsulation by configuring the following two items: LSAP Type Specifies the encapsulation format. LSAP Wildcard Specifies the LSAP mask. Select the Protocol Type box and specify the link layer protocol by configuring the following two items: Protocol Type Specifies a protocol type in Ethernet_II and Ethernet_SNAP frames. Protocol Wildcard Specifies a protocol type mask. Configuring ACL acceleration Select Firewall > ACL from the navigation tree to enter the page shown in Figure 1. All existing ACLs will be displayed in the right pane. You can enable or disable ACL acceleration for an ACL through the ACL Acceleration column: indicates that the ACL is not accelerated. You can click the Start Accelerating link to enable ACL acceleration. indicates that the ACL is accelerated. You can click the Stop Accelerating link to disable ACL acceleration. indicates that the ACL has been modified after it was configured with ACL acceleration. You can click the Start Accelerating link to enable ACL acceleration again, making changes to the ACL take effect. ACL configuration example Network requirements As shown in Figure 9, Host A connects to Firewall through GigabitEthernet 0/1. Configure an ACL to: Allow Host A to access Firewall using HTTP. Allow hosts on other segments to access Firewall using HTTP on only working days. Figure 9 Network diagram Creating a time range # Create a periodic time range of Saturday and Sunday. 11

19 Select Resource > Time Range from the navigation tree and then click Add. Create a time range. Figure 10 Creating a time range Defining an ACL Enter time in the Name field. Select the Periodic Time Range box. Select the Sun. and Sat. boxes. Click Apply. # Create a basic ACL. Select Firewall > ACL from the navigation tree, and then click Add. Create ACL 2000 as shown in Figure 11. Figure 11 Creating an ACL Enter the ACL number Select the match order Config. Click Apply. # Create a rule to allow Host A to access Firewall. From the ACL list, select ACL 2000 and click the corresponding icon in the Operation column. Then, on the page click Add to enter the ACL rule configuration page. 12

20 Figure 12 Configuring a rule to allow Host A to access Firewall Select Permit from the Operation list. Select the Source IP Address box and enter and respectively in the following fields. Click Apply. # Create a rule to deny access of other hosts to Firewall on Saturday and Sunday. On the page displaying the rules of ACL 2000, click Add. Figure 13 Configuring an ACL rule to deny access of other hosts to Firewall on Saturday and Sunday Select Deny as the operation. Select time as the time range. Select Source IP Address box and enter and in the following fields. Click Apply. # Configure an ACL rule to allow other hosts to access Firewall. On the page displaying rules of ACL 2000, click Add. 13

21 Figure 14 Configuring an ACL rule to allow other hosts to access Firewall Select Permit. Click Apply. NOTE: The three ACL rules must be configured in the shown order. Configuring service management # Associate HTTP service with ACL Select Device Management > Service Management from the navigation tree. Associate HTTP service with ACL Figure 15 Associating HTTP service with ACL 2000 Click the + sign before HTTP to expand the configuration area. Enter 2000 in the ACL field. Click Apply. 14

22 Configuring an ACL at the CLI ACL configuration task list Complete the following tasks to configure an ACL: Task Configuring a basic ACL Configuring an advanced ACL Configuring an Ethernet frame header ACL Copying an ACL Enabling ACL acceleration for an IPv4 ACL Remarks Required. Configure at least one task. NOTE: Within an ACL, the permit or deny statement of each rule must be unique. If the ACL rule you are creating or editing has the same deny or permit statement as another rule in the ACL, your creation or editing attempt will fail. You can edit ACL rules only when the match order is config. Optional. Applicable to IPv4 and IPv6. Optional. Configuring a basic ACL Configuring an IPv4 basic ACL IPv4 basic ACLs match packets based only on source IP addresses. To configure an IPv4 basic ACL: Step Command Remarks 1. Enter system view. system-view N/A By default, no ACL exists. 2. Create an IPv4 basic ACL and enter its view. 3. Configure a description for the IPv4 basic ACL. 4. Set the rule numbering step. acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text step step-value IPv4 basic ACLs are numbered in the range 2000 to You can use the acl name acl-name command to enter the view of a named IPv4 ACL. Optional. By default, an IPv4 basic ACL has no ACL description. Optional. 5 by default. 15

23 Step Command Remarks 5. Create or edit a rule. 6. Configure or edit a rule description. rule [ rule-id ] { deny permit } [ counting fragment logging source { sour-addr sour-wildcard any } time-range time-range-name vpn-instance vpn-instance-name ] * rule rule-id comment text By default, an IPv4 basic ACL does not contain any rule. To create or edit multiple rules, repeat this step. The logging keyword takes effect only when the module (for example, a firewall) that uses the ACL supports logging. Optional. By default, an IPv4 ACL rule has no rule description. Configuring an IPv6 basic ACL To configure an IPv6 basic ACL: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an IPv6 basic ACL view and enter its view. 3. Configure a description for the IPv6 basic ACL. acl ipv6 number acl6-number [ name acl6-name ] [ match-order { auto config } ] description text By default, no ACL exists. IPv6 basic ACLs are numbered in the range 2000 to You can use the acl ipv6 name acl6-name command to enter the view of a named IPv6 ACL. Optional. By default, an IPv6 basic ACL has no ACL description. 4. Set the rule numbering step. step step-value Optional. 5 by default. 5. Create or edit a rule. 6. Configure or edit a rule description. rule [ rule-id ] { deny permit } [ counting fragment logging source { ipv6-address prefix-length ipv6-address/prefix-length any } time-range time-range-name vpn-instance vpn-instance-name ] * rule rule-id comment text By default, an IPv6 basic ACL does not contain any rule. To create or edit multiple rules, repeat this step. The logging keyword takes effect only when the module using the ACL supports logging. Optional. By default, an IPv6 basic ACL rule has no rule description. 16

24 Configuring an advanced ACL Configuring an IPv4 advanced ACL IPv4 advanced ACLs match packets based on source IP addresses, destination IP addresses, packet priorities, protocols over IP, and other protocol header information, such as TCP/UDP source and destination port numbers, TCP flags, ICMP message types, and ICMP message codes. Compared to IPv4 basic ACLs, IPv4 advanced ACLs allow more flexible and accurate filtering. To configure an IPv4 advanced ACL: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an IPv4 advanced ACL and enter its view. 3. Configure a description for the IPv4 advanced ACL. acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text By default, no ACL exists. IPv4 advanced ACLs are numbered in the range 3000 to You can use the acl name acl-name command to enter the view of a named IPv4 ACL. Optional. By default, an IPv4 advanced ACL has no ACL description. 4. Set the rule numbering step. step step-value Optional. 5 by default. 5. Create or edit a rule. 6. Configure or edit a rule description. rule [ rule-id ] { deny permit } protocol [ { { ack ack-value fin fin-value psh psh-value rst rst-value syn syn-value urg urg-value } * established } counting destination { dest-addr dest-wildcard any } destination-port operator port1 [ port2 ] dscp dscp fragment icmp-type { icmp-type [ icmp-code ] icmp-message } logging precedence precedence reflective source { sour-addr sour-wildcard any } source-port operator port1 [ port2 ] time-range time-range-name tos tos vpn-instance vpn-instance-name ] * rule rule-id comment text By default, an IPv4 advanced ACL does not contain any rule. To create or edit multiple rules, repeat this step. The logging keyword takes effect only when the module (for example, a firewall) using the ACL supports logging. Optional. By default, an IPv4 advanced ACL rule has no rule description. Configuring an IPv6 advanced ACL IPv6 advanced ACLs match packets based on the source IPv6 addresses, destination IPv6 addresses, packet priorities, protocols carried over IPv6, and other protocol header fields such as the TCP/UDP 17

25 source port number, TCP/UDP destination port number, ICMPv6 message type, and ICMPv6 message code. Compared to IPv6 basic ACLs, IPv6 advanced ACLs allow more flexible and accurate filtering. To configure an IPv6 advanced ACL: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an IPv6 advanced ACL and enter its view. 3. Configure a description for the IPv6 advanced ACL. 4. Set the rule numbering step. 5. Create or edit a rule. 6. Configure or edit a rule description. acl ipv6 number acl6-number [ name acl6-name ] [ match-order { auto config } ] description text step step-value rule [ rule-id ] { deny permit } protocol [ { { ack ack-value fin fin-value psh psh-value rst rst-value syn syn-value urg urg-value } * established } counting destination { dest dest-prefix dest/dest-prefix any } destination-port operator port1 [ port2 ] dscp dscp flow-label flow-label-value fragment icmp6-type { icmp6-type icmp6-code icmp6-message } logging source { source source-prefix source/source-prefix any } source-port operator port1 [ port2 ] time-range time-range-name vpn-instance vpn-instance-name ] * rule rule-id comment text By default, no ACL exists. IPv6 advanced ACLs are numbered in the range 3000 to You can use the acl ipv6 name acl6-name command to enter the view of a named IPv6 ACL. Optional. By default, an IPv6 advanced ACL has no ACL description. Optional. 5 by default. By default IPv6 advanced ACL does not contain any rule. To create or edit multiple rules, repeat this step. The logging keyword takes effect only when the module (for example, a firewall) using the ACL supports logging. Optional. By default, an IPv6 advanced ACL rule has no rule description. Configuring an Ethernet frame header ACL Ethernet frame header ACLs, also called "Layer 2 ACLs," match packets based on Layer 2 protocol header fields such as source MAC address, destination MAC address, 802.1p priority (VLAN priority), and link layer protocol type. To configure an Ethernet frame header ACL: Step Command Remarks 1. Enter system view. system-view N/A 18

26 Step Command Remarks 2. Create an Ethernet frame header ACL and enter its view. 3. Configure a description for the Ethernet frame header ACL. acl number acl-number [ name acl-name ] [ match-order { auto config } ] description text By default, no ACL exists. Ethernet frame header ACLs are numbered in the range 4000 to You can use the acl name acl-name command to enter the view of a named Ethernet frame header ACL. Optional. By default, an Ethernet frame header ACL has no ACL description. 4. Set the rule numbering step. step step-value Optional. 5 by default. 5. Create or edit a rule. 6. Configure or edit a rule description. rule [ rule-id ] { deny permit } [ cos vlan-pri counting dest-mac dest-addr dest-mask { lsap lsap-type lsap-type-mask type protocol-type protocol-type-mask } source-mac sour-addr source-mask time-range time-range-name ] * rule rule-id comment text By default, an Ethernet frame header ACL does not contain any rule. To create or edit multiple rules, repeat this step. Optional. By default, an Ethernet frame header ACL rule has no rule description. Copying an ACL You can create an ACL by copying an existing ACL (source ACL). The new ACL (destination ACL) has the same properties and content as the source ACL, but not the same ACL number and name. To successfully copy an ACL, make sure that: The destination ACL number is from the same category as the source ACL number. The source ACL already exists but the destination ACL does not. Copying an IPv4 ACL Step Command 1. Enter system view. system-view 2. Copy an existing IPv4 ACL to create a new IPv4 ACL. acl copy { source-acl-number name source-acl-name } to { dest-acl-number name dest-acl-name } 19

27 Copying an IPv6 ACL Step Command 1. Enter system view. system-view 2. Copy an existing IPv6 ACL to generate a new one of the same category. acl ipv6 copy { source-acl6-number name source-acl6-name } to { dest-acl6-number name dest-acl6-name } Enabling ACL acceleration for an IPv4 ACL Step Command Remarks 1. Enter system view. system-view N/A 2. Enable ACL acceleration for an IPv4 ACL. acl accelerate number acl-number Disabled by default. The ACL must exist. Only IPv4 basic ACLs and advanced ACLs support ACL acceleration. CAUTION: ACL acceleration is not available for ACLs that contain a non-contiguous wildcard mask. This feature occupies system memory. Use this feature with caution. After you modify an IPv4 ACL with ACL acceleration enabled, disable and re-enable ACL acceleration to guarantee correct rule matching. Displaying and maintaining ACLs Task Command Remarks Display configuration and match statistics for one or all IPv4 ACLs. Display information about the IPv4 ACL acceleration feature. Display configuration and match statistics for one or all IPv6 ACLs. Clear statistics for one or all IPv4 ACLs. Clear statistics for one or all IPv6 basic and advanced ACLs. display acl { acl-number all name acl-name } [ { begin exclude include } regular-expression ] display acl accelerate { acl-number all } [ { begin exclude include } regular-expression ] display acl ipv6 { acl6-number all name acl6-name } [ { begin exclude include } regular-expression ] reset acl counter { acl-number all name acl-name } reset acl ipv6 counter { acl6-number all name acl6-name } Available in any view Available in any view Available in any view Available in user view Available in user view 20

28 ACL configuration example NOTE: IPv4 ACL application usually works with NAT. For IPv4 ACL configuration examples, see NAT Configuration Guide. Network requirements A company interconnects its departments through Firewall. Configure an ACL to: Permit access from the President's office at any time to the financial database server. Permit access from the Financial department to the database server only during working hours (from 8:00 to 18:00) on working days. Deny access from any other department to the database server. Figure 16 Network diagram Financial database server 1000::100/16 GE0/1 GE0/2 GE0/4 Firewall GE0/3 President s office 1001::/16 Financial department 1002::/16 Marketing department 1003::/16 Configuration procedure # Create a periodic time range from 8:00 to 18:00 on working days. <Firewall> system-view [Firewall] time-range work 8:0 to 18:0 working-day # Create an IPv6 advanced ACL numbered 3000 and configure three rules in the ACL. One rule permits access from the President's office to the financial database server, one rule permits access from the Financial department to the database server during working hours, and one rule denies access from any other department to the database server. [Firewall] acl ipv6 number 3000 [Firewall-acl6-adv-3000] rule permit ipv6 source 1001:: 16 destination 1000:: [Firewall-acl6-adv-3000] rule permit ipv6 source 1002:: 16 destination 1000:: time-range work [Firewall-acl6-adv-3000] rule deny ipv6 source any destination 1000:: [Firewall-acl6-adv-3000] quit # Enable IPv6 firewall, and apply IPv6 ACL 3000 to filter outgoing packets on interface GigabitEthernet 0/1. 21

29 [Firewall] firewall ipv6 enable [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] firewall packet-filter ipv outbound [Firewall-GigabitEthernet0/1] quit Verifying the configuration # Ping the database server from a PC in the Financial department during the working hours. (All PCs in this example use Windows XP). C:\> ping 1000::100 Pinging 1000::100 with 32 bytes of data: Reply from 1000::100: time<1ms Reply from 1000::100: time<1ms Reply from 1000::100: time<1ms Reply from 1000::100: time<1ms Ping statistics for 1000::100: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms The output shows that the database server can be pinged. # Ping the database server from a PC in the Marketing department during the working hours. C:\> ping 1000::100 Pinging 1000::100 with 32 bytes of data: Destination net unreachable. Destination net unreachable. Destination net unreachable. Destination net unreachable. Ping statistics for 1000::100: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), The output shows that hat the database server cannot be pinged. # Display configuration and match statistics for IPv6 ACL 3000 on Firewall during the working hours. [Firewall] display acl ipv Advanced IPv6 ACL 3000, named -none-, 3 rules, ACL's step is 5 rule 0 permit ipv6 source 1001::/16 destination 1000::100/128 rule 5 permit ipv6 source 1002::/16 destination 1000::100/128 time-range work (4 times matched) (Active) rule 10 deny ipv6 destination 1000::100/128 (4 times matched) The output shows that rule 5 is active. Rule 5 and rule 10 have been matched four times as the result of the ping operations. 22

30 Configuring security zones You can configure security zones only in the Web interface. To use an interface as a service interface, you must add it to a security zone that is not the management zone before configuring relevant service functions. Overview Traditional firewall/router policies are configured based on packet inbound and outbound interfaces on early dual-homed firewalls. With the development of firewalls, they can not only connect the internal and external network, but also connect the internal network, external network, and the Demilitarized Zone (DMZ). Also, they are providing high-density ports. A high-end firewall can provide dozens of physical interfaces to connect multiple logical subnets. In this networking environment, traditional interface-based policy configuration mode requires configuration of security policies for each interface, which brings great working loads for administrators, and thus increases probability for introducing security problems because of configurations. Different from the traditional interface-based policy configuration mode, the industry-leading firewalls solve the above problems by configuring security policies based on zones. A zone is an abstract conception, and you can classify zones in two ways: Interface-based. A zone can include physical interfaces and logical interfaces, and also Trunk interface + VLAN. Interfaces added to the same zone have consistent security needs in security policy control. IP-address-based. You can classify zones based on IP addresses to control security policies according to the source IP address or destination IP address of service packets. NOTE: DMZ is originally a military term, which refers to the boundary between two or more military powers, where military activity is not permitted. A DMZ in a network is an area separated with the internal and external networks both logically and physically. Typically, a DMZ contains devices accessible to the Internet, such as Web servers and FTP servers. If a service packet can match a zone either based on interface or on IP address, the zone matched based on the interface is adopted. With the zone concept, security administrators can classify interfaces or IP addresses (assign them to different zones) based on their security needs, thus implementing hierarchical policy management. For example, the administrator can add the four interfaces on a firewall that connect to different subnets in the research area to Zone_RND, and the two interfaces connecting the servers to Zone_DMZ, as shown in the following figure. In this way, the administrator only needs to deploy the security policies between the two zones. If the network changes in the future, the administrator only needs to adjust the interfaces in a certain zone, without modifying the security policies. Therefore, with the concepts of zone, not only the policy maintenance is simplified, but also network services and security services are separated. 23

31 Figure 17 Zone classification Zone configuration task list Task Selecting the virtual device to which the specified zone belongs Creating a zone Configuring a zone member Remarks Optional Select Device Management > Virtual Device > Device Selection from the navigation tree to enter the virtual device selection page. For more information, see System Management and Maintenance Configuration Guide. By default, a virtual root device is used. Optional By default, the following zones are available on the virtual root device: Management, Local, Trust, DMZ and Untrust. Required Add specified subnet address source, interfaces, Layer 2 Ethernet interface + VLAN to the created zone, and the interfaces that can be added and the VLANs must be on the same virtual device with the zone. Creating a zone 1. Select Device Management > Zone from the navigation tree. 24

32 Figure 18 Zone list 2. Click Add. Figure 19 Creating a zone 3. Configure the zone as described in Table Click Apply. Table 7 Configuration items Item Zone ID Zone Name Preference Share Description Set the zone ID. Set the zone name. Set the preference of a zone. By default, packets from a high priority zone to a low priority zone are allowed to pass. Set whether the specified zone can be referenced by other virtual devices. Configuring a zone member 1. Select Device Management > Zone from the navigation tree. 2. Click the icon corresponding to the zone to be modified. 25

33 Figure 20 Modifying a zone 3. Configure the zone as described in Table Click Apply. Table 8 Configuration items Item Zone ID Zone Name Description Display the zone ID. Display the zone name. 26

34 Item Preference Share Virtual Device Interface Interface VLAN Description Set the preference of the specified zone By default, packets from a high priority zone to a low priority zone are allowed to pass. Set whether the specified zone can be referenced by other virtual devices. Display the virtual device to which the zone belongs. Set the interfaces to be added to the zone. The interfaces that have been added to a zone are in the selected status, and the interfaces that can be added but have not been added to a zone are in the non-selected status. If the interfaces added to the zone are Layer 2 Ethernet interfaces, you must specify the range of the VLANs to be added to the zone. The VLANs must belong to the virtual device to which the zone belongs and have not been added to other zones. Zone configuration example Network requirements A company uses Firewall as the network border firewall device to connect the internal network and the Internet and to provide WWW and FTP services to the external network. You need to perform some basic configurations for the zones of the firewall to prepare for the configurations of the security policies. The internal network is a trust network and can access the server and the external network. You can deploy the internal network in the Trust zone with a higher priority and connect the interface GigabitEthernet 0/1 on Firewall to the external network. The external network is an untrusted network, and you need to use strict security rules to control access from the external network to the internal network and the server. You can deploy the external network in the Untrust zone with a lower priority and connect the interface GigabitEthernet 0/3 on Firewall to the external network. If you deploy the WWW server and the FTP server on the external network, security cannot be ensured; if you deploy them on the internal network, the external illegal users may use the security holes to attack the internal network. Therefore, you can deploy the servers in the DMZ zone with a priority between Trust and Untrust, and connect the Ethernet interface GigabitEthernet 0/2 on Firewall to the servers. In this way, the server in the DMZ zone can access the external network in the Untrust zone with a lower priority, but when it accesses the internal network in the Trust zone with a higher priority, its access is controlled by the security rules. 27

35 Figure 21 Network diagram GE 0 /1 Firewall GE 0/3 Internet Trust GE 0/2 Untrust DMZ FTP server WWW server Configuration consideration By default, the system has created the Trust, DMZ and Untrust zones, and you only need to configure them and deploy them. Configuration procedure 1. Configure the Trust zone, and add interface GigabitEthernet 0/1 to the Trust zone: a. Select Device Management > Zone from the navigation tree. b. Click the icon of the Trust zone. 28

36 Figure 22 Configuring the Trust zone c. Select the GigabitEthernet 0/1 box. d. Click Apply. 2. Configure the DMZ zone, and add interface GigabitEthernet 0/2 to the DMZ zone: a. Click Back to return to the page for displaying zones. b. Click the icon of the DMZ zone. 29

37 Figure 23 Configuring the DMZ zone c. Select GigabitEthernet 0/2. d. Click Apply. 3. Configure the Untrust zone and add interface GigabitEthernet 0/3 to the Untrust zone. a. Click Back to return to the page for displaying zones. b. Click the icon of the Untrust zone to perform the following configurations. 30

38 Figure 24 Configuring the Untrust zone c. Select GigabitEthernet 0/3. d. Click Apply. 31

39 Configuring service management NOTE: The interzone policy configuration is available only in the web interface. Overview FTP service Telnet service SSH service SFTP service HTTP service HTTPS service The service management module provides six types of services: FTP, Telnet, SSH, SFTP, HTTP and HTTPS. You can enable or disable the services as needed. In this way, the performance and security of the system can be enhanced, thus secure management of the device can be achieved. The service management module also provides the function to modify HTTP and HTTPS port numbers, and the function to associate the FTP, HTTP, or HTTPS service with an ACL, thus reducing attacks of illegal users on these services. The File Transfer Protocol (FTP) is an application layer protocol for sharing files between server and client over a TCP/IP network. The Telnet protocol is an application layer protocol that provides remote login and virtual terminal functions on the network. Secure Shell (SSH) offers an approach to securely logging in to a remote device. By encryption and strong authentication, it protects devices against attacks such as IP spoofing and plain text password interception. The secure file transfer protocol (SFTP) is a new feature in SSH2.0. SFTP uses the SSH connection to provide secure data transfer. The device can serve as the SFTP server, allowing a remote user to log in to the SFTP server for secure file management and transfer. The device can also serve as an SFTP client, enabling a user to login from the device to a remote device for secure file transfer. The Hypertext Transfer Protocol (HTTP) is used for transferring web page information across the Internet. It is an application-layer protocol in the TCP/IP protocol suite. You can log in to the device using the HTTP protocol with HTTP service enabled, accessing and controlling the device with web-based network management. The Secure HTTP (HTTPS) refers to the HTTP protocol that supports the Security Socket Layer (SSL) protocol. The SSL protocol of HTTPS enhances the security in the following ways: 32

40 Encrypts the data exchanged between the HTTPS client and the device to ensure data security and integrity, thus realizing the security management of the device; Uses digital certificates to verify servers to prevent clients from accessing unauthorized servers, thus protecting significant information such as administrator account information. Configuring service management 1. Select Device Management > Service Management from the navigation tree. The service management configuration page appears. Figure 25 Service management 2. Configure service management as described in Table Click Apply. Table 9 Configuration items Item FTP Telnet SSH SFTP HTTP Enable FTP service ACL Enable Telnet service Enable SSH service Enable SFTP service Enable HTTP service Description Specify whether to enable the FTP service. The FTP service is disabled by default. Associate the FTP service with an ACL. Only the clients that pass the ACL filtering are permitted to use the FTP service. You can view this configuration item by clicking the expanding button in front of FTP. Specify whether to enable the Telnet service. The Telnet service is disabled by default. Specify whether to enable the SSH service. The SSH service is disabled by default. Specify whether to enable the SFTP service. The SFTP service is disabled by default. IMPORTANT: When you enable the SFTP service, the SSH service must be enabled. Specify whether to enable the HTTP service. The HTTP service is disabled by default. 33

41 Item HTTPS Port Number ACL Enable HTTPS service Port Number ACL Certificate Description Set the port number for HTTP service. You can view this configuration item by clicking the expanding button in front of HTTP. IMPORTANT: When you modify a port, make sure that the port is not used by other service. Associate the HTTP service with an ACL. Only the clients that pass the ACL filtering are permitted to use the HTTP service. You can view this configuration item by clicking the expanding button in front of HTTP. Specify whether to enable the HTTPS service. The HTTPS service is disabled by default. Set the port number for HTTPS service. You can view this configuration item by clicking the expanding button in front of HTTPS. IMPORTANT: When you modify a port, make sure that the port is not used by other service. Associate the HTTPS service with an ACL. Only the clients that pass the ACL filtering are permitted to use the HTTPS service. You can view this configuration item by clicking the expanding button in front of HTTPS. Set the local certificate for the HTTPS service. The list displays certificate subjects. You can configure the available PKI domains by selecting VPN > Certificate Management from the navigation tree at the left side of the interface. For more information, see VPN Configuration Guide. Service management configuration examples HTTP configuration example Network requirements As shown in Figure 26, Host A resides on /24 and connects to Firewall through GigabitEthernet 0/1. Host A can always access Firewall using HTTP, but other hosts can access Firewall using HTTP only on working days. 34

42 Figure 26 Network diagram Configuring the time range 1. Select Resource > Time Range from the navigation tree. 2. Click Add. The page for adding time range appears. Figure 27 Create a time range 3. Create a time range as shown in Figure 27. a. Enter time in the Name field. b. Select the Periodic Time Range box. c. Select the Sun. and Sat. checkboxes. 4. Click Apply. Creating a basic ACL. 1. Select Firewall > ACL from the navigation tree. 2. Click Add. The page for adding ACL appears. 35

43 Figure 28 Creating an ACL 3. Create ACL 2000 as shown in Figure 28. a. Enter the ACL number b. Select the match order Config. c. Click Apply. Creating a rule to allow Host A to access Firewall 1. Click the icon of ACL 2000 from the ACL list in the Operation column. 2. Click Add. The ACL rule configuration page appears. Figure 29 Configure a rule to allow Host A to access Firewall 3. Create an ACL rule as shown in Figure 29. a. Select Permit from the Operation box. b. Select the Source IP Address box. c. Enter in the Source IP Address field. d. Enter in the Source Wildcard field. 4. Click Apply. Creating a rule to disable other hosts from accessing Firewall on Saturday and Sunday 1. Click Add on the page which displays the rules of ACL Create an ACL rule as shown in Figure

44 a. Select Deny as the operation. b. Select time as the time range. c. Select Source IP Address box. d. Enter in the Source IP Address field. e. Enter in the Source Wildcard field. 3. Click Apply. Sunday Figure 30 Configuring an ACL rule to disable other hosts from accessing Firewall on Saturday and Configuring an ACL rule to allow other hosts to access Firewall 1. Click Add on the page displaying rules of ACL Select Permit as the operation. 3. Click Apply. Figure 31 Configuring an ACL rule to allow other hosts to access Firewall NOTE: The three ACL rules must be configured in the shown order. Associating HTTP service with ACL Select Device Management > Service Management from the navigation tree. 2. Associate HTTP service with ACL 2000 as shown in Figure 32. a. Click the expansion triangle sign before HTTP to expand the configuration area. 37

45 b. Enter 2000 in the ACL field. 3. Click Apply. Figure 32 Associating HTTP service with ACL 2000 HTTPS configuration example Network requirements As shown in Figure 33, Host can access and control Firewall through web pages. To avoid malicious users from accessing and controlling Firewall, users use HTTPS to access web pages on Firewall. SSL is used to authenticate servers, preventing data eavesdropping and data modification. To meet the requirements, configure Firewall as an HTTPS server and apply for a certificate for Firewall. The name of the certificate authority (CA) that issues certificates to Firewall and Host is CA server. NOTE: This example uses a Windows server as the CA that has the Simple Certificate Enrollment Protocol (SCEP) component installed. Before proceeding with the following configuration, make sure that Firewall, Host, and CA are reachable to each other. Figure 33 Network diagram 38

46 Configuring a PKI entity 1. Select VPN > Certificate Management > Entity from the navigation tree. 2. Click Add. The page for adding a PKI entity appears. Figure 34 Adding a PKI entity 3. Configure a PKI entity as shown in Figure 34. a. Enter en as the PKI entity name. b. Enter http-server1 as the common name. c. Enter ssl.security.com in the FQDN field. 4. Click Apply. Creating a PKI domain 1. Select VPN > Certificate Management > Domain from the navigation tree. 2. Click Add. The page for adding a PKI domain appears. 39

47 Figure 35 Add a PKI domain 3. Add a PKI domain as shown in Figure 35. a. Enter 1 as the PKI domain name. b. Enter CA server as the CA identifier. c. Select en as the local entity. d. Select RA as the authority for certificate request. e. Enter as the URL for certificate request. 4. Click Apply. 5. Click OK when the system displays "Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?" Generating an RSA key pair 1. Select VPN > Certificate Management > Certificate from the navigation tree. 2. Click Create Key. The page for generating the RSA key pair appears. 3. Enter 1024 in the Key Length field. 4. Click Apply. Figure 36 Generating an RSA key pair Retrieving the CA certificate 1. Select VPN > Certificate Management > Certificate from the navigation tree. 40

48 2. Click Retrieve Cert. The page for retrieving a certificate appears. 3. Retrieve the CA certificate as shown in Figure 37. a. Select 1 as the PKI domain. b. Select CA as the certificate type. 4. Click Apply. Figure 37 Retrieving the certificate Requesting a local certificate 1. Select VPN > Certificate Management > Certificate from the navigation tree. 2. Click Request Cert. The page for requesting a certificate appears. Figure 38 Requesting a certificate 3. Select 1 as the PKI domain name. 4. Click Apply. 5. Click OK when the system displays "Certificate request has been submitted". Enabling HTTPS service and associating HTTPS service with PKI domain Select Device Management > Service Management from the navigation tree. The service management configuration page appears. 41

49 Figure 39 Enabling HTTPS service 2. Select the Enable HTTPS service box. 3. Select CN=http-server1 from the certificate list. 4. Click Apply. Adding a local user 1. Select User > Local user from the navigation tree. 2. Click Add. The page for adding a local user appears. Figure 40 Adding a local user 3. Configure the local user as shown in Figure 40. a. Enter usera in the User Name field. b. Select the user privilege level Configure. c. Specify the service type as Web. d. Enter password 123 in Password and Confirm Password fields. 4. Click Apply. 42

50 Verifying the configuration Open an Internet browser on Host and enter in the address bar to enter the web login interface. Enter the username usera, password 123, and verification code, and then click Log in. You can access Firewall. 43

51 Configuring address resources NOTE: The address resource configuration is available only in the web interface. Address resource overview Address resources are classified into four categories: IP address resource, IP address group resource, MAC address resource, and MAC address group resource. They can be referenced by interzone policies to define packet match criteria. An IP address resource is a collection of domain names or IP address resources and falls into three types: Host address resource A domain name, or one or more individual IP addresses. Address range resource A range of IP addresses defined by a start IP address and an end IP address. Some individual addresses, if necessary, can be excluded from the range. Subnet address resource A subnet IP address defined by an IP address and a wildcard. Some individual addresses, if necessary, can be excluded from the range. An IP address group resource is a collection of host address resources, address range resources, and subnet address resources. An MAC address resource is a collection of MAC addresses. An MAC address group sources is a collection of MAC address resources. Configuring an address resource Configuring a host address resource Select Resource > Address > IP Address from the navigation tree to enter the host address resource list page, as shown in Figure 41. Then, click Add to enter the host address resource configuration page, as shown in Figure 42. Figure 41 Host address resource list 44

52 Figure 42 Host address resource configuration page Table 10 Configuration items Item IP Address Domain Name Description Select either of them as the address resource form. Specify the name for the host address resource. Name IMPORTANT: All resources (excluding the time range resources) must have unique names. Description IP Address Describe the host address resource in brief. Specify the IP addresses for the host address resource. Enter an IP address in the text box next to the Add button, and then click Add to add it to the IP list. Select one or more IP addresses in the IP list, and then click Remove to remove them from the list. This item is available after you select IP Address as the address resource form. Domain Name Specify the domain name for the host address resource. This item is available after you select Domain Name as the address resource form. Configuring an address range resource Select Resource > Address > IP Address from the navigation tree, and then click the Range tab to enter the address range resource list page, as shown in Figure 43. Then, click Add to enter the address range resource configuration page, as shown in Figure

53 Figure 43 Address range resource list Figure 44 Address range resource configuration page Table 11 Configuration items Item Description Specify the name for the address range resource. Name IMPORTANT: All resources (excluding the time range resources) must have unique names. Description Address Range Exclude IP Address Describe the address range resource in brief. Specify a start IP address and an end IP address to define an address range. Specify the IP addresses to be excluded. Type an IP address in the text box next to the Add button, and then click Add to add it to the excluded IP address list. Select one or more IP addresses in the excluded IP address list, and then click Remove to remove them from the list. 46

54 Configuring a subnet address resource Select Resource > Address > IP Address from the navigation tree, and click the Subnet tab to enter the subnet address resource list page, as shown in Figure 45. Then, click Add to enter the subnet address resource configuration page, as shown in Figure 46. Figure 45 Subnet address resource list Figure 46 Subnet address resource configuration page Table 12 Configuration items Item Name Description IP/Wildcard Description Specify the name for the subnet address resource. IMPORTANT: All resources (excluding the time range resources) must have unique names. Describe the subnet address resource in brief. Specify an IP address and a wildcard to define an address range. 47

55 Item Exclude IP Address Description Specify the IP addresses to be excluded. Type an IP address in the text box next to the Add button, and then click Add to add it to the excluded IP address list. Select one or more IP addresses in the excluded IP address list, and then click Remove to remove them from the list. Configuring an IP address group resource Select Resource > Address > Address Group from the navigation tree to enter the IP address group display page, as shown in Figure 47. Then, click Add to enter the IP address group resource configuration page, as shown in Figure 48. Figure 47 IP address group resource list Figure 48 IP address group resource configuration page 48

56 Table 13 Configuration items Item Description Specify the name for the address group resource. Name Description Group Members IMPORTANT: All resources (excluding the time range resources) must have unique names. Describe the address group resource in brief. Add or remove IP address resources: Select one or more IP address resources from the Available Group Members list and then click the << button to add them to the Group Members list. Select one or more IP address resources from the Group Members list and then click the >> button to remove them from the Group Members list. The Available Group Members list contains all the host resources, address range resources, and subnet address resources that have been configured. Configuring a MAC address resource Select Resource > Address > MAC Address from the navigation tree to enter the MAC address list page, as shown in Figure 49. Then, click Add to enter the MAC address resource configuration page, as shown in Figure 50. Figure 49 MAC address resource list Figure 50 MAC address resource configuration page 49

57 Table 14 Configuration items Item Description Specify the name for the MAC address resource. Name Description MAC Address IMPORTANT: All resources (excluding the time range resources) must have unique names. Describe the MAC address resource in brief. Add or remove MAC address resources: Type a MAC address in the text box next to the Add button, and then click Add to add it to the MAC List. Select one or more MAC addresses in the MAC list, and then click Remove to remove them from the list. Configuring a MAC address group resource NOTE: Configure MAC address resources before configuring MAC address group resources. Select Resource > Address > Address Group from the navigation tree to enter the IP address group page and then select the MAC Address Group tab to enter the MAC address group list page, as shown in Figure 51. Click Add to enter the MAC address group configuration page, as shown in Figure 52. Figure 51 MAC address group list 50

58 Figure 52 MAC address group configuration page Table 15 Configuration items Item Description Specify the name for the MAC address group resource. Name IMPORTANT: All resources (excluding the time range resources) must have unique names. Description Group Members Describe the MAC address group resource in brief. Add or remove MAC address group resources: Select one or more MAC address resources from the Available Group Members list and then click << to add them to the Group Members list. Select one or more MAC address resources from the Group Members list and then click >> to remove them from the Group Members list. The Available Group Members list contains all the MAC address resources, and MAC address group resources that have been configured. Exporting and importing configuration The Web interface allows you to export and import the configurations of IP address resources, IP address group resources, MAC address resources, MAC address group resources, service resources, and interzone policies to and from specified files, facilitating your operation. The default service resources are not involved. NOTE: For more information, see "Configuring service resources" and "Configuring interzone policies." Exporting configuration On any of the resource list page, click Export to bring up the dialog box as shown in Figure 53. Choose the types of configurations you want to export by selecting the boxes and then click Apply. On the pop-up dialog box, click Save. Then, set the path and name of the file for saving the configurations on the local host, and click Save to export and save the selected configurations to the file. 51

59 Figure 53 Export configurations Importing resource configurations On any of the resource list page, click Import to bring up the dialog box as shown in Figure 54. Click Browse, and then choose the configuration file and click Apply to import all configurations in the file. Figure 54 Import configurations 52

60 Configuring service resources NOTE: The service resource configuration is available only in the web interface. Overview A service resource defines a service by specifying the protocol to be carried by IP and the protocol-specific items. It may be referenced by an inter-zone policy as a packet match criterion. Service resources fall into the following categories: Default service resources Created by the device during initialization. Customized service resource Created manually. Service group resource A collection of default service resources and customized service resources. Configuring a service resource Displaying default service resources Select Resource > Service > Default Service from the navigation tree. All existing default service resources are displayed, as shown in Figure

61 Figure 55 Default service resource list Configuring a customized service resource 1. Select Resource > Service > Customized Service from the navigation tree. All existing customized service resources are displayed. Figure 56 Customized service resource list 2. Click Add. The customized service resource configuration page appears. 54

62 Figure 57 Customized service resource configuration page 3. Configure the parameters as described in Table Click Apply. Table 16 Configuration items Item Description Specify a unique name for the customized service resource. Name Description TCP UDP ICMP Other Protocol Source Port Destination Port Source Port Destination Port Type Code Protocol Number IMPORTANT: Service and address resource names must be unique. Type a description for the customized service resource. Set the source and destination TCP port ranges in the fields. These fields are available after you select TCP. To define a single port, type the same port numbers in the two fields in a row. To define a port range, type two different port numbers. Make sure the second port number is greater than the first one. Set the source and destination UDP port ranges in the fields. These fields are available after you select UDP. To define a single port, type the same port numbers in the two fields in a row. To define a port range, type two different port numbers. Make sure the second port number is greater than the first one. Specify the ICMP message type and code. These items are available after you select ICMP. Table 17 lists the ICMP message names and their message types and codes. Specify the protocol to be carried by IP. This item is available after you select Other Protocol and cannot be set to 1 (for ICMP), 6 (for TCP), or 17 (UDP). 55

63 Table 17 ICMP message names and their message types and codes ICMP message name Type Code echo 8 0 echo-reply 0 0 fragmentneed-dfset 3 4 host-redirect 5 1 host-tos-redirect 5 3 host-unreachable 3 1 information-reply 16 0 information-request 15 0 net-redirect 5 0 net-tos-redirect 5 2 net-unreachable 3 0 parameter-problem 12 0 port-unreachable 3 3 protocol-unreachable 3 2 reassembly-timeout 11 1 source-quench 4 0 source-route-failed 3 5 timestamp-reply 14 0 timestamp-request 13 0 ttl-exceeded 11 0 Configuring a service group resource 1. Select Resource > Service > Service Group from the navigation tree. All existing service group resources are displayed. Figure 58 Service group resource list 2. Click Add. The service group resource configuration page appears. 56

64 Figure 59 Service group resource configuration page 3. Configure the parameters as described in Table Click Apply. Table 18 Configuration items Item Description Specify a unique name for the service group resource. Name Description Group Members IMPORTANT: Service and address resource names must be unique. Type a description for the service group resource. Add or remove service resources: Select one or more service resources from the Available Group Members list and then click << to add them to the Group Members list. Select one or more service resource from the Group Members list and then click >> to remove them from the Group Members list. The Available Group Members list contains all default and customized service resources that have been configured. Exporting and importing configuration The Web interface allows you to export and import the configurations of IP address resources, IP address group resources, MAC address resources, MAC address group resources, service resources, and inter-zone policies to and from specified files, facilitating your operation. The default service resources are not involved. 57

65 NOTE: For more information, see "Configuring address resources" and "Configuring interzone policies." Exporting configuration 1. On the customized or service group resource list page, click Export. The page for exporting configurations appears as shown in Figure Choose the types of configurations you want to export by selecting the boxes and then click Apply. 3. On the pop-up dialog box, click Save. 4. Set the path and name of the file for saving the configurations on the local host, and click Save to export and save the selected configuration to the file. Figure 60 Exporting configurations Importing configurations 1. On the customized or service group resource list page, click Import. The page for importing configurations appears as shown in Figure Click Browse, and then choose the configuration file. 3. Click Apply to import all configurations in the file. Figure 61 Import configurations 58

66 Configuring time range resources Overview A time range resource defines a time range, which can be referenced by an ACL or an interzone policy to control when a rule is effective. The following basic types of time range are available: Periodic time range Recurs periodically on a day or days of the week. Absolute time range Represents only a period of time and does not recur. You can create a maximum of 256 time ranges, each with a maximum of 32 periodic statements and 12 absolute statements. The active period of a time range is calculated as follows: 1. Combining all periodic statements 2. Combining all absolute statements 3. Taking the intersection of the two statement sets as the active period of the time range Configuring a time range resource in the Web interface Select Resource > Time Range from the navigation tree to enter a time range list page, as shown in Figure 62. Click Add to enter the time range resource configuration page. Figure 62 Time range list 59

67 Figure 63 Time range resource configuration page Table 19 Configuration items Item Name Description Enter the name for the time range resource. Periodic Time Range Absolute Time Range Start Time End Time Sun., Mon., Tues., Wed., Thurs., Fri., and Sat. From To Set the start time of the periodic time range, in the hh:mm format (24-hour clock). Set the end time of the periodic time range, in the hh:mm format (24-hour clock). The end time must be greater than the start time. Select the day or days of the week on which the periodic time range is valid. Set the start time of the absolute time range. The time of the day is in the hh:mm format (24-hour clock), and the date is in the MM/DD/YYYY format. Set the end time of the absolute time range. The time of the day is in the hh:mm format (24-hour clock), and the date is in the MM/DD/YYYY format. The end time must be greater than the start time. Configuring a time range at the CLI To configure a time range: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure a time range. time-range time-range-name { start-time to end-time days [ from time1 date1 ] [ to time2 date2 ] from time1 date1 [ to time2 date2 ] to time2 date2 } By default, no time range exists. Repeat this command with the same time range name to create multiple statements for a time range. 60

68 Step Command Remarks 3. Display the configuration and status of one or all time ranges. display time-range { time-range-name all } [ { begin exclude include } regular-expression ] Optional. Available in any view. Configuration guidelines If the selected time range resource includes the current time, the time range is displayed as "Active" in the time range resource list. Otherwise, the time range is displayed as "Inactive". 61

69 Interzone policy configuration NOTE: The interzone policy configuration is available only in the web interface. Interzone policy overview Interzone policies, based on ACLs, are used for identification of traffic between zones. An interzone policy references one ACL for a pair of source zone and destination zone. This ACL contains a group of ACL rules, each of which permits or denies packets matching the match criteria. Follow either of the following methods to configure an interzone policy: Method 1: Configure an interzone policy rule directly by referencing an address resource, a service resource, a time range resource, and a content filtering policy template, and configuring a filtering action. Packets are then filtered based on match criteria. The match criteria may include source IP address, destination IP address, source MAC address, destination MAC address, protocol type, protocol features (such as TCP/UDP source or destination port, ICMP message type, and ICMP message code), time range, and content in HTTP/SMTP messages. Rules for a pair of source zone and destination zone are listed in match order on the web page. A rule listed earlier has a higher priority, and is matched earlier. The rules are in the order they are created, and you can manually adjust the order. Method 2: Configure an interzone policy group by referencing advanced ACLs. Packets are then filtered based on match criteria. The match criteria may include source IP address, destination IP address, source port, destination port, and protocol type. ACLs for a pair of source zone and destination zone are listed in match order on the web page. An ACL listed earlier has a higher priority, and is matched earlier. The ACLs are in the order they are selected for the group, and you can manually adjust the order. NOTE: In method 1, the number of an ACL referenced in an interzone policy is assigned automatically by the system. When you create the first rule for two zones, the system will automatically create an ACL for interzone policy, and assign it an ACL number that is one more than the last assigned ACL number, starting from If you remove all rules of the interzone policy, the system will automatically remove the ACL. For a pair of source zone and destination zone, follow the same method to configure an interzone policy. Interzone policies support the ACL acceleration feature, improving the forwarding performance and connection setup performance of the device. ACL acceleration speeds up ACL lookup, and the acceleration effect increases with the number of ACL rules. 62

70 Configuring an interzone policy Configuration task list NOTE: Before configuring an Interzone policy, be sure to configure the zones. For information about zone configuration, see "Zone configuration." Table 20 Interzone policy configuration task list Task Remarks Required Configuring an interzone policy rule Use either method. By default, no interzone policy rules or interzone policy groups are present in the system. IMPORTANT: Before configuring an interzone policy group, configure advanced ACLs by selecting Firewall > ACL. Configuring an interzone policy group For a pair of source zone and destination zone, follow the same method to configure an interzone policy. Up to one interzone policy group can be configured for one pair of source zone and destination zone. Displaying packet statistics of an interzone policy Optional Display the packet statistics of an interzone policy for a pair of source and destination zones. Optional Querying policies by IP address Query interzone policies by source or destination IP address. NOTE: Interzone policy groups do not support query by IP address. Configuring an interzone policy rule Creating an interzone policy rule Select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the interzone policy rule list page, as shown in Figure 64. Then click Add to enter the interzone policy rule (that is the ACL rule) configuration page, as shown in Figure

71 Figure 64 List of interzone policy rule list Table 21 Operations you can perform on the list Field Source Address/Destination Address/Source MAC/Destination MAC Service Content Filtering Policy Template Status Log in the Operation column Operation Click an address (except any_address and any_mac) to enter the address resource configuration page, where you can view and modify the address resource configuration. For information about address resources, see "Address resource configuration." Click a service name (except any_service) to enter the service configuration page, where you can view and modify the service configuration. For information about service resources, see "Service resource configuration." Click a template name to enter the content filtering policy template configuration page, where you can view and modify the template configuration. For information about content filtering template, see Attack Protection Configuration Guide. shows that the interzone policy rule is enabled. You can click Disable to disable the interzone policy rule. shows that the interzone policy rule is disabled. You can click Enable to enable the interzone policy rule. shows that logging is enabled for the interzone policy rule. You can click Disable to disable the logging function. shows that logging is disabled for the interzone policy rule. You can click Enable to enable the logging function. Click the icon of an interzone policy rule to view the logs for traffic that matches the interzone policy rule. For information about interzone policy logs, see System Management and Maintenance Configuration Guide. 64

72 Figure 65 Interzone policy rule configuration page Table 22 Configuration items Item Source Zone Dest Zone Description Source IP Address Description Specify the source zone for the interzone policy. Specify the destination zone for the interzone policy. Describe the ACL rule in brief. Configure a source address resource for the rule by creating an address resource or referencing an existing address resource. If you select the New IP Address option, you need to specify an IP address and wildcard. After you apply the configuration, the system will automatically create a subnet address resource. For example, if you enter / , a subnet address resource is created with the resource name being / If you select the Source IP Address option, you can select an existing address resource from the list or click Multiple to select more. The available address resources are configured in the page brought up by selecting Resource > Address. For more information, see "Address resource configuration." Destination IP Address Configure a destination address resource for the rule by creating an address resource or referencing an existing address resource. If you select the New IP Address option, you need to specify an IP address and wildcard. After you apply the configuration, the system will automatically create a subnet address resource. For example, if you enter / , a subnet address resource is created with the resource name being / If you select the Destination IP Address option, you can select an existing address resource from the list or click Multiple to select more. The available address resources are configured in the page brought up by selecting Resource > Address. For more information, see "Address resource configuration." 65

73 Item Service Filter Action Time Range Content Filtering Policy Template Using MAC Address Source MAC Address Destination MAC Address Enable Syslog Enable the rule Description Select a service resource for the rule. You can select one service resource from the list or click Multiple to select more. The available service resources are configured in the page you enter by selecting Resource > Service. For more information, see "Service resource configuration." Select the operation to be performed for packets matching the rule. Permit: Allows packets matching the rule to pass. Deny: Drops packets matching the rule. Select a time range resource for the rule. Available time range resources are those that have been configured. For more information about time range resource configuration, see "Time range resource configuration." IMPORTANT: If the selected time range resource includes the current time, the time range is displayed as "Active" in the list of interzone policy rules. Otherwise, the time range is displayed as "Inactive". Select a policy template for content filtering. The available policy templates are configured on the page brought up by selecting Identification > Content Filtering > Policy Template and then clicking Add. For more information, see Attack Protection Configuration Guide. Specify whether to enable MAC address filtering. With this box selected, the source and destination MAC address can be configured. Specify the source and destination MAC addresses. Type a new MAC address in the field. The new MAC address will be a MAC address resource after you apply your configuration and the MAC address name is the MAC address. You can also select from the MAC address (group) resource list or click Multiple to select more MAC addresses (groups). Available MAC address (group) resources are configured on the page you enter by selecting Resource > Address. For more information, see "Address resource configuration." Select this box to enable logging for packets matching the rule. You can view the interzone policy logs by selecting Log Report > Report > Interzone Policy Log, or click the icon of an interzone policy rule in Figure 64 to view logs for traffic that matches this interzone policy rule. IMPORTANT: To log content filtering events, enable the logging function for the interzone policy and the referenced content filtering policy. Select this box to enable the rule. 66

74 Item Continue to add next rule Description Specify whether to create another rule after finishing this one. If you select this box, you will enter the interzone policy rule configuration page after clicking Apply, with the source zone and destination zone selected for the last rule. If you do not select this box, you will see the list of interzone policy rule after clicking Apply. Inserting an interzone policy rule IMPORTANT: If you enter the rule configuration page by clicking the insert or replicate icon, you cannot continue to insert or replicate new rules by selecting this box. Select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the interzone policy rule list page, as shown in Figure 64. Click the icon of a rule to enter the page for configuring an interzone policy rule. The new rule takes the source zone and destination zone of the existing one as its default source zone and destination zone. The newly created rule will be inserted before the existing rule for the same zone pair. For more information about the configuration items, see Table 22. Replicating an interzone policy rule Select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the interzone policy rule list page, as shown in Figure 64. Click the icon of a rule to enter the page for creating an interzone policy rule based on the existing one. The new rule takes the settings of the existing one as its default settings. You can make changes as desired. For more information about the configuration items, see Table 22. Changing the priority of a rule Select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the interzone policy rule list page, as shown in Figure 64. Click the icon of a rule to bring up the dialog box as shown in Figure 66. You may change the priorities (match order) of the rules for a pair of source zone and destination zone as required. This operation adjusts the order of the rules in the list. Figure 66 Modify the priority of a rule Type the ID of the target rule in the field to place the rule to which the icon corresponds before the target rule. If you type 65535, the rule is placed at the end of all the rules. If the target ID you type does not exist, the rule is placed before the rule whose ID is the least one greater than the target ID. 67

75 Exporting and importing configuration Select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the interzone policy rule list page, as shown in Figure 64. Click Export to bring up the dialog box as shown in Figure 67. Select the types of configurations you want to export by selecting the boxes, and then click Apply. On the pop-up dialog box, click Save. Then set the path and name of the file for saving the configurations on the local host, and click Save to export the selected configurations to the file. Figure 67 Export configurations Click Import to bring up the dialog box as shown in Figure 68. Click Browse, and then select the configuration file and click Apply to import all configurations in the file. Figure 68 Import configurations Configuring an interzone policy group Select Firewall > Security Policy > Interzone Policy Group from the navigation tree to enter the interzone policy group list page, as shown in Figure 69. Then click Add to enter the interzone policy group configuration page, as shown in Figure 70. Figure 69 Interzone policy group list 68

76 Table 23 Operations you can perform on the list Field Referenced ACLs Status Operation Click an ACL to enter the ACL configuration page, where you can view, create, and delete rules in the ACL. For information about ACL configuration, see "ACL configuration." shows that the interzone policy group is enabled. You can click Disable to disable the interzone policy group. shows that the interzone policy group is disabled. You can click Enable to enable the interzone policy group. Figure 70 Interzone policy group configuration page Table 24 Configuration items Item Source Zone Dest Zone Selected ACLs Enable Description Specify the source zone for the interzone policy group. Specify the destination zone for the interzone policy group. Select the ACLs to be referenced by the interzone policy group. The selected ACLs are listed in the order they are selected, which is also the match order. An ACL listed earlier has a higher priority, and is matched earlier. IMPORTANT: For any ACL referenced by an interzone policy group, only the five tuples (source IP address, destination IP address, source port, destination port, and protocol type) are used. Select this box to enable interzone policy group settings. Displaying packet statistics of an interzone policy Select Firewall > Security Policy > Policy Matching Statistics from the navigation tree to enter the page as shown in Figure 71. Select the source and target zone, and then click Search. The page displays the 69

77 results matching the search conditions. Click Reset in the Operation column to clear the packets statistics of the related interzone policy and at this time the system starts to perform statistics again. Figure 71 Statistics of an interzone policy Table 25 Field description Item Permitted Packets Denied Packets Start Time End Time Description Number of packets that match the interzone policy and are forwarded during the statistics time Number of packets that match the interzone policy and are dropped during the statistics time Start time of the statistics. End time of the statistics. Querying policies by IP address Select Firewall > Security Policy > Policy Inverse Query from the navigation tree to enter the page as shown in Figure 72. Type the IP address in the field, select whether you want to query by source or destination IP address from the list, and then click Search. The page displays the policies with the source or destination IP address. Figure 72 Query policies by IP address TIP: Clicking the Configure Interzone Policy link goes to the interzone policy rule list page. You can also select Firewall > Security Policy > Interzone Policy from the navigation tree to enter the page. Interzone policy configuration examples Network requirements As shown in Figure 73, Firewall connects the corporate network to the Internet. The corporate network belongs to zone Trust, and the external network belongs to zone Untrust. Configure an interzone policy, allowing internal host Public to access the external network at any time and denying all the other internal hosts' access to the external network during working hours (from 8:00 to 18:00) on working days (from Monday through Friday). 70

78 Figure 73 Network diagram Method 1: Configuring an interzone policy rule # Create a periodic time range from 8:00 to 18:00 on working days (from Monday through Friday). Select Resource > Time Range from the navigation tree, and then click Add. Figure 74 Configure a time range Type worktime in the Name field. Select the Periodic Time Range box. Set the start time to 8:00. Set the end time to 18:00. Select the Mon., Tues., Wed., Thurs., and Fri., boxes. Click Apply. # Create an IP address resource. Select Resource > Address > IP Address from the navigation tree, and then click Add. 71

79 Figure 75 Configure an IP address resource Select the IP Address option. Type public as the name. Type as the IP address. Then click Add to add this address to the IP list. Click Apply. # Configure an access rule for host public to access the external network at any time. Select Firewall > Security Policy > Interzone Policy from the navigation tree, and then click Add. Figure 76 Allow the host public to access the external network at any time 72

80 Select Trust as the source zone and Untrust as the destination zone. Select public as the address. Select Permit as the filter action. Select the Status box. Select the Continue to add next rule box. Click Apply. # Configure an access rule to deny the access of all the other hosts to the external network during working time. After the last configuration step, you will enter the interzone policy rule configuration page, with the source and destination zone selected for the last rule. Figure 77 Deny all the other hosts' access to the external network during working time Select Deny as the filter action. Select worktime as the time range. Select the Status box. Click Apply. Method 2: Configuring an interzone policy group # Create a periodic time range from 8:00 to 18:00 on working days (from Monday through Friday). Select Resource > Time Range from the navigation tree, and then click Add. 73

81 Figure 78 Configure a time range Type worktime in the Name field. Select the Periodic Time Range box. Set the start time to 8:00. Set the end time to 18:00. Select the Mon., Tues., Wed., Thurs., and Fri., boxes. Click Apply. # Create ACL Select Firewall > ACL from the navigation tree, and then click Add. Figure 79 Configure ACL 3000 Type 3000 in the ACL Number field. Select Config as the match order. Click Apply. # Configure a rule for ACL 3000, allowing host public to access the external network at any time. Click the icon of ACL 3000 to enter the page that lists the ACL rules. Click Add to enter the page for configuring a rule for ACL

82 Figure 80 Allow the host Public to access the external network at any time Select Permit as the operation. Select the Source IP Address box, and type and in the following fields. Click Apply. # Configure a rule to deny access of all the other hosts to the external network during working time. On the page that lists the rules, click Add. 75

83 Figure 81 Deny all the other hosts' access to the external network during working time Select Deny as the operation. Select the time range worktime. Click Apply. # Configure the interzone policy group. Select Firewall > Security Policy > Interzone Policy Group from the navigation tree to enter the interzone policy group list page, as shown in Figure 69. Then click Add to enter the interzone policy group configuration page. Figure 82 Configure the interzone policy group 76

84 Select Trust as the source zone. Select Untrust as the destination zone. Select 3000 under Available ACLs, and click << to add it to the selected ACL list. Select the enable box. Click Apply. Firewall policy configuration wizard Overview The firewall policy configuration wizard provides a way to configure firewall policies for virtual devices easily. It can also help you to configure interzone policy parameters. Configuring a firewall policy Configuration prerequisites Table 26 Firewall policy configuration prerequisites Item Security zone Address resource Service resource Time range resource Content filtering policy template Description Optional for root virtual devices and required for other virtual devices. Select Device Management > Zone from the navigation tree to configure a security zone. For more information, see "Zone configuration." Optional Select Resource > Address from the navigation tree to configure an address group resource. For more information, see "Address resource configuration." Optional Select Resource > Service from the navigation tree to configure a service group resource. For more information, see "Service resource configuration." Optional Select Resource > Time Range from the navigation tree to configure a time range resource. For more information, see "Time range resource configuration." Optional Select Identification > Content Filtering > Policy Template from the navigation tree to configure a content filtering policy template. For more information, see Application Control Configuration Guide. Configuration procedure 1. After logging in to the web interface, select Wizard from the navigation tree to enter the main page of the configuration wizard. 2. Click the Firewall Policy Configuration link to enter the first page of the firewall policy configuration wizard, as shown in Figure

85 Figure 83 Firewall policy configuration wizard: 1/7 3. Configure the items on the page. Table 27 Configuration items item Source Zone Destination Zone Description Specify the source zone of the firewall policy. Specify the destination zone of the firewall policy. 4. Click Next to enter the second page of the firewall policy configuration wizard. Figure 84 Firewall policy configuration wizard: 2/7 5. Configure the items on the page. 78

86 Table 28 Configuration items Item Filter Action Content Filter Policy Description Specify the action to be taken for packets matching the firewall policy: Permit Allows matched packets to pass. Deny Drops matched packets. Specify the content filtering template to be applied to the packets that match the firewall policy. 6. Click Next to enter the third page of the firewall policy configuration wizard. Figure 85 Firewall policy configuration wizard: 3/7 7. Configure the items on the page. Table 29 Configuration items Item Source IP Address (Group) Destination IP Address (Group) Description Specify the source address or source address group resource for the firewall policy. Specify the destination address or destination address group resource for the firewall policy. 8. Click Next to enter the fourth page of the firewall policy configuration wizard. 79

87 Figure 86 Firewall policy configuration wizard: 4/7 9. Configure the items on the page. Table 30 Configuration items item Service (Group) Description Specify the service resource for the firewall policy. 10. Click Next to enter the fifth page of the firewall policy configuration wizard. 80

88 Figure 87 Firewall policy configuration wizard: 5/7 11. Configure the items on the page. Table 31 Configuration items Item Time Range Description Specify the time range resource for the firewall policy. 12. Click Next to enter the sixth page of the firewall policy configuration wizard. 81

89 Figure 88 Firewall policy configuration wizard: 6/7 13. Configure the items as described in Table 32. Table 32 Configuration items Item Enable Syslog Function Description Specify whether to keep a log of matched packets. 14. Click Next to enter the seventh page of the firewall policy configuration wizard. 82

90 Figure 89 Firewall policy configuration wizard: 7/7 15. Select whether to save the current configuration to the configuration files to be used at next startup (including a cfg file and xml file), check that the settings are what you want, and then select the page to jump to: Interzone policy page Jumps to the page you can enter by selecting Firewall > Security Policy > Interzone Policy from the navigation tree. Configuration Wizard main page Jumps to the page you can enter by selecting Wizard from the navigation tree. Next Firewall Policy Configuration Wizard Jumps to the page you can enter by selecting Wizard from the navigation tree and then clicking the Firewall Policy Configuration hyperlink. Click Finish. 83

91 Managing sessions Overview The session management feature is designed to manage sessions of applications such as network address translation (NAT), application specific packet filter (ASPF), and intrusion protection. This feature regards packet exchanges at the transport layer as sessions and updates the status of sessions or ages out sessions according to the information in packets. Session management allows multiple features to process the same service packet respectively. It implements the following functions: Fast match between packets and sessions Management of transport layer protocol state Identification of application layer protocol types Session aging based on protocol state or application layer protocol type Persistent session Checksum verification for transport layer protocol packets Special packet match for the application layer protocols requiring port negotiation Resolution of ICMP error control packets and session match based on resolution results Session management principle The session management function tracks the status of connections by inspecting the transport layer protocol (TCP or UDP) information, and performs unified status maintenance and management for all connections. In actual applications, session management works together with ASPF to dynamically determine whether a packet can pass the firewall and enter the internal network according to connection status, thus preventing intrusion. The session management function only implements connection status tracking. It cannot block potential attack packets. Session management implementation The session management feature implemented on the firewall provides the following functions: Supporting session creation, session status update and session timeout setting based on protocol state for IPv4 TCP, UDP, ICMP, and Raw IP sessions Supporting port mapping for application layer protocols and allowing application layer protocols to use customized ports and session timeout intervals Supporting checksum verification for TCP, UDP, and ICMP packets. In case of a checksum verification failure, the system does not match sessions or create sessions. Instead, other services based on session management will process the packets Supporting ICMP error packet mapping and allowing the system to search for original sessions according to the payloads of these packets. As ICMP error packets are generated due to errors, this helps speed up the aging of the original sessions. 84

92 Supporting persistent sessions. You can specify TCP sessions meeting certain criteria as persistent sessions. The aging time of a persistent session does not vary with the session state transitions, neither will a persistent session be removed because no packets match it. A persistent session can be specified with an aging time that is longer than those of common sessions (up to 360 hours), or be configured to be a permanent connection, which will be deleted only when the session initiator or responder sends a request to close it or you clear it manually. Supporting both control channels and dynamic data channels of application layer protocols such as DNS, FTP, MSN, QQ, and SIP Supporting both unidirectional and bidirectional traffic (the hybrid mode). Bidirectional traffic environment means that packets in both of the two directions pass the firewall. Unidirectional traffic environment means that packets in only one direction pass the firewall. In this case, the normal session state machine of the firewall cannot process the packets. After the unidirectional traffic detection mode is enabled, session management adopts a special session state machine, which can process the bidirectional and the unidirectional packets simultaneously, but some service functions cannot be supported. For example, ASPF will not check the first TCP packet that is not SYN. Therefore, the system security will be degraded. If unidirectional traffic exists in the network, enable the unidirectional traffic detection to ensure normal processing of the unidirectional traffic. However, if no unidirectional traffic exists in the network, disable the unidirectional traffic detection to ensure the system security. Supporting limiting the number of session-based connections. For more information, see "Connection limit configuration." NOTE: Only TCP sessions in the ESTABLISHED state can be specified as persistent sessions. Configuring session management in the web interface Configuration task list Configuring basic session management settings Task Remarks Optional. Basic session management settings include: Configuring whether to enable unidirectional traffic detection Configuring basic session management settings Configuring persistent session rule, which is available only for TCP sessions in the ESTABLISHED state. Configuring aging times for protocol states, which are effective only for sessions being established Configuring aging times for application layer protocols, which are effective only for the sessions in the READY or ESTABLISHED state. 85

93 Displaying and maintaining session management information Task Displaying session table information Remarks Display the session table information of the current virtual device. Displaying session statistics Task Displaying global session statistics Enabling and disabling session statistics collection Displaying session statistics per IP address Displaying session statistics based on security zone Remarks Display the global session statistics. Enable or disable session statistics collection based on source/destination security zone or source/destination IP address. By default, the session statistics collection function is disabled. IMPORTANT: The session statistics collection function collects only information about traffic occurring during the function is enabled. Display session statistics based on the specified source or destination IP address. IMPORTANT: Before performing this task, be sure to enable session statistics collection based on source/destination IP address. Display session statistics based on the specified source or destination security zone. IMPORTANT: Before performing this task, be sure to enable the session statistics collection based on source/destination security zone. Configuring basic session management settings 1. Select Firewall > Session Table > Configuration from the navigation tree. The configuration interface appears as shown in Figure

94 Figure 90 Session configuration 2. Configure the parameters as described in Table Click Apply. 87

95 Table 33 Configuration items Item Enable unidirectional traffic detection Description Enable or disable unidirectional traffic detection. With unidirectional traffic detection enabled, session management processes both the unidirectional and bidirectional traffic. With unidirectional traffic detection disabled, session management processes only the bidirectional traffic. Specify the ID of an ACL ACL Only one ACL can be referenced as the persistent session rule, and the last referenced ACL takes effect. If no ACL is specified, persistent sessions are not allowed. To configure an ACL, select Firewall > ACL from the navigation tree. For more information, see "ACL configuration." Session Aging Time SYN_SENT State and SYN_RCV State Aging Time Set the aging time of persistent sessions. The value of 0 means that the persistent sessions will not be aged. Specify the SYN_SENT state and SYN_RCV state aging time for TCP TCP Protocol UDP Protocol ICMP Protocol Aging Accelerate Queue RAWIP Protocol FIN_WAIT State Aging Time ESTABLISHED State Aging Time OPEN State Aging Time READY State Aging Time OPEN State Aging Time CLOSED State Aging Time Accelerate Queue Aging Time OPEN State Aging Time READY State Aging Time Specify the FIN_WAIT state aging time for TCP Specify the ESTABLISHED state aging time for TCP Specify the OPEN state aging time for UDP Specify the READY state aging time for UDP Specify the OPEN state aging time for ICMP Specify the CLOSED state aging time for ICMP Specify the accelerate queue aging time Specify the OPEN state aging time for RAW IP Specify the READY state aging time for RAW IP DNS Session Aging Time FTP Session Aging Time MSN Session Aging Time QQ Session Aging Time SIP Session Aging Time Specify the DNS session aging time Specify the FTP session aging time Specify the MSN session aging time Specify the QQ session aging time Specify the SIP session aging time 88

96 Displaying session table information 1. Select Firewall > Session Table > Session Summary from the navigation tree. The session table appears as shown in Figure 91. Figure 91 Session table Table 34 Fields description Field Init Src IP Init Dest IP Init VPN VPN/VLAN/INLINE Resp Src IP Resp Dest IP Resp VPN VPN/VLAN/INLINE Protocol Session Status Lifetime Description Source IP address and port number of packets from the session initiator Destination IP address and port number of packets from the session initiator VPN that packets (from the initiator to responder) belong to and the VLAN and INLINE that the packets belong to during Layer 2 forwarding Source IP address and port number of packets from the session responder Destination IP address and port number of packets from the session responder VPN instance that packets (from the responder to initiator) belong to and the VLAN and INLINE that the packets belongs to during Layer 2 forwarding Transport layer protocol type or number Session status, including Accelerate, SYN, TCP-EST, FIN, UDP-OPEN, UDP-READY, ICMP-OPEN, ICMP-CLOSED, RAWIP-OPEN, and RAWIP-READY Remaining lifetime of the session 2. To display detailed information about a session, click the icon for the session. Figure 92 Detailed information of a session 89

97 Table 35 Field description Field Protocol Description Transport layer protocol, which can be TCP, UDP, ICMP, or RAWIP Session status, which can be: Accelerate SYN TCP-EST FIN State UDP-OPEN UDP-READY ICMP-OPEN ICMP-CLOSED RAWIP-OPEN RAWIP-READY TTL Initiator: VD / ZONE / VPN / IP / PORT Responder: VD / ZONE / VPN / IP / PORT Remaining lifetime of the session The initiator's virutal device/security zone/vpn instance/ip address/port number The responder's virual device/security zone/vpn instance/ip address/port number > Session direction From the initiator to responder < Session direction From the responder to initiator Packets Bytes Number of packets in the direction Number of bytes in the direction Displaying global session statistics Select Firewall > Session Table > Statistics from the navigation tree. The page displays the global statistics by default. 90

98 Figure 93 Global session statistics Table 36 Field description Item Current Session(s) Current TCP Session(s) Current TCP Half-Open Session(s) Current TCP Half-Close Session(s) Current UDP Session(s) Current ICMP Session(s) Current RAWIP Session(s) Current Relation Table(s) Session Establishment Rate TCP Session Establishment Rate UDP Session Establishment Rate ICMP Session Establishment Rate Description Total number of sessions of the system Total number of current TCP half-open connections, TCP half-close connections, and full TCP connections in the system Number of current TCP half-open connections in the system Number of current TCP half-close connections in the system Number of current UDP sessions in the system Number of current ICMP sessions in the system Number of current RAWIP sessions in the system Number of current relation tables in the system Session establishment rate in a 1-second sampling interval TCP session establishment rate in a 1-second sampling interval UDP session establishment rate in a 1-second sampling interval ICMP session establishment rate in a 1-second sampling interval 91

99 Item RAWIP Session Establishment Rate Received TCP Packet(s) Received TCP Byte(s) Received UDP Packet(s) Received UDP Byte(s) Received ICMP Packet(s) Received ICMP Byte(s) Received RAWIP Packet(s) Received RAWIP Byte(s) Description RAWIP session establishment rate in a 1-second sampling interval Number of TCP packets received Number of TCP bytes received Number of UDP packets received Number of UDP bytes received Number of ICMP packets received Number of ICMP bytes received Number of RAWIP packets received Number of RAWIP bytes received Enabling and disabling session statistics collection 1. Select Firewall > Session Table > Statistics from the navigation tree. 2. Click the Statistics Configuration tab. Figure 94 Session statistics configuration page 3. Configure the parameters as described in Table Click Apply. Table 37 Configuration items Item Zone Enable source zone statistics Enable destination zone statistics Enable statistics per source IP address Enable statistics per destination IP address Description Select a security zone Enable collection of statistics on sessions with the source security zone being the specified security zone Enable collection of statistics on sessions with the destination security zone being the specified security zone Enable session statistics collection per source IP address Enable session statistics collection per destination IP address 92

100 Displaying session statistics per IP address 1. Select Firewall > Session Table > Statistics from the navigation tree. 2. Click the IP Statistics tab. 3. Select the direction, specify the IP address, select VPN instance/vlan ID/INLINE ID, and click Search. The matched session statistics are displayed. Figure 95 Session statistics per IP address Table 38 Field description Field Total Connection Count Total Connection Rate TCP Connection Count TCP Half-Open Connection Count TCP Half-Close Connection Count TCP Connection Rate UDP Connection Count UDP Connection Rate ICMP Connection Count ICMP Connection Rate RAWIP Connection Count Description Total number of current connections Connection establishment rate in a 5-second sampling interval Total number of TCP half-open connections, TCP half-close connections, and full TCP connections Number of TCP half-open connections Number of TCP half-close connections TCP connection establishment rate in a 5-second sampling interval Number of full UDP connections UDP connection establishment rate in a 5-second sampling interval Number of full ICMP connections ICMP connection establishment rate in a 5-second sampling interval Number of current RAWIP connections 93

101 Field RAWIP Connection Rate TCP Packet Count TCP Byte Count UDP Packet Count UDP Byte Count ICMP Packet Count ICMP Byte Count RAWIP Packet Count RAWIP Byte Count Description RAWIP connection establishment rate in a 5-second sampling interval Number of TCP packets Number of TCP bytes Number of UDP packets Number of UDP bytes Number of ICMP packets Number of ICMP bytes Number of RAWIP packets Number of RAWIP bytes Displaying session statistics based on security zone To display security zone based session statistics, select Firewall > Session Table > Statistics from the navigation tree, and then click the Zone Statistics tab to enter the page for displaying security zone based session statistics, as show in Figure 96. Select the desired security zone and direction, and then click Search. The matched session statistics will be displayed. Figure 96 Session statistics based on security zone Table 39 Field description Field Total Connection Count Total Connection Rate TCP Connection Count Description Total number of current connections Connection establishment rate in a 5-second sampling interval Total number of TCP half-open connections, TCP half-close connections, and full TCP connections 94

102 Field TCP Half-Open Connection Count TCP Half-Close Connection Count TCP Connection Rate UDP Connection Count UDP Connection Rate ICMP Connection Count ICMP Connection Rate RAWIP Connection Count RAWIP Connection Rate Description Number of TCP half-open connections Number of TCP half-close connections TCP connection establishment rate in a 5-second sampling interval Number of full UDP connections UDP connection establishment rate in a 5-second sampling interval Number of full ICMP connections ICMP connection establishment rate in a 5-second sampling interval Number of current RAWIP connections RAWIP connection establishment rate in a 5-second sampling interval Configuring session management at the CLI In session management, you can set session aging timers based on protocol state and based on application layer protocol type, enable checksum verification, specify the persistent session rule, and clear sessions. These tasks are order independent. You can perform these tasks in any order. Setting session aging times based on protocol states This aging timer settings are effective only to the sessions that are being established. If the application layer protocol of a session supports session aging time configuration, the session takes the session aging time set based on the application layer protocol type as its aging time when it is in the READY/ESTABLISH state. For more information about the configuration, see "Configuring session aging timers based on application layer protocol types." If a session entry is not matched with any packets in a specified period of time, the entry will be aged out. To set the session aging timers based on protocol states: Step Command 1. Enter system view. system-view 2. Set the aging timer for the sessions of a specified protocol and in a specified state. session aging-time { accelerate fin icmp-closed icmp-open rawip-open rawip-ready syn tcp-est udp-open udp-ready } time-value IMPORTANT: For a large amount of sessions (more than ), do not specify a too short aging timer. Otherwise, the console might be slow in response. 95

103 Configuring session aging timers based on application layer protocol types Aging timers set in this task apply only to the sessions in READY/ESTABLISH state. For sessions in READY (with UDP) or ESTABLISH (with TCP) state, you can set the session aging timer according to the type of the application layer protocol to which the sessions belong. To set session aging times based on application layer protocol types: Step Command 1. Enter system view. system-view 2. Set the aging timer for sessions of an application layer protocol. application aging-time { dns ftp msn qq sip } time-value IMPORTANT: For a large amount of sessions (more than ), do not specify a too short aging timer. Otherwise, the console might be slow in response. Enabling checksum verification To make sure that session tracking is not affected by packets with checksum errors, you can enable checksum verification for protocol packets. With checksum verification enabled, the session management feature processes only packets with correct checksums, and packets with incorrect checksums will be processed by other services based on the session management. To enable checksum verification for protocol packets: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable checksum verification. session checksum { all { icmp tcp udp } * } Disabled by default. IMPORTANT: Enabling checksum verification might degrade the device performance. Specifying the persistent session rule You can set some sessions that have specific characteristics as persistent sessions. The aging time of a persistent session does not vary with the session state transitions, neither will a persistent session be removed because no packets match it. A persistent session can be specified with an aging time that is longer than those of common sessions, or be configured to be a permanent connection, which will be cleared only when the session initiator or responder sends a request to close it or you clear it manually. You can set the persistent session criteria by specifying a basic or advanced access control list (ACL). All sessions permitted by the ACL are persistent sessions. For more information about the configuration of basic and advance ACLs, see "Configuring ACLs." To specify the persistent session rule: 96

104 Step Command Remarks 1. Enter system view. system-view N/A 2. Specify the persistent session rule. session persist acl acl-number [ aging-time time-value ] Not specified by default. NOTE: A persistent session rule can reference only one ACL. Only TCP sessions in ESTABLISHED state can be specified as persistent sessions. Clearing sessions To clear sessions: Task Command Remarks Clear sessions. reset session [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol-type protocol-type ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ] Available in user view Displaying and maintaining session management Task Command Remarks Display information about sessions. Display statistics about sessions. Display session relationship table information. Clear sessions. Clear session statistics (on a centralized device). display session table [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ verbose ] [ { begin exclude include } regular-expression ] display session statistics [ vd-name vd-name ] [ { begin exclude include } regular-expression ] display session relation-table [ vd-name vd-name ] [ { begin exclude include } regular-expression ] reset session [ vd-name vd-name ] [ source-ip source-ip ] [ destination-ip destination-ip ] [ protocol-type { icmp raw-ip tcp udp } ] [ source-port source-port ] [ destination-port destination-port ] [ vpn-instance vpn-instance-name ] reset session statistics [ vd-name vd-name ] Available in any view Available in any view Available in any view Available in user view Available in user view 97

105 Configuration guidelines When you configure session management, follow these guidelines: If the number of sessions is too large, for example, more than 800,000 sessions, you are not recommended to set small values for aging times of the protocol states and application layer protocols. Otherwise, the responses of the console will be slow. Only TCP sessions in ESTABLISHED state can be specified as persistent sessions. 98

106 Configuring virtual fragment reassembly The virtual fragment reassembly configuration is available only in the Web interface. Overview To prevent service modules (such as IPSec, NAT and firewall) from processing packet fragments that arrive out of order, you can enable the virtual fragment reassembly feature. This feature can virtually reassemble the fragments of a datagram through fragment checking, sequencing and caching so as to make sure that fragments arrive at service modules in order. The virtual fragment reassembly feature can also detect the following types of fragment attacks, and discard the attack fragments for security. Tiny fragment attack: If the first fragment of a datagram is very small and the transport layer protocol (such as TCP and UDP) header is in the second fragment, a tiny fragment attack is considered. Overlapping fragment attack: If two consecutive incoming fragments are identical or overlapping, an overlapping fragment attack is considered. Fragment-flood attack: If the maximum number of fragments per datagram or the maximum number of fragment queues on the firewall is reached, a fragment-flood attack is considered. Configuring virtual fragment reassembly 1. Select Firewall > Session Table > Advanced from the navigation tree.. Figure 97 Virtual fragment reassembly configuration page 2. Configure the parameters as described in Table

107 3. Click Apply. Table 40 Configuration items Item Security Zone Enable Virtual Fragment Reassembly Specify max number of concurrent reassemblies Specify max number of fragments per reassembly Specify timeout value of the datagram being reassembled Drop all the incoming fragments Description Specify a security zone to be configured with virtual fragment reassembly. Select the box to enable the virtual fragment reassembly feature. Specify the maximum number of concurrent reassemblies. When this value is reached, the firewall discards all subsequent packets and sends a syslog message. This option is available after the virtual fragment reassembly feature is enabled. Specify the maximum number of fragments in each reassembly. When this value is reached, the firewall discards all subsequent fragments of the reassembly and sends a syslog. This option is available after the virtual fragment reassembly feature is enabled. Set the aging time for each reassembly. If the fragments of a datagram (in a reassembly) are not reassembled within this time, all the fragments of the datagram are discarded. This option is available after the virtual fragment reassembly feature is enabled. Select the box to discard all incoming fragments. This option is available after the virtual fragment reassembly feature is enabled. Virtual fragment reassembly configuration example Network requirements As shown in Figure 98, the host accesses the router through the Firewall, and NAT is enabled on interface GigabitEthernet 0/1 of the Firewall. Enable virtual fragment reassembly for security zone Trust on the Firewall to ensure secure and efficient NAT. Figure 98 Network diagram Configuring the Host. Configure a static route to the router. (Details not shown.) Configuring the Firewall. 1. Assign IP addresses to the interfaces and assign the interfaces to the security zones. (Details not shown.) 2. Configure a static address mapping: 100

108 a. Select Firewall > NAT Policy > Static NAT from the navigation tree. b. Click Add in the Static Address Mapping area. c. Enter for Internal IP Address. d. Enter for Global IP Address. e. Click Apply. Figure 99 Adding a static address mapping 3. Enable static NAT on GigabitEthernet 0/1: a. Click Add in the Interface Static Translation area. b. Select interface GigabitEthernet0/1. c. Click Apply. Figure 100 Enabling static NAT on an interface 4. Configure virtual fragment reassembly: a. Select Firewall > Session Table > Advanced from the navigation tree. b. Select Trust for Security Zone. c. Select the Enable Virtual Fragment Reassembly box. d. Click Apply. 101

109 Figure 101 Configuring virtual fragment reassembly After the configuration, if the Firewall receives disordered fragments from the security zone Trust, the Firewall checks and reassembles them. Configuration guidelines When you configure virtual fragment reassembly, follow these guidelines: The virtual fragment reassembly feature only applies to packets incoming to a security zone. The virtual fragment reassembly feature does not support load sharing. That is, the fragments of an IP datagram cannot arrive through different security zones. 102

110 Configuring ASPF The ASPF configuration is available only in the Web interface. Overview Application Specific Packet Filter (ASPF) applications are based on zone management and session management. Zone management is an independent common module. It does not concern service packet processing; it only maintains information relevant to zones and provides policy interfaces for other modules. The session management module simplifies the design of function modules such as Network Address Translation (NAT), ASPF, Application Level Gateway (ALG), attack defense, and connection number limit modules. It is responsible for processing kinds of session information, aging sessions based on session states, and providing the uniform interfaces for the function modules. ASPF policies are configured between zones. When used for packet processing, they use information provided by the session management module, such as whether the connection status is correct, whether a packet is an initial one, and whether a packet is an ICMP error packet. Based on information provided by the session management module and ASPF policies, ASPF applications determine which packets are allowed to pass. ASPF is often used to cooperate with the static packet filter function. In some cases, ASPF cannot determine whether packets are allowed to pass, and it is the static packet filter function that makes the decision. For example, whether broadcast packets are allowed to pass is determined by the static packet filter function based on ACLs or default inter-zone priorities. Configuring ASPF 1. Select Firewall > Session Table > Advanced from the navigation tree. 2. Click the ASPF tab. Figure 102 ASPF policy list 3. Click Add. The page for adding an ASPF policy appears, as shown in Figure

111 Figure 103 Adding an ASPF policy 4. Configure the parameters as described in Table Click Apply. Table 41 Configuration items Item Source Zone Dest Zone Discard ICMP error packets Discard non-syn initial TCP packets Description Select a source/destination zone to which the ASPF policy will be applied. Set whether to discard ICMP error packets If this box is not selected, ICMP error packets are allowed to pass. Set whether to discard initial TCP packets that are not SYN packets If this box is not selected, initial TCP packets that are not SYN packets are allowed to pass. ASPF configuration example Network requirements As shown in Figure 104, configure an ASPF policy between zone 1 and zone 2 to discard ICMP error packets but permit initial TCP packets that are not SYN packets. Figure 104 Network diagram 104

112 Configuration procedure 1. Configure zone 1 and zone 2, and specify security zones for the interfaces. (Details not shown.) 2. Configure an ASPF policy: a. Select Firewall > Session Table > Advanced from the navigation tree. b. Click the ASPF tab. c. Click Add. d. Select zone 1 from the Source Zone list, select zone 2 from the Dest Zone list, and click the Discard ICMP error packets box. e. Click Apply. Figure 105 Configuring ASPF policy 105

113 Configuring connection limits Overview If a client in an internal network initiates a large number of connections to the external network through the firewall, the system resources of the firewall might be used up, and other users cannot access the network resources normally. In addition, if an internal server receives a large number of connection requests from a client in a short time, the server might not be able to process them in time and cannot handle the connection requests from other clients. To protect internal network resources (hosts or servers) and ensure proper allocation of the system resources of the firewall, you can configure connection limit policies on the firewall, based on the following criteria: Source IP address: Limits the number of connections from a specified host or network segment in the internal network to the external network. Destination IP address: Limits the number of connections from hosts or network segments in the external network to a specified internal server. Source IP address and destination IP address: Limits the number of connections from a specified host or network segment in the internal network to a specified host or network segment in the external network. Subnet: Limits the total number of connections through the firewall. Configuring connection limit in the web interface 1. Select Firewall > Session Table > Connection Limit from the navigation tree. By default, connection limit is disabled. Figure 106 Enabling connection limit 2. Click the Enable Connection Limit box to display the connection limit policy list. 106

114 Figure 107 Connection limit policies 3. Click Add to add an entry as required. 4. Configure the necessary parameters as described in Table 42, and click to buffer your configuration. 5. Click Apply to make your settings into effect. Table 42 Configuration items Item Source IP Source Mask Source VPN Destination IP Destination Mask Destination VPN Protocol Max Connections Description Specify the source IP address, mask, and VPN. If you specify neither source IP address nor mask, the configuration limits the number of connections from all hosts in the source network. If you do not specify any source VPN, the configuration limits the number of connections from the host or network segment on the public network. Specify the destination IP address, mask, and VPN. If you specify neither destination IP address nor mask, the configuration limits the number of connections to all hosts in the destination network. If you do not specify any destination VPN, the configuration limits the number of connections to the host or network segment on the public network. Select the protocol type for connection limit. Type the maximum number of allowed connections. Select the criterion for connection limit: Source Limits the number of connections based on source IP address. Limit By Destination Limits the number of connections based on destination IP address. Source-destination Limits the number of connections based on source IP address and destination IP address. Subnet Limits the total number of connections through the firewall. 107

115 NOTE: A connection limit policy cannot have the same source network segment, destination network segment, or protocol as another policy. A later configured policy is first used for matching the connection requests and applies to limit the connections if matched. Therefore, when you configure multiple connection limit policies, configure the ones with a smaller granularity later. Configuring connection limit at the CLI Connection limit configuration task list Complete the following tasks to configure connection limiting: Task Creating a connection limit policy Remarks Required Configuring the connection limit policy Configuring an IP address-based connection limit rule Required Applying the connection limit policy Required Creating a connection limit policy A connection limit policy comprises a set of connection limit rules, which define the valid range and parameters for the policy. To create a connection limit policy: Step Command 1. Enter system view. system-view 2. Create a connection limit policy and enter its view. connection-limit policy policy-number Configuring the connection limit policy A connection limit policy can contain multiple connection limit rules. Each rule defines an object or range to limit the connections that match the rule. For a connection that does not match the rule, the device allows the traffic through the connection to pass. The device only supports IP address-based connection limit rules. Configuring an IP address-based connection limit rule The limit rules are matched in ascending order of rule ID. When you configure connection limit rules for a policy, check the rules and their order carefully. HP recommends arrange the rules in ascending order of granularity and range. To configure an IP address-based connection limit rule: Step Command 1. Enter system view. system-view 108

116 Step Command 2. Enter connection limit policy view. connection-limit policy policy-number 3. Configure an IP address-based connection limit rule. limit limit-id { source ip { ip-address mask-length any } [ source-vpn src-vpn-name ] destination ip { ip-address mask-length any } [ destination-vpn dst-vpn-name ] } * protocol { dns http ip tcp udp } max-connections max-num [ per-destination per-source per-source-destination ] Applying the connection limit policy To make a connection limit policy take effect, apply it globally. To apply a connection limit policy: Step Command Remarks 1. Enter system view. system-view N/A 2. Apply a connection limit policy. connection-limit apply policy policy-number Only one connection limit policy can be applied globally. Displaying and maintaining connection limit Task Command Remarks Display information about one or all connection limit policies. display connection-limit policy { policy-number all } [ { begin exclude include } regular-expression ] Available in any view Connection limit configuration example Network requirements As shown in Figure 108, a company has five public IP addresses: /24 to /24. The internal network address is /16 and two servers are on the internal network. Perform NAT configuration so that the internal users can access the Internet and external users can access the internal servers, and configure connection limiting so that: Each host on segment /24 can establish up to 100 connections to external network and all the other hosts can establish as many connections as possible. Permit up to connections from the external network to the DNS server. Permit up to connections from the external network to the Web server. 109

117 Figure 108 Network diagram Configuration procedure The following describes only connection limit configuraiton steps. For more information about NAT configuration and internal server configuration, see NAT Configuration Guide. # Create a connection limit policy and enter its view. <Firewall> system-view [Firewall] connection-limit policy 0 # Configure connection limit rule 0 to limit connections from hosts on segment /24 to the external network per source address, with the upper connection limit of 100. [Firewall-connection-limit-policy-0] limit 0 source ip destination ip any protocol ip max-connections 100 per-source # Configure connection limit rule 1 to limit connections from the external network to the DNS server /24, with the upper connection limit of [Firewall-connection-limit-policy-0] limit 1 source ip any destination ip protocol dns max-connections # Configure connection limit rule 2 to limit connections from the external network to the Web server /24, with the upper connection limit of [Firewall-connection-limit-policy-0] limit 2 source ip any destination ip protocol http max-connections [Firewall-connection-limit-policy-0] quit # Apply the connection limit policy. [Firewall] connection-limit apply policy 0 Verifying the configuration After the configuration, use the display connection-limit policy to display the information about the connection limit policy. [Firewall] display connection-limit policy 0 Connection-limit policy 0, refcount 1, 3 limits limit 0 source ip destination ip any protocol ip max-connections 100 per-source limit 1 source ip any destination ip protocol dns max-connections limit 2 source ip any destination ip protocol http max-connections

118 Troubleshooting connection limit Connection limit rules with overlapping segments 1. Symptom On the Firewall, create a connection limit policy and configure two rules for the policy. One limits connections from each host on segment /24 with the upper connection limit 10, and another limits connections from with the upper connection limit 100. [Firewall-connection-limit-policy-0] limit 0 source ip destination ip any protocol ip max-connections 10 per-source [Firewall-connection-limit-policy-0] limit 1 source ip destination ip any protocol ip max-connections 100 per-source With the configuration, the host can only initiate up to 10 connections to the external network. 2. Analysis Both rules limit 0 and limit 1 contain the IP address , and the rule with a smaller ID is matched first. Rule 0 is used for connections from Solution Rearrange the two connection limit rules by exchanging their rule IDs so that the rule for the host is matched first. Connection limit rules with overlapping protocol types 1. Symptom Internal server provides both Web and FTP services for external users. On the Firewall, create a connection limit policy and configure two rules, one limiting TCP connections to the server with the upper limit 100 and the second limiting HTTP connections to the server with the upper limit [Firewall-connection-limit-policy-0] limit 0 source ip any destination ip protocol tcp max-connections 100 [Firewall-connection-limit-policy-0] limit 1 source ip any destination ip protocol http max-connections With the configuration, 100 HTTP connections to the server can be established at most. 2. Analysis Both rules limit 0 and limit 1 involve HTTP connections, and the rule with a smaller ID is matched first. Rule 0 is used for HTTP connections. 3. Solution Rearrange the two connection limit rules by exchanging their rule IDs so that the rule for HTTP connections is matched first. 111

119 Configuring portal authentication The portal configuration is available only at the CLI. Feature and hardware compatibility Feature F1000-A-EI/S-EI F1000-E F5000 Firewall module Portal Yes No No No Overview Portal authentication helps control access to the Internet. It is also called " Web authentication." A website implementing portal authentication is called a portal website. With portal authentication, an access device redirects all users to the portal authentication page. All users can access the free services provided on the portal website; but to access the Internet, a user must pass portal authentication. A user can access a known portal website and enter a username and password for authentication. This authentication mode is called active authentication. There is another authentication mode, forced authentication, in which the access device forces a user who is trying to access the Internet through Hypertext Transfer Protocol (HTTP) to log on to a portal website for authentication. The portal feature provides the flexibility for Internet service providers (ISPs) to manage services. A portal website can, for example, present advertisements and deliver community and personalized services. In this way, broadband network providers, equipment vendors, and content service providers form an industrial ecological system. Extended portal functions By forcing patching and anti-virus policies, extended portal functions help users to defend against viruses. Portal authentication supports the following extended functions: Security check Works after identity authentication succeeds to check whether the required anti-virus software, virus definition file, and operating system (OS) patches are installed, and whether there is any unauthorized software installed on the user host. Resource access restriction Allows a user passing identity authentication to access only network resources in the quarantined area, such as the anti-virus server and the patch server. Only users passing both identity authentication and security check can access restricted network resources. Portal system components A typical portal system comprises these basic components: authentication client, access device, portal server, authentication/accounting server, and security policy server. 112

120 Figure 109 Portal system components Authentication client Access device Portal server An authentication client is an entity seeking access to network resources. It is typically an end-user terminal, such as a PC. The client can use a browser or a portal client software for portal authentication. The security check for a client is implemented through the communications between the client and the security policy server. An access device controls user access. It can be a switch or router that provides the following three functions: Redirecting all HTTP requests from unauthenticated users to the portal server. Interacting with the portal server, the security policy server, and the authentication/accounting server for identity authentication, security check, and accounting. Allowing users who have passed identity authentication and security check to access granted Internet resources. A portal server listens to authentication requests from authentication clients and exchanges client authentication information with the access device. It provides free portal services and pushes Web authentication pages to users. Authentication/accounting server An authentication/accounting server implements user authentication and accounting through interaction with the access device. Security policy server A security policy server interacts with authentication clients and access devices for security check and resource authorization. The components of a portal system interact in the following procedure: 1. When an unauthenticated user enters a website address in the browser's address bar to access the Internet, an HTTP request is created and sent to the access device, which redirects the HTTP request to the portal server's Web authentication homepage. For extended portal functions, authentication clients must run the portal client software. 113

121 2. On the authentication homepage/authentication dialog box, the user enters and submits the authentication information, which the portal server then transfers to the access device. 3. Upon receipt of the authentication information, the access device communicates with the authentication/accounting server for authentication and accounting. 4. After successful authentication, the access device checks whether there is a corresponding security policy for the user. If not, it allows the user to access the Internet. Otherwise, the client communicates with the access device and the security policy server for security check. If the client passes security check, the security policy server authorizes the user to access the Internet resources. NOTE: Portal authentication supports NAT traversal whether it is initiated by a Web client or an HP inode. When the portal authentication client is on a private network, but the portal server is on a public network and the access device is enabled with NAT, network address translations performed on the access device do not affect portal authentication. However, in such a case, HP recommends using an interface's public IP address as the source address of outgoing portal packets. Only a RADIUS server can serve as the remote authentication/accounting server in a portal system. To implement security check, the client must be the HP inode client. Portal authentication mode The firewall (as an access device) supports Layer 3 portal authentication. You can enable portal authentication on an access device's Layer 3 interfaces connected to the authentication clients. Portal authentication performed on a Layer 3 interface can be direct authentication, re-dhcp authentication, or cross-subnet authentication. In direct authentication and re-dhcp authentication, no Layer-3 forwarding devices exist between the authentication client and the access device. In cross-subnet authentication, Layer-3 forwarding devices may exist between the authentication client and the access device. Direct authentication Before authentication, a user manually configures a public IP address or directly obtains a public IP address through DHCP, and can access only the portal server and predefined free websites. After passing authentication, the user can access the network resources. The process of direct authentication is simpler than that of re-dhcp authentication. Re-DHCP authentication Before authentication, a user gets a private IP address through DHCP and can access only the portal server and predefined free websites. After passing authentication, the user is allocated a public IP address and can access the network resources. No public IP address is allocated to those who fail authentication. This solves the IP address planning and allocation problem and can be useful. For example, a service provider can allocate public IP addresses to broadband users only when they access networks beyond the residential community network. Cross-subnet authentication Cross-subnet authentication is similar to direct authentication, but it allows Layer 3 forwarding devices to be present between the authentication client and the access device. In direct authentication, re-dhcp authentication, and cross-subnet authentication, the client's IP address is used for client identification. After a client passes authentication, the access device generates an access control list (ACL) for the client based on the client's IP address to permit packets from the client to go through the access port. Because no Layer 3 devices are present 114

122 between the authentication clients and the access device in direct authentication and re-dhcp authentication, the access device can directly learn the MAC addresses of the clients, and thus can control the forwarding of packets from clients in a more granular way by also using the learned MAC addresses. Layer 3 portal authentication process Direct authentication and cross-subnet authentication share the same authentication process, while re-dhcp authentication has a different process because of the presence of two address allocation procedures. Direct authentication/cross-subnet authentication process (with CHAP/PAP authentication) Figure 110 Direct authentication/cross-subnet authentication process The direct authentication/cross-subnet authentication takes the following procedure: 1. An authentication client initiates authentication by sending an HTTP request. When the HTTP packet arrives at the access device, the access device allows it to pass if it is destined for the portal server or a predefined free website, or redirects it to the portal server if it is destined for other websites. The portal server pushes a Web authentication page to the user and the user enters the username and password. 2. The portal server and the access device exchange Challenge Handshake Authentication Protocol (CHAP) messages. For Password Authentication Protocol (PAP) authentication, this step is skipped. 3. The portal server assembles the username and password into an authentication request message and sends it to the access device. Meanwhile, the portal server starts a timer to wait for an authentication acknowledgment message. 4. The access device and the RADIUS server exchange RADIUS packets to authenticate the user. 5. The access device sends an authentication reply to the portal server. 6. The portal server sends an authentication success message to the authentication client to notify it of logon success. 7. The portal server sends an authentication reply acknowledgment message to the access device. With extended portal functions, the process includes two additional steps: 1. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements. 115

123 2. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information. Re-DHCP authentication process (with CHAP/PAP authentication) Figure 111 Re-DHCP authentication process The re-dhcp authentication takes the following procedure: 1. The first steps are the same as those in the direct authentication/cross-subnet authentication process. 2. After receiving the authentication success message, the authentication client obtains a new public IP address through DHCP and notifies the portal server that it has obtained a public IP address. 3. The portal server notifies the access device that the authentication client has obtained a new public IP address. 4. Detecting the change of the IP address by examining ARP packets received, the access device notifies the portal server of the change. 5. The portal server notifies the authentication client of logon success. 6. The portal server sends a user IP address change acknowledgment message to the access device. With extended portal functions, the process includes additional steps: 1. The security policy server exchanges security check information with the authentication client to check whether the authentication client meets the security requirements. 2. Based on the security check result, the security policy server authorizes the user to access certain resources, and sends the authorization information to the access device. The access device then controls access of the user based on the authorization information. 116

124 Portal configuration task list Task Specifying a portal server for Layer 3 portal authentication Enabling Layer 3 portal authentication Remarks Required Required Controlling access of portal users Configuring RADIUS related attributes Configuring a portal-free rule Configuring an authentication source subnet Setting the maximum number of online portal users Specifying the authentication domain for portal users Specifying NAS-Port-Type for an interface Specifying a NAS ID profile for an interface Optional Optional Specifying a source IP address for outgoing portal packets Specifying an auto redirection URL for authenticated portal users Optional Optional Configuring portal detection functions Logging off portal users Configuring online Layer 3 portal user detection Configuring the portal server detection function Configuring portal user information synchronization Optional Optional Configuration prerequisites The portal feature provides a solution for user identity authentication and security check. However, the portal feature cannot implement this solution by itself. RADIUS authentication needs to be configured on the access device to cooperate with the portal feature to complete user authentication. The prerequisites for portal authentication configuration are as follows: The portal server and the RADIUS server have been installed and configured properly. With re-dhcp authentication, the IP address check function of the DHCP relay agent is enabled on the access device, and the DHCP server is installed and configured properly. The portal client, access device, and servers can reach each other. With RADIUS authentication, usernames and passwords of the users are configured on the RADIUS server, and the RADIUS client configurations are performed on the access device. For information about RADIUS client configuration, see "Configuring AAA." To implement extended portal functions, install and configure IMC EAD, and make sure that the ACLs configured on the access device correspond to those specified for the resources in the quarantined area and for the restricted resources on the security policy server. For information about security policy server configuration on the access device, see "Configuring AAA." 117

125 NOTE: For installation and configuration about the security policy server, see IMC EAD Security Policy Help. The ACL for resources in the quarantined area and that for restricted resources correspond to isolation ACL and security ACL on the security policy server respectively. You can modify the authorized ACLs on the access device. However, your changes take effect only for portal users logging on after the modification. Specifying a portal server for Layer 3 portal authentication Use this task to specify portal server parameters for Layer 3 portal authentication, including the portal server IP address, shared encryption key, server port, and the URL address for Web authentication. To specify a remote portal server for Layer 3 portal authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a portal server and configure related parameters. portal server server-name ip ip-address [ key key-string port port-id url url-string ] * By default, no portal server is specified. NOTE: You can specify four portal servers on the firewall at most. The specified parameters of a portal server can be modified or deleted only if the portal server is not referenced on any interface. Enabling Layer 3 portal authentication Before enabling Layer 3 portal authentication on an interface, make sure that: An IP address is configured for the interface. The interface is not added to any port aggregation group. The portal server to be referenced on the interface exists. Configuration guidelines You cannot enable portal authentication on a Layer 3 interface added to an aggregation group, nor can you add a portal-enabled Layer 3 interface to an aggregation group. The destination port number that the firewall uses for sending unsolicited packets to the portal server must be the same as that which the remote portal server actually uses. The portal server and its parameters can be deleted or modified only when the portal server is not referenced by any interface. Cross-subnet authentication mode (portal server server-name method layer3) does not require Layer 3 forwarding devices between the access device and the authentication clients. However, if there are Layer 3 forwarding devices between the authentication client and the access device, you must select the cross-subnet portal authentication mode. 118

126 In re-dhcp authentication mode, a client can use a public IP address to send packets before passing portal authentication. However, responses to the packets are restricted. Configuration procedure To enable Layer 3 portal authentication: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Enable Layer 3 portal authentication on the interface. interface interface-type interface-number portal server server-name method { direct layer3 redhcp } The interface must be a Layer 3 Ethernet interface. Not enabled by default. NOTE: You cannot enable portal authentication on a Layer 3 interface added to an aggregation group, nor can you add a portal-enabled Layer 3 interface to an aggregation group. The destination port number that the firewall uses for sending unsolicited packets to the portal server must be the same as that which the remote portal server actually uses. The portal server and its parameters can be deleted or modified only when the portal server is not referenced by any interface. Cross-subnet authentication mode (portal server server-name method layer3) does not require Layer 3 forwarding devices between the access device and the authentication clients. However, if there are Layer 3 forwarding devices between the authentication client and the access device, you must select the cross-subnet portal authentication mode. In re-dhcp authentication mode, a client can use a public IP address to send packets before passing portal authentication. However, responses to the packets are restricted. Controlling access of portal users Configuring a portal-free rule A portal-free rule allows specified users to access specified external websites without portal authentication. The matching items for a portal-free rule include the source and destination IP address, source MAC address, inbound interface, and VLAN. Packets matching a portal-free rule will not trigger portal authentication, so that users sending the packets can directly access the specified external websites. When you configure a portal-free rule, follow these guidelines: If you specify both a VLAN and an interface in a portal-free rule, the interface must belong to the VLAN. Otherwise, the rule does not take effect. You cannot configure two or more portal-free rules with the same filtering criteria. Otherwise, the system prompts that the rule already exists. A Layer 2 interface in an aggregation group cannot be specified as the source interface of a portal-free rule, and the source interface of a portal-free rule cannot be added to an aggregation group. 119

127 To configure a portal-free rule: Step Command 1. Enter system view. system-view 2. Configure a portal-free rule. portal free-rule rule-number { destination { any ip { ip-address mask { mask-length netmask } any } } source { any [ interface interface-type interface-number ip { ip-address mask { mask-length mask } any } mac mac-address vlan vlan-id ] * } } * NOTE: Regardless of whether portal authentication is enabled, you can only add or remove a portal-free rule. You cannot modify it. Configuring an authentication source subnet By configuring authentication source subnets, you specify that only HTTP packets from users on the authentication source subnets can trigger portal authentication. If an unauthenticated user is not on any authentication source subnet, the access device discards all the user's HTTP packets that do not match any portal-free rule. To configure an authentication source subnet: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure an authentication source subnet. interface interface-type interface-number portal auth-network network-address { mask-length mask } N/A Optional. By default, the authentication source subnet is /0, which means that users from any subnets must pass portal authentication. NOTE: Configuration of authentication source subnets applies to only cross-subnet authentication. In direct authentication mode, the authentication source subnet is /0. In re-dhcp authentication mode, the authentication source subnet of an interface is the subnet to which the private IP address of the interface belongs. Setting the maximum number of online portal users You can use this feature to control the total number of online portal users in the system. To set the maximum number of online portal users allowed in the system: Step Command Remarks 1. Enter system view. system-view N/A 120

128 Step Command Remarks 2. Set the maximum number of online portal users. portal max-user max-number By default, the maximum number of portal users allowed is 512. NOTE: If the number of currently online portal users is larger than the upper limit that you set, the command can be executed successfully and does not impact the online portal users. However, the system does not allow new portal users to log on until the number drops down below the limit. Specifying the authentication domain for portal users After you specify the authentication domain for portal users on an interface, the firewall will use the authentication domain for authentication, authorization, and accounting (AAA) of all portal users on the interface, ignoring the domain names carried in the usernames. This allows you to specify different authentication domains for different interfaces as needed. To specify the authentication domain for portal users on an interface: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify the authentication domain for portal users on the interface. interface interface-type interface-number portal domain domain-name N/A By default, no authentication domain is specified for portal users. NOTE: The firewall selects the authentication domain for a portal user on an interface in this order: the authentication domain specified for the interface, the authentication domain carried in the username, and the system default authentication domain. For information about the default authentication domain, see " Configuring AAA." Configuring RADIUS related attributes Specifying NAS-Port-Type for an interface NAS-Port-Type is a standard RADIUS attribute for indicating a user access port type. With this attribute specified on an interface, when a portal user logs on from the interface, the firewall uses the specified NAS-Port-Type value as that in the RADIUS request to be sent to the RADIUS server. If NAS-Port-Type is not specified, the firewall uses the access port type obtained. To specify the NAS-Port-Type value for an interface: Step Command Remarks 1. Enter system view. system-view N/A 121

129 Step Command Remarks 2. Enter interface view. 3. Specify the NAS-Port-Type value for the interface. interface interface-type interface-number portal nas-port-type { ethernet wireless } N/A Not configured by default. Specifying a NAS ID profile for an interface In some networks, users' access points are identified by their access VLANs. Network carriers need to use NAS-identifiers to identify user access points. With a NAS ID profile specified on an interface, when a user logs in from the interface, the access device will check the specified profile to obtain the NAS ID that is bound with the access VLAN. The value of this NAS ID will be used as that of the NAS-identifier attribute in the RADIUS packets to be sent to the RADIUS server. A NAS ID profile defines the binding relationship between VLANs and NAS IDs. A NAS ID-VLAN binding is defined by the nas-id nas-identifier bind vlan vlan-id command. If no NAS-ID profile is specified for an interface or no matching binding is found in the specified profile, the firewall uses the device name as the interface NAS ID. To configure a NAS ID profile for an interface: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a NAS ID profile and enter NAS ID profile view. 3. Bind a NAS ID with a VLAN. aaa nas-id profile profile-name nas-id nas-identifier bind vlan vlan-id For more information about this command, see Access Control Command Reference. For more information about this command, see Access Control Command Reference. 4. Return to system view. quit N/A 5. Enter interface view. 6. Specify a NAS ID profile for the interface. interface interface-type interface-number portal nas-id-profile profile-name N/A By default, an interface is specified with no NAS ID profile. Specifying a source IP address for outgoing portal packets After you specify a source IP address for outgoing portal packets on an interface, the IP address is used as the source IP address of packets that the access device sends to the portal server, and the destination IP address of packets that the portal server sends to the access device. To specify a source IP address for outgoing portal packets: 122

130 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Specify a source IP address for outgoing portal packets. interface interface-type interface-number portal nas-ip ip-address N/A Optional. By default, no source IP address is specified and the IP address of the user logon interface is used as the source IP address of the outgoing portal packets. In NAT environments, HP recommends specifying the interface's public IP address as the source IP address of outgoing portal packets. Specifying an auto redirection URL for authenticated portal users After a user passes portal authentication, if the access device is configured with an auto redirection URL, it redirects the user to the URL. To specify an auto redirection URL for authenticated portal users: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify an auto redirection URL for authenticated portal users. portal redirect-url url-string By default, an authenticated user is redirected to the URL the user typed in the address bar before portal authentication. NOTE: To use this feature for remote Layer 3 portal authentication, the portal server must be the IMC portal server and the IMC portal server must support the page auto-redirection function. Configuring portal detection functions Configuring online Layer 3 portal user detection This feature is available only for the direct and re-dhcp portal authentication configured on a Layer 3 interface. With online portal user detection enabled on an interface, the firewall will periodically send probe packets (ARP requests) to the portal users of the interface to check whether the portal users are still online, to find out portal users who get offline without logging off. If the firewall receives a reply from a portal user before sending probe packets to the portal user for the maximum number of times, it considers that the portal user is online and will keep sending probe packets to the portal user. 123

131 If the firewall receives no reply from a portal user after sending probe packets to the portal user for the maximum number of times, it considers that the portal user is offline and will stop sending probe packets to the portal user and delete the user. To configure online Layer 3 portal user detection: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter interface view. 3. Configure online Layer 3 portal user detection. interface interface-type interface-number access-user detect type arp retransmit number interval interval N/A Not configured by default. NOTE: Adjust the maximum number of transmission attempts and the interval of sending probe packets according to the actual network conditions. Configuring the portal server detection function During portal authentication, if the communication between the access device and portal server is broken off, new portal users will not be able to log on and the online portal users will not be able to log off normally. To address this problem, the access device needs to be able to detect the reachability changes of the portal server quickly and take corresponding actions to deal with the changes. For example, once detecting that the portal server is unreachable, the access device will allow portal users to access network resources without authentication. This function is referred to as portal authentication bypass. It allows for flexible user access control. With the portal server detection function, the access device can detect the status of a specific portal server. The specific configurations include: Detection methods (you can choose either or both) Probing HTTP connections: The access device periodically sends TCP connection requests to the HTTP service port of the portal servers configured on its interfaces. If the TCP connection with a portal server can be established, the access device considers that the probe succeeds (the HTTP service of the portal server is open and the portal server is reachable). If the TCP connection cannot be established, the access device considers that the probe fails and the portal server is unreachable. Probing portal heartbeat packets: A portal server that supports the portal heartbeat function (currently only the portal server of IMC supports this function) sends portal heartbeat packets to portal access devices periodically. If an access device receives a portal heartbeat packet or an authentication packet within a probe interval, the access device considers that the probe succeeds and the portal server is reachable; otherwise, it considers that the probe fails and the portal server is unreachable. Probe parameters Probe interval: Interval at which probe attempts are made. Maximum number of probe attempts: Maximum number of consecutive probe attempts allowed. If the number of consecutive probes reaches this value, the access device considers that the portal server is unreachable. Actions to be taken when the server reachability status changes (you can choose one or more) 124

132 Sending a trap message: When the status of a portal server changes, the access device sends a trap message to the network management server (NMS). The trap message contains the portal server name and the current state of the portal server. Sending a log: When the status of a portal server changes, the access device sends a log message. The log message indicates the portal server name and the current state and original state of the portal server. Disabling portal authentication enabling portal authentication bypass: When the access device detects that a portal server is unreachable, it disables portal authentication on the interfaces that use the portal server (allows all portal users on the interfaces to access network resources). When the access device receives from the portal server portal heartbeat packets or authentication packets (such as logon requests and logout requests), it re-enables the portal authentication function. You can configure any combination of the configuration items described as needed, with respect to the following: If both detection methods are specified, a portal server will be regarded as unreachable as long as one detection method fails, and an unreachable portal server will be regarded as recovered only when both detection methods succeed. If multiple actions are specified, the access device will execute all the specified actions when the status of a portal server changes. The detection function configured for a portal server takes effect on an interface only after you enable portal authentication and reference the portal server on the interface. To configure the portal server detection function: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the portal server detection function. portal server server-name server-detect method { http portal-heartbeat } * action { log permit-all trap } * [ interval interval ] [ retry retries ] Not configured by default. The portal server specified in the command must exist. NOTE: The portal heartbeat detection method works only when the portal server supports the portal server heartbeat function. Currently, only the IMC portal server supports this function. To implement detection with this method, you also need to configure the portal server heartbeat function on the IMC portal server and make sure that the product of interval and retry is greater than or equal to the portal server heartbeat interval. HP recommends configuring the interval to be greater than the portal server heartbeat interval configured on the portal server. Configuring portal user information synchronization Once the access device loses communication with a portal server, the portal user information on the access device and that on the portal server may be inconsistent after the communication resumes. To solve this problem, the firewall (access device) provides the portal user information synchronization function. This function is implemented by sending and detecting the portal synchronization packet. The process is as follows: 1. The portal server sends the online user information to the access device in a user synchronization packet at the user heartbeat interval, which is set on the portal server. 125

133 2. Upon receiving the user synchronization packet, the access device checks the user information carried in the packet with its own. If the access device finds a nonexistent user in the packet, it informs the portal server of the information and the portal server will delete the user. If the access device finds that one of its users does not appear in the user synchronization packets within N consecutive synchronization probe intervals (N is equal to the value of retries configured in the portal server user-sync command), it considers that the user does not exist on the portal server and logs the user off. To configure the portal user information synchronization function: Step Command Remarks 1. Enter system view. system-view N/A 2. Configure the portal user information synchronization function. portal server server-name user-sync [ interval interval ] [ retry retries ] Not configured by default. The portal server specified in the command must exist. This function can take effect only when the specified portal server is referenced on the interface connecting the users. NOTE: The user information synchronization function requires that a portal server supports the portal user heartbeat function (currently only the IMC portal server supports portal user heartbeat). To implement the portal user synchronization function, you also need to configure the user heartbeat function on the portal server and make sure that the product of interval and retry is greater than or equal to the portal user heartbeat interval. HP recommends configuring the interval to be greater than the portal user heartbeat interval configured on the portal server. For redundant user information on the firewall user information for users who are considered nonexistent on the portal server, the firewall deletes the information during the (N+1)th interval, where N is equal to the value of retries configured in the portal server user-sync command. Logging off portal users Logging off a user terminates the authentication process for the user or removes the user from the authenticated users list. To log off portal users: Step Command 1. Enter system view. system-view 2. Log off portal users. portal delete-user { ip-address all interface interface-type interface-number } 126

134 Displaying and maintaining portal Task Command Remarks Display the ACLs on a specific interface. Display portal connection statistics on a specific interface or all interfaces. Display information about a portal-free rule or all portal-free rules. Display the portal configuration of a specific interface. Display information about a specific portal server or all portal servers. Display portal server statistics on a specific interface or all interfaces. Display TCP spoofing statistics. Display information about portal users on a specific interface or all interfaces. Clear portal connection statistics on a specific interface or all interfaces. Clear portal server statistics on a specific interface or all interfaces. display portal acl { all dynamic static } interface interface-type interface-number [ { begin exclude include } regular-expression ] display portal connection statistics { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] display portal free-rule [ rule-number ] [ { begin exclude include } regular-expression ] display portal interface interface-type interface-number [ { begin exclude include } regular-expression ] display portal server [ server-name ] [ { begin exclude include } regular-expression ] display portal server statistics { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] display portal tcp-cheat statistics [ { begin exclude include } regular-expression ] display portal user { all interface interface-type interface-number } [ { begin exclude include } regular-expression ] reset portal connection statistics {all interface interface-type interface-number } reset portal server statistics { all interface interface-type interface-number } Available in any view Available in any view Available in any view Available in any view Available in any view Available in any view Available in any view Available in any view Available in user view Available in user view Clear TCP spoofing statistics. reset portal tcp-cheat statistics Available in user view Portal configuration examples Configuring direct portal authentication Network requirements As shown in Figure 112: The host is directly connected to the Firewall and the Firewall is configured for direct portal authentication. The host is assigned with a public network IP address either manually or through 127

135 DHCP. Before passing portal authentication, a user can access only the portal server. After passing portal authentication, the user can access Internet resources. A RADIUS server serves as the authentication, authorization, and accounting server. Figure 112 Network diagram GE0/ /24 GE0/ /24 Portal server /24 Host /24 Gateway : /24 Firewall RADIUS server /24 Configuration procedure NOTE: Configure IP addresses for the host, firewall, and servers as shown in Figure 112 and make sure that they can reach each other. Configure the RADIUS server properly to provide authentication and accounting functions for users. 1. Configure the portal server. NOTE: This example assumes that the portal server runs IMC PLAT 5.0-E0101L02 and IMC UAM 5.0-E0101. # Configure the portal server. Log on to the IMC management platform and select the Service tab. Then, select Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 113. Configure the portal parameters as needed. This example uses the default values. 128

136 Figure 113 Portal server configuration # Configure the IP address group. Select Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page. Click Add to enter the page shown in Figure 114. Enter the IP group name. Enter the start IP address and end IP address of the IP group. Make sure that the IP address of the user host ( ) is in the IP group. Select a service group. By default, the group Ungrouped is used. Select the IP group type Normal. Figure 114 Adding an IP address group # Add a portal device. 129

137 Select Portal Service Management > Device from the navigation tree to enter the portal device configuration page. Click Add to enter the page shown in Figure 115. Enter the device name NAS. Enter the IP address of the Firewall's interface connected to the user. Enter the key, which must be the same as that configured on the Firewall. Set whether to enable IP address reallocation. Direct portal authentication is used in this example, and therefore select No from the Reallocate IP list. Set whether to support the portal server heartbeat and user heartbeat functions. In this example, select No for both Support Server Heartbeat and Support User Heartbeat. Figure 115 Adding a portal device # Associate the portal device with the IP address group. As shown in Figure 116, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page. Figure 116 Device list On the port group configuration page, click Add to enter the page for adding a port group, as shown in Figure 117. Perform the following configurations: Enter the port group name. Select the configured IP address group. The IP address used by the user to access the network must be within this IP address group. Use the default settings for other parameters. 130

138 Figure 117 Port group configuration # Select Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the Firewall. 1. Configure a RADIUS scheme # Create a RADIUS scheme named rs1 and enter its view. <Firewall> system-view [Firewall] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [Firewall-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Firewall-radius-rs1] primary authentication [Firewall-radius-rs1] primary accounting [Firewall-radius-rs1] key authentication radius [Firewall-radius-rs1] key accounting radius # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [Firewall-radius-rs1] user-name-format without-domain [Firewall-radius-rs1] quit 2. Configure an authentication domain # Create an ISP domain named dm1 and enter its view. [Firewall] domain dm1 # Configure AAA methods for the ISP domain. [Firewall-isp-dm1] authentication portal radius-scheme rs1 [Firewall-isp-dm1] authorization portal radius-scheme rs1 [Firewall-isp-dm1] accounting portal radius-scheme rs1 [Firewall-isp-dm1] quit 131

139 # Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [Firewall] domain default enable dm1 3. Configure portal authentication # Configure a portal server on the Firewall, making sure that the IP address, port number and URL match those of the actual portal server. [Firewall] portal server newpt ip key portal port url # Enable portal authentication on the interface connecting the host. [Firewall] interface GigabitEthernet 0/2 [Firewall GigabitEthernet0/2] portal server newpt method direct [Firewall GigabitEthernet0/2] quit Verifying the configuration After the above configuration, execute the following command to see whether the portal configuration has taken effect: [Firewall] display portal interface GigabitEthernet 0/2 Interface portal configuration: GigabitEthernet0/2: Portal running Portal server: newpt Authentication type: Direct Authentication domain: Authentication network: address : mask : The user can initiate portal authentication by using the HP inode client or by accessing a Web page. All the initiated Web requests will be redirected to the portal authentication page Before passing portal authentication, the user can access only the authentication page. After passing portal authentication, the user can access Internet resources. After the user passes the portal authentication, you can use the following command to view the portal user information on the Firewall. [Firewall] display portal user interface GigabitEthernet 0/2 Index:19 State:ONLINE SubState:NONE ACL:NONE Work-mode:stand-alone MAC IP Vlan Interface e9a6-7cfe GigabitEthernet 0/2 On interface GigabitEthernet0/2:total 1 user(s) matched, 1 listed. Configuring re-dhcp portal authentication Network requirements As shown in Figure 118: 132

140 The host is directly connected to the Firewall and the Firewall is configured for re-dhcp portal authentication. The host is assigned with an IP address through the DHCP server. Before passing portal authentication, the host uses an assigned private IP address. After passing portal authentication, it can get a public IP address and then the user can access Internet resources. A RADIUS server serves as the authentication/accounting server. Figure 118 Network diagram Configuration procedure NOTE: For re-dhcp authentication, configure a public address pool ( /24, in this example) and a private address pool ( /24, in this example) on the DHCP server. (Details not shown.) For re-dhcp authentication, the Firewall must be configured as a DHCP relay agent (instead of a DHCP server) and the portal-enabled interface must be configured with a primary IP address (a public IP address) and a secondary IP address (a private IP address). For information about DHCP relay agent configuration, see Network Management Configuration Guide. Make sure that the IP address of the portal device added on the portal server is the public IP address of the interface connecting users ( in this example), the private IP address range for the IP address group associated with the portal device is the private network segment where the users reside ( /24 in this example), and the public IP address range for the IP address group is the public network segment /24. Configure IP addresses for the Firewall and servers as shown in Figure 118 and make sure that the host, Firewall, and servers can reach each other. Configure the RADIUS server properly to provide authentication/accounting functions for users. 1. Configure a RADIUS scheme on the Firewall. # Create a RADIUS scheme named rs1, and enter its view. <Firewall> system-view [Firewall] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [Firewall-radius-rs1] server-type extended 133

141 # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Firewall-radius-rs1] primary authentication [Firewall-radius-rs1] primary accounting [Firewall-radius-rs1] key authentication radius [Firewall-radius-rs1] key accounting radius # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [Firewall-radius-rs1] user-name-format without-domain [Firewall-radius-rs1] quit 2. Configure an authentication domain on the Firewall. # Create an ISP domain named dm1 and enter its view. [Firewall] domain dm1 # Configure AAA methods for the ISP domain. [Firewall-isp-dm1] authentication portal radius-scheme rs1 [Firewall-isp-dm1] authorization portal radius-scheme rs1 [Firewall-isp-dm1] accounting portal radius-scheme rs1 [Firewall-isp-dm1] quit # Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [Firewall] domain default enable dm1 3. Configure portal authentication on the Firewall. # Configure the portal server as follows: Name: newpt IP address: Key: portal Port number: URL: [Firewall] portal server newpt ip key portal port url # Configure the Firewall as a DHCP relay agent, and enable the IP address check function. [Firewall] dhcp enable [Firewall] dhcp relay server-group 0 ip [Firewall] interface GigabitEthernet 0/2 [Firewall GigabitEthernet0/2] ip address [Firewall GigabitEthernet0/2] ip address sub [Firewall-GigabitEthernet0/2] dhcp select relay [Firewall-GigabitEthernet0/2] dhcp relay server-select 0 [Firewall-GigabitEthernet0/2] dhcp relay address-check enable # Enable re-dhcp portal authentication on the interface connecting the host. [Firewall GigabitEthernet0/2] portal server newpt method redhcp [Firewall GigabitEthernet0/2] quit 134

142 Configuring cross-subnet portal authentication Network requirements As shown in Figure 119: Firewall A is configured for cross-subnet portal authentication. Before passing portal authentication, a user can access only the portal server. After passing portal authentication, the user can access Internet resources. The host accesses Firewall A through Firewall B. A RADIUS server serves as the authentication/accounting server. Figure 119 Network diagram Host /24 GE0/ /24 GE0/ /24 Firewall A GE0/ /24 Firewall B GE0/ /24 Portal server /24 RADIUS server /24 Configuration procedure NOTE: Make sure that the IP address of the portal device added on the portal server is the IP address of the interface connecting users ( in this example), and the IP address group associated with the portal device is the network segment where the users reside ( /24 in this example). Configure IP addresses for the host, Firewalls, and servers as shown in Figure 119 and make sure that they can reach each other. Configure the RADIUS server properly to provide authentication/accounting functions for users. 1. Configure a RADIUS scheme on the Firewall. # Create a RADIUS scheme named rs1 and enter its view. <FirewallA> system-view [FirewallA] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [FirewallA-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [FirewallA-radius-rs1] primary authentication [FirewallA-radius-rs1] primary accounting [FirewallA-radius-rs1] key authentication radius [FirewallA-radius-rs1] key accounting radius 135

143 # Specify that the ISP domain name should not be included in the username sent to the RADIUS server. [FirewallA-radius-rs1] user-name-format without-domain [FirewallA-radius-rs1] quit 2. Configure an authentication domain on the Firewall. # Create an ISP domain named dm1 and enter its view. [FirewallA] domain dm1 # Configure AAA methods for the ISP domain. [FirewallA-isp-dm1] authentication portal radius-scheme rs1 [FirewallA-isp-dm1] authorization portal radius-scheme rs1 [FirewallA-isp-dm1] accounting portal radius-scheme rs1 [FirewallA-isp-dm1] quit # Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [FirewallA] domain default enable dm1 3. Configure portal authentication on the Firewall. # Configure the portal server as follows: Name: newpt IP address: Key: portal Port number: URL: [FirewallA] portal server newpt ip key portal port url # Enable Layer 3 portal authentication on the interface connecting Firewall B. [FirewallA] interface GigabitEthernet 0/2 [FirewallA GigabitEthernet0/2] portal server newpt method layer3 [FirewallA GigabitEthernet0/2] quit On Firewall B, configure a default route to subnet /24, setting the next hop as (Details not shown.) Configuring direct portal authentication with extended functions Network requirements As shown in Figure 120: The host is directly connected to the Firewall and the Firewall is configured for direct portal authentication. The host is assigned with a public network IP address either manually or through DHCP. If a user fails security check after passing identity authentication, the user can access only subnet /24. After the user passes security check, the user can access Internet resources. A RADIUS server serves as the authentication/accounting server. 136

144 Figure 120 Network diagram Configuration procedure NOTE: Configure IP addresses for the host, Firewall, and servers as shown in Figure 120 and make sure that routes are available between devices before extended portal is enabled. Configure the RADIUS server properly to provide authentication/accounting functions for users. 1. Configure a RADIUS scheme on the Firewall. # Create a RADIUS scheme named rs1 and enter its view. <Firewall> system-view [Firewall] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [Firewall-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Firewall-radius-rs1] primary authentication [Firewall-radius-rs1] primary accounting [Firewall-radius-rs1] key accounting radius [Firewall-radius-rs1] key authentication radius [Firewall-radius-rs1] user-name-format without-domain # Configure the IP address of the security policy server. [Firewall-radius-rs1] security-policy-server [Firewall-radius-rs1] quit 2. Configure an authentication domain on the Firewall. # Create an ISP domain named dm1 and enter its view. [Firewall] domain dm1 # Configure AAA methods for the ISP domain. [Firewall-isp-dm1] authentication portal radius-scheme rs1 [Firewall-isp-dm1] authorization portal radius-scheme rs1 [Firewall-isp-dm1] accounting portal radius-scheme rs1 137

145 [Firewall-isp-dm1] quit # Configure dm1 as the default ISP domain for all users. Then, if a user enters the username without the ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [Firewall] domain default enable dm1 3. On the Firewall, configure the ACL (ACL 3000 ) for resources on subnet /24 and the ACL (ACL 3001) for Internet resources. NOTE: On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [Firewall] acl number 3000 [Firewall-acl-adv-3000] rule permit ip destination [Firewall-acl-adv-3000] rule deny ip [Firewall-acl-adv-3000] quit [Firewall] acl number 3001 [Firewall-acl-adv-3001] rule permit ip [Firewall-acl-adv-3001] quit 4. Configure extended portal authentication on the Firewall: # Configure the portal server as follows: Name: newpt IP address: Key: portal Port number: URL: [Firewall] portal server newpt ip key portal port url # Enable extended portal authentication on the interface connecting the host. [Firewall] interface GigabitEthernet 0/2 [Firewall GigabitEthernet0/2] portal server newpt method direct [Firewall GigabitEthernet0/2] quit Configuring re-dhcp portal authentication with extended functions Network requirements As shown in Figure 121: The host is directly connected to the Firewall and the Firewall is configured for re-dhcp extended portal authentication. The host is assigned with an IP address through the DHCP server. Before extended portal authentication, the host uses an assigned private IP address. After passing the authentication, the host can get a public IP address. If a user fails security check after passing identity authentication, the user can access only subnet /24. After passing security check, the user can access Internet resources. A RADIUS server serves as the authentication/accounting server. 138

146 Figure 121 Network diagram Configuration procedure NOTE: For re-dhcp authentication, configure a public address pool ( /24, in this example) and a private address pool ( /24, in this example) on the DHCP server. (Details not shown.) For re-dhcp authentication, the Firewall must be configured as a DHCP relay agent (instead of a DHCP server) and the portal-enabled interface must be configured with a primary IP address (a public IP address) and a secondary IP address (a private IP address). For information about DHCP relay agent configuration, see Network Management Configuration Guide. Make sure that the IP address of the portal device added on the portal server is the public IP address of the interface connecting users ( in this example), the private IP address range for the IP address group associated with the portal device is the private network segment where the users reside ( /24 in this example), and the public IP address range for the IP address group is the public network segment /24. Configure IP addresses for the Firewall and servers as shown in Figure 121 and make sure that the host, Firewall, and servers can reach each other. Configure the RADIUS server properly to provide authentication/accounting functions for users. 1. Configure a RADIUS scheme on the Firewall. # Create a RADIUS scheme named rs1 and enter its view. <Firewall> system-view [Firewall] radius scheme rs1 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [Firewall-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Firewall-radius-rs1] primary authentication [Firewall-radius-rs1] primary accounting [Firewall-radius-rs1] key authentication radius [Firewall-radius-rs1] key accounting radius 139

147 [Firewall-radius-rs1] user-name-format without-domain # Configure the IP address of the security policy server. [Firewall-radius-rs1] security-policy-server [Firewall-radius-rs1] quit 2. Configure an authentication domain on the Firewall. # Create an ISP domain named dm1 and enter its view. [Firewall] domain dm1 # Configure AAA methods for the ISP domain. [Firewall-isp-dm1] authentication portal radius-scheme rs1 [Firewall-isp-dm1] authorization portal radius-scheme rs1 [Firewall-isp-dm1] accounting portal radius-scheme rs1 [Firewall-isp-dm1] quit # Configure dm1 as the default ISP domain for all users. Then, if a user enters the username without the ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [Firewall] domain default enable dm1 3. On the Firewall, configure the ACL (ACL 3000 ) for resources on subnet /24 and the ACL (ACL 3001) for Internet resources. NOTE: On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [Firewall] acl number 3000 [Firewall-acl-adv-3000] rule permit ip destination [Firewall-acl-adv-3000] rule deny ip [Firewall-acl-adv-3000] quit [Firewall] acl number 3001 [Firewall-acl-adv-3001] rule permit ip [Firewall-acl-adv-3001] quit 4. Configure extended portal authentication on the Firewall. # Configure the portal server as follows: Name: newpt IP address: Key: portal Port number: URL: [Firewall] portal server newpt ip key portal port url # Configure the Firewall as a DHCP relay agent, and enable the IP address check function. [Firewall] dhcp enable [Firewall] dhcp relay server-group 0 ip [Firewall] interface GigabitEthernet 0/2 [Firewall GigabitEthernet0/2] ip address [Firewall GigabitEthernet0/2] ip address sub [Firewall-GigabitEthernet0/2] dhcp select relay [Firewall-GigabitEthernet0/2] dhcp relay server-select 0 140

148 [Firewall-GigabitEthernet0/2] dhcp relay address-check enable # Enable portal authentication on the interface connecting the host. [Firewall GigabitEthernet0/2] portal server newpt method redhcp [Firewall GigabitEthernet0/2] quit Configuring cross-subnet portal authentication with extended functions Network requirements As shown in Figure 122: Firewall A is configured for cross-subnet extended portal authentication. If a user fails security check after passing identity authentication, the user can access only subnet /24. After passing the security check, the user can access Internet resources. The host accesses Firewall A through Firewall B. A RADIUS server serves as the authentication/accounting server. Figure 122 Network diagram Configuration procedure NOTE: Make sure that the IP address of the portal device added on the portal server is the IP address of the interface connecting users ( in this example), and the IP address group associated with the portal device is the network segment where the users reside ( /24 in this example). Configure IP addresses for the host, Firewalls, and servers as shown in Figure 122 and make sure that routes are available between devices. Configure the RADIUS server properly to provide authentication/accounting functions for users. 1. Configure a RADIUS scheme on Firewall A. # Create a RADIUS scheme named rs1 and enter its view. <FirewallA> system-view [FirewallA] radius scheme rs1 141

149 # Set the server type for the RADIUS scheme. When using the IMC server, set the server type to extended. [FirewallA-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [FirewallA-radius-rs1] primary authentication [FirewallA-radius-rs1] primary accounting [FirewallA-radius-rs1] key authentication radius [FirewallA-radius-rs1] key accounting radius [FirewallA-radius-rs1] user-name-format without-domain # Configure the IP address of the security policy server. [FirewallA-radius-rs1] security-policy-server [FirewallA-radius-rs1] quit 2. Configure an authentication domain on Firewall A. # Create an ISP domain named dm1 and enter its view. [FirewallA] domain dm1 # Configure AAA methods for the ISP domain. [FirewallA-isp-dm1] authentication portal radius-scheme rs1 [FirewallA-isp-dm1] authorization portal radius-scheme rs1 [FirewallA-isp-dm1] accounting portal radius-scheme rs1 [FirewallA-isp-dm1] quit # Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [FirewallA] domain default enable dm1 3. On Firewall A, configure the ACL (ACL 3000 ) for resources on subnet /24 and the ACL (ACL 3001) for Internet resources. NOTE: On the security policy server, specify ACL 3000 as the isolation ACL and ACL 3001 as the security ACL. [FirewallA] acl number 3000 [FirewallA-acl-adv-3000] rule permit ip destination [FirewallA-acl-adv-3000] rule deny ip [FirewallA-acl-adv-3000] quit [FirewallA] acl number 3001 [FirewallA-acl-adv-3001] rule permit ip [FirewallA-acl-adv-3001] quit 4. Configure extended portal authentication on Firewall A. # Configure the portal server as follows: Name: newpt IP address: Key: portal Port number: URL: 142

150 [FirewallA] portal server newpt ip key portal port url # Enable portal authentication on the interface connecting Firewall B. [FirewallA] interface GigabitEthernet 0/2 [FirewallA GigabitEthernet0/2] portal server newpt method layer3 [FirewallA GigabitEthernet0/2] quit On Firewall B, configure a default route to subnet /24, setting the next hop as (Details not shown.) Configuring portal server detection and portal user information synchronization Network requirements As shown in Figure 123, a host is directly connected to a Firewall (the access device) and must pass portal authentication before it can access the Internet. A RADIUS server serves as the authentication/accounting server. Detailed requirements are as follows: The host is assigned with a public network IP address either manually or through DHCP. Before passing portal authentication, the host can access only the portal server. After passing portal authentication, the host can access the Internet. The access device (Firewall) can detect whether the portal server is reachable and send trap messages upon state changes. When the portal server is unreachable due to, for example, a connection failure, network device failure, or portal server failure, the access device can disable portal authentication, allowing users to access the Internet without authentication. The access device can synchronize portal user information with the portal server periodically. Figure 123 Network diagram Configuration considerations 1. Configure the portal server and enable portal server heartbeat function and the portal user heartbeat function. 2. Configure the RADIUS server to implement authentication and accounting. 3. Configure direct portal authentication on interface GigabitEthernet 0/2, which is directly connected with the host. 143

151 4. Configure the portal server detection function on the access device, so that the access device can detect the status of the portal server by cooperating with the portal server heartbeat function. 5. Configure the portal user information synchronization function, so that the access device can synchronize portal user information with the portal server by cooperating with the portal user heartbeat function. NOTE: Configure IP addresses for the host, Firewall, and servers as shown in Figure 123 and make sure that they can reach each other. Configure the RADIUS server properly to provide authentication/accounting functions for users. Configuring the portal server. NOTE: This example assumes that the portal server runs on IMC PLAT 5.0-E0101L02 and IMC UAM 5.0-E0101. # Configure the portal server. Log in to IMC and select the Service tab. Then, select Portal Service Management > Server from the navigation tree to enter the portal server configuration page, as shown in Figure 124. Configure the portal server heartbeat interval and user heartbeat interval. Use the default value for other parameters. Figure 124 Portal server configuration # Configure an IP address group. Select Portal Service Management > IP Group from the navigation tree to enter the portal IP address group configuration page. Click Add to enter the pageshown in Figure

152 Enter the IP group name. Enter the start IP address and end IP address of the IP address group. Make sure that the IP address of the user host is within this IP address group. Select a service group. By default, the group Ungrouped is used. Select the IP group type Normal. Figure 125 Adding an IP address group # Add a portal device. Select Portal Service Management > Device from the navigation tree to enter the portal device configuration page. Click Add to enter the page shown in Figure 126. Enter the device name NAS. Enter the IP address of the Firewall's interface connected to the host. Enter the key, which must be the same as that configured on the Firewall. Set whether to enable IP address reallocation. Direct portal authentication is used in this example, and therefore select No from the Reallocate IP list. Set whether to support the portal server heartbeat and user heartbeat functions. In this example, select Yes for both Support Server Heartbeat and Support User Heartbeat. 145

153 Figure 126 Adding a portal device # Associate the portal device with the IP address group. As shown in Figure 127, click the icon in the Port Group Information Management column of device NAS to enter the port group configuration page. Figure 127 Device list On the port group configuration page, click Add to enter the page shown in Figure 128. Perform the following configurations: Enter the port group name. Select the configured IP address group. The IP address used by a user to access the network must be within this IP address group. Use the default settings for other parameters. 146

154 Figure 128 Adding a port group # Select Service Parameters > Validate System Configuration from the navigation tree to validate the configurations. Configuring the Firewall. 1. Configure a RADIUS scheme # Create RADIUS scheme rs1 and enter its view. <Firewall> system-view [Firewall] radius scheme rs1 # Configure the server type for the RADIUS scheme. When using the IMC server, configure the RADIUS server type as extended. [Firewall-radius-rs1] server-type extended # Specify the primary authentication server and primary accounting server, and configure the keys for communication with the servers. [Firewall-radius-rs1] primary authentication [Firewall-radius-rs1] primary accounting [Firewall-radius-rs1] key authentication radius [Firewall-radius-rs1] key accounting radius # Configure the access device to not carry the ISP domain name in the username sent to the RADIUS server. [Firewall-radius-rs1] user-name-format without-domain [Firewall-radius-rs1] quit 2. Configure an authentication domain # Create ISP domain dm1 and enter its view. [Firewall] domain dm1 # Configure AAA methods for the ISP domain. [Firewall-isp-dm1] authentication portal radius-scheme rs1 [Firewall-isp-dm1] authorization portal radius-scheme rs1 [Firewall-isp-dm1] accounting portal radius-scheme rs1 [Firewall-isp-dm1] quit 147

155 # Configure dm1 as the default ISP domain for all users. Then, if a user enters a username without any ISP domain at logon, the authentication and accounting methods of the default domain will be used for the user. [Firewall] domain default enable dm1 3. Configure portal authentication # Configure a portal server on the Firewall, making sure that the IP address, port number and URL match those of the actual portal server. [Firewall] portal server newpt ip key portal port url # Enable portal authentication on the interface connecting the host. [Firewall] interface GigabitEthernet 0/2 [Firewall GigabitEthernet0/2] portal server newpt method direct [Firewall GigabitEthernet0/2] quit 4. Configure the portal server detection function # Configure the access device to detect portal server newpt, specifying the detection method as portal heartbeat probe, setting the server probe interval to 40 seconds, and specifying the access device to send a server unreachable trap message and disable portal authentication to permit unauthenticated portal users if two consecutive probes fail. [Firewall] portal server newpt server-detect method portal-heartbeat action trap permit-all interval 40 retry 2 The product of interval and retry must be greater than or equal to the portal server heartbeat interval, and HP recommends configuring the interval to be greater than the portal server heartbeat interval configured on the portal server. 5. Configure portal user information synchronization # Configure the access device to synchronize portal user information with portal server newpt, setting the synchronization probe interval to 600 seconds, and specifying the access device to log off users if the users do not appear in the user synchronization packets sent from the server within two consecutive probe intervals. [Firewall] portal server newpt user-sync interval 600 retry 2 The product of interval and retry must be greater than or equal to the portal user heartbeat interval, and HP recommends configuring the interval to be greater than the portal user heartbeat interval configured on the portal server. Verifying the configuration Perform the following command to display information about the portal server: <Firewall> display portal server newpt Portal server: 1)newpt: IP : Key : portal Port : URL : Status : Up 148

156 Troubleshooting portal Inconsistent keys on the access device and the portal server Symptom Analysis Solution When a user is forced to access the portal server, the portal server displays a blank Web page, rather than the portal authentication page or an error message. The keys configured on the access device and the portal server are inconsistent, causing CHAP message exchange failure. As a result, the portal server does not display the authentication page. Use the display portal server command to display the key for the portal server on the access device and view the key for the access device on the portal server. Use the portal server command to modify the key on the access device or modify the key for the access device on the portal server to make sure that the keys are consistent. Incorrect server port number on the access device Symptom Analysis Solution After a user passes the portal authentication, you cannot force the user to log off by executing the portal delete-user command on the access device, but the user can log off by using the disconnect attribute on the authentication client. When you execute the portal delete-user command on the access device to force the user to log off, the access device actively sends a REQ_LOGOUT message to the portal server. The default listening port of the portal server is However, if the listening port configured on the access device is not 50100, the destination port of the REQ_LOGOUT message is not the actual listening port on the server, and the portal server cannot receive the REQ_LOGOUT message. As a result, you cannot force the user to log off the portal server. When the user uses the disconnect attribute on the client to log off, the portal server actively sends a REQ_LOGOUT message to the access device. The source port is and the destination port of the ACK_LOGOUT message from the access device is the source port of the REQ_LOGOUT message so that the portal server can receive the ACK_LOGOUT message correctly, no matter whether the listening port is configured on the access device. The user can log off the portal server. Use the display portal server command to display the listening port of the portal server configured on the access device and use the portal server command in the system view to modify it to make sure that it is the actual listening port of the portal server. 149

157 Configuring AAA Feature and hardware compatibility Feature F1000-A-EI/S-EI F1000-E F5000 Firewall module FIPS No No No Yes DVPN users No Yes Yes Yes SSL VPN users Yes Yes No No AAA overview Authentication, Authorization, and Accounting (AAA) provides a uniform framework for implementing network access management. It can provide the following security functions: Authentication Identifies users and determines whether a user is valid. Authorization Grants different users different rights and controls their access to resources and services. For example, a user who has successfully logged in to the network access server (NAS) can be granted read and print permissions to the files on the NAS. Accounting Records all network service usage information of users, including the service type, start time, and traffic. The accounting function not only provides the information required for charging, but also allows for network security surveillance. AAA usually uses a client/server model. The client runs on the network access server (NAS) and the server maintains user information centrally. In an AAA network, a NAS is a server for users but a client for the AAA servers. See Figure 129. Figure 129 Network diagram for AAA When a user tries to log in to the NAS, use network resources, or access other networks, the NAS authenticates the user. The NAS can transparently pass the user's authentication, authorization, and accounting information to the servers. The RADIUS and HWTACACS protocols define how a NAS and a remote server exchange user information between them. 150

158 RADIUS In the network shown in Figure 129, there is a RADIUS server and an HWTACACS server. You can choose different servers for different security functions. For example, you can use the HWTACACS server for authentication and authorization, and the RADIUS server for accounting. You can choose the three security functions provided by AAA as needed. For example, if your company only wants employees to be authenticated before they access specific resources, configure an authentication server. If network usage information is needed, configure an accounting server. AAA can be implemented through multiple protocols. The firewall supports using RADIUS and HWTACACS. RADIUS is often used in practice. Remote Authentication Dial-In User Service (RADIUS) is a distributed information interaction protocol that uses a client/server model. It can protect networks against unauthorized access and is often used in network environments where both high security and remote user access are required. RADIUS uses UDP as the transport protocol. It uses UDP port 1812 for authentication and UDP port 1813 for accounting. RADIUS was originally designed for dial-in user access. With the addition of new access methods, RADIUS has been extended to support additional access methods, such as Ethernet and ADSL. RADIUS provides access authentication and authorization services, and its accounting function collects and records network resource usage information. Client/server model The RADIUS client runs on the NASs located throughout the network. It passes user information to designated RADIUS servers and acts on the responses (for example, rejects or accepts user access requests). The RADIUS server runs on the computer or workstation at the network center and maintains information related to user authentication and network service access. It listens to connection requests, authenticates users, and returns user access control information (for example, rejecting or accepting the user access request) to the clients. In general, the RADIUS server maintains the following databases: Users, Clients, and Dictionary. See Figure 130. Figure 130 RADIUS server components Users Stores user information such as the usernames, passwords, applied protocols, and IP addresses. Clients Stores information about RADIUS clients, such as shared keys and IP addresses. Dictionary Stores RADIUS protocol attributes and their values. Security and authentication mechanisms RADIUS uses a shared key that is never transmitted over the network to authenticate information exchanged between a RADIUS client and the RADIUS server, enhancing the information exchange 151

159 security. In addition, to prevent user passwords from being intercepted on insecure networks, RADIUS encrypts passwords before transmitting them. A RADIUS server supports multiple user authentication methods, such as the Password Authentication Protocol (PAP) and the Challenge Handshake Authentication Protocol (CHAP) of the Point-to-Point Protocol (PPP). Moreover, a RADIUS server can act as the client of another AAA server to provide authentication proxy services. RADIUS basic message exchange process Figure 131 illustrates the interaction between the host, the RADIUS client, and the RADIUS server. Figure 131 RADIUS basic message exchange process RADIUS operates in the following manner: 1. The host initiates a connection request that carries the user's username and password to the RADIUS client. 2. Having received the username and password, the RADIUS client sends an authentication request (Access-Request) to the RADIUS server, with the user password encrypted by using the Message-Digest 5 (MD5) algorithm and the shared key. 3. The RADIUS server authenticates the username and password. If the authentication succeeds, the server sends back an Access-Accept message containing the user's authorization information. If the authentication fails, the server returns an Access-Reject message. 4. The RADIUS client permits or denies the user according to the returned authentication result. If it permits the user, it sends a start-accounting request (Accounting-Request) to the RADIUS server. 5. The RADIUS server returns a start-accounting response (Accounting-Response) and starts accounting. 6. The user accesses the network resources. 7. The host requests the RADIUS client to tear down the connection and the RADIUS client sends a stop-accounting request (Accounting-Request) to the RADIUS server. 152

160 8. The RADIUS server returns a stop-accounting response (Accounting-Response) and stops accounting for the user. RADIUS packet format RADIUS uses UDP to transmit messages. To ensure smooth message exchange between the RADIUS server and the client, RADIUS uses a series of mechanisms, including the timer management mechanism, the retransmission mechanism, and the backup server mechanism. Figure 132 shows the RADIUS packet format. Figure 132 RADIUS packet format Descriptions of the fields are as follows: The Code field (1 byte long) indicates the type of the RADIUS packet. Table 43 gives the possible values and their meanings. Table 43 Main values of the Code field Code Packet type Description 1 Access-Request 2 Access-Accept 3 Access-Reject 4 Accounting-Request 5 Accounting-Response From the client to the server. A packet of this type carries user information for the server to authenticate the user. It must contain the User-Name attribute and can optionally contain the attributes of NAS-IP-Address, User-Password, and NAS-Port. From the server to the client. If all the attribute values carried in the Access-Request are acceptable, the authentication succeeds, and the server sends an Access-Accept response. From the server to the client. If any attribute value carried in the Access-Request is unacceptable, the authentication fails and the server sends an Access-Reject response. From the client to the server. A packet of this type carries user information for the server to start or stop accounting for the user. The Acct-Status-Type attribute in the packet indicates whether to start or stop accounting. From the server to the client. The server sends a packet of this type to notify the client that it has received the Accounting-Request and has successfully recorded the accounting information. The Identifier field (1 byte long) is used to match request packets and response packets and to detect duplicate request packets. Request and response packets of the same type have the same identifier. 153

161 The Length field (2 byte long) indicates the length of the entire packet, including the Code, Identifier, Length, Authenticator, and Attribute fields. Bytes beyond this length are considered padding and are ignored at the receiver. If the length of a received packet is less than this length, the packet is dropped. The value of this field is in the range of 20 to The Authenticator field (16 byte long) is used to authenticate replies from the RADIUS server and to encrypt user passwords. There are two types of authenticators: request authenticator and response authenticator. The Attributes field, variable in length, carries the specific authentication, authorization, and accounting information that defines the configuration details of the request or response. This field may contain multiple attributes, each with three sub-fields: Type, Length, and Value. Type ( (1 byte long) Type of the attribute. It is in the range of 1 to 255. See Table 44 for commonly used attributes for RADIUS authentication, authorization and accounting. Length (1 byte long) Length of the attribute in bytes, including the Type, Length, and Value fields. Value (Up to 253 bytes) Value of the attribute. Its format and content depend on the Type and Length fields. Table 44 Commonly used RADIUS attributes No. Attribute No. Attribute 1 User-Name 45 Acct-Authentic 2 User-Password 46 Acct-Session-Time 3 CHAP-Password 47 Acct-Input-Packets 4 NAS-IP-Address 48 Acct-Output-Packets 5 NAS-Port 49 Acct-Terminate-Cause 6 Service-Type 50 Acct-Multi-Session-Id 7 Framed-Protocol 51 Acct-Link-Count 8 Framed-IP-Address 52 Acct-Input-Gigawords 9 Framed-IP-Netmask 53 Acct-Output-Gigawords 10 Framed-Routing 54 (unassigned) 11 Filter-ID 55 Event-Timestamp 12 Framed-MTU (unassigned) 13 Framed-Compression 60 CHAP-Challenge 14 Login-IP-Host 61 NAS-Port-Type 15 Login-Service 62 Port-Limit 16 Login-TCP-Port 63 Login-LAT-Port 17 (unassigned) 64 Tunnel-Type 18 Reply-Message 65 Tunnel-Medium-Type 19 Callback-Number 66 Tunnel-Client-Endpoint 20 Callback-ID 67 Tunnel-Server-Endpoint 21 (unassigned) 68 Acct-Tunnel-Connection 22 Framed-Route 69 Tunnel-Password 154

162 No. Attribute No. Attribute 23 Framed-IPX-Network 70 ARAP-Password 24 State 71 ARAP-Features 25 Class 72 ARAP-Zone-Access 26 Vendor-Specific 73 ARAP-Security 27 Session-Timeout 74 ARAP-Security-Data 28 Idle-Timeout 75 Password-Retry 29 Termination-Action 76 Prompt 30 Called-Station-Id 77 Connect-Info 31 Calling-Station-Id 78 Configuration-Token 32 NAS-Identifier 79 EAP-Message 33 Proxy-State 80 Message-Authenticator 34 Login-LAT-Service 81 Tunnel-Private-Group-id 35 Login-LAT-Node 82 Tunnel-Assignment-id 36 Login-LAT-Group 83 Tunnel-Preference 37 Framed-AppleTalk-Link 84 ARAP-Challenge-Response 38 Framed-AppleTalk-Network 85 Acct-Interim-Interval 39 Framed-AppleTalk-Zone 86 Acct-Tunnel-Packets-Lost 40 Acct-Status-Type 87 NAS-Port-Id 41 Acct-Delay-Time 88 Framed-Pool 42 Acct-Input-Octets 89 (unassigned) 43 Acct-Output-Octets 90 Tunnel-Client-Auth-id 44 Acct-Session-Id 91 Tunnel-Server-Auth-id NOTE: The attribute types listed in Table 44 are defined in RFC 2865, RFC 2866, RFC 2867, and RFC For more information about commonly used standard RADIUS attributes, see "Commonly used standard RADIUS attributes." Extended RADIUS attributes The RADIUS protocol features excellent extensibility. Attribute 26 (Vendor-Specific), an attribute defined by RFC 2865, allows a vendor to define extended attributes to implement functions that the standard RADIUS protocol does not provide. A vendor can encapsulate multiple sub-attributes in the type-length-value (TLV) format in RADIUS packets for extension of applications. As shown in Figure 133, a sub-attribute encapsulated in Attribute 26 consists of the following parts: Vendor-ID Indicates the ID of the vendor. Its most significant byte is 0, and the other three bytes contains a code that is compliant to RFC The vendor ID of HP is For more information about the proprietary RADIUS sub-attributes of HP, see "Proprietary RADIUS sub-attributes of HP." Vendor-Type Indicates the type of the sub-attribute. 155

163 Vendor-Length Indicates the length of the sub-attribute. Vendor-Data Indicates the contents of the sub-attribute. Figure 133 Segment of a RADIUS packet containing an extended attribute HWTACACS HW Terminal Access Controller Access Control System (HWTACACS) is an enhanced security protocol based on TACACS (RFC 1492). Similar to RADIUS, it uses a client/server model for information exchange between the NAS and the HWTACACS server. HWTACACS typically provides AAA services for Point-to-Point Protocol (PPP) users, Virtual Private Dial-up Network (VPDN) users, and terminal users. In a typical HWTACACS scenario, some terminal users log in to the NAS for operations. Working as the HWTACACS client, the NAS sends the usernames and passwords of the users to the HWTACACS sever for authentication. After passing authentication and being authorized, the users log in to the NAS and performs operations, and the HWTACACS server records the operations that each user performs. Differences between HWTACACS and RADIUS HWTACACS and RADIUS both provide authentication, authorization, and accounting services. They have many features in common, such as using a client/server model, using shared keys for user information security, and providing flexibility and extensibility. Table 45 lists the differences. Table 45 Primary differences between HWTACACS and RADIUS HWTACACS Uses TCP, providing more reliable network transmission. Encrypts the entire packet except for the HWTACACS header. Protocol packets are complicated and authorization is independent of authentication. Authentication and authorization can be deployed on different HWTACACS servers. Supports authorization of configuration commands. Which commands a user can use depends on both the user level and the AAA authorization. A user can use only commands that are at, or lower than, the user level and authorized by the HWTACACS server. RADIUS Uses UDP, providing higher transport efficiency. Encrypts only the user password field in an authentication packet. Protocol packets are simple and the authorization process is combined with the authentication process. Does not support authorization of configuration commands. Which commands a user can use solely depends on the level of the user. A user can use all the commands at, or lower than, the user level. 156

164 HWTACACS basic message exchange process The following example describes how HWTACACS performs user authentication, authorization, and accounting for a Telnet user. Figure 134 HWTACACS basic message exchange process for a Telnet user Host HWTACACS client HWTACACS server 1) The user logs in 2) Start-authentication packet 3) Authentication response requesting the username 4) Request for username 5) The user inputs the username 6) Authentication continuance packet with the username 7) Authentication response requesting the login password 8) Request for password 9) The user inputs the password 10) Authentication continuance packet with the login password 11) Authentication response indicating successful authentication 12) User authorization request packet 14) The user logs in successfully 13) Authorization response indicating successful authorization 15) Start-accounting request 16) Accounting response indicating the start of accounting 17) The user logs off 18) Stop-accounting request 19) Stop-accounting response HWTACACS operates in the following manner: 1. A Telnet user sends an access request to the HWTACACS client. 2. Upon receiving the request, the HWTACACS client sends a start-authentication packet to the HWTACACS server. 3. The HWTACACS server sends back an authentication response to request the username. 4. Upon receiving the response, the HWTACACS client asks the user for the username. 5. The user enters the username. 157

165 6. After receiving the username from the user, the HWTACACS client sends the server a continue-authentication packet that carries the username. 7. The HWTACACS server sends back an authentication response, requesting the login password. 8. Upon receipt of the response, the HWTACACS client asks the user for the login password. 9. The user enters the password. 10. After receiving the login password, the HWTACACS client sends the HWTACACS server a continue-authentication packet that carries the login password. 11. The HWTACACS server sends back an authentication response to indicate that the user has passed authentication. 12. The HWTACACS client sends the user authorization request packet to the HWTACACS server. 13. The HWTACACS server sends back the authorization response, indicating that the user is now authorized. 14. Knowing that the user is now authorized, the HWTACACS client pushes its configuration interface to the user. 15. The HWTACACS client sends a start-accounting request to the HWTACACS server. 16. The HWTACACS server sends back an accounting response, indicating that it has received the start-accounting request. 17. The user logs off. 18. The HWTACACS client sends a stop-accounting request to the HWTACACS server. 19. The HWTACACS server sends back a stop-accounting response, indicating that the stop-accounting request has been received. Domain-based user management A NAS manages users based on Internet service provider (ISP) domains. On a NAS, each user belongs to one ISP domain. A NAS determines the ISP domain a user belongs to by the username entered by the user at login, as shown in Figure 135. Figure 135 Determining the ISP domain of a user by the username The authentication, authorization, and accounting process of a user depends on the AAA methods configured for the domain to which the user belongs. If no specific AAA methods are configured for the domain, the default methods are used. By default, a domain uses local authentication, local authorization, and local accounting. AAA allows you to manage users based on their access types: 158

166 LAN users Users on a LAN who must pass 802.1X authentication or MAC address authentication to access the network. DVPN users. Login users Users who want to log in to the NAS, including SSH users, Telnet users, Web users, FTP users, and terminal users. Portal users Users who must pass portal authentication to access the network. PPP users Users who access through PPP. SSL VPN users Users who access through SSL VPN. In addition, AAA provides the following services for login users to enhance device security: Command authorization Enables the NAS to defer to the authorization server to determine whether a command entered by a login user is permitted for the user, making sure that login users execute only commands they are authorized to execute. For more information about command authorization, see Getting Started Guide. Command accounting Allows the accounting server to record all commands executed on the NAS or all authorized commands successfully executed. For more information about command accounting, see Getting Started Guide. Level switching authentication Allows the authentication server to authenticate users who perform privilege level switching. As long as passing level switching authentication, users can switch their user privilege levels, without logging out and disconnecting current connections. For more information about user privilege level switching, see Getting Started Guide. You can configure different authentication, authorization, and accounting methods for different users in a domain. See "HWTACACS scheme configuration guidelines" AAA across VPNs In a VPN scenario where clients in different VPNs are centrally authenticated, you can deploy AAA across VPNs to enable forwarding of RADIUS and HWTACACS packets across VPNs. As shown in Figure 136, the PE at the left side of the MPLS backbone serves as a NAS and transparently delivers the AAA packets of private users in VPN 1 and VPN 2 to the AAA servers in VPN 3 for centralized authentication. Authentication packets of private users in different VPNs do not affect each other. Figure 136 Network diagram for AAA across VPNs VPN 1 Host NAS MPLS backbone VPN 3 RADIUS server VPN 2 MCE PE P PE CE Host HWTACACS server 159

167 NOTE: Together with the AAA across VPNs feature, you can implement portal authentication across VPNs on MCEs. Protocols and standards The following protocols and standards are related to AAA, RADIUS, and HWTACACS: RFC 2865, Remote Authentication Dial In User Service (RADIUS) RFC 2866, RADIUS Accounting RFC 2867, RADIUS Accounting Modifications for Tunnel Protocol Support RFC 2868, RADIUS Attributes for Tunnel Protocol Support RFC 2869, RADIUS Extensions RFC 1492, An Access Control Protocol, Sometimes Called TACACS RADIUS attributes Commonly used standard RADIUS attributes Table 46 Commonly used standard RADIUS attributes No. Attribute Description 1 User-Name Name of the user to be authenticated. 2 User-Password 3 CHAP-Password 4 NAS-IP-Address User password for PAP authentication, present only in Access-Request packets in PAP authentication mode. Digest of the user password for CHAP authentication, present only in Access-Request packets in CHAP authentication mode. IP address for the server to identify a client. Usually, a client is identified by the IP address of the access interface of the NAS, namely the NAS IP address. This attribute is present in only Access-Request packets. 5 NAS-Port Physical port of the NAS that the user accesses. 6 Service-Type Type of service that the user has requested or type of service to be provided. 7 Framed-Protocol Encapsulation protocol for framed access. 8 Framed-IP-Address IP address assigned to the user. 11 Filter-ID Name of the filter list. 12 Framed-MTU Maximum transmission unit (MTU) for the data link between the user and NAS. 14 Login-IP-Host IP address of the NAS interface that the user accesses. 15 Login-Service Type of the service that the user uses for login. 18 Reply-Message 26 Vendor-Specific 27 Session-Timeout Text to be displayed to the user, which can be used by the server to indicate, for example, the reason of the authentication failure. Vendor specific attribute. A packet can contain one or more such proprietary attributes, each of which can contain one or more sub-attributes. Maximum duration of service to be provided to the user before termination of the session. 160

168 No. Attribute Description 28 Idle-Timeout Maximum idle time permitted for the user before termination of the session. 31 Calling-Station-Id Identification of the user that the NAS sends to the server. 32 NAS-Identifier Identification that the NAS uses for indicating itself. 40 Acct-Status-Type 45 Acct-Authentic 60 CHAP-Challenge 61 NAS-Port-Type 79 EAP-Message Type of the Accounting-Request packet. Possible values are as follows: 1 Start 2 Stop 3 Interium-Update 4 Reset-Charge 7 Accounting-On (Defined in 3GPP, the 3rd Generation Partnership Project) 8 Accounting-Off (Defined in 3GPP) 9 to 14 Reserved for tunnel accounting 15 Reserved for failed Authentication method used by the user. Possible values are as follows: 1 RADIUS 2 Local 3 Remote CHAP challenge generated by the NAS for MD5 calculation during CHAP authentication. Type of the physical port of the NAS that is authenticating the user. Possible values are as follows: 15 Ethernet 16 Any type of ADSL 17 Cable (with cable for cable TV) 201 VLAN 202 ATM If the port is an ATM or Ethernet one and VLANs are implemented on it, the value of this attribute is 201. Used for encapsulating EAP packets to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol. 80 Message-Authentic ator Used for authentication and checking of authentication packets to prevent spoofing Access-Requests. This attribute is used when RADIUS supports EAP authentication. 87 NAS-Port-Id String for describing the port of the NAS that is authenticating the user. Proprietary RADIUS sub-attributes of HP Table 47 Proprietary RADIUS sub-attributes of HP No. Sub-attribute Description 1 Input-Peak-Rate Peak rate in the direction from the user to the NAS, in bps. 2 Input-Average-Rate Average rate in the direction from the user to the NAS, in bps. 3 Input-Basic-Rate Basic rate in the direction from the user to the NAS, in bps. 4 Output-Peak-Rate Peak rate in the direction from the NAS to the user, in bps. 161

169 No. Sub-attribute Description 5 Output-Average-Rate Average rate in the direction from the NAS to the user, in bps. 6 Output-Basic-Rate Basic rate in the direction from the NAS to the user, in bps. 15 Remanent_Volume 20 Command 24 Control_Identifier Remaining, available total traffic of the connection, in different units for different server types. Operation for the session, used for session control. It can be: 1 Trigger-Request 2 Terminate-Request 3 SetPolicy 4 Result 5 PortalClear Identification for retransmitted packets. For retransmitted packets of the same session, this attribute must take the same value. For retransmitted packets of different sessions, this attribute may take the same value. The client response of a retransmitted packet must also carry this attribute and the value of the attribute must be the same. For Accounting-Request packets of the start, stop, and interim update types, the Control-Identifier attribute is ineffective. 25 Result_Code Result of the Trigger-Request or SetPolicy operation. A value of zero means the operation succeeded, and any other value means the operation failed. 26 Connect_ID Index of the user connection. 28 Ftp_Directory Working directory of the FTP user. For an FTP user, when the RADIUS client acts as the FTP server, this attribute is used to set the FTP directory on the RADIUS client. 29 Exec_Privilege Priority of the EXEC user 59 NAS_Startup_Timestam p Startup time of the NAS in seconds, which is represented by the time elapsed after 00:00:00 on Jan. 1, 1970 (UTC). 60 Ip_Host_Addr User IP address and MAC address carried in authentication and accounting requests, in the format A.B.C.D hh:hh:hh:hh:hh:hh. A space is required between the IP address and the MAC address. 61 User_Notify Information to be transparently sent from the server to the client. 62 User_HeartBeat 140 User_Group Hash value assigned after an 802.1X user passes authentication, which is a 32-byte string. This attribute is stored in the user list on the NAS and is used for verifying the handshake messages from the 802.1X user. This attribute exists in only Access-Accept and Accounting-Request packets. User groups assigned after the SSL VPN user passes authentication. A user may belong to more than one user group. In this case, the user groups are delimited by semi-colons. This attribute is used for cooperation with the SSL VPN device. 141 Security_Level Security level assigned after the SSL VPN user passes security authentication. 201 Input-Interval-Octets Bytes input within a real-time accounting interval. 202 Output-Interval-Octets Bytes output within a real-time accounting interval. 203 Input-Interval-Packets Packets input within an accounting interval, in the unit set on the device. 204 Output-Interval-Packets Packets output within an accounting interval, in the unit set on the device. 162

170 No. Sub-attribute Description Input-Interval-Gigaword s Output-Interval-Gigawo rds Result of bytes input within an accounting interval divided by 4G bytes. Result of bytes output within an accounting interval divided by 4G bytes. 207 Backup-NAS-IP Backup source IP address for sending RADIUS packets. 255 Product_ID Product name. AAA configuration considerations and task list To configure AAA, you must complete these tasks on the NAS: 1. Configure the required AAA schemes. Local authentication Configure local users and the related attributes, including the usernames and passwords of the users to be authenticated. Remote authentication Configure the required RADIUS, and HWTACACS schemes. You must configure user attributes on the servers accordingly. 2. Configure AAA methods for the users' ISP domains. Authentication method No authentication (none), local authentication (local), or remote authentication (scheme) Authorization method No authorization (none), local authorization (local), or remote authorization (scheme) Accounting method No accounting (none), local accounting (local), or remote accounting (scheme) Figure 137 AAA configuration procedure 163

171 Table 48 AAA configuration task list Task Remarks Configuring AAA schemes Configuring AAA methods for ISP domains Configuring local users Configuring RADIUS schemes in the web interface Configuring HWTACACS schemes in the web interface Creating an ISP domain Configuring ISP domain attributes Configuring AAA authentication methods for an ISP domain Configuring AAA authorization methods for an ISP domain Configuring AAA accounting methods for an ISP domain Required. Complete at least one task. Required. Optional. Required. Complete at least one task. Forcibly tearing down user connections Configuring a NAS ID-VLAN binding Displaying and maintaining AAA Optional. Optional. Optional. NOTE: To use AAA methods to control access of login users, you must configure the login authentication mode for the user interfaces as scheme by using the authentication-mode command. Configuring AAA schemes Configuring local users To implement local user authentication, authorization, and accounting, you must create local users and configure user attributes on the firewall. The local users and attributes are stored in the local user database on the firewall. A local user is uniquely identified by a username. Configurable local user attributes are as follows: Service type The types of the services that the user can use. Local authentication checks the service types of a local user. If none of the service types is available, the user cannot pass authentication. Service types include DVPN, FTP, portal, PPP, SSH, Telnet, terminal, and Web. In FIPS mode, the firewall does not support FTP and Telnet service types. User state Indicates whether or not a local user can request network services. There are two user states: active and blocked. A user in active state can request network services, but a user in blocked state cannot. Maximum number of users using the same local user account Indicates how many users can use the same local user account for local authentication. 164

172 Validity time and expiration time Indicates the validity time and expiration time of a local user account. A user must use a valid local user account to pass local authentication. When some users need to access the network temporarily, you can create a guest account and specify a validity time and an expiration time for the account to control the validity of the account. User group Each local user belongs to a local user group and bears all attributes of the group, such as the password control attributes and authorization attributes. For more information about local user group, see "Configuring user group attributes." Password control attributes Password control attributes help you control the security of local users' passwords. Password control attributes include password aging time, minimum password length, and password composition policy. You can configure a password control attribute in system view, user group view, or local user view, making the attribute effective for all local users, all local users in a group, or only the local user. A password control attribute with a smaller effective range has a higher priority. For more information about password management and global password configuration, see " Configuring password control." When the firewall is operating in FIPS mode, you must use the password control feature to set passwords for local users. Binding attributes Binding attributes are used for controlling the scope of users. They are checked during local authentication of a user. If the attributes of a user do not match the binding attributes configured for the local user account, the user cannot pass authentication. Binding attributes include the ISDN calling number, IP address, access port, MAC address, and native VLAN. For more information about binding attributes, see "Configuring local user attributes." Be cautious when deciding which binding attributes to configure for a local user. Authorization attributes Authorization attributes indicate the rights that a user has after passing local authentication. Authorization attributes include the ACL, PPP callback number, idle cut function, user level, user role, user profile, VLAN, and FTP/SFTP work directory. For more information about authorization attributes, see "Configuring local user attributes." Every configurable authorization attribute has its definite application environments and purposes. When you configure authorization attributes for a local user, consider which attributes are needed and which are not. For example, for PPP users, you do not need to configure the work directory attribute. You can configure an authorization attribute in user group view or local user view to make the attribute effective for all local users in the group or for only the local user. The setting of an authorization attribute in local user view takes precedence over that in user group view. Local user configuration task list Task Configuring local user attributes Configuring user group attributes Displaying and maintaining local users and local user groups Remarks Required Optional Optional 165

173 Configuring local user attributes Follow these guidelines when you configure the local user attributes: On a firewall supporting the password control feature, local user passwords are not displayed, and the local-user password-display-mode command is not effective. If you configure the local-user password-display-mode cipher-force command, all existing local user passwords are displayed in cipher text, regardless of the configuration of the password command. If you also save the configuration and restart the firewall, all existing local user passwords are always displayed in cipher text, no matter how you configure the local-user password-display-mode command or the password command. The passwords configured after you restore the display mode to auto by using the local-user password-display-mode auto command, however, are displayed as defined by the password command. The access-limit command configured for a local user takes effect only in the case of local accounting. If the user interface authentication mode (set by the authentication-mode command in user interface view) is AAA (scheme), which commands a login user can use after login depends on the privilege level authorized to the user. If the user interface authentication mode is password (password) or no authentication (none), which commands a login user can use after login depends on the level configured for the user interface (set by the user privilege level command in user interface view). For an SSH user using public key authentication, which commands are available depends on the level configured for the user interface. For more information about user interface authentication mode and user interface command level, see Getting Started Guide. You can configure the user profile authorization attribute in both local user view and ISP domain view. The setting in local user view takes precedence. To configure attributes for a local user: Step Command Remarks 1. Enter system view. system-view N/A 2. Set the password display mode for all local users. 3. Add a local user and enter local user view. local-user password-display-mode { auto cipher-force } local-user user-name Optional. The default password display mode is auto for all local users, indicating to display the password of a local user in the way defined by the password command. N/A 166

174 Step Command Remarks Optional. 4. Configure a password for the local user. 5. Specify the service types for the local user. 6. Place the local user to the state of active or blocked. 7. Set the maximum number of concurrent users of the local user account. 8. Configure the password control attributes for the local user. password { cipher simple } password service-type { dvpn ftp lan-access { ssh telnet terminal } * portal ppp web } state { active block } access-limit max-user-number Set the password aging time: password-control aging aging-time Set the minimum password length: password-control length length Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] A local user with no password configured directly passes authentication after providing the valid local username and attributes. To enhance security, configure a password for each local user. In FIPS mode, the firewall does not support this command. To set a password, use the password control feature. By default, no service is authorized to a local user. In FIPS mode, the firewall does not support the ftp and telnet keywords. Optional. When created, a local user is in active state by default, and the user can request network services. Optional. By default, there is no limit to the maximum number of concurrent users of a local user account. This limit is not effective for FTP users. Optional. By default, the password control attributes of the user group to which the local user belongs apply, and any password control attribute that is not configured in the user group uses the global setting. The global settings include a 90-day password aging time, a minimum password length of 10 characters, and at least one password composition type and at least one character required for each password composition type. The minimum password length is 8 characters. In FIPS mode, the value of the type-number argument must be

175 Step Command Remarks 9. Configure the binding attributes for the local user. 10. Configure the authorization attributes for the local user. 11. Set the validity time of the local user. 12. Set the expiration time of the local user. 13. Assign the local user to a user group. bind-attribute { call-number call-number [ : subcall-number ] authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name user-role { guest guest-manager security-audit } vlan vlan-id work-directory directory-name } * validity-date time expiration-date time group group-name Optional. By default, no binding attribute is configured for a local user. This command applies only to PPP users. Optional. By default, no authorization attribute is configured for a local user. For PPP users, only acl, callback-number, idle-cut, and user-profile are supported. For portal users, only acl, idle-cut, user-profile, and vlan are supported. For SSH, terminal, and Web users, only level is supported. For FTP users, only level and work-directory are supported. For Telnet users, only level and user-role is supported. For other types of local users, no binding attribute is supported. Optional. Not set by default. Optional. Not set by default. Optional. By default, a local user belongs to the default user group system. Configuring user group attributes User groups simplify local user configuration and management. A user group comprises a group of local users and has a set of local user attributes. You can configure local user attributes for a user group to implement centralized user attributes management for the local users in the group. Configurable user attributes include password control attributes and authorization attributes. By default, every newly added local user belongs to the system default user group system and bears all attributes of the group. To change the user group to which a local user belongs, use the user-group command in local user view. To configure attributes for a user group: Step Command Remarks 1. Enter system view. system-view N/A 168

176 Step Command Remarks 2. Create a user group and enter user group view. 3. Configure password control attributes for the user group. 4. Configure the authorization attributes for the user group. 5. Set the guest attribute for the user group. user-group group-name Set the password aging time: password-control aging aging-time Set the minimum password length: password-control length length Configure the password composition policy: password-control composition type-number type-number [ type-length type-length ] authorization-attribute { acl acl-number callback-number callback-number idle-cut minute level level user-profile profile-name vlan vlan-id work-directory directory-name } * group-attribute allow-guest N/A Optional. By default, the global settings apply, including a 90-day password aging time, a minimum password length of 10 characters, and at least one password composition type and at least one character required for each password composition type. The minimum password length is 8 characters. In FIPS mode, the value of the type-number argument must be 4. Optional. By default, no authorization attribute is configured for a user group. Optional. By default, the guest attribute is not set for a user group, and guest users created by a guest manager through the web interface cannot join the group. Displaying and maintaining local users and local user groups Task Command Remarks Display local user information. Display the user group configuration information. display local-user [ idle-cut { disable enable } service-type { dvpn ftp lan-access portal ppp ssh telnet terminal web } state { active block } user-name user-name vlan vlan-id ] [ { begin exclude include } regular-expression ] display user-group [ group-name ] [ { begin exclude include } regular-expression ] Available in any view In FIPS mode, the firewall does not support ftp and telnet keywords. Available in any view Configuring RADIUS schemes in the web interface A RADIUS scheme defines a set of parameters that the firewall uses to exchange information with the RADIUS servers. There might be authentication servers and accounting servers, or primary servers and secondary servers. The parameters mainly include the IP addresses of the servers, the shared keys, and the RADIUS server type. By default, no RADIUS scheme exists. 169

177 To configure a RADIUS scheme in the web interface: 1. Select User > RADIUS from the navigation tree to enter the RADIUS scheme list page. Figure 138 RADIUS scheme list 2. Click Add to enter the RADIUS scheme configuration page. Figure 139 RADIUS scheme configuration page 3. Enter a RADIUS scheme name. 4. Click the expand button before Advanced in the Common Configuration area to expand the advanced configuration area. 170

178 Figure 140 Common configuration area 5. Configure the common parameters for the RADIUS scheme as described in Table 49. Table 49 Configuration items Item Server Type Description Select the type of the RADIUS servers supported by the firewall: Standard Specifies the standard RADIUS server. That is, the RADIUS client and RADIUS server communicate by using the standard RADIUS protocol and packet format defined in RFC 2138/2139 or later. Extended Specifies an extended RADIUS server (usually running on IMC server). In this case, the RADIUS client and the RADIUS server communicate by using the proprietary RADIUS protocol and packet format. 171

179 Item Description Select the format of usernames to be sent to the RADIUS server. Username Format Authentication Key Confirm Authentication Key Accounting Key Confirm Accounting Key A username is generally in the format of userid@isp-name, of which isp-name is used by the firewall to determine the ISP domain to which a user belongs. If a RADIUS server (such as a RADIUS server of some early version) does not accept a username that contains an ISP domain name, you can configure the firewall to remove the domain name of a username before sending it to the RADIUS server. The username format options include: Original format Specifies to send the username of a user on an "as is" basis. With domain name Specifies to include the domain name in a username to be sent to the RADIUS server. Without domain name Specifies to remove any domain name of a username that is sent to the RADIUS server. Set the shared key for RADIUS authentication packets and that for RADIUS accounting packets. The RADIUS client and the RADIUS authentication/accounting server use MD5 to encrypt RADIUS packets, and they verify the validity of packets through the specified shared key. The client and the server receive and respond to packets from each other only when they use the same shared key. IMPORTANT: The shared keys configured on the firewall must be consistent with those configured on the RADIUS servers. The shared keys configured in the common configuration part are used only when no corresponding shared keys are configured in the RADIUS server configuration part. Set the time the firewall keeps an unreachable RADIUS server in blocked state. Quiet Time If you set the quiet time to 0, when the firewall attempts to send an authentication or accounting request but finds that the current server is unreachable, it does not change the server's status that it maintains. It simply sends the request to the next server in active state. As a result, when the firewall attempts to send a request of the same type for another user, it still tries to send the request to the server because the server is in active state. You can use this parameter to control whether the firewall changes the status of an unreachable server. For example, if you determine that the primary server is unreachable because the firewall's port for connecting the server is out of service temporarily or the server is busy, you can set the time to 0 so that the firewall uses the primary server as much. 172

180 Item Description Set the RADIUS server response timeout time. Server Response Timeout Time If the firewall sends a RADIUS request to a RADIUS server but receives no response within the specified server response timeout time, it retransmits the request. Setting a proper value according to the network conditions helps in improving the system performance. IMPORTANT: The server response timeout time multiplied by the maximum number of RADIUS packet transmission attempts must not exceed 75. Set the maximum number of attempts for transmitting a RADIUS packet to a single RADIUS server. Request Transmission Attempts Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a RADIUS server but receives no response after the response timeout timer expires, it retransmits the request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it considers the authentication or accounting attempt a failure. IMPORTANT: The server response timeout time multiplied by the maximum number of RADIUS packet transmission attempts must not exceed 75. Set the interval for sending real-time accounting information. The interval must be a multiple of 3. Realtime Accounting Interval Realtime Accounting Attempts Unit for Data Flows To implement real-time accounting, the firewall must send real-time accounting packets to the accounting server for online users periodically. Different real-time accounting intervals impose different performance requirements on the NAS and the RADIUS server. A shorter interval helps achieve higher accounting precision but requires higher performance. Use a longer interval when a large number of users (1000 or more) exist. For more information about the recommended real-time accounting intervals, see "RADIUS scheme configuration guidelines." Set the maximum number of attempts for sending a real-time accounting request. Specify the unit for data flows sent to the RADIUS server: Byte Kilo-byte Mega-byte Giga-byte IMPORTANT: The units specified on the NAS must be consistent with those configured on the RADIUS server. Otherwise, accounting might be wrong. 173

181 Item Unit for Packets Description Specify the unit for data packets sent to the RADIUS server: One-packet Kilo-packet Mega-packet Giga-packet IMPORTANT: The units specified on the NAS must be consistent with those configured on the RADIUS server. Otherwise, accounting might be wrong. Specify the VPN to which the RADIUS scheme belongs. VPN Security Policy Server This setting is effective to all RADIUS authentication servers and accounting servers configured in the RADIUS scheme, but the VPN individually specified for a RADIUS authentication or accounting server takes priority. Specify the IP address of the security policy server. Specify the source IP address for the firewall to use in RADIUS packets sent to the RADIUS server. RADIUS Packet Source IP IMPORTANT: Specifying this source IP address can make sure the response packets from the server can reach the firewall if the physical interface is down. HP recommends you to use a loopback interface address. This source IP address and the RADIUS server IP address specified in the RADIUS scheme must be of the same version. Otherwise, the configuration cannot take effect. Specify the backup source IP address for the firewall to use in RADIUS packets sent to the RADIUS server. RADIUS Packet Backup Source IP Buffer stop-accounting packets In a stateful failover environment, the backup source IP address must be the source IP address for the remote firewall to use in RADIUS packets sent to the RADIUS server. Configuring the backup source IP address in a stateful failover environment makes sure that the backup server can receive the RADIUS packets sent from the RADIUS server when the master firewall fails. Enable or disable buffering of stop-accounting requests for which no responses are received. Set the maximum number of stop-accounting attempts. The maximum number of stop-accounting attempts, together with some other parameters, controls how the NAS deals with stop-accounting request packets. Stop-Accounting Attempts Suppose that the RADIUS server response timeout period is three seconds, the maximum number of transmission attempts is five, and the maximum number of stop-accounting attempts is 20. For each stop-accounting request, if the firewall receives no response within three seconds, it retransmits the request. If it receives no responses after retransmitting the request five times, it considers the stop-accounting attempt a failure, buffers the request, and makes another stop-accounting attempt. If 20 consecutive attempts fail, the firewall discards the request. 174

182 Item Send accounting-on packets Accounting-On Interval Accounting-On Attempts Attribute Interpretation Description Enable or disable the accounting-on feature. The accounting-on feature enables the firewall to send accounting-on packets to RADIUS servers after it reboots, making the servers forcedly log out users who logged in through the firewall before the reboot. IMPORTANT: When enabling the accounting-on feature on the firewall for the first time, you must save the configuration so that the feature takes effect after the firewall reboots. Set the interval for sending accounting-on packets. This field is configurable only when the Send accounting-on packets option is selected. Set the maximum number of accounting-on packets transmission attempts. This field is configurable only when the Send accounting-on packets option is selected. Enable or disable the firewall to interpret the RADIUS class attribute as CAR parameters. 6. In the RADIUS Server Configuration area, click Add to enter the RADIUS server configuration page. Figure 141 RADIUS server configuration page 7. Configure the parameters of the RADIUS authentication servers and accounting servers as described in Table Click Apply to finish server configuration. 9. Click Apply to finish RADIUS scheme configuration. Table 50 Configuration items Item Server Type IP Address Port Description Select the type of the RADIUS server to be configured. Possible values include primary authentication server, primary accounting server, secondary authentication server, and secondary accounting server. Specify the IP address of the RADIUS server. Specify the UDP port of the RADIUS server 175

183 Item Key Confirm Key VPN Description Specify the shared key for communication with the RADIUS server. If no shared key is specified here, the shared key specified in the common configuration part is used. Specify the VPN to which the RADIUS server belongs. If no VPN is specified here, the VPN specified in the common configuration part is used. RADIUS configuration example in the web interface Network requirements As shown in Figure 142, run the RADIUS server runs on IMC to provide authentication, authorization, and accounting services for Telnet users. Add an account on the RADIUS server, with the username and password abc. Set the privilege level for the user to 3. Set the shared keys for authentication, authorization, and accounting packets exchanged between Firewall and the RADIUS server to expert and specify the ports for authentication/authorization and accounting as 1812 and 1813 respectively. Configure the Firewall to include the domain name in a username sent to the RADIUS server. Figure 142 Network diagram Configuring the RADIUS server running on IMC This example assumes that the RADIUS server runs on IMC PLAT 3.20-R2602 and IMC UAM 3.60-E Add Firewall to IMC as an access device: a. Log in to IMC, click the Service tab, and then select Access Service > Service Configuration from the navigation tree. b. Click Add to configure an access device as follows: Set the shared key for authentication and accounting packets to expert. Specify the ports for authentication and accounting as 1812 and 1813, respectively. Select Device Management Service as the service type. Select HP as the access device type. Select SecPath from the device list or manually add it with the IP address of c. Click OK. 176

184 Figure 143 Adding an access device The IP address of the access device must be the same as the source IP address of the RADIUS packets sent from SecPath. By default, the source IP address of a RADIUS packet is the IP address of the interface through which the packet is sent out. 2. Add a user account for device management: a. Click the User tab, and then select Access User View > All Access Users from the navigation tree. b. Click Add to configure a user account for device management as follows: Enter hello@bbb as the account name. Set the password to abc and confirm the password. Select Telnet as the service type. Set the EXEC privilege level to 3. This value identifies the privilege level of the Telnet user after login, which is 0 by default. Click Add in the IP Address List of Managed Devices area to add IP addresses to as the range of hosts to be managed. The address range must contain the IP address of the access device added in the previous step. c. Click OK. 177

185 Figure 144 Adding an account for device management Configuring Firewall # Configure the IP address and security zone of each interface. (Details not shown.) # Configure the RADIUS scheme system: 1. Select User > RADIUS from the navigation tree and then click Add in the RADIUS scheme list area. 2. Configure basic information for the RADIUS scheme: Enter system as the scheme name. Select Extended as the server type. Select With domain name for the username format. 3. In the RADIUS Server Configuration area, click Add to configure a RADIUS authentication server for the scheme as follows: Select Primary Authentication as the server type. Enter as the IP address of the primary authentication server. Enter 1812 as the port. Set the key to expert and confirm the key. 4. Click Apply. 178

186 Figure 145 RADIUS authentication server configuration page 5. In the RADIUS Server Configuration area, click Add to configure a RADIUS accounting server for the scheme as follows: Select Primary Accounting as the server type. Enter as the IP address of the primary accounting server. Enter 1813 as the port. Set the key to expert and confirm the key. Figure 146 RADIUS accounting server configuration 6. Click Apply. The RADIUS scheme configuration page refreshes and the added servers appear in the RADIUS Server Configuration area, as shown in Figure Click Apply. 179

187 Figure 147 RADIUS scheme configuration page # Enable the Telnet service on the Firewall. [Firewall] telnet server enable # Configure the Firewall to use AAA for Telnet users. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Configure the AAA methods for domain bbb. Because RADIUS authorization information is sent to the RADIUS client in the authentication response messages, reference the same scheme for user authentication and authorization. [Firewall] domain bbb [Firewall-isp-bbb] authentication login radius-scheme system [Firewall-isp-bbb] authorization login radius-scheme system [Firewall-isp-bbb] accounting login radius-scheme system [Firewall-isp-bbb] quit # Alternatively, you can achieve the same result by configuring default AAA methods for all types of users in domain bbb. [Firewall] domain bbb [Firewall-isp-bbb] authentication default radius-scheme system [Firewall-isp-bbb] authorization default radius-scheme system [Firewall-isp-bbb] accounting default radius-scheme system 180

188 Verifying the configuration After the configuration, the Telnet user should be able to Telnet to the Firewall and use the configured account (username and password abc) to enter the user interface of the Firewall, and access all the commands of level 0 to level 3. Configure RADIUS schemes at the CLI RADIUS scheme configuration task list Task Creating a RADIUS scheme Specifying the RADIUS authentication/authorization servers Specifying the RADIUS accounting servers and the relevant parameters Specifying the shared keys for authenticating RADIUS packets Specifying the VPN to which the servers belongs Setting the supported RADIUS server type Setting the maximum number of RADIUS request transmission attempts Setting the status of RADIUS servers Setting the username format and traffic statistics units Specifying the source IP address for outgoing RADIUS packets Setting timers for controlling communication with RADIUS servers Configuring RADIUS accounting-on Configuring the IP address of the security policy server Configuring interpretation of RADIUS class attribute as CAR parameters Enabling the trap function for RADIUS Enabling the RADIUS listening port of the RADIUS client Displaying and maintaining RADIUS Remarks Required Required Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Creating a RADIUS scheme Before performing other RADIUS configurations, follow these steps to create a RADIUS scheme and enter RADIUS scheme view: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a RADIUS scheme and enter RADIUS scheme view. radius scheme radius-scheme-name No RADIUS scheme exists by default. NOTE: A RADIUS scheme can be referenced by multiple ISP domains at the same time. 181

189 Specifying the RADIUS authentication/authorization servers You can specify one primary authentication/authorization server and up to 16 secondary authentication/authorization servers for a RADIUS scheme so that the NAS can find a server for user authentication/authorization when using the scheme. When the primary server is not available, a secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server. In RADIUS, user authorization information is piggybacked in authentication responses sent to RADIUS clients. It is neither allowed nor needed to specify a separate RADIUS authorization server. Follow these guidelines when you configure RADIUS authentication/authorization servers: The IP addresses of the primary and secondary authentication/authorization servers for a scheme must be different from each other. Otherwise, the configuration fails. All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version. You can specify a RADIUS authentication/authorization server as the primary authentication/authorization server for one scheme and simultaneously as a secondary authentication/authorization server for another scheme. To specify RADIUS authentication/authorization servers for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify RADIUS authentication/authorizat ion servers. radius scheme radius-scheme-name Specify the primary RADIUS authentication/authorization server: primary authentication { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key vpn-instance vpn-instance-name ] * Specify a secondary RADIUS authentication/authorization server: secondary authentication { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key vpn-instance vpn-instance-name ] * N/A Configure at least one command. No authentication/authorizat ion server is specified by default. Specifying the RADIUS accounting servers and the relevant parameters You can specify one primary accounting server and up to 16 secondary accounting servers for a RADIUS scheme. When the primary server is not available, a secondary server is used, if any. When redundancy is not required, specify only the primary server. By setting the maximum number of real-time accounting attempts for a scheme, you make the firewall disconnect users for whom no accounting response is received before the number of accounting attempts reaches the limit. When the firewall receives a connection teardown request from a host or a connection teardown notification from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the firewall to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the firewall discards the packet. 182

190 Follow these guidelines when you configure RADIUS accounting servers: The IP addresses of the primary and secondary accounting servers must be different from each other. Otherwise, the configuration fails. All servers for authentication/authorization and accountings, primary or secondary, must use IP addresses of the same IP version. If you delete an accounting server that is serving users, the firewall can no longer send real-time accounting requests and stop-accounting requests for the users to that server, or buffer the stop-accounting requests. You can specify a RADIUS accounting server as the primary accounting server for one scheme and simultaneously as a secondary accounting server for another scheme. RADIUS does not support accounting for FTP users. To specify RADIUS accounting servers and set relevant parameters for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify RADIUS accounting servers. 4. Set the maximum number of real-time accounting attempts. 5. Enable buffering of stop-accounting requests to which no responses are received. 6. Set the maximum number of stop-accounting attempts. radius scheme radius-scheme-name Specify the primary RADIUS accounting server: primary accounting { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key vpn-instance vpn-instance-name ] * Specify a secondary RADIUS accounting server: secondary accounting { ip-address ipv6 ipv6-address } [ port-number key [ cipher simple ] key vpn-instance vpn-instance-name ] * retry realtime-accounting retry-times stop-accounting-buffer enable retry stop-accounting retry-times N/A Configure at least one command. No accounting server is specified by default. In FIPS mode, the firewall supports only ciphertext shared keys of at least 8 characters that must contain uppercase letters, lowercase letters, digits, and special characters. Optional. The default setting is 5. Optional. Enabled by default. Optional. The default setting is 500. Specifying the shared keys for authenticating RADIUS packets The RADIUS client and RADIUS server use the MD5 algorithm to encrypt packets exchanged between them and use shared keys to authenticate the packets. They must use the same shared key for the same type of packets. A shared key configured in this task is for all servers of the same type (accounting or authentication) in the scheme, and has a lower priority than a shared key configured individually for a RADIUS server. To specify shared keys for authenticating RADIUS packets: 183

191 Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify a shared key for authenticating RADIUS authentication/authorization or accounting packets. radius scheme radius-scheme-name key { accounting authentication } [ cipher simple ] key N/A No shared key is specified by default. In FIPS mode, the firewall supports only ciphertext shared keys of at least 8 characters that must contain uppercase letters, lowercase letters, digits, and special characters. NOTE: A shared key configured on the firewall must be the same as that configured on the RADIUS server. Specifying the VPN to which the servers belongs After you specify a VPN for a RADIUS scheme, all the authentication/authorization/accounting servers specified for the scheme belong to the VPN. However, if you also specify a VPN when specifying a server for the scheme, the server belongs to the specific VPN. To specify a VPN for a RADIUS scheme: Step Command 1. Enter system view. system-view 2. Enter RADIUS scheme view. radius scheme radius-scheme-name 3. Specify a VPN for the RADIUS scheme. vpn-instance vpn-instance-name Setting the supported RADIUS server type The supported RADIUS server type determines the type of the RADIUS protocol that the firewall uses to communicate with the RADIUS server. It can be standard or extended: Standard Uses the standard RADIUS protocol, compliant to RFC 2865 and RFC 2866 or later. Extended Uses the proprietary RADIUS protocol of HP. When the RADIUS server runs on IMC, you must set the RADIUS server type to extended. When the RADIUS server runs third-party RADIUS server software, either RADIUS server type applies. For the firewall to function as a RADIUS server to authenticate login users, you must set the RADIUS server type to standard. To set the RADIUS server type: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A 184

192 Step Command Remarks 3. Set the RADIUS server type. server-type { extended standard } Optional. The default RADIUS server type is standard. NOTE: Changing the RADIUS server type restores the unit for data flows and that for the packets that are sent to the RADIUS server to the defaults. Setting the maximum number of RADIUS request transmission attempts Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a RADIUS server but receives no response after the response timeout timer (defined by the timer response-timeout command) expires, it retransmits the request. If the number of transmission attempts exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS servers in active state. If no other servers are in active state at the time, it considers the authentication or accounting attempt a failure. For more information about RADIUS server states, see "Setting the status of RADIUS servers." The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server response timeout period cannot be greater than 75 seconds. For more information about the RADIUS server response timeout period, see "Setting timers for controlling communication with RADIUS servers." To set the maximum number of RADIUS request transmission attempts for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the maximum number of RADIUS request transmission attempts. radius scheme radius-scheme-name retry retry-times N/A Optional. The default setting is 3. Setting the status of RADIUS servers By setting the status of RADIUS servers to blocked or active, you can control which servers the firewall will communicate with for authentication, authorization, and accounting or turn to when the current servers are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Generally, the firewall chooses servers based on these rules: When the primary server is in active state, the firewall communicates with the primary server. If the primary server fails, the firewall changes the server's status to blocked and starts a quiet timer for the server, and then turns to a secondary server in active state (a secondary server configured earlier has a higher priority). If the secondary server is unreachable, the firewall changes the server's status to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the firewall finds an available secondary server or has checked all secondary servers in active state. If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server changes back to active automatically, but the firewall does not check the server again during 185

193 the authentication or accounting process. If no server is found reachable during one search process, the firewall considers the authentication or accounting attempt a failure. Once the accounting process of a user starts, the firewall keeps sending the user's real-time accounting requests and stop-accounting requests to the same accounting server. If you remove the accounting server, real-time accounting requests and stop-accounting requests for the user are no longer delivered to the server. If you remove an authentication or accounting server in use, the communication of the firewall with the server soon times out, and the firewall looks for a server in active state from scratch by checking any primary server first and then the secondary servers in the order they are configured. When the primary server and secondary servers are all in blocked state, the firewall communicates with the primary server. If the primary server is available, its status changes to active. Otherwise, its status remains to be blocked. If one server is in active state and all the others are in blocked state, the firewall only tries to communicate with the server in active state, even if the server is unavailable. After receiving an authentication/accounting response from a server, the firewall changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked. By default, the firewall sets the status of all RADIUS servers to active. In some cases, however, you can change the status of a server. For example, if a server fails, you can change the status of the server to blocked to avoid communication with the server. To set the status of RADIUS servers in a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the RADIUS server status. radius scheme radius-scheme-name Set the status of the primary RADIUS authentication/authorization server: state primary authentication { active block } Set the status of the primary RADIUS accounting server: state primary accounting { active block } Set the status of a secondary RADIUS authentication/authorization server: state secondary authentication [ ip ipv4-address ipv6 ipv6-address ] { active block } Set the status of a secondary RADIUS accounting server: state secondary accounting [ ip ipv4-address ipv6 ipv6-address ] { active block } N/A Optional. The default status is active for every server specified in the RADIUS scheme. NOTE: The server status set by the state command cannot be saved to the configuration file. After the firewall restarts, the status of each server is restored to active. To display the states of the servers, use the display radius scheme command. 186

194 Setting the username format and traffic statistics units A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP domain the user belongs to and is used by the firewall to determine which users belong to which ISP domains. However, some earlier RADIUS servers cannot recognize usernames that contain an ISP domain name. In this case, the firewall must remove the domain name of each username before sending the username. You can set the username format on the firewall for this purpose. The firewall periodically sends accounting updates to RADIUS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure that the unit for data flows and that for packets on the firewall are consistent with those on the RADIUS server. Follow these guidelines when you set the username format and the traffic statistics units for a RADIUS scheme: If a RADIUS scheme defines that the username is sent without the ISP domain name, do not apply the RADIUS scheme to more than one ISP domain. Otherwise, users using the same username but in different ISP domains are considered the same user. For level switching authentication, the user-name-format keep-original and user-name-format without-domain commands produce the same results. They make sure usernames sent to the RADIUS server carry no ISP domain name. To set the username format and the traffic statistics units for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the format for usernames sent to the RADIUS servers. 4. Specify the unit for data flows or packets sent to the RADIUS servers. radius scheme radius-scheme-name user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* N/A Optional. By default, the ISP domain name is included in a username. Optional. The default unit is byte for data flows and one-packet for data packets by default. Specifying the source IP address for outgoing RADIUS packets The source IP address of RADIUS packets that a NAS sends must match the IP address of the NAS configured on the RADIUS server. A RADIUS server identifies a NAS by its IP address. Upon receiving a RADIUS packet, a RADIUS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet. Usually, the source address of outgoing RADIUS packets can be the IP address of the NAS's any interface that can communicate with the RADIUS server. In some special scenarios, however, you must change the source IP address. For example, if a Network Address Translation (NAT) device is present between the NAS and the RADIUS server, the source IP address of outgoing RADIUS packets must be a public IP address of the NAS. If the NAS is configured with the Virtual Router Redundancy Protocol (VRRP) for stateful failover, the source IP address of outgoing RADIUS packets can be the virtual IP address of the VRRP group to which the uplink belongs. 187

195 You can specify a source IP address for outgoing RADIUS packets in RADIUS scheme view for a specific RADIUS scheme, or in system view for all RADIUS schemes whose servers are in a VPN or the public network. Before sending a RADIUS packet, a NAS selects a source IP address in this order: The source IP address specified for the RADIUS scheme. The source IP address specified in system view for the VPN or public network, depending on where the RADIUS server resides. The IP address of the outbound interface specified by the route. To specify a source IP address for all RADIUS schemes in a VPN or the public network: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a source IP address for outgoing RADIUS packets. radius nas-ip { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] By default, the IP address of the outbound interface is used as the source IP address. To specify a source IP address for a specific RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Specify a source IP address for outgoing RADIUS packets. radius scheme radius-scheme-name nas-ip { ip-address ipv6 ipv6-address } N/A By default, the IP address of the outbound interface is used as the source IP address. Setting timers for controlling communication with RADIUS servers The firewall uses the following types of timers to control the communication with a RADIUS server: Server response timeout timer (response-timeout) Defines the RADIUS request retransmission interval. After sending a RADIUS request (authentication/authorization or accounting request), the firewall starts this timer. If the firewall receives no response from the RADIUS server before this timer expires, it resends the request. Server quiet timer (quiet) Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the firewall changes the server status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After this timer expires, the firewall changes the status of the server back to active. Real-time accounting timer (realtime-accounting) Defines the interval at which the firewall sends real-time accounting packets to the RADIUS accounting server for online users. To implement real-time accounting, the firewall must periodically send real-time accounting packets to the accounting server for online users. Follow these guidelines when you set timers for controlling communication with RADIUS servers: For a type of users, the maximum number of transmission attempts multiplied by the RADIUS server response timeout period must be less than the client connection timeout time and must not exceed 75 seconds. Otherwise, stop-accounting messages cannot be buffered, and the primary/secondary server switchover cannot take place. For example, the product of the two parameters must be less than 10 seconds for voice users, and less than 30 seconds for Telnet users 188

196 because the client connection timeout period for voice users is 10 seconds and that for Telnet users is 30 seconds. When you configure the maximum number of RADIUS packet transmission attempts and the RADIUS server response timeout period, take the number of secondary servers into account. If the retransmission process takes too much time, the client connection in the access module may be timed out while the firewall is trying to find an available server. When a number of secondary servers are configured, the client connections of access modules that have a short client connection timeout period may still be timed out during initial authentication or accounting, even if the packet transmission attempt limit and server response timeout period are configured with small values. In this case, the next authentication or accounting attempt may succeed because the firewall has set the state of the unreachable servers to blocked and the time for finding a reachable server is shortened. Set the server quiet timer properly. Too short a quiet timer may result in frequent authentication or accounting failures because the firewall has to repeatedly attempt to communicate with an unreachable server that is in active state. For more information about the maximum number of RADIUS packet transmission attempts, see "Setting the maximum number of RADIUS request transmission attempts." To set timers for controlling communication with RADIUS servers: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme view. 3. Set the RADIUS server response timeout timer. 4. Set the quiet timer for the servers. 5. Set the real-time accounting timer. radius scheme radius-scheme-name timer response-timeout seconds timer quiet minutes timer realtime-accounting minutes N/A Optional. The default RADIUS server response timeout timer is 3 seconds. Optional. The default quiet timer is 5 minutes. Optional. The default real-time accounting timer is 12 minutes. Configuring RADIUS accounting-on The accounting-on feature enables a firewall to send accounting-on packets to the RADIUS server after it reboots, making the server log out users who logged in through the firewall before the reboot. Without this feature, users who were online before the reboot cannot re-log in after the reboot, because the RADIUS server considers they are already online. If a firewall sends an accounting-on packet to the RADIUS server but receives no response, it resends the packet to the server at a particular interval for a specified number of times. To configure the accounting-on feature for a RADIUS scheme: Step Command Remarks 1. Enter system view. system-view N/A 189

197 Step Command Remarks 2. Enter RADIUS scheme view. 3. Enable accounting-on and configure parameters. radius scheme radius-scheme-name accounting-on enable [ interval seconds send send-times ] * N/A Disabled by default. The default interval is 3 seconds and the default number of send-times is 5. NOTE: The accounting-on feature requires the cooperation of the HP IMC network management system. Configuring the IP address of the security policy server The core of the HP EAD solution is integration and cooperation, and the security policy server is the management and control center. Using a collection of software, the security policy server provides functions such as user management, security policy management, security status assessment, security cooperation control, and security event audit. The NAS checks the validity of received control packets and accepts only control packets from known servers. To use a security policy server that is independent of the AAA servers, you must configure the IP address of the security policy server on the NAS. To implement all EAD functions, configure both the IP address of the IMC security policy server and that of the IMC Platform on the NAS. To configure the IP address of the security policy server for a scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter RADIUS scheme radius scheme radius-scheme-name N/A view. 3. Specify a security policy server. security-policy-server ip-address No security policy server is specified by default. NOTE: You can specify up to eight security policy servers for a RADIUS scheme. Configuring interpretation of RADIUS class attribute as CAR parameters According to RFC 2865, a RADIUS server assigns the RADIUS class attribute (attribute 25) to a RADIUS client. However, the RFC only requires the RADIUS client to send the attribute to the accounting server on an "as is" basis; it does not require the RADIUS client to interpret the attribute. Some RADIUS servers use the class attribute to deliver the assigned committed access rate (CAR) parameters. In this case, the access devices must interpret the attribute to implement user-based traffic monitoring and controlling. To support such applications, configure the access devices to interpret the class attribute as the CAR parameters. To configure the firewall to interpret the RADIUS class attribute as CAR parameters: Step Command Remarks 1. Enter system view. system-view N/A 190

198 Step Command Remarks 2. Enter RADIUS scheme view. 3. Interpret the class attribute as CAR parameters. radius scheme radius-scheme-name attribute 25 car N/A Be default, RADIUS attribute 25 is not interpreted as CAR parameters. NOTE: Whether interpretation of RADIUS class attribute as CAR parameters is supported depends on two factors: Whether the firewall supports CAR parameters assignment. Whether the RADIUS server supports assigning CAR parameters through the class attribute. Enabling the trap function for RADIUS With the trap function, a NAS sends a trap message when either of the following events occurs: The status of a RADIUS server changes. If a NAS receives no response to an accounting or authentication request before the specified maximum number of RADIUS request transmission attempts is exceeded, it considers the server unreachable, sets the status of the server to block and sends a trap message. If the NAS receives a response from a RADIUS server that it considers unreachable, the NAS considers that the RADIUS server is reachable again, sets the status of the server to active, and sends a trap message. The ratio of the number of failed transmission attempts to the total number of authentication request transmission attempts reaches the threshold. This threshold ranges from 1% to 100% and defaults to 30%. This threshold can only be configured through the MIB. The failure ratio is generally small. If a trap message is triggered because the failure ratio is higher than the threshold, troubleshoot the configuration on and the communication between the NAS and the RADIUS server. To enable the trap function for RADIUS: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the trap function for RADIUS. radius trap { accounting-server-down authentication-error-threshold authentication-server-down } Disabled by default. Enabling the RADIUS listening port of the RADIUS client Only after you enable the RADIUS listening port of a RADIUS client, can the client receive and send RADIUS packets. If RADIUS is not required, disable the RADIUS listening port to avoid attacks that exploit RADIUS packets. To enable the RADIUS listening port of a RADIUS client: Step Command Remarks 1. Enter system view. system-view N/A 2. Enable the RADIUS listening port of a RADIUS client. radius client enable Optional. Enabled by default. 191

199 Displaying and maintaining RADIUS Task Command Remarks Display the configuration information of RADIUS schemes. Display the statistics for RADIUS packets. Display information about buffered stop-accounting requests for which no responses have been received. display radius scheme [ radius-scheme-name ] [ { begin exclude include } regular-expression ] display radius statistics [ { begin exclude include } regular-expression ] display stop-accounting-buffer { radius-scheme radius-server-name session-id session-id time-range start-time stop-time user-name user-name } [ { begin exclude include } regular-expression ] Available in any view Available in any view Available in any view Clear RADIUS statistics. reset radius statistics Available in user view Clear the buffered stop-accounting requests for which no responses have been received. reset stop-accounting-buffer { radius-scheme radius-server-name session-id session-id time-range start-time stop-time user-name user-name } Available in user view RADIUS scheme configuration guidelines When you configure RADIUS, follow these guidelines: Accounting for FTP users is not supported. If you remove the accounting server used for online users, the firewall cannot send real-time accounting requests and stop-accounting messages for the users to the server, and the stop-accounting messages are not buffered locally. The status of RADIUS servers, blocked or active, determines which servers the firewall communicates with or turns to when the current servers are not available. In practice, you can specify one primary RADIUS server and multiple secondary RADIUS servers, with the secondary servers that function as the backup of the primary servers. Generally, the firewall chooses servers based on these rules: When the primary server is in active state, the firewall communicates with the primary server. If the primary server fails, the firewall changes the state of the primary server to blocked, starts a quiet timer for the server, and turns to a secondary server in active state (a secondary server configured earlier has a higher priority). If the secondary server is unreachable, the firewall changes the state of the secondary server to blocked, starts a quiet timer for the server, and continues to check the next secondary server in active state. This search process continues until the firewall finds an available secondary server or has checked all secondary servers in active state. If the quiet timer of a server expires or an authentication or accounting response is received from the server, the status of the server changes back to active automatically, but the firewall does not check the server again during the authentication or accounting process. If no server is found reachable during one search process, the firewall considers the authentication or accounting attempt a failure. Once the accounting process of a user starts, the firewall keeps sending the user's real-time accounting requests and stop-accounting requests to the same accounting server. If you remove 192

200 the accounting server, real-time accounting requests and stop-accounting requests for the user are no longer delivered to the server. If you remove an authentication or accounting server in use, the communication of the firewall with the server soon times out, and the firewall looks for a server in active state from scratch by checking any primary server first and then the secondary servers in the order they are configured. When the primary server and secondary servers are all in blocked state, the firewall communicates with the primary server. If the primary server is available, its statues changes to active. Otherwise, its status remains to be blocked. If one server is in active state but all the others are in blocked state, the firewall only tries to communicate with the server in active state, even if the server is unavailable. After receiving an authentication/accounting response from a server, the firewall changes the status of the server identified by the source IP address of the response to active if the current status of the server is blocked. Table 51 lists the recommended real-time accounting intervals. Table 51 Recommended real-time accounting interval settings Number of users 1 to to to Real-time accounting interval (in minutes) ú1000 ú15 Configuring HWTACACS schemes in the web interface NOTE: You cannot remove the HWTACACS schemes in use or change the IP addresses of the HWTACACS servers in use. Table 52 HWTACACS configuration task list Task Creating an HWTACACS scheme Configuring HWTACACS server Description Required Create an HWTACACS scheme named system. By default, no HWTACACS scheme exists. Authentication server and authorization server are mandatory and accounting server is optional. This section describes how to specify the primary and the secondary HWTACACS authentication/authorization and accounting servers. By default, no server is specified. IMPORTANT: If redundancy is not required, specify only the primary HWTACACS authentication server. 193

201 Task Configuring HWTACACS parameters Description Optional This section describes how to configure the parameters that are necessary for information exchange between the firewall and HWTACACS server. Creating an HWTACACS scheme 1. If the HWTACACS scheme system does not exist, select User > HWTACACS > Server Configuration or User > HWTACACS > Parameter Configuration from the navigation tree. A message appears, asking you to create an HWTACACS scheme first. 2. Click Add to create an HWTACACS scheme named system. Figure 148 Creating an HWTACACS scheme Configuring HWTACACS server 1. If the HWTACACS scheme system already exists, select User > HWTACACS > Server Configuration from the navigation tree. Figure 149 HWTACACS server configuration 2. Configure HWTACACS servers as described in Table Click Apply. Table 53 Configuration items Configuration item Server Type Description Select the type of the server to be configured, which can be Authentication Server, Authorization Server and Accounting Sever. 194

202 Configuration item Primary Server IP Primary Server TCP Port Secondary Server IP Secondary Server TCP Port Shared Key Confirm Shared Key Description Enter the IP address of the primary server. When no primary server is specified, the primary server IP address and the primary server TCP port are empty. If you leave the IP address field empty, any configured the primary server will be removed. The specified IP address of the primary server cannot be the same as that of the secondary server. Enter the TCP port of the primary server. Configure different TCP port numbers specific to the service types. Enter the IP address of the secondary server. When no secondary server is specified, the secondary server IP and the secondary server TCP port are empty. If you leave the IP address field empty, any configured secondary server will be removed. The specified IP address of the primary server cannot be the same as that of the secondary server. Enter the TCP port of the secondary server. Configure different TCP port numbers specific to the service types. Select the box and type the shared key of the server in the field. The HWTACACS client (the NAS) and HWTACACS server use the MD5 algorithm to encrypt packets exchanged between them and a shared key to verify the packets. Only when the same key is used can they properly receive the packets and make responses. Enter the shared key for confirmation, which must be consistent with the shared key. Configuring HWTACACS parameters 1. If the HWTACACS scheme system already exists, select User > HWTACACS > Parameter Configuration from the navigation tree. Figure 150 HWTACACS parameter configuration 195

203 2. Configure HWTACACS parameters as described in Table Click Apply. Table 54 Configuration items Item NAS-IP Realtime-Accounting Interval Stop-Accounting Buffer Stop-Accounting Packet Retransmission Times Response Timeout Interval Quiet Interval Description Source IP address for the firewall to use in HWTACACS packets to be sent to the HWTACACS server. Use a loopback interface address instead of a physical interface address as the source IP address to make sure the response packets from the server can reach the firewall when the physical interface is down. Real-time accounting interval, whose value must be a multiple of 3. To implement real-time accounting on users, it is necessary to set the real-time accounting interval. With this parameter is specified, the firewall will send the accounting information of online users to the HWTACACS server every the specified interval. According to the protocol, the firewall will not disconnect the online users even if the server does not make any response properly. If you leave this field blank, the real-time accounting interval is restored to the default value. IMPORTANT: Consider the performance of the NAS and the HWTACACS server when you set the real-time accounting interval. A shorter interval requires higher performance. Use a longer interval when there are more than 1000 users. Table 55 shows the recommended ratios of the interval to the number of users. Enable or disable buffering stop-accounting requests without responses in the firewall Since stop-accounting requests affect the charge to users, a NAS must make its best effort to send every stop-accounting request to the HWTACACS accounting servers. For each stop-accounting request getting no response in the specified period of time, the NAS buffers and resends the packet until it receives a response or the number of transmission retries reaches the configured limit. In the latter case, the NAS discards the packet. The maximum number of stop-accounting packet transmission attempts if no response is received for the stop-accounting packet If stop-accounting buffer is disabled, this value is ineffective. If you leave this field blank, the number of retransmission times is restored to the default value. Set the HWTACACS server response timeout time. If no response is received from the server within the timeout interval, it may lead to disconnection from the HWTACACS server. If you leave this field blank, the response timeout period is restored to the default value. IMPORTANT: As HWTACACS is based on TCP, the timeout of the server response timeout timer and/or the TCP timeout timer will cause the NAS to be disconnected from the HWTACACS server. Specify the interval the primary server has to wait before being active. If you leave this field blank, the quiet interval is restored to the default value. 196

204 Item Description Set the format of the username sent to the HWTACACS server. Username Format Unit of Data Flows A username is generally in the format of userid@isp-name, of which isp-name is used by the firewall to determine the ISP domain to which the user belongs. If an HWTACACS server does not accept a username including an ISP domain name, you can configure the firewall to remove the domain name before sending it to the HWTACACS server. Options include: Without-domain Specifies to remove the domain name of a username that is to be sent to the RADIUS server. With-domain Specifies to keep the domain name of a username that is to be sent to the RADIUS server. Specify the unit for data flows sent to the HWTACACS server for traffic accounting. Options include: byte kilo-byte mega-byte giga-byte If you leave the box blank, the default unit is used. Unit of Packets Specify the unit for data packets sent to the HWTACACS server for traffic accounting. Options include: packet kilo-packet mega-packet giga-packet If you leave the box blank, the default unit is used. Table 55 Recommended real-time accounting interval settings Number of users Real-time accounting interval (in minutes) 1 to to to ú1000 ú15 HWTACACS configuration example in the web interface Network requirements As shown in Figure 151, configure Firewall to use the HWTACACS server to provide authentication, authorization, and accounting services for the Telnet user. Set the shared keys for secure communication with the HWTACACS server to expert. Configure Firewall to remove the domain name from a username set to the HWTACACS server. 197

205 Figure 151 Network diagram HWTACACS server /24 Internet Telnet user Firewall Configuring the HWTACACS server. # Set the shared keys to expert, add a Telnet user and set a password for the user. (Details not shown.). Configuring the Firewall # Configure the IP address of each interface and add them to security zones. (Details not shown.) # Configure the HWTACACS scheme system: 1. Select User > HWTACACS > Server Configuration from the navigation tree 2. Click Add as shown in Figure 152. The system automatically creates the HWTACACS scheme and displays the HWTACACS server configuration page, as shown in Figure 153. Figure 152 Creating an HWTACACS scheme 3. Configure an HWTACACS authentication server for the scheme as follows: Select Authentication Server as the server type. Enter as the IP address of the primary server. Enter 49 as the TCP port of the primary server. Select the Shared Key box, enter expert as the shared key, and then confirm it. 4. Click Apply. 198

206 Figure 153 Configuring an HWTACACS authentication server 5. On the page as shown in Figure 153, configure an HWTACACS authorization server for the scheme as follows: Select Authorization Server as the server type. Enter as the IP address of the primary server. Enter 49 as the TCP port of the primary server. Select the Shared Key box, enter expert as the shared key, and then confirm it. 6. Click Apply. 7. On the page as shown in Figure 153, configure an HWTACACS accounting server for the scheme as follows: Select Accounting Server as the server type. Enter as the IP address of the primary server. Enter 49 as the TCP port of the primary server. Select the Shared Key box, enter expert as the shared key, and then confirm it. 8. Click Apply. # Configure the parameters for communication between SecPath and the HWTACACS server as follows: 1. Select User > HWTACACS > Parameter Configuration from the navigation tree. 2. Select without-domain for the username format. 3. Click Apply. 199

207 Figure 154 Configuring the parameters for communication # Through CLI, enable Telnet services on Firewall. <Firewall> system-view [Firewall] telnet server enable # Configure Firewall to use AAA for Telnet user access control. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Configure the ISP domain to use the HWTACACS scheme system for AAA. [Firewall] domain bbb [Firewall-isp-bbb] authentication login hwtacacs-scheme system [Firewall-isp-bbb] authorization login hwtacacs-scheme system [Firewall-isp-bbb] accounting login hwtacacs-scheme system [Firewall-isp-bbb] quit # Alternatively, you can configure the ISP domain to use HWTACACS scheme system as the default authentication, authorization, and accounting schemes for all types of users. [Firewall] domain bbb [Firewall-isp-bbb] authentication default hwtacacs-scheme system [Firewall-isp-bbb] authorization default hwtacacs-scheme system [Firewall-isp-bbb] accounting default hwtacacs-scheme system Verifying the configuration erification On the Telnet client, enter the username in the format of userid@bbb and the correct password to log in to the user interface of Firewall. Configuring HWTACACS schemes at the CLI HWTACACS configuration task list Task Creating an HWTACACS scheme Specifying the HWTACACS authentication servers Remarks Required Required 200

208 Task Specifying the HWTACACS authorization servers Specifying the HWTACACS accounting servers and the relevant parameters Specifying the shared keys for authenticating HWTACACS packets Specifying the VPN to which the servers belongs Setting the username format and traffic statistics units Specifying a source IP address for outgoing HWTACACS packets Setting timers for controlling communication with HWTACACS servers Displaying and maintaining HWTACACS Remarks Optional Optional Required Optional Optional Optional Optional Optional Creating an HWTACACS scheme The HWTACACS protocol is configured on a per scheme basis. Before performing other HWTACACS configurations, follow these steps to create an HWTACACS scheme and enter HWTACACS scheme view: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an HWTACACS scheme and enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name Not defined by default. NOTE: Up to 16 HWTACACS schemes can be configured. A scheme can be deleted only when it is not referenced. Specifying the HWTACACS authentication servers You can specify one primary authentication server and up to one secondary authentication server for an HWTACACS scheme so that the NAS can find a server for user authentication when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server. Follow these guidelines when you configure HWTACACS authentication servers: An HWTACACS server can function as the primary authentication server of one scheme and simultaneously as the secondary authentication server of another scheme. The IP addresses of the primary and secondary authentication servers cannot be the same. Otherwise, the configuration fails. You can remove an authentication server only when no active TCP connection for sending authentication packets is using it. To specify HWTACACS authentication servers for an HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name 201 N/A

209 Step Command Remarks 3. Specify HWTACACS authentication servers. Specify the primary HWTACACS authentication server: primary authentication ip-address [ port-number vpn-instance vpn-instance-name ] * Specify the secondary HWTACACS authentication server: secondary authentication ip-address [ port-number vpn-instance vpn-instance-name ] * Configure at least one command. No authentication server is specified by default. Specifying the HWTACACS authorization servers You can specify one primary authorization server and up to one secondary authorization server for an HWTACACS scheme so that the NAS can find a server for user authorization when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server. Follow these guidelines when you configure HWTACACS authorization servers: An HWTACACS server can function as the primary authorization server of one scheme and simultaneously as the secondary authorization server of another scheme. The IP addresses of the primary and secondary authorization servers cannot be the same. Otherwise, the configuration fails. You can remove an authorization server only when no active TCP connection for sending authorization packets is using it. To specify HWTACACS authorization servers for an HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. 3. Specify HWTACACS authorization servers. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS authorization server: primary authorization ip-address [ port-number vpn-instance vpn-instance-name ] * Specify the secondary HWTACACS authorization server: secondary authorization ip-address [ port-number vpn-instance vpn-instance-name ] * N/A Configure at least one command. No authorization server is specified by default. Specifying the HWTACACS accounting servers and the relevant parameters You can specify one primary accounting server and up to one secondary accounting server for an HWTACACS scheme so that the NAS can find a server for user accounting when using the scheme. When the primary server is not available, the secondary server is used, if any. In a scenario where redundancy is not required, specify only the primary server. When the firewall receives a connection teardown request from a host or a connection teardown command from an administrator, it sends a stop-accounting request to the accounting server. You can enable buffering of non-responded stop-accounting requests to allow the firewall to buffer and resend a stop-accounting request until it receives a response or the number of stop-accounting attempts reaches the configured limit. In the latter case, the firewall discards the packet. Follow these guidelines when you configure HWTACACS accounting servers: 202

210 An HWTACACS server can function as the primary accounting server of one scheme and simultaneously as the secondary accounting server of another scheme. The IP addresses of the primary and secondary accounting servers cannot be the same. Otherwise, the configuration fails. You can remove an accounting server only when no active TCP connection for sending accounting packets is using it. HWTACACS does not support accounting for FTP users. To specify HWTACACS accounting servers and set relevant parameters for an HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. 3. Specify HWTACACS accounting servers. 4. Enable buffering of stop-accounting requests to which no responses are received. 5. Set the maximum number of stop-accounting attempts. hwtacacs scheme hwtacacs-scheme-name Specify the primary HWTACACS accounting server: primary accounting ip-address [ port-number vpn-instance vpn-instance-name ] * Specify the secondary HWTACACS accounting server: secondary accounting ip-address [ port-number vpn-instance vpn-instance-name ] * stop-accounting-buffer enable retry stop-accounting retry-times N/A Configure at least one command. No accounting server is specified by default. Optional. Enabled by default. Optional. The default setting is 100. Specifying the shared keys for authenticating HWTACACS packets The HWTACACS client and HWTACACS server use the MD5 algorithm to encrypt packets exchanged between them and use shared keys to authenticate the packets. They must use the same shared key for the same type of packets. To specify the shared keys for authenticating HWTACACS packets: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name N/A 203

211 Step Command Remarks 3. Specify the shared keys for authenticating HWTACACS authentication, authorization, and accounting packets. key { accounting authentication authorization } [ cipher simple ] key No shared key is specified by default. In FIPS mode, the firewall supports only ciphertext shared keys of at least 8 characters that must contain uppercase letters, lowercase letters, digits, and special characters. NOTE: A shared key configured on the firewall must be the same as that configured on the HWTACACS server. Specifying the VPN to which the servers belongs After you specify a VPN for an HWTACACS scheme, all the authentication, authorization, and accounting servers specified for the scheme belong to the VPN. However, if you also specify a VPN when specifying a server for the scheme, the server belongs to the specific VPN. To specify a VPN for an HWTACACS scheme: Step Command 1. Enter system view. system-view 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name 3. Specify a VPN for the HWTACACS scheme. vpn-instance vpn-instance-name Setting the username format and traffic statistics units A username is usually in the format of userid@isp-name, where isp-name represents the name of the ISP domain to which the user belongs to and is used by the firewall to determine which users belong to which ISP domains. However, some HWTACACS servers cannot recognize usernames that contain an ISP domain name. In this case, the firewall must remove the domain name of each username before sending the username. You can set the username format on the firewall for this purpose. The firewall periodically sends accounting updates to HWTACACS accounting servers to report the traffic statistics of online users. For normal and accurate traffic statistics, make sure the unit for data flows and that for packets on the firewall are consistent with those configured on the HWTACACS servers. Follow these guidelines when you set the username format and the traffic statistics units for an HWTACACS scheme: If an HWTACACS server does not support a username with the domain name, configure the firewall to remove the domain name before sending the username to the server. For level switching authentication, the user-name-format keep-original and user-name-format without-domain commands produce the same results. They make sure usernames sent to the HWTACACS server carry no ISP domain name. To set the username format and the traffic statistics units for an HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 204

212 Step Command Remarks 2. Enter HWTACACS scheme view. 3. Set the format of usernames sent to the HWTACACS servers. 4. Specify the unit for data flows or packets sent to the HWTACACS servers. hwtacacs scheme hwtacacs-scheme-name user-name-format { keep-original with-domain without-domain } data-flow-format { data { byte giga-byte kilo-byte mega-byte } packet { giga-packet kilo-packet mega-packet one-packet } }* N/A Optional. By default, the ISP domain name is included in a username. Optional. The default unit is byte for data flows and one-packet for data packets. Specifying a source IP address for outgoing HWTACACS packets The source IP address of HWTACACS packets that a NAS sends must match the IP address of the NAS configured on the HWTACACS server. An HWTACACS server identifies a NAS by IP address. Upon receiving an HWTACACS packet, an HWTACACS server checks whether the source IP address of the packet is the IP address of any managed NAS. If yes, the server processes the packet. If not, the server drops the packet. Usually, the source address of outgoing HWTACACS packets can be the IP address of any interface that the NAS can use to communicate with the HWTACACS server. In some special scenarios, however, you must change the source IP address. For example, if a NAT device is present between the NAS and the HWTACACS server, the source IP address of outgoing HWTACACS packets must be a public IP address of the NAS. If the NAS is configured with VRRP for stateful failover, the source IP address of HWTACACS packets can be the virtual IP address of the VRRP group to which the uplink belongs. You can specify the source IP address for outgoing HWTACACS packets in HWTACACS scheme view for a specific HWTACACS scheme, or in system view for all HWTACACS schemes whose servers are in a VPN or the public network. Before sending an HWTACACS packet, a NAS selects a source IP address in this order: The source IP address specified for the HWTACACS scheme. The source IP address specified in system view for the VPN or public network, depending on where the HWTACACS server resides. The IP address of the outbound interface specified by the route. To specify a source IP address for all HWTACACS schemes of a VPN or the public network: Step Command Remarks 1. Enter system view. system-view N/A 2. Specify a source IP address for outgoing HWTACACS packets. hwtacacs nas-ip ip-address [ vpn-instance vpn-instance-name ] By default, the IP address of the outbound interface is used as the source IP address. To specify a source IP address for a specific HWTACACS scheme: Step Command Remarks 1. Enter system view. system-view N/A 205

213 Step Command Remarks 2. Enter HWTACACS scheme view. 3. Specify a source IP address for outgoing HWTACACS packets. hwtacacs scheme hwtacacs-scheme-name nas-ip ip-address N/A By default, the IP address of the outbound interface is used as the source IP address. Setting timers for controlling communication with HWTACACS servers The firewall uses the following timers to control the communication with an HWTACACS server: Server response timeout timer (response-timeout) Defines the HWTACACS request retransmission interval. After sending an HWTACACS request (authentication, authorization, or accounting request), the firewall starts this timer. If the firewall receives no response from the server before this timer expires, it resends the request. Server quiet timer (quiet) Defines the duration to keep an unreachable server in blocked state. If a server is not reachable, the firewall changes the server's status to blocked, starts this timer for the server, and tries to communicate with another server in active state. After this timer expires, the firewall changes the status of the server back to active. Real-time accounting timer (realtime-accounting) Defines the interval at which the firewall sends real-time accounting updates to the HWTACACS accounting server for online users. To implement real-time accounting, the firewall must send real-time accounting packets to the accounting server for online users periodically. To set timers for controlling communication with HWTACACS servers: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter HWTACACS scheme view. hwtacacs scheme hwtacacs-scheme-name N/A 3. Set the HWTACACS server response timeout timer. 4. Set the quiet timer for the primary server. 5. Set the real-time accounting interval. timer response-timeout seconds timer quiet minutes timer realtime-accounting minutes Optional. The default HWTACACS server response timeout timer is 5 seconds. Optional. The default quiet timer for the primary server is 5 minutes. Optional. The default real-time accounting interval is 12 minutes. NOTE: Consider the performance of the NAS and the HWTACACS server when you set the real-time accounting interval. A shorter interval requires higher performance. 206

214 Displaying and maintaining HWTACACS Task Command Remarks Display the configuration information or statistics of HWTACACS schemes. Display information about buffered stop-accounting requests for which no responses have been received. Clear HWTACACS statistics. Clear buffered stop-accounting requests that get no responses. display hwtacacs [ hwtacacs-server-name [ statistics ] ] [ { begin exclude include } regular-expression ] display stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name [ { begin exclude include } regular-expression ] reset hwtacacs statistics { accounting all authentication authorization } reset stop-accounting-buffer hwtacacs-scheme hwtacacs-scheme-name Available in any view Available in any view Available in user view Available in user view HWTACACS scheme configuration guidelines When you configure the HWTACACS client, follow these guidelines: Except for deleting HWTACACS schemes and changing the IP addresses of the HWTACACS servers, you can make any changes to HWTACACS parameters, no matter whether there are users online or not. HWTACACS authentication must work with HWTACACS authorization. If only HWTACACS authentication is configured but HWTACACS authorization is not, users cannot log in. You can remove an authentication/authorization server or an accounting server only when no active TCP connection for sending authentication/authorization or accounting packets is using it. HWTACACS does not support accounting for FTP users. Configuring AAA methods for ISP domains You configure AAA methods for an ISP domain by referencing configured AAA schemes in ISP domain view. Each ISP domain has a set of default AAA methods, which are local authentication, local authorization, and local accounting by default and can be customized. If you do not configure any AAA methods for an ISP domain, the firewall uses the system default AAA methods for authentication, authorization, and accounting of the users in the domain. Configuration prerequisites To use local authentication for users in an ISP domain, configure local user accounts (see "Configuring local user attributes") on the firewall. To use remote authentication, authorization, and accounting, create the required RADIUS and HWTACACS schemes as described in "Configuring RADIUS schemes in the web interface," and "RADIUS scheme configuration guidelines." 207

215 Creating an ISP domain In a networking scenario with multiple ISPs, an access device may connect users of different ISPs, and users of different ISPs may have different user attributes, such as different username and password structures, different service types, and different rights. To distinguish the users of different ISPs, configure ISP domains, and configure different AAA methods and domain attributes for the ISP domains. On a NAS, each user belongs to an ISP domain. A NAS can accommodate up to 16 ISP domains, including the system predefined ISP domain system. You can specify one of the ISP domains as the default domain. If a user provides no ISP domain name at login, the firewall considers that the user belongs to the default ISP domain. To create an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Create an ISP domain and domain isp-name N/A enter ISP domain view. 3. Return to system view. quit N/A 4. Specify the default ISP domain. domain default enable isp-name Optional. By default, the default ISP domain is the system predefined ISP domain system. NOTE: To delete the ISP domain that is functioning as the default ISP domain, you must change it to a non-default ISP domain by using the undo domain default enable command. Configuring ISP domain attributes To configure ISP domain attributes: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Place the ISP domain to the state of active or blocked. 4. Specify the maximum number of active users in the ISP domain. state { active block } access-limit enable max-user-number 5. Configure the idle cut function. idle-cut enable minute [ flow ] Optional. By default, an ISP domain is in active state, and users in the domain can request network services. Optional. No limit by default. Optional. Disabled by default. This command is effective for only LAN users, portal users, and PPP users. 208

216 Step Command Remarks 6. Enable the self-service server location function and specify the URL of the self-service server. 7. Define an IP address pool for allocating addresses to PPP users. self-service-url enable url-string ip pool pool-number low-ip-address [ high-ip-address ] Optional. Disabled by default. Optional. By default, no IP address pool is configured for PPP users. 8. Specify the default authorization user profile. authorization-attribute user-profile profile-name Optional. By default, an ISP domain has no default authorization user profile. NOTE: If a user passes authentication but is authorized with no user profile, the firewall authorizes the default user profile of the ISP domain to the user and restricts the user's behavior based on the profile. A self-service RADIUS server, such as Intelligent Management Center (IMC), is required for the self-service server location function to work. Configuring AAA authentication methods for an ISP domain In AAA, authentication, authorization, and accounting are separate processes. Authentication refers to the interactive authentication process of username/password/user information during an access or service request. The authentication process neither sends authorization information to a supplicant nor triggers any accounting. AAA supports the following authentication methods: No authentication (none) All users are trusted and no authentication is performed. Generally, do not use this method. Local authentication (local) Authentication is performed by the NAS, which is configured with the user information, including the usernames, passwords, and attributes. Local authentication allows high speed and low cost, but the amount of information that can be stored is limited by the hardware. Remote authentication (scheme) The access device cooperates with a RADIUS or HWTACACS server to authenticate users. Remote authentication provides centralized information management, high capacity, high reliability, and support for centralized authentication service for multiple access devices. You can configure local or no authentication as the backup method, which is used when the remote server is not available. No authentication can only be configured for LAN users as the backup method of remote authentication. You can configure AAA authentication to work alone without authorization and accounting. By default, an ISP domain uses the local authentication method. Before configuring authentication methods, complete the following tasks: For RADIUS or HWTACACS authentication, configure the RADIUS, or HWTACACS scheme to be referenced first. The local and none authentication methods do not require a scheme. Determine the access type or service type to be configured. With AAA, you can configure an authentication method for each access type and service type, limiting the authentication protocols that can be used for access. 209

217 Determine whether to configure an authentication method for all access types or service types. Follow these guidelines when you configure AAA authentication methods for an ISP domain: The authentication method specified with the authentication default command is for all types of users and has a priority lower than that for a specific access type. With an authentication method that references a RADIUS scheme, AAA accepts only the authentication result from the RADIUS server. The Access-Accept message from the RADIUS server also carries the authorization information, but the authentication process ignores the information. If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local option when you configure an authentication method, local authentication is the backup method and is used only when the remote server is not available. If you specify only the local or none keyword in an authentication method configuration command, the firewall has no backup authentication method and performs only local authentication or does not perform any authentication. If the method for level switching authentication references an HWTACACS scheme, the firewall uses the login username of a user for level switching authentication of the user by default. If the method for level switching authentication references a RADIUS scheme, the system uses the username configured for the corresponding privilege level on the RADIUS server for level switching authentication, rather than the login username. A username configured on the RADIUS server is in the format of $enablevel$, where level specifies the privilege level to which the user wants to switch. For example, if user user1 of domain aaa wants to switch the privilege level to 3, the system uses $enab3@aaa$ for authentication when the domain name is required and uses $enab3$ for authentication when the domain name is not required. To configure AAA authentication methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Specify the default authentication method for all types of users. 4. Specify the authentication method for LAN users. 5. Specify the authentication method for login users. 6. Specify the authentication method for portal users. 7. Specify the authentication method for PPP users. authentication default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authentication lan-access { local none radius-scheme radius-scheme-name [ local none ] } authentication login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authentication portal { local none radius-scheme radius-scheme-name [ local ] } authentication ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } Optional. The default authentication method is local for all types of users. Optional. The default authentication method is used by default. Optional. The default authentication method is used by default. Optional. The default authentication method is used by default. Optional. The default authentication method is used by default. 210

218 Step Command Remarks 8. Specify the authentication method for SSL VPN users. 9. Specify the authentication method for privilege level switching. authentication ssl-vpn radius-scheme radius-scheme-name authentication super { hwtacacs-scheme hwtacacs-scheme-name radius-scheme radius-scheme-name } Optional. The default authentication method is used by default. Optional. The default authentication method is used by default. Configuring AAA authorization methods for an ISP domain In AAA, authorization is a separate process at the same level as authentication and accounting. Its responsibility is to send authorization requests to the specified authorization servers and to send authorization information to users after successful authorization. Authorization method configuration is optional in AAA configuration. AAA supports the following authorization methods: No authorization (none) The access device performs no authorization exchange. After passing authentication, non-login users can access the network, FTP users can access the root directory of the access device, and other login users have only the right of Level 0 (visiting). Local authorization (local) The access device performs authorization according to the user attributes configured for users. Remote authorization (scheme) The access device cooperates with a RADIUS or HWTACACS server to authorize users. RADIUS authorization is bound with RADIUS authentication. RADIUS authorization can work only after RADIUS authentication is successful, and the authorization information is carried in the Access-Accept message. HWTACACS authorization is separate from HWTACACS authentication, and the authorization information is carried in the authorization response after successful authentication. You can configure local authorization or no authorization as the backup method, which is used when the remote server is not available. Before configuring authorization methods, complete the following tasks: 1. For HWTACACS authorization, configure the HWTACACS scheme to be referenced first. For RADIUS authorization, the RADIUS authorization scheme must be the same as the RADIUS authentication scheme; otherwise, it does not take effect. 2. Determine the access type or service type to be configured. With AAA, you can configure an authorization scheme for each access type and service type, limiting the authorization protocols that can be used for access. 3. Determine whether to configure an authorization method for all access types or service types. Follow these guidelines when you configure AAA authorization methods for an ISP domain: The authorization method specified with the authorization default command is for all types of users and has a priority lower than that for a specific access type. If you configure an authentication method and an authorization method that use RADIUS schemes for an ISP domain, the RADIUS scheme for authorization must be the same as that for authentication. If the RADIUS authorization configuration is invalid or RADIUS authorization fails, the RADIUS authentication also fails. Whenever RADIUS authorization fails, an error message is sent to the NAS, indicating that the server is not responding. If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name [ local none ] option when you configure an authorization method, local 211

219 authorization or no authorization is the backup method and is used only when the remote server is not available. If you specify only the local or none keyword in an authorization method configuration command, the firewall has no backup authorization method and performs only local authorization or does not perform any authorization. To configure AAA authorization methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Specify the default authorization method for all types of users. 4. Specify the command authorization method. 5. Specify the authorization method for DVPN users. 6. Specify the authorization method for login users. 7. Specify the authorization method for portal users. 8. Specify the authorization method for PPP users. 9. Specify the authorization method for SSL VPN users. authorization default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authorization command { hwtacacs-scheme hwtacacs-scheme-name [ local none ] local none } authorization dvpn { local none radius-scheme radius-scheme-name [ local none ] } authorization login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authorization portal { local none radius-scheme radius-scheme-name [ local ] } authorization ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } authorization ssl-vpn radius-scheme radius-scheme-name Optional. The default authorization method is local for all types of users. Optional. The default authorization method is used by default. Optional. The default authorization method is used by default. Optional. The default authorization method is used by default. Optional. The default authorization method is used by default. Optional. The default authorization method is used by default. Optional. The default authorization method is used by default. Configuring AAA accounting methods for an ISP domain In AAA, accounting is a separate process at the same level as authentication and authorization. This process sends accounting start/update/end requests to the specified accounting server. Accounting is optional. AAA supports the following accounting methods: No accounting (none) The system does not perform accounting for the users. Local accounting (local) Local accounting is implemented on the access device. It counts and controls the number of concurrent users who use the same local user account; it does not provide 212

220 statistics for charging. The maximum number of concurrent users using the same local user account is set by the access-limit command in local user view. Remote accounting (scheme) The access device works with a RADIUS server or HWTACACS server for accounting. You can configure local or no accounting as the backup method, which will be used when the remote server is not available. By default, an ISP domain uses the local accounting method. Before configuring accounting methods, complete the following tasks: 1. For RADIUS or HWTACACS accounting, configure the RADIUS or HWTACACS scheme to be referenced first. The local and none accounting methods do not require a scheme. 2. Determine the access type or service type to be configured. With AAA, you can configure an accounting method for each access type and service type, limiting the accounting protocols that can be used for access. 3. Determine whether to configure an accounting method for all access types or service types. Follow these steps when you configure AAA accounting methods for an ISP domain: If you configure the accounting optional command, the limit on the number of local user connections is not effective. The accounting method specified with the accounting default command is for all types of users and has a priority lower than that for a specific access type. If you specify the radius-scheme radius-scheme-name local or hwtacacs-scheme hwtacacs-scheme-name local option when you configure an accounting method, local accounting is the backup method and is used only when the remote server is not available. If you specify only the local or none keyword in an accounting method configuration command, the firewall has no backup accounting method and performs only local accounting or does not perform any accounting. Accounting is not supported for FTP services. To configure AAA accounting methods for an ISP domain: Step Command Remarks 1. Enter system view. system-view N/A 2. Enter ISP domain view. domain isp-name N/A 3. Enable the accounting optional feature. 4. Specify the default accounting method for all types of users. 5. Specify the command accounting method. accounting optional accounting default { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting command hwtacacs-scheme hwtacacs-scheme-name Optional. Disabled by default. With the accounting optional feature, the firewall allows users to use network resources when no accounting server is available or communication with all accounting servers fails. Optional. The default accounting method is local for all types of users. Optional. The default accounting method is used by default. 213

221 Step Command Remarks 6. Specify the accounting method for DVPN users. 7. Specify the accounting method for login users. 8. Specify the accounting method for portal users. 9. Specify the accounting method for PPP users. 10. Specify the accounting method for SSL VPN users. accounting dvpn { local none radius-scheme radius-scheme-name [ local none ] } accounting login { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting portal { local none radius-scheme radius-scheme-name [ local ] } accounting ppp { hwtacacs-scheme hwtacacs-scheme-name [ local ] local none radius-scheme radius-scheme-name [ local ] } accounting ssl-vpn radius-scheme radius-scheme-name Optional. The default accounting method is used by default. Optional. The default accounting method is used by default. Optional. The default accounting method is used by default. Optional. The default accounting method is used by default. Optional. The default accounting method is used by default. Forcibly tearing down user connections To tear down user connections: Step Command Remarks 1. Enter system view. system-view N/A 2. Forcibly tear down AAA user connections. cut connection { access-type { dot1x mac-authentication portal } all domain isp-name interface interface-type interface-number ip ip-address mac mac-address ucibindex ucib-index user-name user-name vlan vlan-id } This command applies only to portal and PPP user connections. Configuring a NAS ID-VLAN binding The access locations of users can be identified by their access VLANs. In application scenarios where it is required to identify the access locations of users, configure NAS ID-VLAN bindings on the access device. Then, when a user gets online, the access device obtains the NAS ID by the access VLAN of the user and sends the NAS ID to the RADIUS server through the NAS-identifier attribute. To configure a NAS ID-VLAN binding: Step Command Remarks 1. Enter system view. system-view N/A 2. Create a NAS ID profile and enter NAS ID profile view. aaa nas-id profile profile-name You can apply a NAS ID profile to an interface enabled with portal. See " Configuring portal." 214

222 Step Command Remarks 3. Configure a NAS ID-VLAN binding. nas-id nas-identifier bind vlan vlan-id By default, no NAS ID-VLAN binding exists. Displaying and maintaining AAA Task Command Remarks Display the configuration information of ISP domains. Display information about user connections. display domain [ isp-name ] [ { begin exclude include } regular-expression ] display connection [ access-type { dot1x mac-authentication portal } domain isp-name interface interface-type interface-number ip ip-address mac mac-address ucibindex ucib-index user-name user-name vlan vlan-id ] [ { begin exclude include } regular-expression ] Available in any view Available in any view AAA configuration examples Authentication and authorization for Telnet and SSH users by a RADIUS server The RADIUS authentication and authorization configuration for SSH users is similar to that for Telnet users. This example describes the configuration for Telnet users. Network requirements As shown in Figure 155, configure Firewall to use the RADIUS server to provide authentication and authorization services for Telnet users and add an account with the username hello@bbb on the RADIUS server, so that the Telnet user can log in to Firewall and is authorized with the privilege level 3 after login. Set the shared keys for secure RADIUS communication to expert, and set the ports for authentication/authorization and accounting to 1812 and 1813 respectively. Configure Firewall to include the domain name in the username sent to the RADIUS server. Figure 155 Network diagram 215

223 Configuring the RADIUS server on IMC PLAT 5.0 This section uses IMC PLAT 5.0 (E0101H03) and IMC UAM 5.0 SP1 (E0101P03). 1. Add an access device: a. Log in to IMC, click the Service tab, and then select User Access Manager > Access Device Management > Access Device from the navigation tree. b. Click Add to configure an access device as follows: Set the shared key for authentication and accounting to expert. Set the ports for authentication and accounting to 1812 and 1813, respectively. Select Device Management Service as the service type. Select HP(General) as the access device type. Select the access device from the device list or manually add the device with the IP address of c. Click OK. The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from SecPath, which is chosen in this order: IP address specified with the nas-ip command on the access device IP address specified with the radius nas-ip command on the access device IP address of the outbound interface (the default) Figure 156 Adding an access device 2. Add a user for device management: a. Click the User tab, and then select Access User View > Device Mgmt User from the navigation tree. b. Click Add to configure a device management account as follows: Enter the account name hello@bbb and set the password. Select Telnet as the service type. Set the EXEC privilege level to 3. This value identifies the privilege level of the Telnet user after login and defaults to

224 Specify IP addresses to as the range of hosts to be managed. The IP address range must contain the IP address of the access device. c. Click OK. NOTE: The IP address range must contain the IP address of the access device. Figure 157 Adding an account for device management Configuring the Firewall in the web interface You can use either method to configure SecPath. Method 1: You can configure the RADIUS scheme for SecPath in the Web interface and complete other configurations at the CLI. # Configure the IP address and security zone of each interface. (Details not shown.) # Configure the RADIUS scheme system: a. Select User > RADIUS from the navigation tree and then click Add in the RADIUS scheme list area. b. Configure basic information for the RADIUS scheme: Enter system as the scheme name. Select Extended as the server type. Select With domain name for the username format. 217

225 c. In the RADIUS Server Configuration area, click Add to configure a RADIUS authentication server for the scheme as follows: Select Primary Authentication as the server type. Enter as the IP address of the primary authentication server. Enter 1812 as the port. Set expert as the key and confirm the key. Figure 158 RADIUS authentication server configuration page d. Click Apply. e. In the RADIUS Server Configuration area, click Add to configure a RADIUS accounting server for the scheme as follows: Select Primary Accounting as the server type. Enter as the IP address of the primary accounting server. Enter 1813 as the port. Set expert as the key. Figure 159 RADIUS accounting server configuration f. Click Apply. The RADIUS scheme configuration page refreshes and the added servers appear in the RADIUS Server Configuration area, as shown in Figure

226 g. Click Apply. Figure 160 RADIUS scheme configuration page # Enable the Telnet service on Firewall. [Firewall] telnet server enable # Configure Firewall to use AAA for Telnet users. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Configure the AAA methods for domain bbb. As RADIUS authorization information is sent to the RADIUS client in the authentication response messages, be sure to reference the same scheme for user authentication and authorization. [Firewall] domain bbb [Firewall-isp-bbb] authentication login radius-scheme system [Firewall-isp-bbb] authorization login radius-scheme system [Firewall-isp-bbb] accounting login radius-scheme system [Firewall-isp-bbb] quit Method 2: This method allows you to configure SecPath at the CLI. # Configure the IP address of interface GigabitEthernet 0/1, through which the Telnet user accesses Firewall. <Firewall> system-view [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] ip address [Firewall-GigabitEthernet0/1] quit 219

227 # Configure the IP address of interface GigabitEthernet 0/2, through which Firewall communicates with the server. [Firewall] interface GigabitEthernet 0/2 [Firewall-GigabitEthernet0/2] ip address [Firewall-GigabitEthernet0/2] quit # Enable the Telnet server on Firewall. [Firewall] telnet server enable # Configure Firewall to use AAA for Telnet users. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Create RADIUS scheme rad. [Firewall] radius scheme rad # Specify the primary authentication server. [Firewall-radius-rad] primary authentication # Set the shared key for authenticating authentication packets to expert. [Firewall-radius-rad] key authentication expert # Specify the service type for the RADIUS server, which must be extended when the server runs on IMC. [Firewall-radius-rad] server-type extended # Specify the scheme to include the domain names in usernames to be sent to the RADIUS server. [Firewall-radius-rad] user-name-format with-domain [Firewall-radius-rad] quit # Configure the AAA methods for domain bbb. Because RADIUS authorization information is sent to the RADIUS client in the authentication response messages, reference the same scheme for user authentication and authorization. [Firewall] domain bbb [Firewall-isp-bbb] authentication login radius-scheme rad [Firewall-isp-bbb] authorization login radius-scheme rad [Firewall-isp-bbb] quit Verifying the configuration After you complete the configuration, the user can Telnet to telnet to Firewall, use the configured account to enter the user interface of Firewall, and access all the commands of level 0 to level 3. # Use the display connection command to view the connection information on Firewall. [Firewall] display connection Index=1,Username=hello@bbb IP= IPv6=N/A Total 1 connection(s) matched. Local authentication and authorization for Telnet and FTP users The local authentication and authorization configuration for FTP users is similar to that for Telnet users. This example describes the configuration for Telnet users. 220

228 Network requirements As shown in Figure 161, configure Firewall to perform local authentication and authorization for Telnet users. Figure 161 Network diagram Configuration procedure 1. Configure Firewall # Configure the IP address of interface GigabitEthernet 0/1, through which the Telnet user accesses Firewall. <Firewall> system-view [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] ip address [Firewall-GigabitEthernet0/1] quit # Enable the Telnet server on Firewall. [Firewall] telnet server enable # Configure Firewall to use AAA for Telnet users. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Create local user named telnet. [Firewall] local-user telnet [Firewall-luser-telnet] service-type telnet [Firewall-luser-telnet] password simple aabbcc [Firewall-luser-telnet] quit # Configure the AAA methods for the ISP domain as local authentication and authorization. [Firewall] domain system [Firewall-isp-system] authentication login local [Firewall-isp-system] authorization login local [Firewall-isp-system] quit 2. Verify the configuration A Telnet user can access the user interface of Firewall by using username telnet@system and correct password. # Use the display connection command to view the connection information on Firewall. [Firewall] display connection Index=1,Username=telnet@system IP= IPv6=N/A Total 1 connection(s) matched. 221

229 Level switching authentication for Telnet users by a RADIUS server The RADIUS server in this example runs ACSv4.0. Network requirements As shown in Figure 162, configure Firewall to: Use local authentication for the Telnet user and assign the privilege level of 0 to the user when the user passes authentication. Use the RADIUS server for level switching authentication of the Telnet user. If the RADIUS server is not available, use local authentication instead. Figure 162 Network diagram Configuration considerations 1. Configure Firewall to use AAA, particularly, local authentication for Telnet users: Create ISP domain bbb and configure it to use local authentication for Telnet users. Create a local user account, configure the password, and assign the user privilege level. 2. On Firewall, configure the authentication method for user privilege level switching. Specify to use RADIUS authentication and, if RADIUS authentication is not available, use local authentication for users switching from a lower level to a higher level. Configure RADIUS scheme rad and assign an IP address to the RADIUS server. Set the shared keys for authenticating AAA packets and specify that usernames sent to the RADIUS server carry no domain name. Configure the domain to use RADIUS scheme rad for user privilege level switching authentication. Configure the password for local user privilege level switching authentication. 3. On the RADIUS server, add the username and password for user privilege level switching authentication. Configuring Firewall # Configure the IP address of GigabitEthernet 0/1, through which the Telnet user accesses Firewall. <Firewall> system-view [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] ip address [Firewall-GigabitEthernet0/1] quit 222

230 # Configure the IP address of GigabitEthernet 0/2, through which Firewall communicates with the server. [Firewall] interface GigabitEthernet 0/2 [Firewall-GigabitEthernet0/2] ip address [Firewall-GigabitEthernet0/2] quit # Enable Firewall to provide Telnet service. [Firewall] telnet server enable # Configure Firewall to use AAA for Telnet users. [Firewall] user-interface vty 0 4 [Firewall-ui-vty0-4] authentication-mode scheme [Firewall-ui-vty0-4] quit # Use RADIUS authentication for user privilege level switching authentication and, if RADIUS authentication is not available, use local authentication. [Firewall] super authentication-mode scheme local # Create RADIUS scheme rad. [Firewall] radius scheme rad # Specify the IP address of the primary authentication server as , and the port for authentication as [Firewall-radius-rad] primary authentication # Set the shared key for authenticating authentication packets to expert. [Firewall-radius-rad] key authentication expert # Specify the service type of the RADIUS server as standard. [Firewall-radius-rad] server-type standard # Specify the scheme to exclude the domain names from usernames to be sent to the RADIUS server. [Firewall-radius-rad] user-name-format without-domain [Firewall-radius-rad] quit # Create ISP domain bbb. [Firewall] domain bbb # Configure the AAA methods for domain bbb as local authentication. [Firewall-isp-bbb] authentication login local # Configure the domain to use the RADIUS scheme rad for user privilege level switching authentication. [Firewall-isp-bbb] authentication super radius-scheme rad [Firewall-isp-bbb] quit # Create a local Telnet user named test. [Firewall] local-user test [Firewall-luser-test] service-type telnet [Firewall-luser-test] password simple aabbcc # Configure the user level of the Telnet user to 0 after user login. [Firewall-luser-test] authorization-attribute level 0 [Firewall-luser-test] quit # Configure the password for local level switching authentication to [Firewall] super password simple [Firewall] quit 223

231 Configuring the RADIUS server Add the usernames and passwords for user privilege level switching authentication, as shown in Table 56 and Figure 163. Table 56 Adding username and passwords for user privilege level switching authentication Username Password Switching to level $enab1$ pass1 1 $enab2$ pass2 2 $enab3$ pass3 3 NOTE: A username configured on the RADIUS server is in the format of $enablevel$, where level specifies the privilege level to which the user wants to switch. Figure 163 Configuring a username for privilege level switching (take $enab1$ in this example) 224

232 Figure 164 List of the usernames for privilege level switching Verifying the configuration After you complete the configuration, the user can Telnet to Firewall and use username and password aabbcc to enter the user interface of Firewall, and access all level 0 commands. <Firewall> telnet Trying Press CTRL+K to abort Connected to ****************************************************************************** * Copyright (c) Hewlett-Packard Development Company, L.P. * * Without the owner's prior written consent, * * no decompiling or reverse-engineering shall be allowed. * ****************************************************************************** Login authentication Username:test@bbb Password: <Firewall>? User view commands: display Display current system information ping Ping function quit Exit from current command view ssh2 Establish a secure shell client connection super Set the current user priority level telnet Establish one TELNET connection tracert Trace route function When switching to user privilege level 3, the Telnet user only needs to enter password pass3 as prompted. <Firewall> super 3 Password: User privilege level is 3, and only those commands can be used whose level is equal or less than this. Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE If the RADIUS authentication is not available, the Telnet user needs to enter password as prompted for local authentication. <Firewall> super 3 Password: Enter the password for RADIUS privilege level switch authentication 225

233 Error: Invalid configuration or no response from the authentication server. Info: Change authentication mode to local. Password: Enter the password for local privilege level switch authentication User privilege level is 3, and only those commands can be used whose level is equal or less than this. Privilege note: 0-VISIT, 1-MONITOR, 2-SYSTEM, 3-MANAGE AAA for portal users by a RADIUS server Network requirements As shown in Figure 165, the host automatically obtains a public network IP address through DHCP. Configure Firewall to: Use the RADIUS server for authentication, authorization, and accounting of portal users. Provide direct portal authentication so that the host can access only the portal server before passing portal authentication and can access the Internet after passing portal authentication. Include the domain name in a username sent to the RADIUS server. On the RADIUS server, add a service that charges 120 dollars for up to 120 hours per month, configure a user with the name dot1x@bbb, and assign the service to the user. Set the shared keys for secure RADIUS communication to expert. Set the ports for authentication/authorization and accounting to 1812 and 1813 respectively. Figure 165 Network diagram Configuration prerequisites Configure IP addresses for the devices as shown in Figure 165 and make sure that devices have IP connectivity between each other. Configuring the RADIUS server on IMC PLAT 5.0 This section uses IMC PLAT 5.0 (E0101H03), IMC UAM 5.0 SP1 (E0101P03), and IMC 5.0 (E0101P01). 1. Add SecPath to IMC as an access device: a. Log in to IMC, click the Service tab, and then select User Access Manager > Access Device Management > Access Device from the navigation tree. b. Click Add to configure an access device as follows: Set the shared key for authentication and accounting to expert. 226

234 Set the ports for authentication and accounting to 1812 and 1813, respectively. Select LAN Access Service as the service type. Select HP(General) as the access device type. Select the access device from the device list or manually add the device with the IP address of Leave the default settings for other parameters. c. Click OK. The IP address of the access device specified here must be the same as the source IP address of the RADIUS packets sent from the access device, which is chosen in this order: IP address specified with the nas-ip command on the access device IP address specified with the radius nas-ip command on the access device IP address of the outbound interface (the default) Figure 166 Adding an access device 2. Add a charging plan: a. Click the Service tab, and then select Accounting Manager > Charging Plans from the navigation tree. b. Click Add to configure a charging plan as follows: Enter UserAcct as the plan name. Select Flat rate as the charging template. Select time for Charge Based on, select Monthly for Billing Term, and type 120 in the Fixed Fee field. Enter 120 in the Usage Threshold field and select hr for the in field to allow the user to access the Internet for up to 120 hours per month. c. Click OK. 227

235 Figure 167 Adding a charging plan 3. Add a service: a. Click the Service tab, and then select User Access Manager > Service Configuration from the navigation tree. b. Click Add to configure a service as follows: Enter Portal auth/acct as the service name, and set the service suffix to dm1. The service suffix represents the authentication domain for the portal user. With the service suffix configured, you must configure the access device to send usernames that carry domain names to the RADIUS server. Select UserAcct as the charging plan. Configure other parameters as needed. c. Click OK. Figure 168 Adding a service 4. Add an access user account: a. Click the User tab, and then select Access User View > All Access Users from the navigation tree. 228

236 b. Click Add to configure an access user account as follows: Select the user hello from the IMC Platform or add the user if it does not exist. Enter the account name portal and set the password. Select the service Portal auth/acct for the access user account. Configure other parameters as needed. c. Click OK. Figure 169 Adding an access user account Configuring the portal server on IMC PLAT 5.0 This section uses IMC PLAT 5.0 (E0101H03) and IMC UAM 5.0 SP1 (E0101P03). 1. Configure the portal server: a. Log in to IMC, click the Service tab, and then select User Access Manager > Portal Service Management > Server from the navigation tree. b. Enter the URL address of the portal authentication login page in the format of where ip and port are the same as those configured during IMC UAM installation. Usually, the default port 8080 is used. c. Leave the default settings for other parameters and click OK. 229

237 Figure 170 Portal server configuration 2. Configure the IP address group: a. Select User Access Manager > Portal Service Management > IP Group from the navigation tree. b. Click Add to configure an IP address group as follows: Enter Portal_user as the IP group name. Set the start IP address to and the end IP address to The IP address of the host must be within this IP address group. Select Normal from the Action list. c. Click OK. Figure 171 Adding an IP address group 3. Add a portal device: 230

238 a. Select User Access Manager > Portal Service Management > Device from the navigation tree. b. Click Add to configure a portal device as follows: Enter NAS as the device name. Enter the IP address of the access interface on the firewall, which is Enter the key, which is portal, the same as that configured on SecPath. Enable or disable IP address reallocation. To use direct portal authentication, select No from the Reallocate IP list. c. Leave the default settings for other parameters and click OK. Figure 172 Adding a portal device 4. Associate the portal device with the IP address group: a. In the portal device list, click the Port Group Information Management icon for device NAS. Figure 173 Device list b. Click Add to configure a port group as follows: Enter group as the port group name. 231