HP A-F1000-A-EI_A-F1000-S-EI VPN Firewalls

Transcription

1 HP A-F1000-A-EI_A-F1000-S-EI VPN Firewalls VPN Configuration Guide Part number: Document version: 6PW

2 Legal and notice information Copyright 2011 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 GRE configuration 1 GRE overview 1 Introduction to GRE 1 GRE security options 2 GRE applications 3 Protocols and standards 4 Configuring a GRE over IPv4 tunnel 4 Configuring a GRE over IPv4 tunnel in the web interface 4 GRE over IPv4 tunnel configuration example in the web interface 6 Configuring a GRE over IPv4 tunnel at the CLI 9 GRE over IPv4 tunnel configuration example at the CLI 11 Configuring a GRE over IPv6 tunnel 14 Configuration guidelines 14 Configuration prerequisites 15 Configuration procedure 15 GRE over IPv6 tunnel configuration example 16 Displaying and maintaining GRE 19 Troubleshooting GRE 19 Point to multi-point GRE tunnel 21 P2MP GRE tunnel overview 21 Background 21 Operation of the P2MP GRE tunnel 21 P2MP GRE tunnel backup 23 Advantages and restrictions of the P2MP GRE tunnel technology 24 Configuring a P2MP GRE tunnel in the web interface 25 Configuration prerequisites 25 Configuration task list 25 Configuring a P2MP GRE tunnel interface 26 Displaying information about established P2MP GRE tunnels 28 Basic P2MP GRE tunnel configuration example 28 Configuration example for P2MP GRE tunnel backup at the headquarters 32 Configuration example for P2MP GRE tunnel backup at a branch 42 Configuring a P2MP GRE tunnel at the CLI 48 Configuration guidelines 48 Configuration prerequisites 48 Configuring a P2MP GRE tunnel 48 Displaying and maintaining P2MP GRE tunnels 50 Basic P2MP GRE tunnel configuration example 50 Configuration example for P2MP GRE tunnel backup at the headquarters 52 Configuration example for P2MP GRE tunnel backup at a branch 56 AFT Configuration 60 AFT overview 60 Application scenario 60 Basic concepts 60 AFT modes 61 AFT operation 62 DNS64 function 64 AFT Limitations 64 i

4 Protocols and standards 64 AFT configuration task list 65 When communication is initiated by an IPv6 host 65 When communication is initiated by an IPv4 host 65 Configuring AFT 65 Configuration prerequisites 65 Enabling AFT 65 Configuring a DNS64 prefix 66 Configuring an IVI prefix 66 Configuring a 6to4 AFT policy 66 Configuring 4to6 AFT policies 67 Displaying and maintaining AFT 68 AFT configuration examples 69 An IPv6 host with an IVI address initiates communication with an IPv4 host 69 An IPv4 host initiates communication with an IPv6 host 70 Configure the DNS64 function of AFT 73 Troubleshooting AFT 76 Tunneling configuration 77 Tunneling overview 77 IPv6 over IPv4 tunnels 77 IPv4 over IPv4 tunneling 80 IPv4 over IPv6 tunneling 81 IPv6 over IPv6 tunneling 84 Protocols and standards 84 Tunneling configuration task list 85 Configuring a tunnel interface 85 Configuring an IPv6 manual tunnel 86 Configuration prerequisites 86 Configuration procedure 86 Configuration example 87 Configuring a 6to4 tunnel 90 Configuration prerequisites 90 Configuration procedure 90 6to4 tunnel configuration example 91 6to4 relay configuration example 94 Configuring an ISATAP tunnel 96 Configuration prerequisites 96 Configuration procedure 96 Configuration example 97 Configuring an IPv4 over IPv4 tunnel 99 Configuration prerequisites 99 Configuration procedure 99 Configuration example 100 Configuring an IPv4 over IPv6 manual tunnel 103 Configuration prerequisites 103 Configuration procedure 103 Configuration example 104 Configuring a DS-lite tunnel 107 Configuration prerequisites 107 Configuring the CPE of a tunnel 107 Configuring the AFTR of a tunnel 108 Configuration example 109 Configuring an IPv6 over IPv6 tunnel 113 Configuration prerequisites 113 ii

5 Configuration procedure 113 Configuration example 114 Displaying and maintaining tunneling configuration 117 Troubleshooting tunneling configuration 118 IKE configuration 119 IKE overview 119 IKE security mechanism 119 IKE operation 119 Functions of IKE in IPsec 120 Relationship between IKE and IPsec 121 Protocols 121 IKE configuration prerequisites 121 Configuring IKE in the web interface 122 Configuring global IKE parameters 123 Configuring an IKE proposal 123 Configuring IKE DPD 125 Configuring an IKE peer 126 Viewing IKE SAs 128 IKE configuration example in the web interface 129 Configuring IKE at the CLI 132 IKE configuration task list 132 Configuring a name for the local security gateway 132 Configuring an IKE proposal 132 Configuring an IKE peer 133 Setting keepalive timers 135 Setting the NAT keepalive timer 136 Configuring a DPD detector 136 Disabling next payload field checking 137 Displaying and maintaining IKE 137 IKE configuration examples at the CLI 137 Main mode IKE with pre-shared key authentication configuration example 137 Aggressive mode IKE with NAT traversal configuration example 142 Troubleshooting IKE 145 Invalid user ID 145 Proposal mismatch 146 Failing to establish an IPsec tunnel 146 ACL configuration error 146 IPsec configuration 148 IPsec overview 148 IPsec implementation 148 Basic concepts 149 IPsec tunnel interface 151 IPsec for IPv6 routing protocols 152 IPsec RRI 152 IPsec stateful failover 153 Protocols and standards 154 Configuring IPsec 154 Configuring ACL-based IPsec in the web interface 154 Configuration considerations 154 Recommended configuration procedure 155 Configuring ACLs 156 Configuring an IPsec proposal 159 Configuring an IPsec policy template 162 iii

6 Configuring an IPsec policy 164 Applying an IPsec policy group 167 Viewing IPsec SAs 167 Viewing packet statistics 168 Configuring ACL-based IPsec at the CLI 168 Configuration task list 168 Configuring ACLs 169 Configuring an IPsec proposal 171 Configuring a manual IPsec policy 171 Configuring an IPsec policy that uses IKE 174 Applying an IPsec policy group to an interface 177 Enabling the encryption engine 178 Enabling ACL checking of de-encapsulated IPsec packets 178 Configuring the IPsec anti-replay function 178 Configuring packet information pre-extraction 179 Enabling invalid SPI recovery 180 Configuring IPsec RRI 180 Configuring tunnel interface-based IPsec 181 Configuration task list 181 Configuring an IPsec profile 182 Configuring an IPsec tunnel interface 184 Enabling packet information pre-extraction on the IPsec tunnel interface 185 Applying a QoS policy to an IPsec tunnel interface 185 Configuring IPsec for IPv6 routing protocols 186 Configuring IPsec stateful failover 186 Displaying and maintaining IPsec 187 IPsec configuration examples 188 Manual mode IPsec tunnel for IPv4 packets configuration example in the web interface 188 Manual mode IPsec tunnel for IPv4 packets configuration example at the CLI 194 IKE-based IPsec tunnel for IPv4 packets configuration example 197 IPsec with IPsec tunnel interfaces configuration example 199 IPsec for RIPng configuration example 203 IPsec RRI configuration example 207 IPsec stateful failover configuration example 210 IPsec configuration guidelines 218 IPSec VPN configuration wizard 219 IPSec VPN configuration wizard overview 219 Configuring an IPsec VPN 219 Launching the IPsec VPN policy configuration wizard 219 Configuring a center node 220 Configuring a branch node 223 Configuring a peer node 226 L2TP configuration 230 Overview 230 Typical networking application of L2TP 230 Basic concepts of L2TP 231 L2TP tunnel modes and tunnel establishment process 233 L2TP features 236 Protocols and standards 236 Configuring L2TP in the web interface 236 L2TP configuration task list 237 Enabling L2TP 237 Adding an L2TP group 237 iv

7 Displaying L2TP tunnel information 244 L2TP configuration example 244 Configuring L2TP at the CLI 249 L2TP configuration task list 249 Configuring basic L2TP capability 250 Configuring an LAC 250 Configuring an LNS 253 Configuring L2TP connection parameters 257 Displaying and maintaining L2TP 259 Configuration example for NAS-initiated VPN 259 Configuration example for client-initiated VPN 261 Configuration example for LAC-auto-initiated VPN 263 Configuration example for L2TP multi-domain application 265 Complicated network application 269 Troubleshooting L2TP 269 Certificate management 271 PKI overview 271 PKI terms 271 Architecture of PKI 272 Applications of PKI 273 Operation of PKI 273 Configuring PKI in the web interface 273 Configuration task list 273 Creating a PKI entity 276 Creating a PKI domain 277 Generating an RSA key pair 280 Destroying the RSA key pair 281 Retrieving and displaying a certificate 281 Requesting a local certificate 282 Retrieving and displaying a CRL 283 PKI configuration examples in the web interface 284 Configuring a PKI entity to request a certificate from a CA (method i) 284 Configuring a PKI entity to request a certificate from a CA (method ii) 290 Applying RSA digital signature in IKE negotiation 294 Configuring PKI at the CLI 302 PKI configuration task list 302 Configuring an entity DN 302 Configuring a PKI domain 303 Submitting a PKI certificate request 305 Retrieving a certificate manually 307 Configuring PKI certificate verification 307 Destroying a local RSA key pair 308 Deleting a certificate 309 Configuring an access control policy 309 Displaying and maintaining PKI 310 PKI configuration examples at the CLI 310 Requesting a certificate from a CA server running RSA Keon 310 Requesting a certificate from a CA server running Windows 2003 Server 313 Applying RSA digital signature in IKE negotiation 316 Configuring a certificate attribute-based access control policy 319 Troubleshooting PKI 320 Failed to retrieve a CA certificate 320 Failed to request a local certificate 321 Failed to retrieve CRLs 321 v

8 Configuration guidelines 322 Public key configuration 323 Asymmetric key algorithm overview 323 Basic concepts 323 Key algorithm types 323 Asymmetric key algorithm applications 323 Configuring the local asymmetric key pair 324 Creating an asymmetric key pair 324 Displaying or exporting the local RSA or DSA host public key 324 Destroying an asymmetric key pair 325 Configuring a peer public key 325 Displaying and maintaining public keys 326 Public key configuration examples 326 Configuring a peer public key manually 326 Importing a peer public key from a public key file 328 SSL VPN configuration 331 SSL VPN overview 331 How SSL VPN works 331 Advantages of SSL VPN 332 CLI configuration required to implement SSL VPN 333 Configuration prerequisites 333 Configuration procedure 333 Example of the CLI configuration required for SSL VPN 334 Web configuration required to implement SSL VPN 335 SSL VPN gateway configuration task list 335 Configuring the SSL VPN service 337 Configuring web proxy server resources 337 Configuring TCP application resources 340 Configuring IP network resources 346 Configuring a resource group 352 Configuring local users 354 Configuring a user group 356 Viewing user information 358 Performing basic configurations for the SSL VPN domain 359 Configuring authentication policies 362 Configuring a security policy 367 Customizing the SSL VPN user interface 371 User access to SSL VPN 375 SSL VPN configuration example 380 Support and other resources 398 Contacting HP 398 Subscription service 398 Related information 398 Documents 398 Websites 398 Conventions 399 Index 401 vi

9 GRE configuration GRE overview Introduction to GRE Generic Routing Encapsulation (GRE) is a protocol designed for encapsulating and carrying the packets of one network layer protocol (for example, IP) over another network layer protocol (for example, IP). GRE is a tunneling technology and serves as a Layer 3 tunneling protocol. A GRE tunnel is a virtual point-to-point connection for transferring encapsulated packets. Packets are encapsulated at one end of the tunnel and de-encapsulated at the other end. Figure 1 depicts the encapsulation and de-encapsulation processes. Figure 1 X protocol networks interconnected through the GRE tunnel The following takes the network shown in Figure 1 as an example to describe how an X protocol packet traverses the IP network through a GRE tunnel. Encapsulation process 1. After receiving an X protocol packet through the interface connected to Group 1, Device A submits it to the X protocol for processing. 2. The X protocol checks the destination address field in the packet header to determine how to route the packet. 3. If the packet must be tunneled to reach its destination, Device A sends it to the tunnel interface. 4. Upon receipt of the packet, the tunnel interface encapsulates it in a GRE packet. Then, the system encapsulates the packet in an IP packet and forwards the IP packet based on its destination address and the routing table. GRE encapsulation format Figure 2 GRE encapsulation format As an example, Figure 3 shows the format of an X packet encapsulated for transmission over an IP tunnel. 1

10 Figure 3 Format of an X packet encapsulated for transmission over an IP tunnel These are the terms involved: Payload Packet that needs to be encapsulated and transmitted. Passenger protocol Protocol that the payload packet uses, X in the example. Encapsulation or carrier protocol Protocol used to encapsulate the payload packet, that is, GRE. Delivery or transport protocol Protocol used to encapsulate the GRE packet and then forward the packet to the other end of the tunnel, IP in this example. Depending on the transport protocol, two tunnel modes are present: GRE over IPv4 and GRE over IPv6. De-encapsulation process De-encapsulation is the reverse of the encapsulation process: 1. Upon receiving an IP packet from the tunnel interface, Device B checks the destination address. 2. If the destination is itself, Device B strips off the IP header of the packet and submits the resulting packet to the GRE protocol. 3. The GRE protocol checks the key, checksum and sequence number in the packet, and then strips off the GRE header and submits the payload to the X protocol for forwarding. NOTE: Encapsulation and de-encapsulation processes on both ends of the GRE tunnel and the resulting increase in data volumes will degrade the forwarding efficiency for the GRE-enabled device to some extent. GRE security options For the purpose of tunnel security, GRE provides two options: tunnel interface key and end-to-end checksum. According to RFC 1701, If the Key Present field of a GRE packet header is set to 1, the Key field will carry the key for the receiver to authenticate the source of the packet. This key must be the same at both ends of a tunnel. Otherwise, packets delivered over the tunnel will be discarded. If the Checksum Present bit of a GRE packet header is set to 1, the Checksum field contains valid information. The sender calculates the checksum for the GRE header and the payload and sends the packet containing the checksum to the peer. The receiver calculates the checksum for the received packet and compares it with that carried in the packet. If the checksums are the same, the receiver considers the packet intact and continues to process the packet. Otherwise, the receiver discards the packet. 2

11 GRE applications Multi-protocol communications through a single-protocol backbone Figure 4 Multi-protocol communications through a single-protocol backbone In the example shown in Figure 4, Group 1 and Group 2 are local networks running Novell IPX, and Team 1 and Team 2 are local networks running IP. Through the GRE tunnel between Device A and Device, Group 1 can communicate with Group 2 and Team 1 can communicate with Team 2. They will not interfere with each other. Scope enlargement of a hop-limited protocol such as RIP Figure 5 Network scope enlargement Device A Device D IP network GRE tunnel IP network Host A Device B IP network Device C Host B When the hop count between two terminals exceeds 15, the terminals cannot communicate with each other. Using GRE, you can hide some hops so as to enlarge the scope of the network. 3

12 VPN establishment by connecting discontinuous subnets Figure 6 Connect discontinuous subnets with a tunnel to form a VPN In the example as shown in Figure 6, Group 1 and Group 2 running Novell IPX are deployed in different cities. They can constitute a trans-wan virtual private network (VPN) through the tunnel. GRE-IPsec tunnel application Figure 7 GRE-IPsec tunnel application GRE can work with IPsec, allowing data packets like routing protocol, voice, and video packets to be encapsulated by GRE and then encrypted by IPsec to improve security of data transmission in a tunnel. Protocols and standards RFC 1701, Generic Routing Encapsulation (GRE) RFC 1702, Generic Routing Encapsulation over IPv4 networks RFC 2784, Generic Routing Encapsulation (GRE) Configuring a GRE over IPv4 tunnel Configuring a GRE over IPv4 tunnel in the web interface Configuration prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can communicate with the interface used as the source interface of the tunnel interface on the peer device normally. 4

13 Configuration task list Table 1 GRE over IPv4 tunnel configuration task list Task Creating a GRE over IPv4 tunnel interface Configuring a route for packet forwarding through the tunnel Remarks Required Create a tunnel interface and configure GRE over IPv4 tunnel related parameters. Optional Each end of the tunnel must have a route (static or dynamic) for packet forwarding through the tunnel to the other end, so that GRE encapsulated packets can be forwarded normally. For information about static and dynamic route configuration, see Network Management Configuration Guide. Creating a GRE over IPv4 tunnel interface Select VPN > GRE > GRE from the navigation tree to enter the GRE over IPv4 tunnel interface management page, as shown in Figure 8. Then, click Add to add a GRE over IPv4 tunnel interface, as shown in Figure 9. Figure 8 GRE over IPv4 tunnel management page Figure 9 Add a GRE over IPv4 tunnel interface 5

14 Table 2 Configuration items Item Tunnel Interface Description Specify the number of the tunnel interface. Specify the IP address and subnet mask of the tunnel interface. IP/Mask Zone Tunnel Source IP/Interface Tunnel Destination IP GRE Key GRE Packet Checksum Keepalive Keepalive Interval Number of Retries IMPORTANT: When configuring a static route on the tunnel interface, note that the destination IP address of the static route must not be in the subnet of the tunnel interface. Specify the security zone to which the tunnel interface belongs. Specify the source IP address and destination IP address for the tunnel interface. For the tunnel source address, you can input an IP address or select an interface. In the latter case, the primary IP address of the interface will be used as the tunnel source address. IMPORTANT: The source address and destination address of a tunnel uniquely identify a path. They must be configured at both ends of the tunnel and the source address at one end must be the destination address at the other end and vice versa. Specify the key for the GRE tunnel interface. This configuration is to prevent the tunnel ends from servicing or receiving packets from other places. IMPORTANT: The two ends of a tunnel must have the same key or have no key at the same time. Enable or disable the GRE packet checksum function. Enable or disable the GRE keepalive function. With the GRE keepalive function enabled on a tunnel interface, the firewall sends GRE keepalive packets from the tunnel interface periodically. If no response is received from the peer within the specified interval, the firewall retransmits the keepalive packet. If the firewall still receives no response from the peer after sending the keepalive packet for the maximum number of attempts, the local tunnel interface goes down and stays down until it receives a keepalive acknowledgement packet from the peer. Specify the interval between sending the keepalive packets and the maximum number of transmission attempts. The two configuration items are available when you select Enable for the GRE keepalive function. GRE over IPv4 tunnel configuration example in the web interface NOTE: In this configuration example, either Device A or Device B is the firewall. Network requirements As shown in Figure 10, Device A and Device B are interconnected through the Internet. Two private IP subnets Group 1 and Group 2 are interconnected through a GRE tunnel between Device A and Device B. 6

15 Figure 10 Network diagram NOTE: Before the configuration, make sure that Device A and Device B have IP connectivity to each other. Configuring Device A # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a GRE tunnel interface. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure 11. Figure 11 Create a GRE tunnel interface Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Trust from the Zone list. (Select a security zone according to your network configuration.) Enter the source end IP address , the IP address of GigabitEthernet 0/1. Enter the destination end IP address , the IP address of GigabitEthernet 0/1 on Device B. Click Apply. # Configure a static route from Device A through interface Tunnel 0 to Group 2. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 12. 7

16 Figure 12 Add a static route from Device A through interface Tunnel 0 to Group 2 Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Click Apply. Configuring Device B The configuration pages of Device B are similar to those of Device A. See the figures provided for configurations on Device A. # Configure an IPv4 address and assign the interfaces to security zones. (Details not shown) # Create a GRE tunnel interface. Select VPN > GRE > GRE from the navigation tree and then click Add. Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Trust from the Zone list. (Select a security zone according to your network configuration.) Enter the source end IP address , the IP address of GigabitEthernet 0/1. Enter the destination end IP address , the IP address of GigabitEthernet 0/1 on Device A. Click Apply. # Configure a static route from Device B through interface Tunnel 0 to Group 1. Select Network > Routing Management > Static Routing from the navigation tree and then click Add. Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Click Apply. Verifying the configuration # After the above configurations, log in to the web interface of Device A and then select Device Management > Interface from the navigation tree. Click the name link of Tunnel0. You can view the status of interface Tunnel0, as shown in Figure 13. 8

17 Figure 13 Status information and statistics of interface Tunnel0 # From Device B, ping the IP address of GigabitEthernet 0/0 on Device A. <DeviceB> ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=2 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=2 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/2 ms Configuring a GRE over IPv4 tunnel at the CLI Configuration guidelines The source address and destination address of a tunnel uniquely identify a path. They must be configured at both ends of the tunnel and the source address at one end must be the destination address at the other end and vice versa. Tunnel interfaces using the same encapsulation protocol must have different source addresses and destination addresses. 9

18 If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. You can enable or disable the checksum function at both ends of the tunnel as needed. If the checksum function is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you are not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. Instead, you can do one of the following: Configuration prerequisites Configure a static route, using the address of the network segment that the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Enable a dynamic routing protocol on both the tunnel interface and the router interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets through the tunnel. On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can normally communicate with the interface used as the source interface of the tunnel interface on the peer device. Configuration procedure Follow these steps to configure a GRE over IPv4 tunnel: To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to GRE over IPv4 Configure the source address or interface for the tunnel interface Configure the destination address for the tunnel interface interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre source { ip-address interface-type interface-number } destination ip-address Required By default, no tunnel interface is created on the firewall. Required By default, a tunnel interface has no IPv4 address. Optional The default tunnel mode is GRE over IPv4. You must configure the same tunnel mode on both ends of a tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for a tunnel interface. Required By default, no destination address is configured for a tunnel interface. 10

19 To do Use the command Remarks Enable GRE keepalive and set the interval and the maximum number of transmission attempts Enable the GRE packet checksum function Configure the key for the GRE tunnel interface Configure a route for packet forwarding through the tunnel keepalive [ seconds [ times ] ] gre checksum gre key key-number See Network Management Configuration Guide Optional Disabled by default Optional Disabled by default Optional By default, no key is configured for a GRE tunnel interface. The two ends of a tunnel must have the same key or have no key at the same time. Required Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. Return to system view quit Configure the firewall to discard the IPv4-compatible IPv6 packets tunnel discard ipv4-compatible-packet Optional By default, the firewall does not discard the IPv4-compatible IPv6 packets. NOTE: For information tunnel interfaces and more configuration commands in a tunnel interface, see the chapter Tunneling configuration. GRE over IPv4 tunnel configuration example at the CLI NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements Router A and Router B are interconnected through the Internet. Two private IPv4 subnets Group 1 and Group 2 are interconnected through a GRE tunnel between the two routers. Figure 14 Network diagram Configuration procedure 11

20 NOTE: Before the configuration, make sure that Router A and Router B are reachable to each other. 1. Configure Router A # Configure an IPv4 address for interface GigabitEthernet 0/1. <RouterA> system-view [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ip address [RouterA-GigabitEthernet0/1] quit # Configure an IPv4 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ip address [RouterA-GigabitEthernet0/2] quit # Create a tunnel interface Tunnel0. [RouterA] interface tunnel 0 # Configure an IPv4 address for interface Tunnel0. [RouterA-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [RouterA-Tunnel0] tunnel-protocol gre # Configure the source address of interface Tunnel0 to be the IP address of GigabitEthernet 0/2. [RouterA-Tunnel0] source # Configure the destination address of interface Tunnel0 to be the IP address of GigabitEthernet 0/2 on Router B. [RouterA-Tunnel0] destination [RouterA-Tunnel0] quit # Configure a static route from Router A through interface Tunnel0 to Group 2. [RouterA] ip route-static tunnel 0 2. Configure Router B # Configure an IPv4 address for interface GigabitEthernet 0/1. <RouterB> system-view [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ip address [RouterB-GigabitEthernet0/1] quit # Configure an IPv4 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ip address [RouterB-GigabitEthernet0/2] quit # Create a tunnel interface Tunnel0. [RouterB] interface tunnel 0 # Configure an IP address for interface Tunnel0. [RouterB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [RouterB-Tunnel0] tunnel-protocol gre 12

21 # Configure the source address of interface Tunnel0 to be the IP address of interface GigabitEthernet 0/2. [RouterB-Tunnel0] source # Configure the destination address of interface Tunnel0 to be the IP address of interface GigabitEthernet 0/2 on Router A. [RouterB-Tunnel0] destination [RouterB-Tunnel0] quit # Configure a static route from Router B through interface Tunnel0 to Group 1. [RouterB] ip route-static tunnel 0 3. Verify the configuration # Display the tunnel interface status on Router A and Router B respectively. [RouterA] display interface tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1476 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source , destination Tunnel keepalive disabled Tunnel protocol/transport GRE/IP GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error [RouterB] display interface tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1476 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source , destination Tunnel keepalive disabled Tunnel protocol/transport GRE/IP GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 13

22 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 2 bytes/sec, 0 packets/sec Last 300 seconds output: 2 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error # From Router B, you can ping the IP address of GigabitEthernet 0/1 on Router A. [RouterB] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=2 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=2 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 2/2/2 ms Configuring a GRE over IPv6 tunnel NOTE: The GRE over IPv6 tunnel configuration is available only at the CLI. Configuration guidelines Deleting a tunnel interface also remove the functions configured on this tunnel interface. The source address and destination address of a tunnel uniquely identify a path. They must be configured at both ends of the tunnel and the source address at one end must be the destination address at the other end and vice versa. Tunnel interfaces using the same encapsulation protocol must have different source addresses and destination addresses. If you configure a source interface for a tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. You can enable or disable the checksum function at both ends of the tunnel as needed. If the checksum function is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. Contrarily, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you are not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. Instead, you can do one of the following: 14

23 Configure a static route, using the address of the network segment the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Enable a dynamic routing protocol on both the tunnel interface and the router interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets through the tunnel. Configuration prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can normally communicate with the interface used as the source interface of the tunnel interface on the peer device. Configuration procedure Follow these steps to configure a GRE over IPv6 tunnel: To do Use the command Remarks Enter system view system-view Enable the IPv6 packet forwarding function Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to GRE over IPv6 Configure the source address or interface for the tunnel interface Configure the destination address for the tunnel interface Set the maximum number of encapsulations in the tunnel Enable the GRE packet checksum function ipv6 interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre ipv6 source { ipv6-address interface-type interface-number } destination ipv6-address encapsulation-limit [ number ] gre checksum Required Disabled by default Required By default, no tunnel interface is created on the firewall. Required By default, no IPv4 address is configured for a tunnel interface. Required The default tunnel mode is GRE over IPv6. You must configure the same tunnel mode on both ends of a tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for a tunnel interface. Required By default, no destination address is configured for a tunnel interface. Optional 4 by default Optional Disabled by default 15

24 To do Use the command Remarks Configure the key for the GRE tunnel interface gre key key-number Optional By default, no key is configured for a GRE tunnel interface. The two ends of a tunnel must have the same key or have no key at the same time. Return to system view quit Configure the firewall to discard the IPv4-compatible IPv6 packets Configure a route for packet forwarding through the tunnel tunnel discard ipv4-compatible-packet See Network Management Configuration Guide Optional By default, the firewall does not discard the IPv4-compatible IPv6 packets. Required Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. NOTE: For more information about tunnel interfaces and related configurations, see the chapter Tunneling configuration. GRE over IPv6 tunnel configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements Two IPv4 subnets Group 1 and Group 2 are connected to an IPv6 network. Create a GRE over IPv6 tunnel between Router A and Router B, so that the two IPv4 subnets can communicate with each other through the GRE tunnel over the IPv6 network. Figure 15 Network diagram for a GRE over IPv6 tunnel Configuration procedure NOTE: Before the configuration, make sure that Router A and Router B are reachable to each other. 1. Configure Router A <RouterA> system-view 16

25 # Enable IPv6. [RouterA] ipv6 # Configure an IPv4 address for interface GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ip address [RouterA-GigabitEthernet0/1] quit # Configure an IPv6 address for interface GigabitEthernet 0/2, the physical interface of the tunnel. [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ipv6 address 2002::1:1 64 [RouterA-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [RouterA] interface tunnel 0 # Configure an IPv4 address for interface Tunnel 0. [RouterA-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv6. [RouterA-Tunnel0] tunnel-protocol gre ipv6 # Configure the source address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2. [RouterA-Tunnel0] source 2002::1:1 # Configure the destination address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2 on Router B). [RouterA-Tunnel0] destination 2001::2:1 [RouterA-Tunnel0] quit # Configure a static route from Router A through interface Tunnel 0 to Group 2. [RouterA] ip route-static tunnel 0 2. Configure Router B <RouterB> system-view # Enable IPv6. [RouterB] ipv6 # Configure an IPv4 address for interface GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ip address [RouterB-GigabitEthernet0/1] quit # Configure an IPv6 address for interface GigabitEthernet 0/2, the physical interface of the tunnel). [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ipv6 address 2001::2:1 64 [RouterB-GigabitEthernet0/2] quit # Create an interface named Tunnel 0. [RouterB] interface tunnel 0 # Configure an IPv4 address for interface Tunnel 0. [RouterB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv6. [RouterB-Tunnel0] tunnel-protocol gre ipv6 17

26 # Configure the source address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2. [RouterB-Tunnel0] source 2001::2:1 # Configure the destination address of interface Tunnel 0 to be the IP address of interface GigabitEthernet 0/2 on Router A. [RouterB-Tunnel0] destination 2002::1:1 [RouterB-Tunnel0] quit # Configure a static route from Router B through interface Tunnel 0 to Group 1. [RouterB] ip route-static tunnel 0 3. Verify the configuration # Display the tunnel interface status on Router A and Router B respectively. [RouterA] display interface Tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1456 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 2002::1:1, destination 2001::2:1 Tunnel protocol/transport GRE/IPv6 GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error [RouterB] display interface Tunnel 0 Tunnel0 current state: UP Line protocol current state: UP Description: Tunnel0 Interface The Maximum Transmit Unit is 1456 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 2001::2:1, destination 2002::1:1 Tunnel protocol/transport GRE/IPv6 GRE key disabled Checksumming of GRE packets disabled Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never 18

27 Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 10 packets input, 840 bytes 0 input error 10 packets output, 840 bytes 0 output error # From Router B, you can ping the IP address of GigabitEthernet 0/1 on Router A. [RouterB] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=3 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=3 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 2/2/3 ms Displaying and maintaining GRE To do Use the command Remarks Display information about a specific or all tunnel interfaces Display IPv6 information about a tunnel interface display interface [ tunnel ] [ brief [ down ] ] [ { begin exclude include } regular-expression ] display interface tunnel number [ brief ] [ { begin exclude include } regular-expression ] display ipv6 interface tunnel [ number ] [ brief ] [ { begin exclude include } regular-expression ] Available in any view Available in any view Troubleshooting GRE NOTE: In this example, either Router A or Router C is the firewall. The key to configuring GRE is to keep the configurations consistent. Most faults can be located by using the debugging gre or debugging tunnel command. This section analyzes one type of fault for illustration, with the scenario shown in Figure

28 Figure 16 Troubleshoot GRE Symptom: The interfaces at both ends of the tunnel are configured correctly and can ping each other, but Host A and Host B cannot ping each other. Solution: On Router A and Router C, execute the display ip routing-table command in any view respectively. On Router A, observe whether there is a route from Router A through Tunnel 0 to /16. On Router C, observe whether there is a route from Router C through Tunnel 0 to /16. If an expected static route is missing, use the ip route-static command in system view to configure. For example, configure a static route on Router A as follows: [RouterA] ip route-static tunnel 0 20

29 Point to multi-point GRE tunnel P2MP GRE tunnel overview Background Figure 17 P2MP GRE tunnel application scenario A traditional GRE tunnel is a point to point connection. To use traditional GRE tunnels on an enterprise network shown as Figure 17, you need to configure a P2P GRE tunnel between the headquarters and each branch. When an enterprise has plenty of branches, the configuration workload is huge and, adding new branches requires additional configurations on the headquarters node, burdening network administrators. Besides, if branches dial in to the network through ADSL, the configurations on the headquarters is rather complicated due to the indetermination of the public network addresses of the branches. The P2MP GRE tunnel technology solves this problem. It is very applicable to enterprise networks with a lot of branches. In a P2MP GRE tunnel application, you only need to configure the tunnel interface on the headquarters node to work in P2MP GRE tunnel mode and that on each branch node to work in traditional P2P GRE tunnel mode. Then, a GRE tunnel will be established dynamically between the headquarters and each branch. Operation of the P2MP GRE tunnel The encapsulation and de-encapsulation of P2MP GRE tunnel packets are the same as those of P2P GRE tunnel packets. For details, see the chapter GRE configuration. 21

30 Figure 18 Learning tunnel destination addresses dynamically Different from a P2P GRE tunnel interface, a P2MP GRE tunnel interface does not require manual configuration of the tunnel destination addresses but learns them from GRE tunnel packets received from peers. As shown in Figure 18, Device A resides at the headquarters and has a P2MP GRE tunnel interface configured, while Device B resides at a branch and has a P2P GRE tunnel interface configured. After Device A receives a GRE packet from Device B, it establishes a tunnel entry, taking the source address in the transport protocol (IPv4) header as the tunnel destination address and the source address in the passenger protocol (IPv4) header (that is, the private network address of the branch) as the packet destination address. When forwarding a packet through a P2MP GRE tunnel, the device searches the tunnel entries for the tunnel destination address according to the packet s destination address, and then encapsulates the packet with GRE and then with IPv4, using the tunnel destination address as the destination address in the transport protocol header. NOTE: The mask length of the packet destination address in a tunnel entry is configurable. After you configure a mask length for a packet destination address, the node at the headquarters establishes only one tunnel entry for private IP addresses in the same network segment, thus reducing the number of tunnel entries on the node at the headquarters and allowing branches to initiate establishment of tunnels by sending emulated data to the node at the headquarters. 22

31 P2MP GRE tunnel backup GRE tunnel backup at a branch Figure 19 GRE tunnel backup at a branch As shown in Figure 19, for higher network reliability, a branch can use multiple gateway devices so that a GRE tunnel is established between the headquarters and each gateway of the branch for GRE tunnel backup. When creating a GRE tunnel on a gateway of the branch, you can configure the GRE key. The headquarters Device will read the GRE key from the GRE packet and record the GRE key value in the corresponding tunnel entry. The headquarters device determines the priority of a tunnel entry according to the value of the GRE key, and uses the tunnel corresponding to the tunnel entry with the highest priority to forward packets destined for the peer and uses the other tunnels for backup. A tunnel entry without a GRE key has the highest priority. For tunnel entries carrying a GRE key, a smaller key value means a higher priority. NOTE: You can configure the GRE key on only a tunnel interface in P2P GRE tunnel mode. A tunnel interface working in P2MP GRE tunnel mode does not support the GRE key argument 23

32 GRE tunnel backup at the headquarters Figure 20 GRE tunnel backup at the headquarters As shown in Figure 20, for higher network reliability, you can deploy multiple gateways at the headquarters and specify one or more backup interfaces for the main tunnel interface on the main gateway, such as Tunnel 1, to implement headquarters node backup and GRE tunnel backup. If the link between the main gateway and the branch gateway goes down, the main tunnel interface will soon lose the matching tunnel entry for forwarding packets to the branch. In this case, the main tunnel interface will forward the packets to the backup interface, which will then forward the packets to the branch. You need to configure the GRE over IPv4 mode on the backup interface. When a matching tunnel entry exists, a backup interface can also participate in tunnel selection that is based on tunnel priority. If you do not specify a GRE key on a backup interface, the backup interface will have a lower priority than any P2MP tunnel entry. If you specify a GRE key on the backup interface, the key value will be compared with the GRE key values in the P2MP tunnel entries, and the smaller the key value, the higher the priority. Advantages and restrictions of the P2MP GRE tunnel technology The P2MP GRE tunnel technology features the following advantages: Simple configuration. On the headquarters node, you only need to configure the P2MP GRE tunnel mode, instead of configuring a P2P GRE tunnel with each branch node. Low maintenance cost. When a branch is added, no manual configuration is required on the headquarters node; the headquarters node will learn the address of the added branch and then establish a tunnel with the branch node. Flexible access of branches. As the headquarters node learns tunnel destination addresses dynamically, whether the branches obtain public addresses dynamically or not does not impact the configurations on the headquarters node. This allows for more flexible accesses for branches. Wonderful interoperability and investment protection. Based on the standard GRE protocol, the P2MP GRE tunnel technology requires no special or proprietary protocol, nor special requirements on branch gateways. The branch gateways can be from any vendors as long as they support GRE. This not only ensures better cooperation of devices from different vendors, but also helps avoid repetitive investments on branch node devices. 24

33 High reliability. It supports GRE tunnel backup at the headquarters and branches, improving the network reliability. The P2MP GRE tunnel technology has the following restrictions: Both the transport protocol and passenger protocol must be IPv4. The headquarters node cannot send packets to a branch before the branch sends packets to it. Only after receiving a packet from the branch, can the headquarters node installs a tunnel entry for the branch and send packets to the branch. No tunnel can be established between branch nodes and therefore branch nodes cannot communicate with each. Configuring a P2MP GRE tunnel in the web interface Configuration prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can communicate with the interface used as the source interface of the tunnel interface on the peer device normally. Configuration task list Table 3 P2MP GRE tunnel configuration task list Task Configuring a P2MP GRE tunnel interface Configuring a route for packet forwarding through the tunnel Remarks Required Create a P2MP GRE tunnel interface and configure the related parameters. Required Each end of the tunnel must have a route (static or dynamic) for packet forwarding through the tunnel to the other end, so that GRE encapsulated packets can be forwarded normally. When configuring a route through the tunnel, you can configure a static route, using the address of the network segment that the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Or, you can enable a dynamic routing protocol on both the tunnel interface and the interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that instructs the firewall to forward packets through the tunnel. For information about static and dynamic route configuration, see Network Management Configuration Guide. IMPORTANT: It is not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. 25

34 Task Displaying information about established P2MP GRE tunnels Remarks Optional Configuring a P2MP GRE tunnel interface Select VPN > GRE > P2MP from the navigation tree to enter the P2MP GRE tunnel interface management page, as shown in Figure 21. Then, click Add to add a P2MP GRE tunnel interface, as shown in Figure 22. Figure 21 P2MP GRE tunnel interface management page Figure 22 Add a P2MP GRE tunnel interface Table 4 Configuration items Item Tunnel Interface Description Specify the number of the tunnel interface. Specify the IP address and subnet mask of the tunnel interface. IP/Mask IMPORTANT: When configuring a static route on the tunnel interface, note that the destination IP address of the static route must not be in the subnet of the tunnel interface. 26

35 Item Zone Description Specify the security zone to which the tunnel interface belongs. Specify the source IP address for the tunnel interface. You can input an IP address or select an interface. In the latter case, the primary IP address of the interface will be used as the tunnel source address. Tunnel Source IP/Interface IMPORTANT: You must configure a source address on a P2MP GRE tunnel interface. Two or more P2MP GRE tunnel interfaces cannot share the same source address. On each branch node, you need to configure the destination address of the GRE over IPv4 tunnel interface as the source address of the P2MP GRE tunnel interface. Configure the mask of the private network addresses of the branch to be used in tunnel entries. Branch Network Mask After you configure a mask, the firewall at the headquarters will establish only one tunnel entry for all private IP addresses that belong to the same network segment. This is to reduce the number of tunnel entries on the firewall. On a branch network, you can simulate a traffic flow destined for the headquarters to trigger the firewall at the headquarters to create a tunnel entry for the entire branch network. IMPORTANT: By default, the mask of branch network addresses is Modifying the mask will delete all tunnel entries created on the firewall. Before configuring a mask, make sure that all the branch networks of the enterprise have the same mask length. For a branch device with a different mask length, you can configure NAT to implement the mask length consistency. Configure the aging time for P2MP GRE tunnel entries. Aging Time Enable Interface Backup Backup Interface The creation of a tunnel entry for a branch network is triggered by the traffic from the branch network. If the firewall at the headquarters does not receive traffic from the branch network within the aging time, the firewall will age out the tunnel entry. Select whether to enable the interface backup function, and if yes, specify the backup tunnel interface. IMPORTANT: The backup tunnel interface to be specified must be a GRE over IPv4 tunnel interface. The backup tunnel interface to be specified must have existed. Enable or disable the GRE packet checksum function. With this function enabled, the tunnel interface will verify the validity of packets and discard those invalid. GRE Packet Checksum You can enable or disable the checksum function at both ends of the tunnel as needed. If checksum is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. In contrast, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. 27

36 Displaying information about established P2MP GRE tunnels Select VPN > GRE > P2MP from the navigation tree and then click the Tunnel List tab to view the P2MP GRE tunnel list, as shown in Figure 23. Figure 23 Tunnel list Table 5 Field description Field Tunnel Interface Tunnel Dest Address Branch Network Address/Mask GRE Key Description Name of the tunnel interface IP address of the tunnel destination IP address and mask of the branch network GRE key of the tunnel, used to identify the priority of the tunnel entry. If the tunnel peer device is not configured with a GRE key, nothing will be displayed for this field. Basic P2MP GRE tunnel configuration example NOTE: In this configuration example, either Device A or Device B is the firewall. Network requirements A company has a network at the headquarters and each of its branches. It is required to implement communication between the headquarters and the branches through GRE. Figure 24 shows a simplified scenario, where there is only one branch. Device A is the gateway at the headquarters, and Device B is the gateway of the branch. Host A is an internal user at the headquarters and Host B is an internal user at the branch. A GRE tunnel is established between Device A and Device B to implement communication between Host A and Host B. If you use P2P GRE tunnels, the number of GRE tunnels to be configured is the same as that of the branches. To simplify the configuration at the headquarters, you can create a P2MP GRE tunnel interface on Device A, and configure a GRE over IPv4 tunnel interface on Device B. 28

37 NOTE: This example gives only the configuration of one branch gateway (Device B). The configuration on other branch gateways is similar. Figure 24 Network diagram Configuring Device A # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a P2MP GRE tunnel interface. Select VPN > GRE > P2MP from the navigation tree and then click Add to perform the configurations shown in Figure 25. Figure 25 Add a P2MP GRE tunnel interface Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) 29

38 Select GigabitEthernet0/1 as the tunnel source interface. Enter 24 as the branch network address mask. Enter 10 as the tunnel entry aging time. Click Apply. # Configure a static route from Device A through interface Tunnel 0 to the branch network. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 26. Figure 26 Add a static route from Device A through interface Tunnel 0 to the branch network Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Click Apply. Configuring Device B # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a GRE over IPv4 tunnel interface. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure

39 Figure 27 Add a GRE over IPv4 tunnel interface Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Select the tunnel source interface GigabitEthernet 0/1. Enter the tunnel destination IP address , the IP address of GigabitEthernet 0/1 on Device A. Click Apply. # Configure a static route from Device B through interface Tunnel 0 to the headquarters node. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 28. Figure 28 Add a static route from Device B through interface Tunnel 0 to the headquarters node Enter as the destination IP address. Select mask

40 Select Tunnel0 as the outbound interface. Click Apply. Verifying the configuration # On Device A, select VPN > GRE > P2MP from the navigation tree, and then click the Tunnel List tab to view the tunnel entries. There should be no tunnel entry. # Ping Host A from Host B. The ping operation succeeds. # On Device A, click Refresh under the tunnel entry list. The P2MP GRE tunnel entry should have been installed, as shown in Figure 29. Figure 29 Verify the configuration result Configuration example for P2MP GRE tunnel backup at the headquarters Network requirements As shown in Figure 30, the headquarters uses two gateways at the egress of the internal network, with Firewall B for backup. Two GRE tunnels are created on Firewall C, the gateway at the branch, one for connecting Firewall A and the other for connecting Firewall B. Normally, packets are forwarded along the tunnel between Firewall A and Firewall C. When a failure occurs along this path, the tunnel between Firewall B and Firewall C is used to transmit packets. To meet the above requirements, you need to establish a P2MP GRE tunnel with the branch on both Firewall A and Firewall B, establish a GRE over IPv4 tunnel between Firewall A and Firewall B, and on Firewall A, configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface. Thus, when Firewall A cannot find the corresponding tunnel entry for a packet, it delivers the packet to Firewall B, which then forwards the packet to Firewall C. NOTE: To avoid looping, do not configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface on Firewall B. 32

41 Figure 30 Network diagram Device Interface IP address Device Interface IP address Firewall A GE0/ /24 Firewall B GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 Tunnel /24 Tunnel /24 Tunnel /24 Tunnel /24 Firewall C GE0/ /24 Firewall C Tunnel /24 Configuring Firewall A GE0/ /24 Tunnel /24 # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create GRE over IPv4 tunnel interface, with the tunnel interface number being 1. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure

42 Figure 31 Add a GRE over IPv4 tunnel interface (Tunnel 1) Enter 1 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Click Apply. # Create a P2MP GRE tunnel interface, with the tunnel interface number being 0. Select VPN > GRE > P2MP from the navigation tree and then click Add to perform the configurations shown in Figure

43 Figure 32 Add a P2MP GRE tunnel interface (Tunnel 0) Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter as the tunnel source address. Enter 24 as the branch network address mask. Enter 10 as the tunnel entry aging time. Select the check box before Enable Interface Backup, and select backup interface Tunnel1. Click Apply. # Configure a static route from Firewall A through interface Tunnel 0 to the branch network. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 33. Figure 33 Add a static route from Firewall A through interface Tunnel 0 to the branch network Enter as the destination IP address. 35

44 Select mask Select Tunnel0 as the outbound interface. Click Apply. Configuring Firewall B # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a P2MP GRE tunnel interface, with the tunnel interface number being 0. Select VPN > GRE > P2MP from the navigation tree and then click Add to perform the configurations shown in Figure 34. Figure 34 Add a P2MP GRE tunnel interface (Tunnel 0) Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter as the tunnel source address. Enter 24 as the branch network address mask. Enter 10 as the tunnel entry aging time. Click Apply. # Create a GRE over IPv4 tunnel interface, with the tunnel interface number being 1. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure

45 Figure 35 Add a GRE over IPv4 tunnel interface (Tunnel 1) Enter 1 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Click Apply. # Configure a static route from Firewall B through interface Tunnel 0 to the branch network. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 36. Figure 36 Add a static route from Firewall B through interface Tunnel 0 to the branch network Enter as the destination IP address. 37

46 Select mask Select Tunnel0 as the outbound interface. Click Apply. Configuring Firewall C # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a GRE over IPv4 tunnel interface, with the tunnel interface number being 0. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure 37. Figure 37 Add a GRE over IPv4 tunnel interface (Tunnel 0) Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Click Apply. # Create a GRE over IPv4 tunnel interface, with the tunnel interface number being 1. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure

47 Figure 38 Add a GRE over IPv4 tunnel interface (Tunnel 1) Enter 1 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Click Apply. # Configure a static route from Firewall C through interface Tunnel 0 to the headquarters node, with the routing priority being 1. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 39. Figure 39 Add a static route from Firewall C through interface Tunnel 0 to the headquarters node 39

48 Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Enter priority 1. Click Apply. # Configure a static route from Firewall C through interface Tunnel 1 to the headquarters node, with the routing priority being 10. This makes the priority of this route lower than that of the static route of interface Tunnel 0, making sure that Firewall C prefers the tunnel between Firewall A and Firewall C for packet forwarding. On the static route management page, click Add to perform the configurations shown in Figure 40. Figure 40 Add a static route from Firewall C through interface Tunnel 1 to the headquarters node Enter as the destination IP address. Select mask Select Tunnel1 as the outbound interface. Enter priority 10. Click Apply. If the link between Firewall A and Firewall C goes down, Firewall C will sense the failure and try to send packets to Firewall B, initiating the establishment of the tunnel between Firewall B and Firewall C. Only then can Firewall B learn the tunnel entry. If Firewall A and Firewall C are directly connected, configuring a static route on Firewall C can make sure that Firewall C senses the failure of the link between Firewall A and Firewall C. If the two are not directly connected, you need to use either of the following methods to achieve the effect: Configure dynamic routing on Firewall A, Firewall B, and Firewall C. On Firewall C, associate the static route with a track entry, so as to use the track entry to track the status of the static route. For more information about a track entry, see High Availability Configuration Guide. Verifying the configuration # After the configurations, ping Host A from Host C. The ping operation succeeds. On Firewall A, select VPN > GRE > P2MP from the navigation tree and then click the Tunnel List tab. You can see information about the P2MP GRE tunnels established on Firewall A, as shown in Figure

49 Perform the same operations on Firewall B and you can see that there is no P2MP GRE tunnel established on Firewall B. Figure 41 Verify the configuration result on Firewall A The above information indicates that there is a tunnel entry to reach the branch network, and packets to the branch network are forwarded through Firewall A. # Cut off the tunnel link between Firewall A and Firewall C. On Firewall C, select Device Management > Interface from the navigation tree and then click the icon of interface Tunnel 0. Click the Disable button to shut down interface Tunnel 0. # After the tunnel aging time (10 seconds in this example) elapses, refresh and view the tunnel entry information on Firewall A. There should be no tunnel entry any more. # Ping Host A from Host C. The ping operation succeeds. Refresh and view the P2MP GRE tunnel information on Firewall B again. You can see that a P2MP GRE tunnel is established on Firewall B, as shown in Figure 42. Figure 42 Verify the configuration result on Firewall B The information indicates that: After the link between Firewall A and Firewall C went down, the tunnel entry aging timer started to work, and after the timer expired, the tunnel entry on Firewall A was removed. After Firewall C sent a packet to Firewall B, a tunnel entry to the branch network was generated on Firewall B, and packets to the branch network were forwarded through Firewall B 41

50 Configuration example for P2MP GRE tunnel backup at a branch Network requirements As shown in Figure 43, a branch uses two gateways at the egress of the internal network, with Firewall C for backup. A P2MP GRE tunnel template is created on Firewall A, the gateway at the headquarters, allowing Firewall A to establish two GRE tunnels to the branch network, one for connecting Firewall B and the other for connecting Firewall C. Firewall A decides which GRE tunnel to use to send packets to the hosts on the branch network. To meet the above requirements, you need to configure different GRE keys for the GRE tunnels on Firewall B and Firewall C, so that Firewall A can choose a tunnel according to the GRE key values. In this example, the GRE tunnel between Firewall A and Firewall B has a higher priority. Figure 43 Network diagram Branch Headquarters Tunnel0 Firewall B GE0/2 Firewall A GE0/2 GE0/1 IPv4 network GE0/1 Host A Tunnel0 Tunnel0 GE0/1 GE0/2 Host B GRE P2MP tunnel Firewall C (Backup gateway) Device Interface IP address Device Interface IP address Firewall A GE0/ /24 Firewall B GE0/ /24 GE0/ /24 GE0/ /24 Tunnel /24 Tunnel /24 Firewall C GE0/ /24 Firewall C Tunnel /24 GE0/ /24 Configuring Firewall A # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a P2MP GRE tunnel interface. Select VPN > GRE > P2MP from the navigation tree and then click Add to perform the configurations shown in Figure

51 Figure 44 Add a P2MP GRE tunnel interface Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter as the tunnel source interface. Enter 24 as the branch network address mask. Enter 10 as the tunnel entry aging time. Click Apply. # Configure a static route from Firewall A through interface Tunnel 0 to the branch network. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 45. Figure 45 Add a static route from Firewall A through interface Tunnel 0 to the branch network Enter as the destination IP address. Select mask

52 Select Tunnel0 as the outbound interface. Click Apply. Configuring Firewall B # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a GRE over IPv4 tunnel interface. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure 46. Figure 46 Add a GRE over IPv4 tunnel interface Enter 0 in the Tunnel Interface field. Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Enter the GRE key 1. Click Apply. # Configure a static route from Firewall B through interface Tunnel 0 to the headquarters node. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure

53 Figure 47 Add a static route from Firewall B through interface Tunnel 0 to the headquarters node Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Click Apply. Configuring Firewall C # Configure an IPv4 address for each interface and assign the interfaces to security zones. (Details not shown) # Create a GRE over IPv4 tunnel interface. Select VPN > GRE > GRE from the navigation tree and then click Add to perform the configurations shown in Figure 48. Figure 48 Add a GRE over IPv4 tunnel interface Enter 0 in the Tunnel Interface field. 45

54 Enter IP address/mask /24. Select Management from the Zone list. (Select a security zone according to your network configuration.) Enter the tunnel source IP address Enter the tunnel destination IP address Enter the GRE key 2. Click Apply. # Configure a static route from Firewall C through interface Tunnel 0 to the headquarters node. Select Network > Routing Management > Static Routing from the navigation tree and then click Add to perform the configurations shown in Figure 49. Figure 49 Add a static route from Firewall C through interface Tunnel 0 to the headquarters node Enter as the destination IP address. Select mask Select Tunnel0 as the outbound interface. Click Apply. Verifying the configuration # On Host B, specify Firewall C as the default gateway. Ping Host A from Host B. The ping operation succeeds. On Firewall A, select VPN > GRE > P2MP from the navigation tree and then click the Tunnel List tab. You can see information about the P2MP GRE tunnels established on Firewall A, as shown in Figure

55 Figure 50 Verify the configuration result on Firewall A (1) # On Host B, specify Firewall B as the default gateway. Ping Host A from Host B. The ping operation succeeds. Click the Refresh button under the tunnel list of Firewall A. You can see that another P2MP tunnel entry is generated on Firewall A, as shown in Figure 51. Figure 51 Verify the configuration result on Firewall A (2) The information indicates that on Firewall A there are two tunnel entries destined for the branch network. Firewall A will prefer the tunnel entry with a smaller GRE key value, that is, packets will be forwarded to hosts on the branch network through Firewall B. # Cut off the tunnel link between Firewall A and Firewall B. Select Device Management > Interface from the navigation tree of Firewall B. Click the icon of interface Tunnel 0. Click the Disable button to shut down interface Tunnel 0. # On Host B, specify Firewall C as the default gateway. After the tunnel entry corresponding to Firewall B ages out, ping Host A from Host B. The ping operation succeeds. View P2MP GRE tunnel entries on Firewall A again, the information is shown as Figure

56 Figure 52 Verify the configuration result on Firewall A (3) The information indicates that after the link between Firewall A and Firewall B is down, Firewall A has only the tunnel entry that uses Firewall C for forwarding of packets to the branch network. Configuring a P2MP GRE tunnel at the CLI Configuration guidelines Two or more P2MP GRE tunnel interfaces cannot share the same source address. If you specify a source interface for a P2MP GRE tunnel interface, the tunnel interface takes the primary IP address of the source interface as its source address. You can enable or disable the checksum function at both ends of the tunnel as needed. If checksum is enabled at the local end but not at the remote end, the local end calculates the checksum of a packet to be sent but does not check the checksum of a received packet. In contrast, if the checksum function is enabled at the remote end but not at the local end, the local end checks the checksum of a received packet but does not calculate the checksum of a packet to be sent. When configuring a route through the tunnel, you are not allowed to set up a static route whose destination address is in the subnet of the tunnel interface. Instead, you can do one of the following: Configure a static route, using the address of the network segment the original packet is destined for as its destination address and the address of the peer tunnel interface as its next hop. Enable a dynamic routing protocol on both the tunnel interface and the router interface connecting the private network, so that the dynamic routing protocol can establish a routing entry that allows the tunnel to forward packets through the tunnel. Configuration prerequisites On each of the peer devices, configure an IP address for the interface to be used as the source interface of the tunnel interface (which can be a, for example, VLAN interface, GigabitEthernet interface, or loopback interface), and make sure that this interface can communicate with the interface used as the source interface of the tunnel interface on the peer device normally. Configuring a P2MP GRE tunnel Follow these steps to configure a P2MP GRE tunnel: 48

57 To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter tunnel interface view Configure an IPv4 address for the tunnel interface Set the tunnel mode to P2MP GRE Configure the source address or interface for the tunnel interface Enable the GRE packet checksum function Configure a route for packet forwarding through the tunnel interface tunnel interface-number ip address ip-address { mask mask-length } tunnel-protocol gre p2mp source { ip-address interface-type interface-number } gre checksum See Network Management Configuration Guide Required By default, no tunnel interface is created on the firewall. Required By default, a tunnel interface has no IPv4 address. Required The default tunnel mode is GRE over IPv4. In P2MP GRE tunnel mode, both the transport protocol and passenger protocol are IPv4. You must configure the tunnel mode as GRE over IPv4 on the tunnel peers. Required By default, no source address or interface is configured for a tunnel interface. On each branch node, you need to configure the tunnel destination address as this source address. Optional Disabled by default For more information about the GRE packet checksum function, see the chapter GRE configuration. Required Each end of the tunnel must have a route (static or dynamic) through the tunnel to the other end. Configure the aging time for the tunnel entries gre p2mp aging-time aging-time Optional 5 seconds by default Specify the backup interface gre p2mp backup-interface tunnel number Optional By default, no backup interface is specified. The backup interface must be an existing tunnel interface that works in GRE over IPv4 mode. 49

58 To do Use the command Remarks Configure the mask or mask length of the private network addresses of the branch gre p2mp branch-network-mask { mask mask-length } Optional By default, the mask of the private network address of a branch is , that is, the default mask length is 32. NOTE: For more information about tunnel interfaces and related configurations, see the chapter Tunneling configuration. Displaying and maintaining P2MP GRE tunnels To do Use the command Remarks Display the tunnel entry information of a P2MP GRE tunnel interface Clear the tunnel entry information of a P2MP GRE tunnel interface display gre p2mp tunnel-table interface tunnel number [ { begin exclude include } regular-expression ] reset gre p2mp tunnel-table [ interface tunnel number [ dest-address tunnel-dest-address] ] Available in any view Available in user view Basic P2MP GRE tunnel configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements A company has a network at the headquarters and each of its branches. Implement communication between the headquarters and the branches through GRE, but forbid communication between the branches. Figure 53 shows a simplified scenario, where there is only one branch. Router A is the gateway at the headquarters, and Router B is the gateway of the branch. Host A is an internal user at the headquarters and Host B is an internal user at the branch. A GRE tunnel is established between Router A and Router B to implement intercommunication between Host A and Host B. If you use P2P GRE tunnels, the number of GRE tunnels to be configured is the same as that of the branches. To simplify the configuration at the headquarters, you can create a P2MP GRE tunnel interface on Router A, and configure a GRE over IPv4 tunnel interface on Router B. NOTE: This example gives only the configuration on one branch gateway (Router B). The configuration on other branch gateways is similar. 50

59 Figure 53 Network diagram Configuration procedure 1. Configure Router A. # Configure an IP address for interface GigabitEthernet 0/1. <RouterA> system-view [RouterA] interface GigabitEthernet 0/1 [RouterA GigabitEthernet0/1] ip address [RouterA GigabitEthernet0/1] quit # Configure an IP address for interface GigabitEthernet 0/2. [RouterA] interface GigabitEthernet 0/2 [RouterA GigabitEthernet0/2] ip address [RouterA GigabitEthernet0/2] quit # Create a tunnel interface Tunnel0 and configure an IP address for it. [RouterA] interface tunnel 0 [RouterA-Tunnel0] ip address # Configure the tunnel encapsulation mode as P2MP GRE. [RouterA-Tunnel0] tunnel-protocol gre p2mp # Configure the mask of the branch network as [RouterA-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [RouterA-Tunnel0] gre p2mp aging-time 20 # Configure the source IP address of interface Tunnel0. [RouterA-Tunnel0] source [RouterA-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel0. [RouterA] ip route-static tunnel 0 2. Configure Router B. # Configure an IP address for interface GigabitEthernet 0/1. <RouterB> system-view [RouterB] interface GigabitEthernet 0/1 [RouterB GigabitEthernet0/1] ip address

60 [RouterB GigabitEthernet0/1] quit # Configure an IP address for interface GigabitEthernet 0/2. [RouterB] interface GigabitEthernet 0/2 [RouterB GigabitEthernet0/2] ip address [RouterB GigabitEthernet0/2] quit # Create a tunnel interface Tunnel0 and configure an IP address for it. [RouterB] interface tunnel 0 [RouterB-Tunnel0] ip address # Configure the tunnel encapsulation mode as GRE over IPv4. [RouterB-Tunnel0] tunnel-protocol gre # Configure the source IP address of interface Tunnel0. [RouterB-Tunnel0] source # Configure the destination IP address of interface Tunnel0. [RouterB-Tunnel0] destination [RouterB-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 0. [RouterB] ip route-static tunnel 0 Verifying the configuration # After the configurations, view the tunnel entry information on Router A. No tunnel entry exists. [RouterA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key # Ping Host A from Host B. The operation succeeds. # View tunnel entry information on Router A again. As the branch has initiated the establishment of the tunnel by sending packets to the headquarters, a tunnel entry should be installed, as shown in the following output information: [RouterA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key Configuration example for P2MP GRE tunnel backup at the headquarters Network requirements As shown in Figure 54, the headquarters uses two gateways at the egress of the internal network, with Firewall B for backup. Two GRE tunnels are created on Firewall C, the gateway at the branch, one for connecting Firewall A and the other for connecting Firewall B. Normally, packets are forwarded along the tunnel between Firewall A and Firewall C. When a failure occurs along this path, the tunnel between Firewall B and Firewall C is used to transmit packets. To meet the requirements, establish a P2MP GRE tunnel with the branch on both Firewall A and Firewall B, establish a GRE over IPv4 tunnel between Firewall A and Firewall B, and on Firewall A configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface. Thus, when Firewall A cannot find the corresponding tunnel entry for a packet, it delivers the packet to Firewall B, which then forwards the packet to Firewall C. 52

61 NOTE: To avoid looping, do not configure the tunnel interface of the GRE over IPv4 tunnel as the backup interface of the P2MP GRE tunnel interface on Firewall B. Figure 54 Network diagram Device Interface IP Address Device Interface IP Address Firewall A GE0/ /24 Firewall B GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 GE0/ /24 Tunnel /24 Tunnel /24 Tunnel /24 Tunnel /24 Firewall C GE0/ /24 Firewall C Tunnel /24 GE0/ /24 Tunnel /24 Configuration procedure Configure IP addresses and masks for interfaces as per Figure 54. (Details not shown) 1. Configure Firewall A. # Create interface Tunnel 1 and configure an IP address for it. <FirewallA> system-view [FirewallA] interface tunnel 1 [FirewallA-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel 1 as GRE over IPv4. [FirewallA-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel 1. [FirewallA-Tunnel1] source [FirewallA-Tunnel1] destination [FirewallA-Tunnel1] quit # Create a tunnel interface Tunnel0 and configure an IP address for it. [FirewallA] interface tunnel 0 [FirewallA-Tunnel0] ip address

62 # Configure the tunnel encapsulation mode of interface Tunnel0 as P2MP GRE. [FirewallA-Tunnel0] tunnel-protocol gre p2mp # Configure the mask of the branch network connected to Tunnel0 as [FirewallA-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [FirewallA-Tunnel0] gre p2mp aging-time 20 # Configure the source IP address of interface Tunnel0. [FirewallA-Tunnel0] source # Configure Tunnel 1 as the backup interface of Tunnel0. [FirewallA-Tunnel0] gre p2mp backup-interface tunnel 1 [FirewallA-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel0. [FirewallA] ip route-static tunnel 0 2. Configure Firewall B. # Create a tunnel interface Tunnel0 and configure an IP address for it. <FirewallB> system-view [FirewallB] interface tunnel 0 [FirewallB-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel0 as P2MP GRE. [FirewallB-Tunnel0] tunnel-protocol gre p2mp # Configure the source IP address of interface Tunnel0. [FirewallB-Tunnel0] source # Configure the mask of the branch network connected to Tunnel0 as [FirewallB-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [FirewallA-Tunnel0] gre p2mp aging-time 20 [FirewallB-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel0. [FirewallB] ip route-static tunnel 0 # Create tunnel interface Tunnel1 and configure an IP address for it. [FirewallB] interface tunnel 1 [FirewallB-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel1 as GRE over IPv4. [FirewallB-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel1. [FirewallB-Tunnel1] source [FirewallB-Tunnel1] destination [FirewallB-Tunnel1] quit 3. Configure Firewall C. # Create interface Tunnel 0 and configure an IP address for it. <FirewallC> system-view [FirewallC] interface tunnel 0 54

63 [FirewallC-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel0 as GRE over IPv4. [FirewallC-Tunnel0] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel0. [FirewallC-Tunnel0] source [FirewallC-Tunnel0] destination [FirewallC-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel0 and priority value being 1. [FirewallC] ip route-static tunnel 0 preference 1 # Create tunnel interface Tunnel 1 and configure an IP address for it. [FirewallC] interface tunnel 1 [FirewallC-Tunnel1] ip address # Configure the tunnel encapsulation mode of interface Tunnel1 as GRE over IPv4. [FirewallC-Tunnel1] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel1. [FirewallC-Tunnel1] source [FirewallC-Tunnel1] destination [FirewallC-Tunnel1] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel1 and priority value being 10. This makes the priority of this route lower than that of the static route of interface Tunnel0, making sure that Firewall C prefers the tunnel between Firewall A and Firewall C for packet forwarding. [FirewallC] ip route-static tunnel 1 preference 10 NOTE: If the link between Firewall A and Firewall C goes down, Firewall C will sense the failure and try to send packets to Firewall B, initiating the establishment of the tunnel between Firewall B and Firewall C. Only then can Firewall B learn the tunnel entry. If Firewall A and Firewall C are directly connected, configuring a static route on Firewall C can make sure that Firewall C senses the failure of the link between Firewall A and Firewall C. If the two are not directly connected, you need to use either of the following methods to achieve the effect: Configure dynamic routing on Firewall A, Firewall B, and Firewall C. On Firewall C, associate the static route with a track entry, so as to use the track entry to track the status of the static route. For details about track entry, see High Availability Configuration Guide. Verifying the configuration # Ping Host A from Host C. The ping operation succeeds. View the tunnel entries on Firewall A and Firewall B. [FirewallA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key [FirewallB] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key 55

64 The output shows that Firewall A has a tunnel entry to the branch network. Packets to the branch network are forwarded through Firewall A. # On Firewall C, shut down interface Tunnel0 to cut off the tunnel link between Firewall A and Firewall C. [FirewallC] interface tunnel 0 [FirewallC-Tunnel0] shutdown # After the tunnel entry aging time (20 seconds in this example) elapses, view the tunnel entry information on Firewall A. [FirewallA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key # Ping Host A from Host C. View tunnel entries on Firewall B: [FirewallB] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key Then, Host A can ping Host C. The verification process indicates that: After the link between Firewall A and Firewall C went down, the tunnel entry aging timer started to work. After the timer expired, the tunnel entry on Firewall A was removed. After Firewall C sent a packet to Firewall B, a tunnel entry to the branch network was generated on Firewall B. Packets from the headquarters to the branch network are delivered by Firewall A to Firewall B through the backup interface, and then Firewall B forwards these packets to the branch. Configuration example for P2MP GRE tunnel backup at a branch Network requirements As shown in Figure 55, a branch uses two gateways at the egress of the internal network, with Firewall C for backup. A P2MP GRE tunnel is created on Firewall A, the gateway at the headquarters, allowing Firewall A to establish two GRE tunnels to the branch network, one for connecting Firewall B and the other for connecting Firewall C. Firewall A decides which GRE tunnel to use to send packets to the hosts on the branch network. To meet the requirements, configure different GRE keys for the GRE tunnels on Firewall B and Firewall C, so that Firewall A can choose a tunnel according to the GRE key values. In this example, the GRE tunnel between Firewall A and Firewall B has a higher priority. 56

65 Figure 55 Network diagram Headquarters Tunnel0 Firewall B GE0/2 Branch Firewall A GE0/2 GE0/1 IPv4 network GE0/1 Host A Tunnel0 Tunnel0 GE0/1 GE0/2 Host B GRE P2MP tunnel Firewall C (Backup gateway) Device Interface IP Address Device Interface IP Address Firewall A GE0/ /24 Firewall B GE0/ /24 GE0/ /24 GE0/ /24 Tunnel /24 Tunnel /24 Firewall C GE0/ /24 Firewall C Tunnel /24 GE0/ /24 Configuration procedure Configure IP addresses and masks for interfaces as per Figure 55. (Details not shown) 1. Configure Firewall A. # Create tunnel interface Tunnel0 and configure an IP address for it. <FirewallA> system-view [FirewallA] interface tunnel 0 [FirewallA-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel0 as P2MP GRE. [FirewallA-Tunnel0] tunnel-protocol gre p2mp # Configure the mask of the branch network connected to Tunnel0 as [FirewallA-Tunnel0] gre p2mp branch-network-mask # Set the tunnel entry aging time to 20 seconds. [FirewallA-Tunnel0] gre p2mp aging-time 20 # Configure the source IP address of interface Tunnel0. [FirewallA-Tunnel0] source [FirewallA-Tunnel0] quit # Configure a static route to the branch network with the outgoing interface being Tunnel 0. [FirewallA] ip route-static tunnel 0 2. Configure Firewall B. # Create tunnel interface Tunnel0 and configure an IP address for it. <FirewallB> system-view [FirewallB] interface tunnel 0 [FirewallB-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel0 as GRE over IPv4. [FirewallB-Tunnel0] tunnel-protocol gre 57

66 # Configure the source and destination IP addresses of interface Tunnel0. [FirewallB-Tunnel0] source [FirewallB-Tunnel0] destination # Set the GRE key of Tunnel0 to 1. [FirewallB-Tunnel0] gre key 1 [FirewallB-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 0. [FirewallB] ip route-static tunnel 0 3. Configure Firewall C. # Create tunnel interface Tunnel0 and configure an IP address for it. <FirewallC> system-view [FirewallC] interface tunnel 0 [FirewallC-Tunnel0] ip address # Configure the tunnel encapsulation mode of interface Tunnel0 as GRE over IPv4. [FirewallC-Tunnel0] tunnel-protocol gre # Configure the source and destination IP addresses of interface Tunnel0. [FirewallC-Tunnel0] source [FirewallC-Tunnel0] destination # Set the GRE key of Tunnel0 to 2. [FirewallC-Tunnel0] gre key 2 [FirewallC-Tunnel0] quit # Configure a static route to the headquarters network with the outgoing interface being Tunnel 0. [FirewallC] ip route-static tunnel 0 Verifying the configuration # On Host B, specify Firewall C as the default gateway. Ping Host A from Host B. The ping operation succeeds. View tunnel entries on Firewall A: [FirewallA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key # On Host B, specify Firewall B as the default gateway.ping Host A from Host B. The ping operation succeeds. View tunnel entries on Firewall A: [FirewallA] display gre p2mp tunnel-table interface tunnel 0 Dest Addr Mask Tunnel Dest Addr Gre Key The output indicates that Firewall A has two tunnel entries to the branch network and prefers the tunnel entry with a smaller GRE key value. Packets are forwarded to hosts on the branch network through Firewall B first. # On Firewall B, shut down interface Tunnel0 to cut off the tunnel link between Firewall A and Firewall B. [FirewallB] interface tunnel 0 [FirewallB-Tunnel0] shutdown # On Host B, specify Firewall C as the default gateway. After the tunnel entry corresponding to Firewall B ages out, ping Host A from Host B. The ping operation succeeds. View tunnel entries on Firewall A: [FirewallA] display gre p2mp tunnel-table interface tunnel 0 58

67 Dest Addr Mask Tunnel Dest Addr Gre Key The output indicates that after the link between Firewall A and Firewall B fails, Firewall A has only the tunnel entry that uses Firewall C to forward packets to the branch network. 59

68 AFT Configuration NOTE: AFT configuration is available only at the command line interface (CLI). AFT overview Application scenario Address Family Translation (AFT) is a transition technology for communication between IPv4 and IPv6 networks. As Figure 56 shows, the AFT router performs address and protocol translation between IPv4 and IPv6 networks. With AFT, IPv6 and IPv4 hosts can communicate with one another without changing their configurations. Figure 56 AFT diagram Basic concepts DNS64 prefix A DNS64 prefix is an IPv6 address prefix used to translate IPv4 addresses into IPv6 addresses. The length of a DNS64 prefix can be 32, 40, 48, 56, 64, or 96 bits, as shown in Figure 57. The address translation methods vary depending on the length of the DNS64 prefix. If the length of the DNS64 prefix is 40, 48, or 56 bits, the IPv4 address has two parts separated by the bits from bit 64 to bit

69 Figure 57 DNS64 prefix is added to an IPv4 address to translate it into an IPv6 address IVI prefix For an IPv4 packet sent from an IPv4 host to an IPv6 host, AFT translates its source IPv4 address to an IPv6 address by adding a DNS64 prefix. When an IPv6 host sends a packet to an IPv4 host, the destination IPv6 address is formed by adding the DNS64 prefix to the IPv4 address of the IPv4 host. When the AFT receives such a packet, it extracts the IPv4 address from the IPv6 destination address so that the packet can be forwarded to the IPv4 host. An IVI prefix is a 32-bit IPv6 address prefix. An IVI address comprises an IVI prefix and an IPv4 address, with bits 32 to 39 set to all 1s, as shown in Figure 58. Figure 58 IVI address format If the source IPv6 address of an IPv6 packet sent from an IPv6 host to an IPv4 host is in the IVI address format, AFT translates the source IPv6 address to the IPv4 address contained in the source IPv6 address. For an IPv4 packet sent from an IPv4 host to an IPv6 host, AFT translates its destination IPv4 address to an IPv6 address by adding an IVI prefix to the IPv4 address. NOTE: An IVI address is an IPv6 address that is actually used by an IPv6 host; however, an IPv6 address with a DNS64 prefix is merely a translated IPv6 version of an IPv4 address and is not used by any host. AFT modes AFT can be stateless or stateful. Stateless AFT Stateless AFT uses DNS64 or IVI prefixes for address translation. The mappings between IPv4 and IPv6 addresses are fixed because the IPv4 address is embedded in the IPv6 address. Stateful AFT Stateful AFT dynamically creates and maintains mappings between IPv4 addresses and IPv6 addresses. It translates the source IPv6 address of an IPv6 packet into an IPv4 address only when the source IPv6 address is not an IVI address. Otherwise, stateless AFT is used. 61

70 Stateful AFT can also perform port address translation (PAT) to translate both addresses and TCP/UDP port numbers. This method can translate multiple IPv6 addresses into one IPv4 address. It distinguishes the IPv6 addresses by port number. AFT operation AFT allows an IPv6 host to initiate communication with any IPv4 host, but allows an IPv4 host to initiate communication with only IPv6 hosts whose addresses are IVI addresses. The address translation process for communication initiated by an IPv6 host is different from that for communication initiated by an IPv4 host. Communication initiated by an IPv6 host Figure 59 AFT process when communication is initiated by an IPv6 host AFT operates in the following steps: 1. Determines whether address translation is needed. Upon receiving a packet from an IPv6 host, the AFT checks whether the prefix of the destination IPv6 address is a predefined DNS64 prefix. If yes, the packet is destined to an IPv4 host and address translation is needed. 2. Translates the source IP address. If the source IPv6 address of the packet matches the IVI format, the AFT uses the IPv4 address embedded in the source IPv6 address as the translated source IPv4 address of the packet. If not, the AFT translates the source IPv6 address into an IPv4 address based on the 6to4 AFT policy. 3. Translates the destination IP address. The AFT extracts the embedded IPv4 address from the destination IPv6 address based on the length of the DNS64 prefix and uses the IPv4 address as the translated destination IPv4 address. 4. Forwards the packet and records the mapping. The AFT performs protocol translation such as changing the IPv6 header to the IPv4 header, forwards the packet, and records the IPv4-IPv6 mappings. 62

71 5. Translates and forwards the response packet. Upon receiving a response from the IPv4 host, the AFT replaces the IPv4 addresses in the packet header with IPv6 addresses based on the recorded address mappings and forwards the packet to the IPv6 host. NOTE: To view the address mappings, use the display session table command. For more information about this command, see Access Control Configuration Guide. Communication initiated by an IPv4 host Figure 60 AFT process when communication is initiated by an IPv4 host IPv6 addr: 3000:0:FF02:202: 200:: Embedded IPv4 addr: DNS64 prefix: 2000::/32 IVI prefix: 3000::/32 IPv4 addr: Translated IPv6 addr: 2000:0:101:101:: IPv6 host Dst : 3000:0: FF02: 202: 200:: Src : 2000:0: 101: 101:: AFT Translates addresses based on v4tov 6 AFT policy Dst: Src: IPv4 host Dst : 2000:0: 101: 101:: Src : 3000:0:FF 02:202: 200:: Translates addresses based on the recorded mappings Dst : Src : AFT operates in the following steps: 1. Determines whether address translation is needed. If the destination IPv4 address of the packet matches the AFT policy for 4to6 destination address translation, address translation is needed. 2. Translates the source IP address. If the packet matches the AFT policy for 4to6 source address translation, the AFT adds the DNS64 prefix referenced by the policy to the address to translate it into an IPv6 address. If not, the AFT adds the first configured DNS64 prefix to the address to translate it into an IPv6 address. 3. Translates the destination address. If the destination IPv4 address of the packet matches the AFT policy for 4to6 destination address translation, the AFT adds the IVI prefix referenced by the 4to6 AFT policy to the IPv4 destination address to translate it into an IPv6 address. 4. Forwards the packet and records the mappings. The AFT performs protocol translation such as changing the IPv4 header to the IPv6 header, forwards the packet, and records the IPv4-IPv6 mappings. 5. Translate and forwards the response packet. Upon receiving a response from the IPv6 host, the AFT replaces the IPv6 addresses in the packet header with IPv4 addresses based on the recorded address mappings and forwards the packet to the IPv4 host. 63

72 NOTE: To view the address mappings, use the display session table command. For more information about this command, see Access Control Configuration Guide. DNS64 function A DNS client in an IPv6 network cannot communicate with a DNS server in an IPv4 network because their address formats are different. The DNS64 function of AFT can solve this issue. When an IPv6 host sends an AAAA (IPv6) DNS query to an IPv4 DNS server, the destination IPv6 address is translated from the IPv4 address of the DNS server. Upon receiving the AAAA DNS query, the AFT translates the IPv6 source and destination addresses to IPv4 addresses as described in Communication initiated by an IPv6 host. The AFT translates the AAAA DNS query into a type A (IPv4) DNS query and sends the original AAAA request and the translated type A request to the DNS server. Upon receiving the reply from the DNS server, the AFT translates the IPv4 source and destination addresses into IPv6 addresses based on the recorded address mappings. If the AFT receives a type A DNS reply, it examines the resolved IPv4 address. If the IPv4 address matches the AFT policy for 4tov6 source address translation, it translates the address into an IPv6 address by using the DNS64 prefix referenced by the policy. If not, the AFT translates the address by using the first configured DNS64 prefix. Then, the AFT translates the type A DNS reply into an AAAA DNS reply and sends it to the IPv6 host. If the AFT receives an AAAA DNS reply, it directly sends it to the IPv6 host. After receiving the DNS reply, the IPv6 host uses the translated IPv6 address to communicate with the IPv4 host as described in Communication initiated by an IPv6 host. AFT Limitations AFT has the following limitations: The request and response packets of a session must be processed by the same AFT. AFT cannot translate some information, such as the Option field in the IPv4 packet header. AFT cannot provide end-to-end security. AFT cannot process IPv4 and ICMPv6 fragments. Currently, AFT supports Internet Control Message Protocol (ICMP), Domain Name System (DNS), File Transfer Protocol (FTP), and protocols that employ the network layer protocol but have no address information in the protocol messages. AFT is not suitable for some scenarios. For example, if an IPv6 host attempts to communicate with another IPv6 host over an IPv4 network, tunneling is preferred. Protocols and standards draft-ietf-behave-v6v4-xlate-stateful-11 draft-xli-behave-ivi-07 64

73 AFT configuration task list When communication is initiated by an IPv6 host Complete the following tasks to configure AFT for communication initiated by an IPv6 host: Task Enabling AFT Configuring a DNS64 prefix Configuring an IVI prefix Configuring a 6to4 AFT policy Remarks Required Required Required Perform either one When communication is initiated by an IPv4 host Complete the following tasks to configure AFT for communication initiated by an IPv4 host: Task Enabling AFT Configuring a DNS64 prefix Configuring an IVI prefix Configuring 4to6 AFT policies Remarks Required Required Required Required Configuring AFT Configuration prerequisites Before configuring AFT: Enable IPv6 on the AFT. For more information, see Network Management Configuration Guide. Configure an IPv4 or IPv6 address as required on the interface on which AFT is to be enabled. Enabling AFT You must enable AFT on both the interface connected to the IPv4 network and the interface connected to the IPv6 network. Follow these steps to enable AFT: To do Use the command Remarks Enter system view system-view Enter interface view interface interface-type interface-number Enable AFT on the interface aft enable Required Disabled by default. 65

74 NOTE: The aft enable command enables both AFT and NAT-PT. For more information about NAT-PT, see NAT Configuration Guide. Avoid configuring AFT and NAT-PT on the same device. Configuring a DNS64 prefix Follow these steps to configure a DNS64 prefix: To do Use the command Remarks Enter system view system-view Configure a DNS64 prefix aft prefix-dns64 dns64-prefix prefix-length Required No DNS64 prefix is configured by default. NOTE: The DNS64 prefix cannot be in the same network segment as the connected IPv6 network. The DNS64 prefix cannot be the same as the IVI prefix. Configuring an IVI prefix Follow these steps to configure an IVI prefix: To do Use the command Remarks Enter system view system-view Configure an IVI prefix aft prefix-ivi ivi-prefix Required No IVI prefix is configured by default. NOTE: The DNS64 prefix cannot be the same as the IVI prefix. Configuring a 6to4 AFT policy When the communication is initiated by an IPv6 host and the address of the IPv6 host is not an IVI address, the AFT translates the IPv6 address into an IPv4 address based on the 6to4 ATF policy. The detailed process is described as follows: If the source IPv6 address of the packet matches the specified IPv6 ACL or the destination IPv6 address prefix is the same as the specified DNS64 prefix, the AFT translates the source IPv6 address into an IPv4 address in the IPv4 address pool or the IPv4 address of an interface. The AFT supports the following types of 6to4 AFT policy: Type 1: IPv6 ACL + address pool If the source IPv6 address matches the IPv6 ACL, the address is translated into an IPv4 address in the specified address pool. If the no-pat keyword is specified, only the IP address is translated. If not, both the IP address and the port number are translated to save the IPv4 addresses in the address pool. 66

75 Type 2: IPv6 ACL + interface address If the source IPv6 address matches the IPv6 ACL, the AFT translates the address into the IPv4 address of the specified interface. The port number is also translated. Type 3: DNS64 prefix + address pool If the prefix of the destination IPv6 address is the DNS64 prefix specified in the policy, the source address is translated into an IPv4 address in the specified address pool. If the no-pat keyword is specified, only the IP address is translated. Otherwise, both the IP address and the port number are translated to save the IPv4 addresses in the address pool. Type 4: DNS64 prefix + interface address If the prefix of the destination IPv6 address is the DNS64 prefix specified in the policy, AFT translates the source address into the IPv4 address of the specified interface. The port number is also translated. Follow these steps to configure the 6to4 AFT policy To do Use the command Remarks Enter system view system-view Configure an AFT IPv4 address pool Configure the AFT policy (IPv6 ACL + address pool) Configure the AFT policy (IPv6 ACL + interface address) Configure the AFT policy (DNS64 prefix + address pool) Configure the AFT policy (DNS64 prefix + interface address) aft address-group group-number start-ipv4-address end-ipv4-address aft v6tov4 acl6 number acl6-number address-group group-number [ no-pat ] aft v6tov4 acl6 number acl6-number interface interface-type interface-number aft v6tov4 prefix-dns64 dns64-prefix prefix-length address-group group-number [ no-pat ] aft v6tov4 prefix-dns64 dns64-prefix prefix-length interface interface-type interface-number Required for type 1 and type 3 Ignored for type 2 and type 4 Required Configure one of them NOTE: The AFT address pool contains a range of continuous IPv4 addresses. When the AFT policy is type 1 or type 3, the AFT choose an IPv4 address from the address pool as the translated IPv4 address. The DNS64 prefix must be configured with the aft prefix-dns64 command. For more information about ACL, see Access Control Configuration Guide. Configuring 4to6 AFT policies When the communication is initiated by an IPv4 host, the source and destination IPv4 addresses are translated into IPv6 addresses based on two 4to6 AFT policies. One 4to6 AFT policy is used for source address translation, and the other is for destination address translation. Policy for the source IPv4 address translation: If the packet matches the specified ACL, the AFT translates the source address into an IPv6 address by using the specified DNS64 prefix. If not, the AFT translates the address into an IPv6 address by using the first configured DNS64 prefix. 67

76 Policy for destination IPv4 address translation: If the destination IPv4 address matches the specified ACL, the AFT translates the address into an IPv6 address by using the specified IVI prefix. If not, the address is not translated. Follow these steps to configure 4to6 AFT policy: To do Use the command Remarks Enter system view system-view Configure the 4to6 AFT policy for source address translation Configure the 4to6 AFT policy for destination address translation aft v4tov6 acl number acl-number prefix-dns64 dns64-prefix prefix-length aft v4tov6 acl number acl-number prefix-ivi ivi-prefix Optional Required NOTE: The DNS64 and IVI prefixes must be those configured by the aft prefix-dns64 and aft prefix-ivi commands. With the DNS64 function, the AFT translates the IPv4 address resolved by the DNS server into an IPv6 address by using the DNS64 prefix specified in the 4to6 AFT policy for source address translation. The ACL specified in the aft v4tov6 acl number prefix-ivi command must be configured to check the destination addresses of packets. For more information about ACL, see Access Control Configuration Guide. Displaying and maintaining AFT To do Use the command Remarks Display all AFT related information Display AFT address pool configuration information Display AFT address mappings information Display AFT statistics information display aft all [ { begin exclude include } regular-expression ] display aft address-group [ { begin exclude include } regular-expression ] display aft address-mapping [ { begin exclude include } regular-expression ] display aft statistics [ { begin exclude include } regular-expression ] Available in any view Available in any view Available in any view Available in any view Clear all AFT statistics information reset aft statistics Available in user view 68

77 AFT configuration examples An IPv6 host with an IVI address initiates communication with an IPv4 host Network requirements As shown in Figure 61, Firewall A is in an IPv6 network and has an address of 6:0:ff06:606:200::, and Firewall C is in an IPv4 network and has an address of Firewall A wishes to communicate with Firewall C. The IPv6 address of Firewall A is an IVI address. For Firewall A to communicate with Firewall C, enable AFT and configure DNS64 and IVI prefixes on Firewall B. Figure 61 Network diagram Configuration procedure 1. Configure Firewall B (the AFT) # Enable IPv6. <FirewallB> system-view [FirewallB] ipv6 # Configure IP addresses for the interfaces and enable AFT on the interfaces. [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ipv6 address 6:0:ff06:606:100::/64 [FirewallB-GigabitEthernet0/1] aft enable [FirewallB-GigabitEthernet0/1] quit [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address [FirewallB-GigabitEthernet0/2] aft enable [FirewallB-GigabitEthernet0/2] quit # Configure the DNS64 prefix. [FirewallB] aft prefix-dns :: 32 # Configure the IVI prefix. [FirewallB] aft prefix-ivi 6:: 2. Configure Firewall A # Enable IPv6. <FirewallA> system-view [FirewallA] ipv6 # Configure an IPv6 address for interface GigabitEthernet 0/1 on Firewall A. [FirewallA] interface GigabitEthernet 0/1 69

78 Verification [FirewallA-GigabitEthernet0/1] ipv6 address 6:0:ff06:606:200::/64 [FirewallA-GigabitEthernet0/1] quit # Configure a static route to network 2000::/32 (the DNS64 prefix). [FirewallA] ipv6 route-static 2000:: 32 6:0:ff06:606:100:: 3. Configure Firewall C # Configure an IP address for interface GigabitEthernet 0/1. <FirewallC> system-view [FirewallC] interface GigabitEthernet 0/1 [FirewallC-GigabitEthernet0/1] ip address [FirewallC-GigabitEthernet0/1] quit # Configure a static route to the IPv4 network ( /24) embedded in the IVI address. [FirewallC] ip route-static Issue the ping ipv6 2000:0:404:402:: command on Firewall A. The ping operation should be successful. # Issue the display session table verbose command on Firewall B to view the established sessions. [FirewallB] display session table verbose Initiator: Source IP/Port : 0006:0:ff06:0606:0200::/32768 Dest IP/Port : 2000:0:0404:0402::/43982 VPN-Instance/VLAN ID/VLL ID: Responder: Source IP/Port : /0 Dest IP/Port : /43982 VPN-Instance/VLAN ID/VLL ID: Pro: ICMPv6(58) App: unknown State: ICMP-CLOSED Start time: :06:44 TTL: 14s Root Zone(in): Zone(out): Management Received packet(s)(init): 5 packet(s) 520 byte(s) Received packet(s)(reply): 5 packet(s) 420 byte(s) Total find: 1 An IPv4 host initiates communication with an IPv6 host Network requirements As shown in Figure 62, Firewall A is in an IPv6 network and has an address of 6:0:ff06:606:200::, and Firewall C is in an IPv4 network and has an address of Firewall C wishes to communicate with Firewall A. For Firewall C to communicate with Firewall A, enable AFT and configure DNS64 and IVI prefixes and 4to6 AFT policies on Firewall B. 70

79 Figure 62 Network diagram Firewall A GE0/1 6:0:ff06:606:200::/64 Firewall B Firewall C GE0/ /24 GE0/1 6:0:ff06:606:100::/64 IPv6 network GE0/ /24 IPv4 network Configuration procedure 1. Configure Firewall B (the AFT) # Enable IPv6. <FirewallB> system-view [FirewallB] ipv6 # Configure IP addresses for the interfaces and enable AFT on the interfaces. [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ipv6 address 6:0:ff06:606:100::/64 [FirewallB-GigabitEthernet0/1] aft enable [FirewallB-GigabitEthernet0/1] quit [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address [FirewallB-GigabitEthernet0/2] aft enable [FirewallB-GigabitEthernet0/2] quit # Configure the DNS64 prefix. [FirewallB] aft prefix-dns :: 32 # Configure the IVI prefix. [FirewallB] aft prefix-ivi 6:: # Create ACL 3000 to permit ICMP packets destined to the IPv4 network /24, which is embedded in the IVI address. [FirewallB] acl number 3000 [FirewallB-acl-adv-3000] rule permit icmp destination [FirewallB-acl-adv-3000] quit # Configure the 4to6 AFT policy for destination address translation so that the Firewall B can translate the destination address into an IPv6 address by using the IVI prefix (6::) for packets destined to network /24. [FirewallB] aft 4to6 acl number 3000 prefix-ivi 6:: # Create ACL 2000 to permit packets from the IPv4 network /24, on which Firewall C resides (this step is optional). [FirewallB] acl number 2000 [FirewallB-acl-basic-2000] rule permit source [FirewallB-acl-basic-2000] quit # Configure the 4to6 AFT policy for source address translation so that the Firewall B can translate the source address into an IPv6 address by using the DNS prefix (2000::/32) for packets from network /24 (this step is optional). [FirewallB] aft 4to6 acl number 2000 prefix-dns :: 32 71

80 Verification NOTE: Configuring the 4to6 AFT policy for source address translation is optional. If the policy is not configured, AFT uses the first configured DNS64 prefix to translate the source IPv4 address into an IPv6 address. 2. Configure Firewall A # Enable IPv6. <FirewallA> system-view [FirewallA] ipv6 # Configure an IPv6 address for interface GigabitEthernet 0/1. [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ipv6 address 6:0:ff06:606:200::/64 [FirewallA-GigabitEthernet0/1] quit # Configure a static route to IPv6 network 2000::/32 (the DNS64 prefix). [FirewallA] ipv6 route-static 2000:: 32 6:0:ff06:606:100:: 3. Configure Firewall C # Configure an IP address for interface GigabitEthernet 0/1. <FirewallC> system-view [FirewallC] interface GigabitEthernet 0/1 [FirewallC-GigabitEthernet0/1] ip address [FirewallC-GigabitEthernet0/1] quit # Configure a static route to the IPv4 network ( /24) embedded in the IVI address. [FirewallC] ip route-static Issue the ping command on Firewall C. The ping operation should be successful. # Issue the display session table verbose command on Firewall B to view the established sessions. [FirewallB] display session table verbose Initiator: Source IP/Port : /2048 Dest IP/Port : /1 VPN-Instance/VLAN ID/VLL ID: Responder: Source IP/Port : 0006:0:ff06:0606:0200::/33024 Dest IP/Port : 2000:0:0404:0402::/1 VPN-Instance/VLAN ID/VLL ID: Pro: ICMP(1) App: unknown State: ICMP-CLOSED Start time: :27:00 TTL: 23s Root Zone(in): Management Zone(out): Received packet(s)(init): 5 packet(s) 420 byte(s) Received packet(s)(reply): 5 packet(s) 520 byte(s) Total find: 1 72

81 Configure the DNS64 function of AFT Network requirements Firewall C is in an IPv4 network and has an IPv4 address of and a domain name of FirewallC.com. Firewall A is in an IPv6 network and has an IPv6 address of 6::2. The DNS server is in the IPv4 network and has an address of The DNS server has the mapping between FirewallC.com and Firewall A wishes to visit Firewall C through domain name FirewallC.com. To meet the requirements, perform the following configurations: On Firewall B, enable AFT, and configure a DNS64 prefix and a 6to4 AFT policy because the address of Firewall A is not an IVI address. Enable dynamic domain name resolution on Firewall A and specify the IPv6 address of the DNS server (2000:0:303:305::, which is translated from IPv4 address ). Figure 63 Network diagram Configuration procedure 1. Configure Firewall B (the AFT) # Enable IPv6. <FirewallB> system-view [FirewallB] ipv6 # Configure IP addresses for the interfaces and enable AFT on the interfaces. [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ipv6 address 6::1/64 [FirewallB-GigabitEthernet0/1] aft enable [FirewallB-GigabitEthernet0/1] quit [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address [FirewallB-GigabitEthernet0/2] aft enable [FirewallB-GigabitEthernet0/2] quit [FirewallB] interface GigabitEthernet 0/3 [FirewallB-GigabitEthernet0/3] ip address [FirewallB-GigabitEthernet0/3] aft enable [FirewallB-GigabitEthernet0/3] quit # Configure the DNS64 prefix. 73

82 [FirewallB] aft prefix-dns :: 32 # Configure an AFT address pool. [FirewallB] aft address-group # Configure a 6to4 AFT policy so that if the prefix of the destination address of a packet is the DNS64 prefix (2000::/32), the source address is translated into an IPv4 address in address pool 1 and the port number is also translated. [FirewallB] aft 6to4 prefix-dns :: 32 address-group 1 # Create ACL 2000 to permit packets from network /24 where Firewall C resides (this step is optional). [FirewallB] acl number 2000 [FirewallB-acl-basic-2000] rule permit source [FirewallB-acl-basic-2000] quit # Configure a 4to6 AFT policy for source address translation so that if the resolved IPv4 address is in network /24, the address is translated into an IPv6 address by using DNS64 prefix 2000::/32 (this step is optional). [FirewallB] aft 4to6 acl number 2000 prefix-dns :: 32 NOTE: It is optional to configure the 4to6 AFT policy for source address translation. If the policy is not configured, AFT uses the first configured DNS64 prefix to translate the resolved IPv4 address into an IPv6 address. 2. Configure Firewall A # Enable IPv6. <FirewallA> system-view [FirewallA] ipv6 # Configure an IPv6 address for interface GigabitEthernet 0/1. [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ipv6 address 6::2/64 [FirewallA-GigabitEthernet0/1] quit # Configure a static route to network 2000::/32 (the DNS64 prefix). [FirewallA] ipv6 route-static 2000:: 32 6::1 # Specify the IPv6 address (2000:0:303:305::, which is translated from ) of the DNS server. [FirewallA] dns server ipv6 2000:0:303:305:: # Enable dynamic domain name resolution. [FirewallA] dns resolve 3. Configure Firewall C # Configure the IP address of interface GigabitEthernet 0/1. <FirewallC> system-view [FirewallC] interface GigabitEthernet 0/1 [FirewallC-GigabitEthernet0/1] ip address [FirewallC-GigabitEthernet0/1] quit # Configure a static route to network /24, which the AFT address pool belongs to. [FirewallC] ip route-static

83 Verification NOTE: You must also configure a static route to network /24 on the DNS server. The configuration procedure is not shown. # Issue the ping ipv6 FirewallC.com command on Firewall A. The ping operation is successful and the output displays that the resolved address is 2000:0:404:402::. This address is translated from the IPv4 address of Firewall C by using the DNS64 prefix. [FirewallA] ping ipv6 FirewallC.com Trying DNS resolve, press CTRL_C to break Trying DNS server (2000:0:303:305::) PING FirewallC.com (2000:0:404:402::): 56 data bytes, press CTRL_C to break Reply from 2000:0:404:402:: bytes=56 Sequence=1 hop limit=254 time = 2 ms Reply from 2000:0:404:402:: bytes=56 Sequence=2 hop limit=254 time = 2 ms Reply from 2000:0:404:402:: bytes=56 Sequence=3 hop limit=254 time = 1 ms Reply from 2000:0:404:402:: bytes=56 Sequence=4 hop limit=254 time = 1 ms Reply from 2000:0:404:402:: bytes=56 Sequence=5 hop limit=254 time = 2 ms --- FirewallC.com ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/2 ms # Issue the display session table verbose command on Firewall B to view the established sessions. [FirewallB] display session table verbose Initiator: Source IP/Port : 0006::0002/2628 Dest IP/Port : 2000:0:0303:0305::/53 VPN-Instance/VLAN ID/VLL ID: Responder: Source IP/Port : /53 Dest IP/Port : /12298 VPN-Instance/VLAN ID/VLL ID: Pro: UDP(17) App: DNS State: UDP-READY Start time: :00:06 TTL: 52s Root Zone(in): Zone(out): Management Received packet(s)(init): 1 packet(s) 77 byte(s) Received packet(s)(reply): 2 packet(s) 183 byte(s) Initiator: 75

84 Source IP/Port : 0006::0002/32768 Dest IP/Port : 2000:0:0404:0402::/44012 VPN-Instance/VLAN ID/VLL ID: Responder: Source IP/Port : /0 Dest IP/Port : /12299 VPN-Instance/VLAN ID/VLL ID: Pro: ICMPv6(58) App: unknown State: ICMP-CLOSED Start time: :00:06 TTL: 23s Root Zone(in): Management Zone(out): Management Received packet(s)(init): 5 packet(s) 520 byte(s) Received packet(s)(reply): 5 packet(s) 420 byte(s) Total find: 2 Troubleshooting AFT Symptom 1 Solution Symptom 2 Solution When an IPv6 host with a non-ivi address initiates communication with an IPv4 host, AFT fails to perform address translation. Enable debugging for AFT and locate the causes based on the debugging information. Verify whether the translation of the source address is successful based on the debugging information. If not, the address pool might run out of IP addresses. You can configure a larger address pool or use IP address + port number translation to save the IP addresses in the address pool. When an IPv6 host with an IVI address initiates communication with an IPv4 host, AFT fails to perform address translation. Verify whether the IVI address complies with the IVI address format. If not, change the address of the IPv6 host or configure a 6to4 AFT policy. 76

85 Tunneling configuration Tunneling overview Tunneling is an encapsulation technology. It uses one network protocol to encapsulate packets of another network protocol and transfer them over a virtual point-to-point connection. The virtual connection is called a tunnel. Packets are encapsulated and de-encapsulated at both ends of a tunnel. Tunneling refers to the whole process from data encapsulation to data transfer to data de-encapsulation. Tunneling provides the following features: Transition techniques, such as IPv6 over IPv4 tunneling, to interconnect IPv4 and IPv6 networks. Virtual private networks (VPNs) for guaranteeing communication security, such as IPv4 over IPv4 tunneling, IPv4/IPv6 over IPv6 tunneling, Generic Routing Encapsulation (GRE), and IPsec tunneling. Unless otherwise specified, the term tunnel used throughout this document refers to an IPv6 over IPv4, IPv4 over IPv4, IPv4 over IPv6, or IPv6 over IPv6 tunnel. NOTE: For more information about GRE, see the chapter GRE configuration. For more information about IPsec, see the chapter IPsec configuration. IPv6 over IPv4 tunnels Implementation IPv6 over IPv4 tunneling adds an IPv4 header to IPv6 data packets so that IPv6 packets can pass an IPv4 network through a tunnel to realize internetworking between isolated IPv6 networks, as shown in Figure 64. The IPv6 over IPv4 tunnel can be established between two hosts, a host and a device, or two devices. The tunnel destination node can forward IPv6 packets if it is not the destination of the IPv6 packets. NOTE: The devices at both ends of an IPv6 over IPv4 tunnel must support the IPv4/IPv6 dual stack. Figure 64 IPv6 over IPv4 tunnel 77

86 Tunnel types The IPv6 over IPv4 tunnel processes packets in the following ways. 1. A host in the IPv6 network sends an IPv6 packet to Device A at the tunnel source. 2. After determining according to the routing table that the packet needs to be forwarded through the tunnel, Device A encapsulates the IPv6 packet with an IPv4 header and forwards it through the physical interface of the tunnel. 3. Upon receiving the packet, Device B de-encapsulates the packet. 4. Device B forwards the packet according to the destination address in the de-encapsulated IPv6 packet. If the destination address is the device itself, Device B forwards the IPv6 packet to the upper-layer protocol for processing. IPv6 over IPv4 tunnels are divided into manually configured tunnels and automatic tunnels, depending on how the IPv4 address of the tunnel destination is acquired. Manually configured tunnel: The destination address of the tunnel cannot be automatically acquired through the destination IPv6 address of an IPv6 packet at the tunnel source, and must be manually configured. Automatic tunnel: The destination address of the tunnel is an IPv6 address with an IPv4 address embedded, and the IPv4 address can be automatically acquired through the destination IPv6 address of an IPv6 packet at the tunnel source. According to the way an IPv6 packet is encapsulated, IPv6 over IPv4 tunnels are divided into the following modes. Table 6 IPv6 over IPv4 tunnel modes and key parameters Tunnel type Tunnel mode Tunnel source/destination address Tunnel interface address type IPv6 manual tunneling The source/destination IP address is a manually configured IPv4 address. IPv6 address Manually configured tunnel IPv6-over-IPv4 GRE tunneling 6to4 tunneling The source/destination IP address is a manually configured IPv4 address. The source IP address is a manually configured IPv4 address. The destination IP address need not be configured. IPv6 address 6to4 address, in the format of 2002:IPv4-source-addr ess::/48 Intra-site automatic tunnel addressing protocol (ISATAP) tunneling The source IP address is a manually configured IPv4 address. The destination IP address need not be configured. ISATAP address, in the format of Prefix:0:5EFE:IPv4-sour ce-address/64 1. IPv6 manual tunneling A manually configured tunnel is a point-to-point link. Each link is a separate tunnel. IPv6 manual tunnels are mainly used to provide stable connections for regular secure communication between border routers or between border routers and hosts for access to remote IPv6 networks. 2. IPv6-over-IPv4 GRE tunneling IPv6 packets can be carried over IPv6-over-IPv4 GRE tunnels to pass through an IPv4 network. Like an IPv6 manually configured tunnel, an IPv6-over-IPv4 GRE tunnel is a point-to-point link. IPv6-over-IPv4 GRE 78

87 tunnels are mainly used to provide stable connections for secure communication between border routers or between host and border router. For more information about related configurations, see the chapter GRE configuration. 3. 6to4 tunneling Ordinary 6to4 tunneling An automatic 6to4 tunnel is a point-to-multipoint tunnel and is used to connect multiple isolated IPv6 networks over an IPv4 network to remote IPv6 networks. The embedded IPv4 address in an IPv6 address is used to automatically acquire the destination IPv4 address of the tunnel. The automatic 6to4 tunnel adopts 6to4 addresses. The address format is 2002:abcd:efgh:subnet number::interface ID/64, where 2002 represents the fixed IPv6 address prefix, and abcd:efgh represents the 32-bit globally unique source IPv4 address of the 6to4 tunnel, in hexadecimal notation. For example, can be represented by 0101:0101. The part that follows 2002:abcd:efgh uniquely identifies a host in a 6to4 network. The tunnel destination is automatically determined by the embedded IPv4 address, which makes it easy to create a 6to4 tunnel. Because the 16-bit subnet number of the 64-bit address prefix in 6to4 addresses can be customized and the first 48 bits in the address prefix are fixed to a permanent value and the IPv4 address of the tunnel source or destination, it is possible that IPv6 packets can be forwarded by the tunnel. A 6to4 tunnel interconnects IPv6 networks over an IPv4 network. 6to4 relay A 6to4 tunnel is only used to connect 6to4 networks, whose IP prefix must be 2002::/16. However, IPv6 network addresses with the prefix such as 2001::/16 may also be used in IPv6 networks. To connect a 6to4 network to an IPv6 network, a 6to4 router must be used as a gateway to forward packets to the IPv6 network. Such a router is called 6to4 relay router. As shown in Figure 65, a static route must be configured on the border router (Device A) in the 6to4 network and the next-hop address must be the 6to4 address of the 6to4 relay router (Device C). In this way, all packets destined for the IPv6 network will be forwarded to the 6to4 relay router, and then to the IPv6 network. Thus, internetworking between the 6to4 network (with the address prefix starting with 2002) and the IPv6 network is realized. Figure 65 Principle of 6to4 tunneling and 6to4 relay 6to4 router 6to4 router 6to4 tunnel Device B 6to4 network Site 2 6to4 network Site 1 Device A IPv4 network 6to4 tunnel 6to4 relay IPv6 network Site 3 Device C 4. ISATAP tunneling With the application of the IPv6 technology, there will be more and more IPv6 hosts in the existing IPv4 network. The ISATAP tunneling technology provides a satisfactory solution for IPv6 application. An ISATAP tunnel is a point-to-multipoint automatic tunnel. The destination of a tunnel can automatically be acquired from the embedded IPv4 address in the destination address of an IPv6 packet. 79

88 When an ISATAP tunnel is used, the destination address of an IPv6 packet and the IPv6 address of a tunnel interface both adopt special ISATAP addresses. The ISATAP address format is prefix(64bit):0:5efe:abcd:efgh. The 64-bit prefix is the prefix of a valid IPv6 unicast address, but abcd:efgh is a 32-bit source IPv4 address in hexadecimal, which might not be globally unique. Through the embedded IPv4 address, an ISATAP tunnel can be automatically created to transfer IPv6 packets. The ISATAP tunnel is mainly used for communication between IPv6 routers or between a host and an IPv6 router over an IPv4 network. Figure 66 Principle of ISATAP tunneling IPv4 over IPv4 tunneling Introduction IPv4 over IPv4 tunneling (specified in RFC 1853) is developed for IP data packet encapsulation so that data can be transferred from one IPv4 network to another IPv4 network. Encapsulation and de-encapsulation Figure 67 Principle of IPv4 over IPv4 tunneling Packets traveling through a tunnel undergo encapsulation and de-encapsulation processes, as shown in Figure 67. Encapsulation The encapsulation follows these steps. 1. Device A receives an IP packet from an IPv4 host and submits it to the IP protocol stack. 2. The IP protocol stack determines how to forward the packet according to the destination address in the IP header. If the packet is destined for the IPv4 host connected to Device B, Device A delivers the packet to the tunnel interface. 3. The tunnel interface encapsulates the packet into an IPv4 packet and submitted to the IP protocol stack for processing. The IP protocol stack determines the outgoing interface of the tunnel according to the IP header, and sends the packet out. De-encapsulation 80

89 The de-encapsulation follows these steps. 4. After receiving the packet, Device A delivers it to the IP protocol stack, which then checks the protocol number in the IP header. 5. If the protocol number is IPv4 (indicating an IPv4 packet is encapsulated within the packet), the IP packet is sent to the tunnel module for de-encapsulation. 6. The de-encapsulated IP packet is sent back to the IP protocol stack for processing. IPv4 over IPv6 tunneling Introduction IPv4 over IPv6 tunneling adds an IPv6 header to IPv4 packets so that the IPv4 packets can traverse an IPv6 network and reach another IPv4 network. Encapsulation and de-encapsulation Figure 68 Principle of IPv4 over IPv6 tunneling The encapsulation and de-encapsulation processes illustrated in Figure 68 are described as follows: Encapsulation 1. Upon receiving a packet from the attached IPv4 network, Device A examines the destination address of the packet and determines the outgoing interface. 2. If the packet is destined for the IPv4 network attached to Device B, Device A delivers the packet to the tunnel interface pointed to Device B. 3. The tunnel interface adds an IPv6 header to the original IPv4 packet and delivers the packet to the IPv6 protocol stack for forwarding. De-encapsulation 4. Upon receiving a packet from the attached IPv6 network, Device B delivers the packet to the IPv6 protocol stack to examine the protocol type encapsulated in the data portion of the packet. 5. If the protocol type is IPv4, the IPv6 protocol stack delivers the packet to the tunneling module. 6. The tunneling module removes the IPv6 header and delivers the remaining IPv4 packet to the IPv4 protocol stack for subsequent forwarding. IPv4 over IPv6 tunnel modes IPv4 over IPv6 tunnels fall into the following modes: IPv4 over IPv6 manual tunnel 81

90 In this tunnel mode, you must manually configure the source and destination IPv6 addresses for the tunnel. An IPv4 over IPv6 manual tunnel is a point-to-point virtual link. IPv4-over-IPv6 GRE tunnel The IPv4 over IPv6 GRE tunnel is also a point-to-point virtual link and the source and destination IPv6 address for the tunnel are also manually configured. The difference is that, in the case of manual tunnel, IPv4 packets are encapsulated by using the IPv6 header, whereas in the case of GRE tunnel, IPv4 packets are encapsulated based on standard GRE protocol. NOTE: The encapsulation and de-encapsulation of the IPv4-over-IPv6 GRE tunnel is slightly different from Encapsulation and de-encapsulation. For more information about GRE, see the chapter GRE configuration. DS-lite tunnel Dual Stack Lite (DS-lite) combines the IPv4 over IPv6 tunneling and network address translation (NAT) to connect IPv4 networks over IPv6 networks without sacrificing the benefits of NAT. Figure 69 Network diagram DS-lite tunnel As shown in Figure 69, a DS-lite network involves the following parts: Customer Premises Equipment (CPE): Resides at the customer s premise, connects the customer s network to an Internet Service Provider (ISP) network, and usually serves as the gateway of the customer s network. As a tunnel end, the CPE encapsulates IPv4 packets of the customer s network into IPv6 packets and sends them to the other end of the tunnel, and de-encapsulates IPv6 packets into IPv4 packets and sends them to the customer s network. Some hosts can serve as the CPE. Such hosts are referred to as DS-lite hosts. Address Family Transition Router (AFTR): Resides in the ISP network and serves as both an IPv4 over IPv6 tunnel end and the NAT device. After IPv6 packets are de-encapsulated into IPv4 packets, the AFTR translates the source private IPv4 address of each packet into a public IPv4 address and sends the packet to the destination IPv4 host. The AFTR also translates the destination public IPv4 address of each response packet into a private IPv4 address, encapsulates the packet into an IPv6 packet, and forwards the packet to the CPE. In addition, the AFTR records the NAT entries and the IPv6 82

91 address of each CPE so that IPv4 networks connected to different CPEs can use the same address space. DS-lite tunnel: The IPv4 over IPv6 tunnel between the CPE and AFTR which carries IPv4 packets over an IPv6 network. Figure 70 Packet forwarding process in DS-lite When a gateway serves as the CPE, the changes of source and destination IP addresses and port numbers are illustrated in Figure 70. The entire process is summarized as follows: The CPE and AFTR encapsulate and de-encapsulate packets. The AFTR performs NAT. When a host serves as the CPE, the process is similar and therefore not shown. NOTE: NAT supports both basic address translation between private and public addresses and Network Address Port Translation (NAPT), which translates both IP address (private or public) and port number. Figure 70 shows an example of NAPT. For more information about NAT, see NAT Configuration Guide. DS-lite tunnel supports only an IPv4 host in a private network initiating communication with an IPv4 host on the Internet and does not support an IPv4 host on the Internet initiating communication with an IPv4 host in a private network. 83

92 IPv6 over IPv6 tunneling Introduction IPv6 over IPv6 tunneling (specified in RFC 2473) is developed for IPv6 data packet encapsulation so that encapsulated packets can be transmitted over an IPv6 network. The encapsulated packets are IPv6 tunnel packets. Encapsulation and de-encapsulation Figure 71 Principle of IPv6 over IPv6 tunneling Figure 71 shows the encapsulation and de-encapsulation processes. Encapsulation 1. After receiving the IPv6 packet, the interface of Device A connecting private network A submits it to the IPv6 module for processing. The IPv6 module then determines how to forward the packet. 2. If the packet is destined for Host B connected to Device B, the packet is sent to Router A s tunnel interface that is connected to Device B. 3. After receiving the packet, the tunnel interface adds an IPv6 header to it and submits it to the IPv6 module for processing. 4. The IPv6 module re-determines how to forward the packet according to the destination address in the IPv6 header. De-encapsulation The de-encapsulation follows these steps. 5. The packet received from the IPv6 network interface is sent to the IPv6 module for processing. 6. The IPv6 module checks the protocol type of the data portion encapsulated in the IPv6 packet. If the encapsulation protocol is IPv6, the packet is sent to the tunnel processing module for de-encapsulation. 7. The de-encapsulated packet is sent to the IPv6 protocol module for the secondary routing process. NOTE: GRE can realize the IPv6 over IPv6 tunnel function. For more information about related configurations, see the chapter GRE configuration. Protocols and standards RFC 1853, IP in IP Tunneling 84

93 RFC 2473, Generic Packet Tunneling in IPv6 Specification RFC 2893, Transition Mechanisms for IPv6 Hosts and Routers RFC 3056, Connection of IPv6 Domains via IPv4 Clouds RFC 4214, Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) Tunneling configuration task list Complete the following tasks to configure the tunneling feature: Task Configuring a tunnel interface Remarks Required Configuring an IPv6 over IPv4 tunnel Configuring an IPv6 manual tunnel Configuring a 6to4 tunnel Configuring an ISATAP tunnel Optional Use one as needed. Configuring an IPv4 over IPv4 tunnel Configuring an IPv4 over IPv6 manual tunnel Configuring an IPv6 over IPv6 tunnel Configuring an IPv4 over IPv6 manual tunnel Configuring a DS-lite tunnel Optional Optional Optional Configuring a tunnel interface Configure a Layer 3 virtual tunnel interface on each device on a tunnel so that devices at both ends can send, identify, and process packets from the tunnel. Follow these steps to configure a tunnel interface: To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter its view Configure the description for the interface interface tunnel number description text Required By default, no tunnel interface is created. Optional By default, the description of a tunnel interface is Tunnelnumber Interface. Set the MTU of the tunnel interface Set the MTU for IPv4 packets sent over the interface Set the MTU for IPv6 packets sent over the interface mtu size ipv6 mtu size Optional Use either command as needed. Set the bandwidth of the tunnel interface tunnel bandwidth bandwidth-value Optional By default, the bandwidth of the tunnel interface is 64 kbps. 85

94 To do Use the command Remarks Restore the default setting default Optional Shut down the tunnel interface shutdown Optional By default, the interface is up. NOTE: For more information about the ipv6 mtu command, see Network Management Configuration Guide. The tunnel bandwidth command does not change the actual bandwidth of the tunnel interface, but sets a bandwidth value for dynamical routing protocols to calculate the cost of a tunnel path. You can determine the value according to the bandwidth of the output interface. Configuring an IPv6 manual tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the device to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure an IPv6 manual tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 packet forwarding function is disabled. Enter tunnel interface view interface tunnel number Configure an IPv6 address for the tunnel interface Configure a global unicast IPv6 address or a site-local address Configure a link-local IPv6 address ipv6 address { ipv6-address prefix-length ipv6-address/prefix-length } ipv6 address ipv6-address/prefix-length eui-64 ipv6 address auto link-local ipv6 address ipv6-address link-local Required Use either command. By default, no IPv6 global unicast address or site-local address is configured for the tunnel interface. Optional By default, a link-local address will automatically be created when an IPv6 global unicast address or site-local address is configured. 86

95 To do Use the command Remarks Specify the IPv6 manual tunnel mode Configure a source address or interface for the tunnel Configure a destination address for the tunnel tunnel-protocol ipv6-ipv4 source { ip-address interface-type interface-number } destination ip-address Required By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. Required By default, no destination address is configured for the tunnel. Return to system view quit Enable dropping of IPv6 packets using IPv4-compatible IPv6 addresses tunnel discard ipv4-compatible-packet Optional Disabled by default. NOTE: After a tunnel interface is deleted, all the features configured on the tunnel interface will be deleted. To encapsulate and forward IPv6 packets whose destination address does not belong to the subnet where the current tunnel interface resides, you must configure a static route or dynamic routing for forwarding those packets through this tunnel interface. If you configure a static route to that destination IPv6 address, specify this tunnel interface as the outbound interface, or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. If you configure dynamic routing at both ends, enable the dynamic routing protocol on both tunnel interfaces. For the detailed configuration, see Network Management Configuration Guide. Configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements As shown in Figure 72, two IPv6 networks are connected over an IPv4 network. An IPv6 over IPv4 tunnel need be configured between Router A and Router B to make the two IPv6 networks reachable to each other. If the destination IPv4 address cannot be automatically obtained from the destination IPv6 addresses of packets, configure an IPv6 manual tunnel. 87

96 Figure 72 Network diagram Router A GE0/1 3002::1/64 IPv6 Group 1 GE0/ /24 Tunnel0 3001::1/64 IPv4 netwok IPv6 manual tunnel GE0/ /24 Tunnel0 3001::2/64 Router B IPv6 Group 2 GE0/1 3003::1/64 Configuration procedure NOTE: Before configuring an IPv6 manual tunnel, make sure that Router A and Router B are reachable to each other. Configure Router A # Enable IPv6. <RouterA> system-view [RouterA] ipv6 # Configure an IPv4 address for GigabitEthernet 0/2. [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ip address [RouterA-GigabitEthernet0/2] quit # Configure an IPv6 address for GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ipv6 address 3002::1 64 [RouterA-GigabitEthernet0/1] quit # Configure an IPv6 manual tunnel. [RouterA] interface tunnel 0 [RouterA-Tunnel0] ipv6 address 3001::1/64 [RouterA-Tunnel0] source GigabitEthernet 0/2 [RouterA-Tunnel0] destination [RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 [RouterA-Tunnel0] quit # Configure a static route to IPv6 Group 2 through Tunnel 0 on Router A. [RouterA] ipv6 route-static 3003:: 64 tunnel 0 Configure Router B # Enable IPv6. <RouterB> system-view [RouterB] ipv6 # Configure an IPv4 address for GigabitEthernet 0/2. [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ip address [RouterB-GigabitEthernet0/2] quit 88

97 Verification # Configure an IPv6 address for GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ipv6 address 3003::1 64 [RouterB-GigabitEthernet0/1] quit # Configure an IPv6 manual tunnel. [RouterB] interface tunnel 0 [RouterB-Tunnel0] ipv6 address 3001::2/64 [RouterB-Tunnel0] source GigabitEthernet 0/2 [RouterB-Tunnel0] destination [RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 [RouterB-Tunnel0] quit # Configure a static route to IPv6 Group 1 through Tunnel 0 on Router B. [RouterB] ipv6 route-static 3002:: 64 tunnel 0 After the above configurations, display the status of the tunnel interfaces on Router A and Router B, respectively. [RouterA] display ipv6 interface tunnel 0 Tunnel0 current state :UP Line protocol current state :UP IPv6 is enabled, link-local address is FE80::C0A8:6401 Global unicast address(es): 3001::1, subnet is 3001::/64 Joined group address(es): FF02::1:FF00:0 FF02::1:FF00:1 FF02::1:FFA8:6401 FF02::2 FF02::1 MTU is 1480 bytes ND reachable time is milliseconds ND retransmit interval is 1000 milliseconds Hosts use stateless autoconfig for addresses IPv6 Packet statistics: InReceives: [RouterB] display ipv6 interface tunnel 0 Tunnel0 current state :UP Line protocol current state :UP IPv6 is enabled, link-local address is FE80::C0A8:3201 Global unicast address(es): 3001::2, subnet is 3001::/64 Joined group address(es): FF02::1:FF00:0 FF02::1:FF00:1 FF02::1:FFA8:3201 FF02::2 FF02::1 89

98 MTU is 1480 bytes ND reachable time is milliseconds ND retransmit interval is 1000 milliseconds Hosts use stateless autoconfig for addresses IPv6 Packet statistics: InReceives: # Ping the IPv6 address of GigabitEthernet 0/1 at the peer end from Router A. [RouterA] ping ipv6 3003::1 PING 3003::1 : 56 data bytes, press CTRL_C to break Reply from 3003::1 bytes=56 Sequence=1 hop limit=64 time = 1 ms Reply from 3003::1 bytes=56 Sequence=2 hop limit=64 time = 1 ms Reply from 3003::1 bytes=56 Sequence=3 hop limit=64 time = 1 ms Reply from 3003::1 bytes=56 Sequence=4 hop limit=64 time = 1 ms Reply from 3003::1 bytes=56 Sequence=5 hop limit=64 time = 1 ms ::1 ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms Configuring a 6to4 tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the firewall to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure a 6to4 tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 packet forwarding function is disabled. Enter tunnel interface view interface tunnel number 90

99 To do Use the command Remarks Configure an IPv6 address for the tunnel interface Configure an IPv6 global unicast address or a site-local address Configure an IPv6 link-local address ipv6 address { ipv6-address prefix-length ipv6-address/prefix-length } ipv6 address ipv6-address/prefix-length eui-64 ipv6 address auto link-local ipv6 address ipv6-address link-local Required. Use either command. By default, no IPv6 global unicast address or site-local address is configured for the tunnel interface. Optional By default, a link-local address will automatically be generated when an IPv6 global unicast address or site-local address is configured. Specify the 6to4 tunnel mode Configure a source address or interface for the tunnel tunnel-protocol ipv6-ipv4 6to4 source { ip-address interface-type interface-number } Required By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. Return to system view quit Enable dropping of IPv6 packets using IPv4-compatible IPv6 addresses tunnel discard ipv4-compatible-packet Optional Disabled by default. NOTE: No destination address needs to be configured for a 6to4 tunnel because the destination address can automatically be obtained from the IPv4 address embedded in the 6to4 IPv6 address. To encapsulate and forward IPv6 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route to reach the destination IPv6 address through this tunnel interface on the firewall. Because automatic tunnels do not support dynamic routing, you can configure a static route to that destination IPv6 address with this tunnel interface as the outbound interface or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. For the detailed configuration, see Network Management Configuration Guide. The automatic tunnel interfaces using the same encapsulation protocol cannot share the same source IP address. 6to4 tunnel configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. 91

100 Network requirements As shown in Figure 73, two 6to4 networks are connected to an IPv4 network through two 6to4 routers (Router A and Router B) respectively. Configure a 6to4 tunnel to make Host A and Host B reachable to each other. Figure 73 Network diagram Configuration consideration To enable communication between 6to4 networks, configure 6to4 addresses for 6to4 routers and hosts in the 6to4 networks. The IPv4 address of GigabitEthernet 0/2 on Router A is /24, and the corresponding 6to4 prefix is 2002:0201:0101::/48 after it is translated to an IPv6 address. Assign interface Tunnel 0 to subnet 2002:0201:0101::/64 and GigabitEthernet 0/1 to subnet 2002:0201:0101:1::/64. The IPv4 address of GigabitEthernet 0/2 on Router B is /24, and the corresponding 6to4 prefix is 2002:0501:0101::/48 after it is translated to an IPv6 address. Assign interface Tunnel 0 to subnet 2002:0501:0101::/64 and GigabitEthernet 0/1 to subnet 2002:0501:0101:1::/64. Configuration procedure NOTE: Before configuring a 6to4 tunnel, make sure that Router A and Router B are reachable to each other. Configure Router A. # Enable IPv6. <RouterA> system-view [RouterA] ipv6 # Configure an IPv4 address for GigabitEthernet 0/2. [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ip address [RouterA-GigabitEthernet0/2] quit # Configure an IPv6 address for GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ipv6 address 2002:0201:0101:1::1/64 [RouterA-GigabitEthernet0/1] quit # Configure the 6to4 tunnel. 92

101 [RouterA] interface tunnel 0 [RouterA-Tunnel0] ipv6 address 2002:201:101::1/64 [RouterA-Tunnel0] source GigabitEthernet 0/2 [RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4 [RouterA-Tunnel0] quit # Configure a static route whose destination address is 2002::/16 and next-hop is the tunnel interface. [RouterA] ipv6 route-static 2002:: 16 tunnel 0 Configure Router B # Enable IPv6. <RouterB> system-view [RouterB] ipv6 # Configure an IPv6 address for GigabitEthernet 0/2. [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ip address [RouterB-GigabitEthernet0/2] quit # Configure an IPv6 address for GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ipv6 address 2002:0501:0101:1::1/64 [RouterB-GigabitEthernet0/1] quit # Configure a 6to4 tunnel. [RouterB] interface tunnel 0 [RouterB-Tunnel0] ipv6 address 2002:0501:0101::1/64 [RouterB-Tunnel0] source GigabitEthernet 0/2 [RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4 [RouterB-Tunnel0] quit # Configure a static route whose destination address is 2002::/16 and next-hop is the tunnel interface. [RouterB] ipv6 route-static 2002:: 16 tunnel 0 Verification After the above configuration, ping either host from the other, and the ping operation succeeds. D:\>ping6 -s 2002:201:101:1::2 2002:501:101:1::2 Pinging 2002:501:101:1::2 from 2002:201:101:1::2 with 32 bytes of data: Reply from 2002:501:101:1::2: bytes=32 time=13ms Reply from 2002:501:101:1::2: bytes=32 time=1ms Reply from 2002:501:101:1::2: bytes=32 time=1ms Reply from 2002:501:101:1::2: bytes=32 time<1ms Ping statistics for 2002:501:101:1::2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 13ms, Average = 3ms 93

102 6to4 relay configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements As shown in Figure 74, Router A is a 6to4 router, and 6to4 addresses are used on the connected IPv6 network. Router B serves as a 6to4 relay router and is connected to the IPv6 network (2001::/16). Configure a 6to4 tunnel between Router A and Router B to make Host A and Host B reachable to each other. Figure 74 Network diagram Configuration procedure NOTE: Before configuring a 6to4 relay, make sure that Router A and Router B are reachable to each other. The configuration on a 6to4 relay router is similar to that on a 6to4 router. However, to enable communication between the 6to4 network and the IPv6 network, you must configure a route to the IPv6 network on the 6to4 router. Configure Router A # Enable IPv6. <RouterA> system-view [RouterA] ipv6 # Configure an IPv4 address for GigabitEthernet 0/2. [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ip address [RouterA-GigabitEthernet0/2] quit # Configure an IPv6 address for GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ipv6 address 2002:0201:0101:1::1/64 [RouterA-GigabitEthernet0/1] quit # Configure a 6to4 tunnel. [RouterA] interface tunnel 0 94

103 [RouterA-Tunnel0] ipv6 address 2002:0201:0101::1/64 [RouterA-Tunnel0] source GigabitEthernet 0/2 [RouterA-Tunnel0] tunnel-protocol ipv6-ipv4 6to4 [RouterA-Tunnel0] quit # Configure a static route to the 6to4 relay router. [RouterA] ipv6 route-static 2002:0601:0101:: 64 tunnel 0 # Configure the default route to the IPv6-only network. [RouterA] ipv6 route-static :: :0601:0101::1 Configure Router B # Enable IPv6. <RouterB> system-view [RouterB] ipv6 # Configure an IPv4 address for GigabitEthernet 0/2. [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ip address [RouterB-GigabitEthernet0/2] quit # Configure an IPv6 address for GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ipv6 address 2001::1/16 [RouterB-GigabitEthernet0/1] quit # Configure a 6to4 tunnel. [RouterB] interface tunnel 0 [RouterB-Tunnel0] ipv6 address 2002:0601:0101::1/64 [RouterB-Tunnel0] source GigabitEthernet 0/2 [RouterB-Tunnel0] tunnel-protocol ipv6-ipv4 6to4 [RouterB-Tunnel0] quit # Configure a static route whose destination address is 2002::/16 and next-hop is the tunnel interface. [RouterB] ipv6 route-static 2002:: 16 tunnel 0 Verification After the above configuration, ping Host B from Host A. D:\>ping6 -s 2002:201:101:1::2 2001::2 Pinging 2001::2 from 2002:201:101:1::2 with 32 bytes of data: Reply from 2001::2: bytes=32 time=13ms Reply from 2001::2: bytes=32 time=1ms Reply from 2001::2: bytes=32 time=1ms Reply from 2001::2: bytes=32 time<1ms Ping statistics for 2001::2: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 13ms, Average = 3ms 95

104 Configuring an ISATAP tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the firewall to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure an ISATAP tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 forwarding function is disabled. Enter tunnel interface view interface tunnel number Configure an IPv6 address for the tunnel interface Configure an IPv6 global unicast address or site-local address Configure an IPv6 link-local address ipv6 address { ipv6-address prefix-length ipv6-address/prefix-length } ipv6 address ipv6-address/prefix-length eui-64 ipv6 address auto link-local ipv6 address ipv6-address link-local Required. Use either command. By default, no IPv6 global unicast address is configured for the tunnel interface. Optional By default, a link-local address will automatically be generated when an IPv6 global unicast address or link-local address is configured. Specify the ISATAP tunnel mode Configure a source address or interface for the tunnel tunnel-protocol ipv6-ipv4 isatap source { ip-address interface-type interface-number } Required By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. Return to system view quit Enable dropping of IPv6 packets using IPv4-compatible IPv6 addresses tunnel discard ipv4-compatible-packet Optional Disabled by default. 96

105 NOTE: No destination address needs to be configured for an ISATAP tunnel. The destination address of the tunnel can be automatically obtained through the IPv4 address embedded in the ISATAP address. To encapsulate and forward IPv6 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route to reach the destination IPv6 address through this tunnel interface on the firewall. Because automatic tunnels do not support dynamic routing, you can configure a static route to that destination IPv6 address with this tunnel interface as the outbound interface or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. For the detailed configuration, see Network Management Configuration Guide. The automatic tunnel interfaces using the same encapsulation protocol cannot share the same source IP address. Configuration example Network requirements As shown in Figure 75, an IPv6 network is connected to an IPv4 network through an ISATAP router (Firewall). IPv6 hosts reside in the IPv4 network. Configure the IPv6 hosts to access the IPv6 network through the ISATAP tunnel. Figure 75 Network diagram ISATAP router IPv6 host 3002::2/64 IPv6 network GE0/2 3001::1/64 Firewall GE0/ /8 IPv4 network ISATAP tunnel Tunnel0 2001::5EFE:0101:0101/64 ISATAP host IPv4 address: /32 IPv6 address: FE80::5EFE:0201: ::5EFE:0201:0102 Configuration procedure NOTE: Before configuring an ISATAP tunnel, make sure that GigabitEthernet 0/1 on the ISATAP router and the ISATAP host are reachable to each other. Configure the Firewall # Enable IPv6. <Firewall> system-view [Firewall] ipv6 # Configure addresses for interfaces. [Firewall] interface GigabitEthernet 0/2 [Firewall-GigabitEthernet0/2] ipv6 address 3001::1/64 [Firewall-GigabitEthernet0/2] quit [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] ip address [Firewall-GigabitEthernet0/1] quit 97

106 # Configure an ISATAP tunnel. [Firewall] interface tunnel 0 [Firewall-Tunnel0] ipv6 address 2001::5efe:0101: [Firewall-Tunnel0] source GigabitEthernet 0/1 [Firewall-Tunnel0] tunnel-protocol ipv6-ipv4 isatap # Disable the RA suppression so that hosts can acquire information such as the address prefix from the RA message released by the ISATAP router. [Firewall-Tunnel0] undo ipv6 nd ra halt [Firewall-Tunnel0] quit # Configure a static route to the ISATAP host. [Firewall] ipv6 route-static 2001:: 16 tunnel 0 Configure the ISATAP host The specific configuration on the ISATAP host is related to its operating system. The following example shows the configuration of the host running the Windows XP. # Install IPv6. C:\>ipv6 install # On a Windows XP-based host, the ISATAP interface is usually interface 2. Configure the IPv4 address of the ISATAP router on interface 2 to complete the configuration on the host. Before that, display information on the ISATAP interface: C:\>ipv6 if 2 Interface 2: Automatic Tunneling Pseudo-Interface Guid {48FCE3FC-EC30-E50E-F1A AEEE3AE} does not use Neighbor Discovery does not use Router Discovery routing preference 1 EUI-64 embedded IPv4 address: router link-layer address: preferred link-local fe80::5efe: , life infinite link MTU 1280 (true link MTU 65515) current hop limit 128 reachable time 42500ms (base 30000ms) retransmission interval 1000ms DAD transmits 0 default site prefix length 48 # A link-local address (fe80::5efe: ) in the ISATAP format was automatically generated for the ISATAP interface. Configure the IPv4 address of the ISATAP router on the ISATAP interface. C:\>ipv6 rlu After carrying out the above command, look at the information on the ISATAP interface. C:\>ipv6 if 2 Interface 2: Automatic Tunneling Pseudo-Interface Guid {48FCE3FC-EC30-E50E-F1A AEEE3AE} does not use Neighbor Discovery uses Router Discovery routing preference 1 EUI-64 embedded IPv4 address: router link-layer address:

107 preferred global 2001::5efe: , life 29d23h59m46s/6d23h59m46s (public) preferred link-local fe80::5efe: , life infinite link MTU 1500 (true link MTU 65515) current hop limit 255 reachable time 42500ms (base 30000ms) retransmission interval 1000ms DAD transmits 0 default site prefix length 48 # By comparison, it is found that the host acquires the address prefix 2001::/64 and automatically generates the address 2001::5efe: Meanwhile, uses Router Discovery is displayed, indicating that the router discovery function is enabled on the host. Ping the IPv6 address of the tunnel interface of the router. If the address is successfully pinged, an ISATAP tunnel is established. C:\>ping 2001::5efe: Pinging 2001::5efe: with 32 bytes of data: Reply from 2001::5efe: : time=1ms Reply from 2001::5efe: : time=1ms Reply from 2001::5efe: : time=1ms Reply from 2001::5efe: : time=1ms Verification Ping statistics for 2001::5efe: : Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 1ms, Average = 1ms After the configuration, the ISATAP host can access the host in the IPV6 network. Configuring an IPv4 over IPv4 tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the firewall to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure an IPv4 over IPv4 tunnel: To do Use the command Remarks Enter system view system-view Enter tunnel interface view interface tunnel number Configure an IPv4 address for the tunnel interface ip address ip-address { mask mask-length } [ sub ] Required By default, no IPv4 address is configured for the tunnel interface. 99

108 To do Use the command Remarks Specify the IPv4 over IPv4 tunnel mode Configure a source address or interface for the tunnel interface Configure a destination address for the tunnel interface tunnel-protocol ipv4-ipv4 source { ip-address interface-type interface-number } destination ip-address Optional By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. Required By default, no destination address is configured for the tunnel. NOTE: To encapsulate and forward IPv4 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route or dynamic routing for forwarding those packets through this tunnel interface. If you configure a static route to that destination IPv4 address, specify this tunnel interface as the outbound interface, or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. If you configure dynamic routing at both ends, enable the dynamic routing protocol on both tunnel interfaces. For the detailed configuration, see Network Management Configuration Guide. The IPv4 address of the local tunnel interface cannot be on the same subnet as the destination address of the tunnel. The destination address of a route with a tunnel interface as the egress interface must not be on the same subnet as the destination address of the tunnel. Two or more tunnel interfaces using the same encapsulation protocol must have different source and destination addresses. If you specify a source interface instead of a source address for the tunnel, the source address of the tunnel is the primary IP address of the source interface. Configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements As shown in Figure 76, the two subnets Group 1 and Group 2 use private IPv4 addresses. Configure an IPv4 over IPv4 tunnel between Router A and Router B to make the two subnets reachable to each other. 100

109 Figure 76 Network diagram GE0/ /24 Router A IPv4 Group 1 GE0/ /24 Tunnel /24 IPv4 netwok IPv4 over IPv4 tunnel GE0/ /24 Tunnel /24 Router B IPv4 Group 2 GE0/ /24 Configuration procedure NOTE: Before configuring an IPv4 over IPv4 tunnel, make sure that Router A and Router B are reachable to each other. Configure Router A # Configure an IPv4 address for GigabitEthernet 0/1. <RouterA> system-view [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ip address [RouterA-GigabitEthernet0/1] quit # Configure an IPv4 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ip address [RouterA-GigabitEthernet0/2] quit # Create interface Tunnel 1. [RouterA] interface tunnel 1 # Configure an IPv4 address for interface Tunnel 1. [RouterA-Tunnel1] ip address # Configure the tunnel encapsulation mode. [RouterA-Tunnel1] tunnel-protocol ipv4-ipv4 # Configure a source address for interface Tunnel 1 (IP address of GigabitEthernet 0/2). [RouterA-Tunnel1] source # Configure a destination address for interface Tunnel 1 (IP address of GigabitEthernet 0/2 of Router B). [RouterA-Tunnel1] destination [RouterA-Tunnel1] quit # Configure a static route from Router A through interface Tunnel 1 to Group 2. [RouterA] ip route-static tunnel 1 Configure Router B # Configure an IPv4 address for GigabitEthernet 0/1. <RouterB> system-view [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ip address

110 Verification [RouterB-GigabitEthernet0/1] quit # Configure an IPv4 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ip address [RouterB-GigabitEthernet0/2] quit # Create interface Tunnel 2. [RouterB] interface tunnel 2 # Configure an IPv4 address for interface Tunnel 2. [RouterB-Tunnel2] ip address # Configure the tunnel encapsulation mode. [RouterB-Tunnel2] tunnel-protocol ipv4-ipv4 # Configure the source address for interface Tunnel 2 (IP address of GigabitEthernet 0/2). [RouterB-Tunnel2] source # Configure a destination address for interface Tunnel 2 (IP address of GigabitEthernet 0/2 of Router A). [RouterB-Tunnel2] destination [RouterB-Tunnel2] quit # Configure a static route from Router B through interface Tunnel 2 to Group 1. [RouterB] ip route-static tunnel 2 After the above configuration, display the status of the tunnel interfaces on Router A and Router B, respectively. [RouterA] display interface tunnel 1 Tunnel1 current state: UP Line protocol current state: UP Description: Tunnel1 Interface The Maximum Transmit Unit is Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set Tunnel source , destination Tunnel protocol/transport IP/IP Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 2 bytes/sec, 0 packets/sec 4 packets input, 256 bytes 0 input error 12 packets output, 768 bytes 0 output error [RouterB] display interface tunnel 2 Tunnel2 current state: UP Line protocol current state: UP Description: Tunnel2 Interface The Maximum Transmit Unit is

111 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set Tunnel source , destination Tunnel protocol/transport IP/IP Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 5 packets input, 320 bytes 0 input error 9 packets output, 576 bytes 0 output error # Ping the IPv4 address of the peer interface GigabitEthernet 0/1 from Router A. [RouterA] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=15 ms Reply from : bytes=56 Sequence=2 ttl=255 time=15 ms Reply from : bytes=56 Sequence=3 ttl=255 time=16 ms Reply from : bytes=56 Sequence=4 ttl=255 time=16 ms Reply from : bytes=56 Sequence=5 ttl=255 time=15 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 15/15/16 ms Configuring an IPv4 over IPv6 manual tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the firewall to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure an IPv4 over IPv6 manual tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 packet forwarding function is disabled. Enter tunnel interface view interface tunnel number 103

112 To do Use the command Remarks Configure an IPv4 address for the tunnel interface Specify the IPv4 over IPv6 manual tunnel mode Configure the source address or interface for the tunnel interface Configure the destination address for the tunnel interface ip address ip-address { mask mask-length } [ sub ] tunnel-protocol ipv4-ipv6 source { ipv6-address interface-type interface-number } destination ipv6-address Required By default, no IPv4 address is configured for the tunnel interface. Optional By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. Required By default, no destination address is configured for the tunnel. NOTE: To encapsulate and forward IPv4 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route or dynamic routing for forwarding those packets through this tunnel interface. If you configure a static route to that destination IPv4 address, specify this tunnel interface as the outbound interface, or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. If you configure dynamic routing at both ends, enable the dynamic routing protocol on both tunnel interfaces. For the detailed configuration, see Network Management Configuration Guide. Two or more tunnel interfaces using the same encapsulation protocol must have different source and destination addresses. If you specify a source interface instead of a source address for the tunnel, the source address of the tunnel is the primary IP address of the source interface. Configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements As shown in Figure 77, the two IPv4 subnets Group 1 and Group 2 are connected over an IPv6 network. Configure an IPv4 over IPv6 manual tunnel between Router A and Router B to make the two subnets reachable to each other. 104

113 Figure 77 Network diagram GE0/ /24 Router A GE0/2 2002::1:1/64 Tunnel /24 IPv6 network IPv4 over IPv6 tunnel GE0/2 2002::2:1/64 Tunnel /24 Router B GE0/ /24 IPv4 Group 1 IPv4 Group 2 Configuration procedure NOTE: Before configuring an IPv4 over IPv6 tunnel, make sure that Router A and Router B are reachable to each other. Configure Router A # Enable IPv6. <RouterA> system-view [RouterA] ipv6 # Configure an IPv4 address for GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ip address [RouterA-GigabitEthernet0/1] quit # Configure an IPv6 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ipv6 address 2002::1:1 64 [RouterA-GigabitEthernet0/2] quit # Create interface Tunnel 1. [RouterA] interface tunnel 1 # Configure an IPv4 address for interface Tunnel 1. [RouterA-Tunnel1] ip address # Configure the tunnel encapsulation mode. [RouterA-Tunnel1] tunnel-protocol ipv4-ipv6 # Configure a source address for interface Tunnel 1 (IP address of GigabitEthernet 0/2). [RouterA-Tunnel1] source 2002::1:1 # Configure a destination address for interface Tunnel 1 (IP address of GigabitEthernet 0/2 of Router B). [RouterA-Tunnel1] destination 2002::2:1 [RouterA-Tunnel1] quit # Configure a static route from Router A through interface Tunnel 1 to Group 2. [RouterA] ip route-static tunnel 1 Configure Router B # Enable IPv6. <RouterB> system-view 105

114 Verification [RouterB] ipv6 # Configure an IPv4 address for GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ip address [RouterB-GigabitEthernet0/1] quit # Configure an IPv6 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ipv6 address 2002::2:1 64 [RouterB-GigabitEthernet0/2] quit # Create interface Tunnel 2. [RouterB] interface tunnel 2 # Configure an IPv4 address for interface Tunnel 2. [RouterB-Tunnel2] ip address # Configure the tunnel encapsulation mode. [RouterB-Tunnel2] tunnel-protocol ipv4-ipv6 # Configure the source address for interface Tunnel 2 (IP address of GigabitEthernet 0/2). [RouterB-Tunnel2] source 2002::2:1 # Configure a destination address for interface Tunnel 2 (IP address of GigabitEthernet 0/2 of Router A). [RouterB-Tunnel2] destination 2002::1:1 [RouterB-Tunnel2] quit # Configure a static route from Router B through interface Tunnel 2 to Group 1. [RouterB] ip route-static tunnel 2 After the above configuration, display the status of the tunnel interfaces on Router A and Router B, respectively. [RouterA] display interface tunnel 1 Tunnel1 current state: UP Line protocol current state: UP Description: Tunnel1 Interface The Maximum Transmit Unit is Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set Tunnel source 2002::0001:0001, destination 2002::0002:0001 Tunnel protocol/transport IP/IPv6 Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 152 packets input, 9728 bytes 0 input error 168 packets output, bytes 0 output error [RouterB] display interface tunnel 2 106

115 Tunnel2 current state: UP Line protocol current state: UP Description: Tunnel2 Interface The Maximum Transmit Unit is Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set Tunnel source 2002::0002:0001, destination 2002::0001:0001 Tunnel protocol/transport IP/IPv6 Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last 300 seconds input: 1 bytes/sec, 0 packets/sec Last 300 seconds output: 1 bytes/sec, 0 packets/sec 167 packets input, bytes 0 input error 170 packets output, bytes 0 output error # Ping the IPv4 address of the peer interface GigabitEthernet 0/1 from Router A. [RouterA] ping PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=46 ms Reply from : bytes=56 Sequence=2 ttl=255 time=15 ms Reply from : bytes=56 Sequence=3 ttl=255 time=16 ms Reply from : bytes=56 Sequence=4 ttl=255 time=15 ms Reply from : bytes=56 Sequence=5 ttl=255 time=16 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 15/21/46 ms Configuring a DS-lite tunnel The following section describes the DS-lite tunnel configuration on the CPE and on the AFTR. Configuration prerequisites Configure IPv6 addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface). One of the interfaces will be used as the source interface of the tunnel. Configuring the CPE of a tunnel You can configure the CPE of a DS-lite tunnel or IPv4 over IPv6 manual tunnel. If you configure a DS-lite tunnel on the CPE, the CPE automatically obtains the IPv6 address of the AFTR through DHCPv6 and uses the address as the destination address of the tunnel. If you configure an IPv4 over IPv6 manual tunnel on the CPE, you must manually specify the address of the AFTR as the destination address of the tunnel. 107

116 This section describes how to configure a DS-lite tunnel on the CPE. For how to configure an IPv4 over IPv6 manual tunnel on the CPE, see Configuring an IPv4 over IPv6 manual tunnel. Follow these steps to configure the CPE of a DS-lite tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required No enabled by default. Enter tunnel interface view interface tunnel number Configure an IPv4 address for the tunnel interface Specify the DS-lite- CPE tunnel mode Configure the source interface for the tunnel interface ip address ip-address { mask mask-length } [ sub ] tunnel-protocol ipv4-ipv6 dslite-cpe source interface-type interface-number Required By default, no IPv4 address is configured for the tunnel interface. Required By default, the tunnel mode is GRE over IPv4. The tunnel mode at the other end of the tunnel should be DS-lite AFTR. Otherwise, packet delivery will fail. Required By default, no source interface is configured for the tunnel. NOTE: Tunnel interfaces using the same encapsulation protocol must have different source and destination addresses. To encapsulate and forward IPv4 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route or dynamic routing for forwarding those packets through this tunnel interface. If you configure a static route to that destination IPv4 address, specify this tunnel interface as the outbound interface, or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. If you configure dynamic routing at both ends, enable the dynamic routing protocol on both tunnel interfaces. For the detailed configuration, see Network Management Configuration Guide. If you configure a DS-lite tunnel on the CPE, you can specify the source interface but not source address for the tunnel interface. The primary IP address of the source interface is the source address of the tunnel. After you configure the source interface for the tunnel, the CPE automatically obtains the address of the AFTR through DHCPv6 and uses the address as the destination address of the tunnel. Configuring the AFTR of a tunnel Follow these steps to configure the AFTR of a DS-lite tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 packet forwarding function is disabled. 108

117 To do Use the command Remarks Enter tunnel interface view interface tunnel number Configure an IPv4 address for the tunnel interface Specify the DS-lite AFTR tunnel mode Configure the source address or interface for the tunnel interface ip address ip-address { mask mask-length } [ sub ] tunnel-protocol ipv4-ipv6 dslite-aftr source { ipv6-address interface-type interface-number } Required By default, no IPv4 address is configured for the tunnel interface. Required By default, the tunnel mode is GRE over IPv4. The tunnel mode at the other end of the tunnel should be DS-lite CPE. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. NOTE: Tunnel interfaces using the same encapsulation protocol must have different source and destination addresses. If you configure the source interface for the tunnel, the primary IP address of the source interface is the source address of the tunnel. Configuring a destination address on the AFTR is unnecessary. When receiving a packet from the tunnel, the AFTR records the source IPv6 address of the packet and uses it as the IPv6 address of the tunnel destination (address of the CPE). You must enable NAT on the AFTR s interface which is connected to the Internet. AFTR does not support static NAT mappings or VPN instance matching. If an ACL rule includes a VPN instance, the rule does not take effect. A CPE tunnel interface can establish tunnel with only one AFTR tunnel interface, but an AFTR tunnel interface can establish tunnels with multiple CPE tunnel interfaces. Configuration example Network requirements As shown in Figure 78, a private IPv4 network and a public IPv4 network are separated by an IPv6 network. Build a DS-lite tunnel between CPE (Firewall A) and AFTR (Firewall B) and configure NAT on AFTR s interface connecting to the public IPv4 network, so that hosts in the private IPv4 network can access the public IPv4 network and hosts from different private IPv4 networks can use the same IPv4 addresses. In the IPv6 network, deploy a DHCPv6 server (Firewall C) for CPE to obtain AFTR s IPv6 address. 109

118 Figure 78 Network diagram Configuration procedure NOTE: Before configuring a DS-lite tunnel, make sure that Firewall A and Firewall B are reachable to each other. In this example, Firewall A and Firewall C are in the same network segment. Otherwise, you must deploy a DHCPv6 relay agent between them. DHCPv6 relay agent is beyond the scope of this document. For more information about DHCPv6, see Network Management Configuration Guide. Configure Firewall A (the CPE) # Enable IPv6. <FirewallA> system-view [FirewallA] ipv6 # Configure an IPv4 address for interface GigabitEthernet 0/1. [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ip address [FirewallA-GigabitEthernet0/1] quit # Configure an IPv6 address for interface GigabitEthernet 0/2 (the physical interface of the tunnel). [FirewallA] interface GigabitEthernet0/2 [FirewallA- GigabitEthernet0/2] ipv6 address 1::1 64 [FirewallA- GigabitEthernet0/2] quit # Create interface Tunnel 1. [FirewallA] interface tunnel 1 # Configure an IPv4 address for interface Tunnel 1. [FirewallA-Tunnel1] ip address # Specify the tunnel encapsulation mode. [FirewallA-Tunnel1] tunnel-protocol ipv4-ipv6 dslite-cpe # Configure a source interface for Tunnel 1 [FirewallA-Tunnel1] source GigabitEthernet 0/2 [FirewallA-Tunnel1] quit # Configure a static route to the public IPv4 network. [FirewallA] ip route-static tunnel 1 Configure Firewall B (the AFTR) 110

119 # Enable IPv6. <FirewallB> system-view [FirewallB] ipv6 # Configure an IPv6 address for interface GigabitEthernet 0/1 (the physical interface of the tunnel). [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ipv6 address 1::2 64 [FirewallB-GigabitEthernet0/1] quit # Configure an IPv4 address for interface GigabitEthernet 0/2. [FirewallB] interface GigabitEthernet 0/2 [FirewallB- GigabitEthernet0/2] ip address [FirewallB- GigabitEthernet0/2] quit # Create interface Tunnel 2. [FirewallB] interface tunnel 2 # Configure an IPv4 address for interface Tunnel 2. [FirewallB-Tunnel2] ip address # Specify the tunnel encapsulation mode. [FirewallB-Tunnel2] tunnel-protocol ipv4-ipv6 dslite-aftr # Configure the source interface for interface Tunnel 2. [FirewallB-Tunnel2] source GigabitEthernet 0/1 [FirewallB-Tunnel2] quit # Configure NAT and use the IP address of interface GigabitEthernet 0/2 as the translated IP address. [FirewallB] acl number 2000 [FirewallB-acl-basic-2000] rule permit source [FirewallB-acl-basic-2000] quit [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] nat outbound 2000 [FirewallB-GigabitEthernet0/2] quit Configure Firewall C (the DHCPv6 server) # Enable IPv6. <FirewallC> system-view [FirewallC] ipv6 # Enable DHCPv6. [FirewallC] ipv6 dhcp server enable # Create address pool 1 and specify the address of the AFTR (1::2). [FirewallC] ipv6 dhcp pool 1 [FirewallC-dhcp6-pool-1] ds-lite address 1::2 [FirewallC-dhcp6-pool-1] quit # Configure the IPv6 address of interface GigabitEthernet 0/1. [FirewallC] interface GigabitEthernet 0/1 [FirewallC-GigabitEthernet0/1] ipv6 address 1::3 64 # Apply address pool 1 to the interface. [FirewallC-GigabitEthernet0/1] ipv6 dhcp server apply pool 1 111

120 Verification Display the status of the tunnel interfaces on Firewall A and Firewall B: [FirewallA] display interface tunnel 1 Tunnel1 current state: UP Line protocol current state: UP Description: Tunnel1 Interface The Maximum Transmit Unit is 1460 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 1::1 (GigabitEthernet0/2) Tunnel bandwidth 64 (kbps) Tunnel protocol/transport IP/IPv6 dslite-cpe Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 9 packets input, 540 bytes 0 input error 9 packets output, 540 bytes 0 output error [FirewallB] display interface tunnel 2 Tunnel2 current state: UP Line protocol current state: UP Description: Tunnel2 Interface The Maximum Transmit Unit is 1460 Internet Address is /24 Primary Encapsulation is TUNNEL, service-loopback-group ID not set. Tunnel source 1::2 (GigabitEthernet0/1) Tunnel bandwidth 64 (kbps) Tunnel protocol/transport IP/IPv6 dslite-aftr Output queue : (Urgent queuing : Size/Length/Discards) 0/100/0 Output queue : (Protocol queuing : Size/Length/Discards) 0/500/0 Output queue : (FIFO queuing : Size/Length/Discards) 0/75/0 Last clearing of counters: Never Last 300 seconds input: 0 bytes/sec, 0 packets/sec Last 300 seconds output: 0 bytes/sec, 0 packets/sec 65 packets input, 3900 bytes 0 input error 65 packets output, 3900 bytes 0 output error # Ping the IPv4 host on the public network from the IPv4 host on the private network: [FirewallA] ping a PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=1 ms Reply from : bytes=56 Sequence=2 ttl=255 time=1 ms Reply from : bytes=56 Sequence=3 ttl=255 time=1 ms 112

121 Reply from : bytes=56 Sequence=4 ttl=255 time=1 ms Reply from : bytes=56 Sequence=5 ttl=255 time=1 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/1/1 ms Configuring an IPv6 over IPv6 tunnel Configuration prerequisites Configure IP addresses for interfaces (such as the VLAN interface, GigabitEthernet interface, and loopback interface) on the firewall to ensure normal communication. One of the interfaces will be used as the source interface of the tunnel. Configuration procedure Follow these steps to configure an IPv6 over IPv6 tunnel: To do Use the command Remarks Enter system view system-view Enable IPv6 ipv6 Required By default, the IPv6 packet forwarding function is disabled. Enter tunnel interface view Interface tunnel number Configure an IPv6 address for the tunnel interface Configure an IPv6 global unicast address or site-local address Configure an IPv6 link-local address ipv6 address { ipv6-address prefix-length ipv6-address/prefix-length } ipv6 address ipv6-address/prefix-length eui-64 ipv6 address auto link-local ipv6 address ipv6-address link-local Required Use one of the commands. By default, no IPv6 address is configured for the tunnel interface. Specify the IPv6 over IPv6 tunnel mode Configure a source address or interface for the tunnel interface tunnel-protocol ipv6-ipv6 source { ipv6-address interface-type interface-number } Optional By default, the tunnel mode is GRE over IPv4. The same tunnel mode should be configured at both ends of the tunnel. Otherwise, packet delivery will fail. Required By default, no source address or interface is configured for the tunnel. 113

122 To do Use the command Remarks Configure the destination address for the tunnel interface Configure the maximum number of nested encapsulations of a packet destination ipv6-address encapsulation-limit [ number ] Required By default, no destination address is configured for the tunnel. Optional 4 by default. Return to system view quit Enable dropping of IPv6 packets using IPv4-compatible IPv6 addresses tunnel discard ipv4-compatible-packet Optional Disabled by default. NOTE: To encapsulate and forward IPv6 packets whose destination address does not belong to the subnet where the receiving tunnel interface resides, configure a static route or dynamic routing for forwarding those packets through this tunnel interface. If you configure a static route to that destination IPv6 address, specify this tunnel interface as the outbound interface, or the peer tunnel interface address as the next hop. A similar configuration needs to be performed at the other tunnel end. If you configure dynamic routing at both ends, enable the dynamic routing protocol on both tunnel interfaces. For the detailed configuration, see Network Management Configuration Guide. The IPv6 address of a tunnel interface must not be on the same subnet as the destination address of the tunnel. The destination address of a route with the tunnel interface as the egress interface must not be on the same subnet as the destination address of the tunnel. Two or more tunnel interfaces using the same encapsulation protocol must have different source and destination addresses. If you specify a source interface instead of a source address for the tunnel, the source address of the tunnel is the primary IP address of the source interface. Only the IPv6 over IPv6 tunnel has a maximum number of nested encapsulations for a packet. Configuration example NOTE: In this configuration example, either Router A or Router B is the firewall. Network requirements As shown in Figure 79, the two subnets Group 1 and Group 2 running IPv6 are connected over an IPv6 network. Configure an IPv6 over IPv6 tunnel between Router A and Router B to make the two subnets reachable to each other without disclosing their IPv6 addresses to the IPv6 network. 114

123 Figure 79 Network diagram Configuration procedure NOTE: Before configuring an IPv6 over IPv6 tunnel, make sure that Router A and Router B are reachable to each other. Configure Router A # Enable IPv6. <RouterA> system-view [RouterA] ipv6 # Configure an IPv6 address for GigabitEthernet 0/1. [RouterA] interface GigabitEthernet 0/1 [RouterA-GigabitEthernet0/1] ipv6 address 2002:1::1 64 [RouterA-GigabitEthernet0/1] quit # Configure an IPv6 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterA] interface GigabitEthernet 0/2 [RouterA-GigabitEthernet0/2] ipv6 address 2002::11:1 64 [RouterA-GigabitEthernet0/2] quit # Create interface Tunnel 1. [RouterA] interface tunnel 1 # Configure an IPv6 address for interface Tunnel 1. [RouterA-Tunnel1] ipv6 address 3001::1:1 64 # Configure the tunnel encapsulation mode. [RouterA-Tunnel1] tunnel-protocol ipv6-ipv6 # Configure a source address for interface Tunnel 1 (IP address of GigabitEthernet 0/2). [RouterA-Tunnel1] source 2002::11:1 # Configure a destination address for interface Tunnel 1 (IP address of GigabitEthernet 0/2 of Router B). [RouterA-Tunnel1] destination 2002::22:1 [RouterA-Tunnel1] quit # Configure a static route from Router A through interface Tunnel 1 to Group 2. [RouterA] ipv6 route-static 2002:3:: 64 tunnel 1 Configure Router B # Enable IPv6. <RouterB> system-view 115

124 Verification [RouterB] ipv6 # Configure an IPv6 address for GigabitEthernet 0/1. [RouterB] interface GigabitEthernet 0/1 [RouterB-GigabitEthernet0/1] ipv6 address 2002:3::1 64 [RouterB-GigabitEthernet0/1] quit # Configure an IPv6 address for GigabitEthernet 0/2 (the physical interface of the tunnel). [RouterB] interface GigabitEthernet 0/2 [RouterB-GigabitEthernet0/2] ipv6 address 2002::22:1 64 [RouterB-GigabitEthernet0/2] quit # Create interface Tunnel 2. [RouterB] interface tunnel 2 # Configure an IPv6 address for interface Tunnel 2. [RouterB-Tunnel2] ipv6 address 3001::1:2 64 # Configure the tunnel encapsulation mode. [RouterB-Tunnel2] tunnel-protocol ipv6-ipv6 # Configure a source address for interface Tunnel 2 (IP address of GigabitEthernet 0/2). [RouterB-Tunnel2] source 2002::22:1 # Configure a destination address for interface Tunnel 2 (IP address of GigabitEthernet 0/2 of Router A). [RouterB-Tunnel2] destination 2002::11:1 [RouterB-Tunnel2] quit # Configure a static route from Router B through interface Tunnel 2 to Group 1. [RouterB] ipv6 route-static 2002:1:: 64 tunnel 2 After the above configuration, display the status of the tunnel interfaces on Router A and Router B, respectively. [RouterA] display ipv6 interface tunnel 1 Tunnel1 current state :UP Line protocol current state :UP IPv6 is enabled, link-local address is FE80::2013:1 Global unicast address(es): 3001::1:1, subnet is 3001::/64 Joined group address(es): FF02::1:FF13:1 FF02::1:FF01:1 FF02::1:FF00:0 FF02::2 FF02::1 MTU is 1460 bytes ND reachable time is milliseconds ND retransmit interval is 1000 milliseconds Hosts use stateless autoconfig for addresses IPv6 Packet statistics:... [RouterB] display ipv6 interface tunnel 2 Tunnel2 current state :UP 116

125 Line protocol current state :UP IPv6 is enabled, link-local address is FE80::2024:1 Global unicast address(es): 3001::1:2, subnet is 3001::/64 Joined group address(es): FF02::1:FF24:1 FF02::1:FF01:2 FF02::1:FF00:0 FF02::2 FF02::1 MTU is 1460 bytes ND reachable time is milliseconds ND retransmit interval is 1000 milliseconds Hosts use stateless autoconfig for addresses IPv6 Packet statistics:... # Ping the IPv6 address of the peer interface GigabitEthernet 0/1 from Router A. [RouterA] ping ipv6 2002:3::1 PING 2002:3::1 : 56 data bytes, press CTRL_C to break Reply from 2002:3::1 bytes=56 Sequence=1 hop limit=64 time = 31 ms Reply from 2002:3::1 bytes=56 Sequence=2 hop limit=64 time = 1 ms Reply from 2002:3::1 bytes=56 Sequence=3 hop limit=64 time = 16 ms Reply from 2002:3::1 bytes=56 Sequence=4 hop limit=64 time = 16 ms Reply from 2002:3::1 bytes=56 Sequence=5 hop limit=64 time = 31 ms :3::1 ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 1/19/31 ms Displaying and maintaining tunneling configuration To do Use the command Remarks Display information about tunnel interfaces Display IPv6 information on tunnel interfaces display interface [ tunnel ] [ brief [ down ] ] [ { begin exclude include } regular-expression ] display interface tunnel number [ brief ] [ { begin exclude include } regular-expression ] display ipv6 interface tunnel [ number ] [ brief ] [ { begin exclude include } regular-expression ] Available in any view Available in any view 117

126 To do Use the command Remarks Clear statistics on tunnel interfaces reset counters interface [ tunnel [ number ] ] Available in user view Troubleshooting tunneling configuration Symptom Solution After the configuration of related parameters such as tunnel source address, tunnel destination address, and tunnel mode, the tunnel interface is still not up. Follow these steps: 1. The common cause is that the physical interface of the tunnel source is not up. Use the display interface tunnel or display ipv6 interface tunnel commands to view whether the physical interface of the tunnel source is up. If the physical interface is down, check the network connections. 2. Another possible cause is that the tunnel destination is unreachable. Use the display ipv6 routing-table or display ip routing-table command to view whether the tunnel destination is reachable. If no routing entry is available for tunnel communication in the routing table, configure related routes. 118

127 IKE configuration IKE overview Built on a framework defined by the Internet Security Association and Key Management Protocol (ISAKMP), Internet Key Exchange (IKE) provides automatic key negotiation and SA establishment services for IPsec, simplifying the application, management, configuration and maintenance of IPsec dramatically. Instead of transmitting keys directly across a network, IKE peers transmit keying materials between them, and calculate shared keys respectively. Even if a third party captures all exchanged data for calculating the keys, it cannot calculate the keys. IKE security mechanism IKE has a series of self-protection mechanisms and supports secure identity authentication, key distribution, and IPsec SA establishment on insecure networks. Data authentication DH PFS Data authentication involves two concepts: Identity authentication Mutual identity authentication between peers. Two authentication methods are available: pre-shared key authentication and PKI-based digital signature authentication (RSA signature). Identity protection Encrypts the identity information with the generated keys before sending the information. The Diffie-Hellman (DH) algorithm is a public key algorithm. With this algorithm, two peers can exchange keying material and then use the material to calculate the shared keys. Due to the decryption complexity, a third party cannot decrypt the keys even after intercepting all keying materials. The Perfect Forward Secrecy (PFS) feature is a security feature based on the DH algorithm. By making sure keys have no derivative relations, it guarantees a broken key brings no threats to other keys. For IPsec, PFS is implemented by adding an additional key exchange at IKE negotiation phase 2. IKE operation IKE negotiates keys and establishes SAs for IPsec in two phases: 1. Phase 1 The two peers establish an ISAKMP SA, a secure, authenticated channel for communication. In this phase, two modes are available: main mode and aggressive mode. 2. Phase 2 Using the ISAKMP SA established in phase 1, the two peers negotiate to establish IPsec SAs. 119

128 Figure 80 IKE exchange process in main mode As shown in Figure 80, the main mode of IKE negotiation in phase 1 involves three pairs of messages: SA exchange, used for negotiating the security policy. Key exchange, used for exchanging the Diffie-Hellman public value and other values like the random number. Key data is generated in this stage. ID and authentication data exchange, used for authentication of identity and exchanged data in phase 1. The main difference between main mode and aggressive mode is that aggressive mode does not provide identity protection and only exchanges the above three messages. Aggressive mode exchanges less information and features higher negotiation speed; it applies to scenarios where the requirement for identity protection is lower. For scenarios with higher requirement for identity protection, use the main mode. Functions of IKE in IPsec IKE provides the following functions for IPsec: Automatically negotiates IPsec parameters such as the keys, reducing the manual configuration complexity. Performs DH exchange whenever establishing an SA, making sure that each SA has a key independent of any other keys. Automatically negotiates SAs when the sequence number in the AH or ESP header overflows, making sure that IPsec provides the anti-replay service normally by using the sequence number. Provides end-to-end dynamic authentication. Identity authentication and management of peers influence IPsec deployment. A large-scale IPsec deployment needs the support of certificate authorities (CAs) or other institutes which manage identity data centrally. 120

129 Relationship between IKE and IPsec Figure 81 Relationship between IKE and IPsec Protocols Figure 81 illustrates the relationship between IKE and IPsec: IKE is an application layer protocol using UDP and functions as the signaling protocol of IPsec. IKE negotiates SAs for IPsec and delivers negotiated parameters and generated keys to IPsec. IPsec uses the SAs set up through IKE negotiation for encryption and authentication of IP packets. IKE related protocols include: RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) RFC2409, The Internet Key Exchange (IKE) RFC2412, The OAKLEY Key Determination Protocol IKE configuration prerequisites Before configuring IKE, you must determine the following parameters: The strength of the algorithms for IKE negotiation, namely the security protection level, including the identity authentication method, encryption algorithm, authentication algorithm, and DH group. Different algorithms provide different levels of protection. A stronger algorithm means more resistant to decryption of protected data but requires more resources. Generally, the longer the key, the stronger the algorithm. The pre-shared key or the PKI domain that the certificate belongs to. For more information about PKI configuration, see the chapter Certificate and Public Key Configuration. 121

130 Configuring IKE in the web interface Table 7 IKE configuration task list Task Configuring global IKE parameters Remarks Optional Configure the IKE local name and NAT keepalive interval. Required when IKE peers need to specify an IKE proposal. An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You may create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented by its sequence number, and the smaller the sequence number, the higher the preference. Configuring an IKE proposal Two peers must have at least one pair of matched IKE proposals for successful IKE negotiation. During IKE negotiation, the negotiation initiator sends its IKE proposals to the peer. The peer will match the IKE proposals against its own IKE proposals, starting with the one with the smallest sequence number. The match goes on until a match is found or all IKE proposals are found mismatched. The matched IKE proposals will be used to establish the security tunnel. Two matched IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The ISAKMP SA lifetime will take the smaller one of the two matched IKE proposals. By default, there is an IKE proposal, which has the lowest preference and uses these default settings: Authentication method Pre-shared key Authentication algorithm SHA Encryption algorithm DES-CBC DH group Group1 SA lifetime seconds Optional Configuring IKE DPD DPD irregularly detects dead IKE peers. When the local end sends an IPsec packet, DPD checks the time the last IPsec packet was received from the peer. If the time exceeds the DPD interval, it sends a DPD hello to the peer. If the local end receives no DPD acknowledgement within the DPD packet retransmission interval, it retransmits the DPD hello. If the local end still receives no DPD acknowledgement after having made the maximum number of retransmission attempts (two by default), it considers the peer already dead, and clears the IKE SA and the IPsec SAs based on the IKE SA. Required Create an IKE peer and configure the related parameters. Configuring an IKE peer Viewing IKE SAs IMPORTANT: If you change the settings of an IKE peer, be sure to clear the established IPsec SAs and ISAKMP SAs on the pages displayed after you select VPN > IKE > IKE SA and select VPN > IPSec > IPSec SA respectively. Otherwise, SA renegotiation will fail. Optional View the summary information of the current ISAKMP SA. 122

131 Configuring global IKE parameters 1. Select VPN > IKE > Global from the navigation tree to enter IKE global configuration page. Figure 82 IKE global configuration page 2. Configure global IKE parameters as described in Table Click Apply. Table 8 Configuration items Item IKE Local Name NAT Keepalive Interval Description Enter a name for the local security gateway. If the local device acts as the IKE negotiation initiator and uses the ID type of Fully Qualified Domain Name (FQDN) or the user FQDN of the security gateway for IKE negotiation, you need to configure this argument on the local device. Then, the local device sends its gateway name as identification to its peer and the peer uses the locally configured remote gateway name to authenticate the local device. Make sure that the local gateway name configured here is identical to the remote gateway name configured on its peer. By default, the device name is used as the local gateway name. Set the interval at which the ISAKMP SA sends NAT keepalive packets to its peer. NAT mappings on a NAT gateway may get aged. If no packet traverses an IPsec tunnel in a certain period of time, the NAT mapping will be deleted, disabling the tunnel beyond the NAT gateway from transferring data. To prevent NAT mappings from being aged, an ISAKMP SA sends to its peer NAT keepalive packets at a certain interval to keep the NAT session alive. Configuring an IKE proposal 1. Select VPN > IKE > Proposal from the navigation tree to display existing IKE proposals. Figure 83 IKE proposal list 123

132 2. Click Add to enter the IKE proposal configuration page. Figure 84 Add an IKE proposal 3. Configure an IKE proposal as described in Table Click Apply. Table 9 Configuration items Item IKE Proposal Number Authentication Method Authentication Algorithm Encryption Algorithm DH Group Description Enter the IKE proposal number. The number also stands for the priority of the IKE proposal, with a smaller value meaning a higher priority. During IKE negotiation, the system matches IKE proposals in order of proposal number, starting from the smallest one. Select the authentication method to be used by the IKE proposal. Options include: Preshared Key Uses the pre-shared key method. RSA Signature Uses the RSA digital signature method. Select the authentication algorithm to be used by the IKE proposal. Options include: SHA1 Uses HMAC-SHA1. MD5 Uses HMAC-MD5. Select the encryption algorithm to be used by the IKE proposal. Options include: DES-CBC Uses the DES algorithm in CBC mode and 56-bit keys for encryption. 3DES-CBC Uses the 3DES algorithm in CBC mode and 168-bit keys for encryption. AES-128 Uses the AES algorithm in CBC mode and 128-bit keys for encryption. AES-192 Uses the AES algorithm in CBC mode and 192-bit keys for encryption. AES-256 Uses the AES algorithm in CBC mode and 256-bit keys for encryption. Select the DH group to be used in key negotiation phase 1. Options include: Group1 Uses the 768-bit Diffie-Hellman group. Group2 Uses the 1024-bit Diffie-Hellman group. Group5 Uses the 1536-bit Diffie-Hellman group. Group14 Uses the 2048-bit Diffie-Hellman group. 124

133 Item SA Lifetime Description Enter the ISAKMP SA lifetime of the IKE proposal. Before an SA expires, IKE negotiates a new SA. As soon as the new SA is set up, it takes effect immediately and the old one will be cleared automatically when it expires. IMPORTANT: If the SA lifetime expires, the system automatically updates the ISAKMP SA. DH calculation in IKE negotiation takes time, especially on low-end devices. Set the lifetime greater than 10 minutes to prevent the SA update from influencing normal communication. Configuring IKE DPD 1. Select VPN > IKE > DPD from the navigation tree to display existing DPD detectors. Figure 85 DPD detector list 2. Click Add to enter the DPD configuration page. Figure 86 Add an IKE DPD detector 3. Configure an IKE DPD as described in Table Click Apply. Table 10 Configuration items Item DPD Name DPD Query Triggering Interval DPD Packet Retransmission Interval Description Enter a name for the IKE DPD. Enter the interval after which DPD is triggered if no IPsec protected packets is received from the peer. Enter the interval after which DPD packet retransmission will occur if no DPD response is received. 125

134 Configuring an IKE peer 1. Select VPN > IKE > Peer from the navigation tree to display existing IKE peers. Figure 87 IKE peer list 2. Click Add to enter the IKE peer configuration page. Figure 88 Add an IKE peer 3. Configure an IKE peer as described in Table Click Apply. 126

135 Table 11 Configuration items Item Peer Name Description Enter a name for the IKE peer. Select the IKE negotiation mode in phase 1, which can be Main or Aggressive. IKE Negotiation Mode Local ID Type IMPORTANT: If one end of an IPsec tunnel is configured to obtain an IP address dynamically, the IKE negotiation mode must be Aggressive. In this case, SAs can be established as long as the username and password are correct. The specified negotiated mode is used when the local peer is the negotiation initiator. When acting as the responder, the negotiation mode of the initiator is used. Select the local ID type for IKE negotiation phase 1. Options include: IP Address Uses an IP address as the ID in IKE negotiation. FQDN Uses the FQDN type as the ID in IKE negotiation. If this option is selected, enter a name string without any at sign (@) for the local security gateway, for example, foo.bar.com. User FQDN Uses a user FQDN type as the ID in IKE negotiation. If this option is selected, enter a name string with an at sign (@) for the local security gateway, for example, test@foo.bar.com. IMPORTANT: In main mode, only the ID type of IP address can be used in IKE negotiation and SA establishment. Enter the IP address of the local security gateway. By default, it is the primary IP address of the interface referencing the security policy. Configure this item when you want to specify a special address for the local security gateway Local IP Address IMPORTANT: Remote Gateway IP Address Hostname Normally, you do not need to specify the local IP address unless you want to specify a special address, such as the loopback interface address. For the local peer to act as the initiator, you need to configure the remote security gateway name or IP address, so that the initiator can find the remote peer during the negotiation. Enter the IP address or host name of the remote security gateway. You can specify an IP address or a range of IP addresses for the remote gateway. If the local end is the initiator of IKE negotiation, it can have only one remote IP address and its remote IP address must match the local IP address configured on its peer. If the local end is the responder of IKE negotiation, it can have more than one remote IP address and one of its remote IP addresses must match the local IP address configured on its peer. The host name of the remote gateway is the only identifier of the IPsec peer in the network. The host name can be resolved into an IP address by the DNS server. If host name is used, the local end can serve as the initiator of IKE negotiation. 127

136 Item Remote ID Pre-Shared Key PKI Domain Enable DPD Enable the NAT traversal function Description Enter the name of the remote security gateway. If the local ID type configured for the IKE negotiation initiator is FQDN or user FQDN, the initiator sends its gateway name (IKE Local Name) to the responder for identification. The responder then uses the locally configured remote gateway name (Remote ID) to authenticate the initiator. Make sure that the remote gateway name configured here is identical to the local gateway name (IKE Local Name) configured on its peer. To use the authentication method of pre-shared key, select Pre-Shared Key and then enter the pre-shared key in the following field. To use the authentication method of RSA signature, select PKI Domain and then select the PKI domain to which the certificate belongs in the following drop-down box. Available PKI domains are those configured on the page you enter by selecting VPN > Certificate Manager > Domain from the navigation tree. Select the IKE DPD to be applied to the IKE peer. Enable the NAT traversal function for IPsec/IKE. The NAT traversal function must be enabled if a NAT security gateway exists in an IPsec/IKE VPN tunnel. In main mode, IKE does not support NAT traversal and this item is unavailable. IMPORTANT: To save IP addresses, ISPs often deploy NAT gateways on public networks to allocate private IP addresses to users. In this case, one end of an IPsec/IKE tunnel may have a public address while the other end may have a private address, and NAT traversal must be configured at the private network side to set up the tunnel. Viewing IKE SAs Select VPN > IKE > IKE SA from the navigation tree to display brief information about established ISAKMP SAs, as shown in Figure 89. You can click Delete All to remove all ISAKMP SAs. When you clear a local IPsec SA, if the corresponding ISAKMP SA is still present, the local end will send a Delete Message to the remote end across the ISAKMP SA, notifying the remote end to delete the IPsec SA. If the corresponding ISAKMP SA is no longer present, the local end cannot notify the remote end to clear the IPsec SA. Figure 89 IKE SA list 128

137 Table 12 Field description Field Connection ID Remote IP Address Flag Description Identifier of the ISAKMP SA Remote IP address of the SA Status of the SA. Possible values include: RD (ready) Indicates that the SA has already been established and is ready for use. ST (stayalive) Indicates that the local end is the tunnel negotiation initiator. RL (replaced) Indicates that the tunnel has been replaced and will be cleared soon. FD (fading) Indicates that the soft lifetime expires but the tunnel is still in use. The tunnel will be deleted when the hard lifetime expires. TO (timeout) Indicates the SA has received no keepalive packets after the last keepalive timeout. If no keepalive packets are received before the next keepalive timeout, the SA will be deleted. IMPORTANT: IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured with the keepalive timeout, you must configure the keepalive packet transmission interval on the local end. If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA will be tagged with the TIMEOUT tag (if it does not have the tag), or be deleted along with the IPsec SAs it negotiated (when it has the tag already). Domain of Interpretation Interpretation domain that the SA belongs to IKE configuration example in the web interface NOTE: In this configuration example, either Device A or Device B is the firewall. Network requirements As shown in Figure 90, configure an IPsec tunnel that uses IKE negotiation between the security gateways Device A and Device B to allow secure communication between Host A and Host B. For Device A, configure an IKE proposal that uses the sequence number 10 and the authentication algorithm MD5. Leave Device B with only the default IKE proposal. Configure the two devices to use the pre-shared key authentication method. 129

138 Figure 90 Network diagram Configuration procedure 1. Configure security gateway Device A # Configure the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add. The IKE peer configuration page appears, as shown in Figure 91. Figure 91 Configure the IKE peer Perform the following operations on the page: 130

139 Enter peer as the peer name. Select Main as the negotiation mode. Enter as the remote gateway IP address. Select Pre-Shared Key and enter abcde as the pre-shared key. Click Apply. # Create an IKE proposal numbered 10. Select VPN > IKE > Proposal from the navigation tree and then click Add. The IKE proposal configuration page appears, as shown in Figure 92. Figure 92 Create an IKE proposal numbered 10 Perform the following operations on the page: Enter 10 as the IKE proposal number. Select Preshared Key as the authentication method. Select MD5 as the authentication algorithm. Enter 5000 as the SA lifetime. Click Apply. 2. Configure security gateway Device B # Configure the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add to enter the IKE peer configuration page, as shown in Figure 91. Perform the following operations on the page: Enter peer as the peer name. Select Main as the negotiation mode. Enter as the remote gateway IP address. Select Pre-Shared Key and enter abcde as the pre-shared key. Click Apply. After you complete the configuration, security gateways Device A and Device B should be able to perform IKE negotiation. Device A is configured with an IKE proposal numbered 10, which uses the authentication algorithm of MD5; but Device B has only a default IKE proposal, which uses the default authentication algorithm of SHA. Device B has no proposal matching proposal 10 of Device A, and the 131

140 two devices have only one pair of matched proposals, namely the default IKE proposals. The two devices do not need to have the same ISAKMP SA lifetime; they will negotiate one. Configuring IKE at the CLI IKE configuration task list Task Configuring a name for the local security gateway Configuring an IKE proposal Configuring an IKE peer Setting keepalive timers Setting the NAT keepalive timer Configuring a DPD detector Disabling next payload field checking Remarks Optional Optional Required if you want to specify an IKE proposal for an IKE peer to reference. Required Optional Optional Optional Optional Configuring a name for the local security gateway If the IKE negotiation peer uses the security gateway name as its ID to initiate IKE negotiation (that is, the id-type name or id-type user-fqdn command is configured on the initiator), configure the ike local-name command in system view or the local-name command in IKE peer view on the local device. If you configure both commands, the name configured by in IKE peer view is used. Follow these steps to configure a name for the local security gateway: To do Use the command Remarks Enter system view system-view Configure a name for the local security gateway ike local-name name Optional By default, the device name is used as the name of the local security gateway. Configuring an IKE proposal An IKE proposal defines a set of attributes describing how IKE negotiation should take place. You may create multiple IKE proposals with different preferences. The preference of an IKE proposal is represented by its sequence number, and the lower the sequence number, the higher the preference. Two peers must have at least one matching IKE proposal for successful IKE negotiation. During IKE negotiation, the initiator sends its IKE proposals to the peer, and the peer searches its own IKE proposals for a match. The search starts from the one with the lowest sequence number and proceeds in the ascending order of sequence number until a match is found or all the IKE proposals are found mismatching. The matching IKE proposals will be used to establish the secure tunnel. 132

141 Two matching IKE proposals have the same encryption algorithm, authentication method, authentication algorithm, and DH group. The SA lifetime will take the smaller one of the settings on the two sides. By default, there is an IKE proposal, which has the lowest preference and uses the default encryption algorithm, authentication method, authentication algorithm, DH group, and ISAKMP SA lifetime. Follow these steps to configure an IKE proposal: To do Use the command Remarks Enter system view system-view Create an IKE proposal and enter its view Specify an encryption algorithm for the IKE proposal Specify an authentication method for the IKE proposal Specify an authentication algorithm for the IKE proposal Specify a DH group for key negotiation in phase 1 Set the ISAKMP SA lifetime for the IKE proposal ike proposal proposal-number encryption-algorithm { 3des-cbc aes-cbc [ key-length ] des-cbc } authentication-method { pre-share rsa-signature } authentication-algorithm { md5 sha } dh { group1 group2 group5 group14 } sa duration seconds Required Optional 56-bit DES by default Optional Pre-shared key by default Optional SHA1 by default Optional group1, namely the 768-bit DH group, by default Optional seconds by default NOTE: Before an ISAKMP SA expires, IKE negotiates a new SA to replace it. DH calculation in IKE negotiation takes time, especially on low-end devices. To prevent SA updates from influencing normal communication, set the lifetime greater than 10 minutes. Configuring an IKE peer For an IPsec policy that uses IKE, you must configure an IKE peer by performing the following tasks: Specify the IKE negotiation mode for the local end to use in IKE negotiation phase 1. If the IP address of the remote end is obtained dynamically, the IKE negotiation mode of the local end must be aggressive. When acting as the IKE negotiation responder, the local end uses the IKE negotiation mode of the remote end. Specify the IKE proposals for the local end to use when acting as the IKE negotiation initiator. When acting as the responder, the local end uses the IKE proposals configured in system view for negotiation. Configure a pre-shared key for pre-shared key authentication or a PKI domain for digital signature authentication. Specify the ID type for the local end to use in IKE negotiation phase 1. With pre-shared key authentication, the ID type must be IP address for main mode IKE negotiation and can be IP address, FQDN, or user FQDN for aggressive mode IKE negotiation. Specify the name or IP address of the local security gateway. You perform this task only when you want to specify a special address, a loopback interface address, for example, as the local security gateway address. 133

142 Specify the name or IP address of the remote security gateway. For the local end to initiate IKE negotiation, you must specify the name or IP address of the remote security gateway on the local end so the local end can find the remote end. Enable NAT traversal. If there is NAT gateway on the path for tunneling, you must configure NAT traversal at the two ends of the IPsec tunnel, because one end may use a public address while the other end uses a private address. Specify the dead peer detection (DPD) detector for the IKE peer. Follow these steps to configure an IKE peer: To do Use the command Remarks Enter system view system-view Create an IKE peer and enter IKE peer view Specify the IKE negotiation mode for phase 1 Specify the IKE proposals for the IKE peer to reference Configure the pre-shared key for pre-shared key authentication Configure the PKI domain for digital signature authentication Select the ID type for IKE negotiation phase 1 ike peer peer-name exchange-mode { aggressive main } proposal proposal-number&<1-6> pre-shared-key [ cipher simple ] key certificate domain domain-name id-type { ip name user-fqdn } Required Optional main by default Optional By default, an IKE peer references no IKE proposals, and, when initiating IKE negotiation, it uses the IKE proposals configured in system view. Required Configure either command according to the authentication method for the IKE proposal Optional ip by default Optional Configure the names of the two ends Specify a name for the local security gateway Configure the name of the remote security gateway local-name name remote-name name By default, no name is configured for the local security gateway in IKE peer view, and the security gateway name configured by using the ike local-name command is used. The remote gateway name configured with remote-name command on the local gateway must be identical to the local name configured with the local-name command on the peer. Configure the IP addresses of the two ends Specify an IP address for the local gateway local-address ip-address Optional By default, it is the primary IP address of the interface referencing the security policy. The remote IP address configured 134

143 To do Use the command Remarks Configure the IP addresses of the remote gateway remote-address { hostname [ dynamic ] low-ip-address [ high-ip-address ] } with the remote-address command on the local gateway must be identical to the local IP address configured with the local-address command on the peer. Optional Enable the NAT traversal function for IPsec/IKE nat traversal Required when a NAT gateway is present in the VPN tunnel constructed by IPsec/IKE Disabled by default Set the subnet types of the two ends Set the subnet type of the local end Set the subnet type of the peer end local { multi-subnet single-subnet } peer { multi-subnet single-subnet } Optional single-subnet by default Used only when the device is working together with a NetScreen device. Optional Apply a DPD detector to the IKE peer dpd dpd-name No DPD detector is applied to an IKE peer by default. For more information about DPD configuration, see Configuring a DPD detector. NOTE: After modifying the configuration of an IPsec IKE peer, execute the reset ipsec sa and reset ike sa commands to clear existing IPsec and IKE SAs. Otherwise, SA re-negotiation will fail. Setting keepalive timers IKE maintains the link status of an ISAKMP SA by keepalive packets. Generally, if the peer is configured with the keepalive timeout, you need to configure the keepalive packet transmission interval on the local end. If the peer receives no keepalive packet during the timeout interval, the ISAKMP SA will be tagged with the TIMEOUT tag (if it does not have the tag), or be deleted along with the IPsec SAs it negotiated (when it has the tag already). Follow these steps to set the keepalive timers: To do Use the command Remarks Enter system view system-view Set the ISAKMP SA keepalive interval Set the ISAKMP SA keepalive timeout ike sa keepalive-timer interval seconds ike sa keepalive-timer timeout seconds Required No keepalive packet is sent by default. Required No keepalive packet is sent by default. 135

144 NOTE: The keepalive timeout configured at the local end must be longer than the keepalive interval configured at the remote end. Since it seldom occurs that more than three consecutive packets are lost on a network, the keepalive timeout can be configured to be three times of the keepalive interval. Setting the NAT keepalive timer If IPsec traffic needs to pass through NAT security gateways, you need to configure the NAT traversal function. If no packet travels across an IPsec tunnel in a certain period of time, the NAT mapping may get aged and be deleted, disabling the tunnel beyond the NAT gateway from transmitting data to the intended end. To prevent NAT mappings from being aged, an ISAKMP SA behind the NAT security gateway sends NAT keepalive packets to its peer at a certain interval to keep the NAT session alive. Follow these steps to set the NAT keepalive timer: To do Use the command Remarks Enter system view system-view Set the NAT keepalive interval ike sa nat-keepalive-timer interval seconds Required 20 seconds by default Configuring a DPD detector Dead peer detection (DPD) irregularly detects dead IKE peers. It works as follows: 1. When the local end sends an IPsec packet, it checks the time the last IPsec packet was received from the peer. 2. If the time interval exceeds the DPD interval, it sends a DPD hello to the peer. 3. If the local end receives no DPD acknowledgement within the DPD packet retransmission interval, it retransmits the DPD hello. 4. If the local end still receives no DPD acknowledgement after having made the maximum number of retransmission attempts (two by default), it considers the peer already dead, and clears the IKE SA and the IPsec SAs based on the IKE SA. DPD enables an IKE entity to check the liveliness of its peer only when necessary. It generates less traffic than the keepalive mechanism, which exchanges messages periodically. Follow these steps to configure a DPD detector: To do Use the command Remarks Enter system view system-view Create a DPD detector and enter its view Set the DPD interval Set the DPD packet retransmission interval ike dpd dpd-name interval-time interval-time time-out time-out Required Optional 10 seconds by default Optional 5 seconds by default 136

145 Disabling next payload field checking The Next payload field is in the generic payload header of the last payload of the IKE negotiation message (the message comprises multiple payloads). According to the protocol, this field must be 0 if the payload is the last payload of the packet. However, it may be set to other values on some brands of devices. For interoperability, disable the checking of this field. Follow these steps to disable Next payload field checking: To do Use the command Remark Enter system view system-view Disable Next payload field checking ike next-payload check disabled Required Enabled by default Displaying and maintaining IKE To do Use the command Remarks Display IKE DPD information Display IKE peer information Display IKE SA information Display IKE proposal information display ike dpd [ dpd-name ] [ { begin exclude include } regular-expression ] display ike peer [ peer-name ] [ { begin exclude include } regular-expression ] display ike sa [ verbose [ connection-id connection-id remote-address remote-address ] ] [ { begin exclude include } regular-expression ] display ike proposal [ { begin exclude include } regular-expression ] Available in any view Available in any view Available in any view Available in any view Clear SAs established by IKE reset ike sa [ connection-id ] Available in user view IKE configuration examples at the CLI Main mode IKE with pre-shared key authentication configuration example Network requirements As shown in Figure 93, configure an IPsec tunnel that uses IKE negotiation between Firewall A and Firewall B to secure the communication between subnet /24 and subnet /24. For Firewall A, configure an IKE proposal that uses the sequence number 10 and authentication algorithm MD5. Leave Firewall B with only the default IKE proposal. Configure the two firewalls to use the pre-shared key authentication method. 137

146 Figure 93 Network diagram Configuring Firewall A NOTE: Make sure that Firewall A and Firewall B can reach each other. # Configure ACL 3101 to identify traffic from subnet /24 to subnet /24. <FirewallA> system-view [FirewallA] acl number 3101 [FirewallA-acl-adv-3101] rule permit ip source destination [FirewallA-acl-adv-3101] quit # Create IPsec proposal tran1. [FirewallA] ipsec proposal tran1 # Set the packet encapsulation mode to tunnel. [FirewallA-ipsec-proposal-tran1] encapsulation-mode tunnel # Use security protocol ESP. [FirewallA-ipsec-proposal-tran1] transform esp # Specify encryption and authentication methods. [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Create IKE peer peer. [FirewallA] ike peer peer # Set the pre-shared key. [FirewallA-ike-peer-peer] pre-shared-key abcde # Specify the IP address of the peer security gateway. [FirewallA-ike-peer-peer] remote-address [FirewallA-ike-peer-peer] quit # Create an IKE proposal numbered 10. [FirewallA] ike proposal 10 # Set the authentication algorithm to MD5. [FirewallA-ike-proposal-10] authentication-algorithm md5 138

147 # Set the authentication method to pre-shared key. [FirewallA-ike-proposal-10] authentication-method pre-share # Set the ISAKMP SA lifetime to 5,000 seconds. [FirewallA-ike-proposal-10] sa duration 5000 [FirewallA-ike-proposal-10] quit # Create an IPsec policy that uses IKE negotiation. [FirewallA] ipsec policy map1 10 isakmp # Reference IPsec proposal tran1. [FirewallA-ipsec-policy-isakmp-map1-10] proposal tran1 # Reference ACL 3101 to identify the protected traffic. [FirewallA-ipsec-policy-isakmp-map1-10] security acl 3101 # Reference IKE peer peer. [FirewallA-ipsec-policy-isakmp-map1-10] ike-peer peer [FirewallA-ipsec-policy-isakmp-map1-10] quit # Assign an IP address to interface GigabitEthernet 0/2. [FirewallA] interface GigabitEthernet 0/2 [FirewallA-GigabitEthernet0/2] ip address [FirewallA-GigabitEthernet0/2] quit # Assign an IP address to interface GigabitEthernet 0/1. [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ip address # Apply the IPsec policy to interface GigabitEthernet 0/1. [FirewallA-GigabitEthernet0/1] ipsec policy map1 # Configure a static route to subnet /24. [FirewallA] ip route-static Configuring Firewall B # Configure ACL 3101 to identify traffic from subnet /24 to subnet /24. <FirewallB> system-view [FirewallB] acl number 3101 [FirewallB-acl-adv-3101] rule permit ip source destination [FirewallB-acl-adv-3101] quit [FirewallB] ipsec proposal tran1 # Create IPsec proposal tran1. [FirewallB] ipsec proposal tran1 # Set the packet encapsulation mode to tunnel. [FirewallB-ipsec-proposal-tran1] encapsulation-mode tunnel # Use security protocol ESP. [FirewallB-ipsec-proposal-tran1] transform esp # Specify encryption and authentication methods. [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit 139

148 # Create IKE peer peer. [FirewallB] ike peer peer # Set the pre-shared key. [FirewallB-ike-peer-peer] pre-shared-key abcde # Specify the IP address of the peer security gateway. [FirewallB-ike-peer-peer] remote-address [FirewallB-ike-peer-peer] quit # Create an IPsec policy that uses IKE negotiation. [FirewallB] ipsec policy use1 10 isakmp # Reference ACL 3101 to identify the protected traffic. [FirewallB-ipsec-policy-isakmp-use1-10] security acl 3101 # Reference IPsec proposal tran1. [FirewallB-ipsec-policy-isakmp-use1-10] proposal tran1 # Reference IKE peer peer. [FirewallB-ipsec-policy-isakmp-use1-10] ike-peer peer [FirewallB-ipsec-policy-isakmp-use1-10] quit # Assign an IP address to interface GigabitEthernet 0/2. [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address [FirewallB-GigabitEthernet0/2] quit # Assign an IP address to interface GigabitEthernet 0/1. [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ip address # Apply the IPsec policy to interface GigabitEthernet 0/1. [FirewallB-GigabitEthernet0/1] ipsec policy use1 # Configure a static route to subnet /24. [FirewallB] ip route-static Verifying the configuration # Check the IKE proposal configuration. [FirewallA] display ike proposal priority authentication authentication encryption Diffie-Hellman duration method algorithm algorithm group (seconds) PRE_SHARED MD5 DES_CBC MODP_ default PRE_SHARED SHA DES_CBC MODP_ [FirewallA] display ike proposal priority authentication authentication encryption Diffie-Hellman duration method algorithm algorithm group (seconds) default PRE_SHARED SHA DES_CBC MODP_ Firewall A and Firewall B has only one pair of matching IKE proposals. Matching IKE proposals do not necessarily use the same ISAKMP SA lifetime setting. 140

149 # Send traffic from subnet /24 to subnet /24. Firewall A starts IKE negotiation with Firewall B when receiving the first packet. # View the SAs established in the two IKE negotiation phases. [FirewallA] display ike sa total phase-1 SAs: 1 connection-id peer flag phase doi RD ST 1 IPSEC RD ST 2 IPSEC flag meaning RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT # Display information about the established IPsec SAs, which protect traffic between subnet /24 and subnet /24. [FirewallA] display ipsec sa =============================== Interface: GigabitEthernet0/1 path MTU: 1500 =============================== IPsec policy name: "map1" sequence number: 10 mode: isakmp connection id: 1 encapsulation mode: tunnel perfect forward secrecy: tunnel: local address: remote address: flow: sour addr: / port: 0 protocol: IP dest addr: / port: 0 protocol: IP [inbound ESP SAs] spi: (0x3d6d3a62) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3590 max received sequence-number: 4 anti-replay check enable: Y anti-replay window size: 32 udp encapsulation used for nat traversal: N [outbound ESP SAs] spi: (0x553faae) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 141

150 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3590 max received sequence-number: 5 udp encapsulation used for nat traversal: N Aggressive mode IKE with NAT traversal configuration example Network requirements As shown in Figure 94, the branch and the headquarters connect to an ATM network through a router and a firewall, respectively. The router connects to the public network through an ADSL line and acts as the PPPoE client. The interface connecting to the public network uses a private address dynamically assigned by the ISP. The Firewall uses a fixed public IP address for the interface connected to the public network. Configure IPsec tunnels between the router and Firewall to protect traffic between the branch and its headquarters. Use IKE to establish the IPsec tunnels. Figure 94 Network diagram GE0/ /24 ADSL line ATM 1/0 Router PPPoE client NAT IP network GE0/ /24 Firewall GE0/ /24 Branch Headquarters Configuring the Firewall NOTE: The IKE negotiation mode must be aggressive because Router uses a dynamic IP address. You must configure NAT traversal at both ends of the IPsec tunnel because one end of the tunnel uses a public IP address but the other end uses a private IP address. # Specify a name for the local security gateway. <Firewall> system-view [Firewall] ike local-name Firewall # Configure an ACL. [Firewall] acl number 3101 [Firewall-acl-adv-3101] rule 0 permit ip source destination [Firewall-acl-adv-3101] quit # Configure an IKE proposal. [Firewall] ike proposal 1 [Firewall-ike-proposal-1] authentication-algorithm sha [Firewall-ike-proposal-1] authentication-method pre-share 142

151 [Firewall-ike-proposal-1] encryption-algorithm 3des-cbc [Firewall-ike-proposal-1] dh group2 # Configure an IKE peer. [Firewall] ike peer peer [Firewall-ike-peer-peer] exchange-mode aggressive [Firewall-ike-peer-peer] pre-shared-key abc [Firewall-ike-peer-peer] id-type name [Firewall-ike-peer-peer] remote-name routerb [Firewall-ike-peer-peer] nat traversal [Firewall-ike-peer-peer] quit # Configure an IPsec proposal named prop. [Firewall] ipsec proposal prop [Firewall-ipsec-proposal-prop] encapsulation-mode tunnel [Firewall-ipsec-proposal-prop] transform esp [Firewall-ipsec-proposal-prop] esp encryption-algorithm 3des [Firewall-ipsec-proposal-prop] esp authentication-algorithm sha1 [Firewall-ipsec-proposal-prop] quit # Create an IPsec policy, specifying to set up SAs through IKE negotiation. [Firewall] ipsec policy policy 10 isakmp # Configure the IPsec policy to reference the IKE peer. [Firewall-ipsec-policy-isakmp-policy-10] ike-peer peer # Configure the IPsec policy to reference ACL [Firewall-ipsec-policy-isakmp-policy-10] security acl 3101 # Configure the IPsec policy to reference IPsec proposal prop. [Firewall-ipsec-policy-isakmp-policy-10] proposal prop [Firewall-ipsec-policy-isakmp-policy-10] quit # Configure the IP address of interface GigabitEthernet 0/2 and apply the IPsec policy to the interface. [Firewall] interface GigabitEthernet 0/2 [Firewall-GigabitEthernet0/2] ip address [Firewall-GigabitEthernet0/2] ipsec policy policy [Firewall-GigabitEthernet0/2] quit # Configure the IP address of interface GigabitEthernet 0/1. [Firewall] interface GigabitEthernet 0/1 [Firewall-GigabitEthernet0/1] ip address [Firewall-GigabitEthernet0/1] quit # Configure a static route to the branch LAN. [FirewallA] ip route-static GigabitEthernet 0/2 Configuring the router # Specify a name for the local security gateway. <Router> system-view [Router] ike local-name routerb # Configure an ACL. [Router] acl number

152 [Router-acl-adv-3101] rule 0 permit ip source destination [Router-acl-adv-3101] quit # Configure an IKE proposal. [Router] ike proposal 1 [Router-ike-proposal-1] authentication-algorithm sha [Router-ike-proposal-1] authentication-method pre-share [Router-ike-proposal-1] encryption-algorithm 3des-cbc [Router-ike-proposal-1] dh group2 # Configure an IKE peer. [Router] ike peer peer [Router-ike-peer-peer] exchange-mode aggressive [Router-ike-peer-peer] pre-shared-key abc [Router-ike-peer-peer] id-type name [Router-ike-peer-peer] remote-name Firewall [Router-ike-peer-peer] remote-address [Router-ike-peer-peer] nat traversal [Router-ike-peer-peer] quit # Create an IPsec proposal named prop. [Router] ipsec proposal prop [Router-ipsec-proposal-prop] encapsulation-mode tunnel [Router-ipsec-proposal-prop] transform esp [Router-ipsec-proposal-prop] esp encryption-algorithm 3des [Router-ipsec-proposal-prop] esp authentication-algorithm sha1 [Router-ipsec-proposal-prop] quit # Create an IPsec policy that uses IKE. [Router] ipsec policy policy 10 isakmp # Configure the IPsec policy to reference the IKE peer. [Router-ipsec-policy-isakmp-policy-10] ike-peer peer # Configure the IPsec policy to reference ACL [Router-ipsec-policy-isakmp-policy-10] security acl 3101 # Configure the IPsec policy to reference IPsec proposal prop. [Router-ipsec-policy-isakmp-policy-10] proposal prop [Router-ipsec-policy-isakmp-policy-10] quit # Create a dialer rule. [Router] dialer-rule 1 ip permit # Configure dialer interface Dialer 0. Use the username and password assigned by the ISP for dial and PPP authentication. [Router] interface dialer 0 [Router-Dialer0] link-protocol ppp [Router-Dialer0] ppp pap local-user test password simple [Router-Dialer0] ip address ppp-negotiate [Router-Dialer0] dialer user 1 [Router-Dialer0] dialer-group 1 [Router-Dialer0] dialer bundle 1 144

153 [Router-Dialer0] ipsec policy policy [Router-Dialer0] mtu 1492 [Router-Dialer0] quit # Configure a static route to the headquarters LAN. [Router] ip route-static dialer 0 # Configure interface GigabitEthernet 0/1. [Router] interface GigabitEthernet 0/1 [Router-GigabitEthernet0/1] tcp mss 1450 [Router-GigabitEthernet0/1] ip address [Router-GigabitEthernet0/1] quit # Create a virtual Ethernet interface, and create a PPPoE session that uses dialer bundle 1 on the interface. [Router] interface virtual-ethernet 0 [Router-Virtual-Ethernet0] pppoe-client dial-bundle-number 1 [Router-Virtual-Ethernet0] mac-address # Map the virtual Ethernet interface to a PVC on interface ATM 1/0. [Router] interface atm 1/0 [Router-Atm1/0] pvc 0/100 [Router-atm-pvc-Atm1/0-0/100] map bridge virtual-ethernet 0 [Router-atm-pvc-Atm1/0-0/100] quit Troubleshooting IKE When you configure parameters to establish an IPsec tunnel, enable IKE error debugging to locate configuration problems: <Firewall> debugging ike error Invalid user ID Symptom Analysis Solution Invalid user ID. In IPsec, user IDs are used to identify data flows and to set up different IPsec tunnels for different data flows. Now, the IP address and username are used as the user ID. The following is the debugging information: got NOTIFY of type INVALID_ID_INFORMATION Or drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION Check that the ACLs in the IPsec policies configured on the interfaces at both ends are compatible. Configure the ACLs to mirror each other. For more information about ACL mirroring, see the chapter IPsec configuration. 145

154 Proposal mismatch Symptom Analysis Solution The proposals mismatch. The following is the debugging information: got NOTIFY of type NO_PROPOSAL_CHOSEN Or drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN The two parties in the negotiation have no matched proposals. For the negotiation in phase 1, look up the IKE proposals for a match. For the negotiation in phase 2, check whether the parameters of the IPsec policies applied on the interfaces are matched, and whether the referred IPsec proposals have a match in protocol, encryption and authentication algorithms. Failing to establish an IPsec tunnel Symptom Analysis Solution The expected IPsec tunnel cannot be established. Sometimes this may happen that an IPsec tunnel cannot be established or there is no way to communicate in the presence of an IPsec tunnel in an unstable network. According to examination results, however, ACLs of both parties are configured correctly, and proposals are also matched. In this case, the problem is usually caused by the reboot of one Firewall after the IPsec tunnel is established. Use the display ike sa command to check whether both parties have established an SA in phase 1. Use the display ipsec sa policy command to check whether the IPsec policy on the interface has established IPsec SA. If the two commands show that one party has an SA but the other does not, use the reset ipsec sa command to clear the IPsec SA that has no corresponding SA, use the reset ike sa command to clear the IKE SA that has no corresponding IKE SA, and trigger SA re-negotiation. ACL configuration error Symptom Analysis ACL configuration error results in data flow blockage. When multiple devices create different IPsec tunnels early or late, a device may have multiple peers. If the device is not configured with ACL rule, the peers send packets to it to set up different IPsec tunnels in different protection granularity respectively. As the priorities of IPsec tunnels are determined by the order 146

155 they are established, a device cannot interoperate with other peers in fine granularity when its outbound packets are first matched with an IPsec tunnel in coarse granularity. Solution When a device has multiple peers, configure ACLs on the device to distinguish different data flows and try to avoid configuring overlapping ACL rules for different peers. If it is unavoidable, the subrules in fine granularity should be configured with higher preferences. 147

156 IPsec configuration NOTE: The term router in this document refers to both routers and Layer 3 firewalls. IPsec overview IP Security (IPsec) is a security framework defined by the Internet Engineering Task Force (IETF) for securing IP communications. It is a Layer 3 virtual private network (VPN) technology that transmits data in a secure tunnel established between two endpoints. IPsec guarantees the confidentiality, integrity, and authenticity of data and provides anti-replay service at the IP layer in an insecure network environment. Confidentiality The sender encrypts packets before transmitting them over the Internet. Data integrity The receiver verifies the packets received from the sender to make sure that they are not tampered with during transmission. Data origin authentication The receiver verifies the authenticity of the sender. Anti-replay The receiver examines packets and drops outdated and duplicate packets. IPsec delivers these benefits: Reduced key negotiation overheads and simplified maintenance by supporting the Internet Key Exchange (IKE) protocol. IKE provides automatic key negotiation and automatic IPsec security association (SA) setup and maintenance. Good compatibility. You can apply IPsec to all IP-based application systems and services without modifying them. Encryption on a per-packet rather than per-flow basis. Per-packet encryption allows for flexibility and greatly enhances IP security. IPsec implementation IPsec comprises a set of protocols for IP data security, including Authentication Header (AH), Encapsulating Security Payload (ESP), IKE, and algorithms for authentication and encryption. AH and ESP provides security services and IKE performs key exchange. For more information about IKE, see the chapter IKE configuration. IPsec provides two security mechanisms: authentication and encryption. The authentication mechanism allows the receiver of an IP packet to authenticate the sender and check if the packet has been tampered with. The encryption mechanism ensures data confidentiality and protects the data from being eavesdropped en route. IPsec is available with two security protocols: AH (protocol 51), which provides data origin authentication, data integrity, and anti-replay services. For these purposes, an AH header is added to each IP packet. AH is suitable for transmitting non-critical data because it cannot prevent eavesdropping, although it can prevent data tampering. 148

157 AH supports authentication algorithms such as Message Digest (MD5) and Secure Hash Algorithm (SHA-1). ESP (protocol 50), which provides data encryption as well as data origin authentication, data integrity, and anti-replay services. ESP works by inserting an ESP header and an ESP trailer in IP packets. Unlike AH, ESP encrypts data before encapsulating the data to ensure data confidentiality. ESP supports encryption algorithms such as Data Encryption Standard (DES), 3DES, and Advanced Encryption Standard (AES), and authentication algorithms such as MD5 and SHA-1. The authentication function is optional to ESP. Both AH and ESP provide authentication services, but the authentication service provided by AH is stronger. In practice, you can choose either or both security protocols. When both AH and ESP are used, an IP packet is encapsulated first by ESP and then by AH. Figure 95 shows the format of IPsec packets. Basic concepts Security association A security association is an agreement negotiated between two communicating parties called IPsec peers. It comprises a set of parameters for data protection, including security protocols, encapsulation mode, authentication and encryption algorithms, and shared keys and their lifetime. SAs can be set up manually or through IKE. An SA is unidirectional. At least two SAs are needed to protect data flows in a bidirectional communication. If two peers want to use both AH and ESP to protect data flows between them, they construct an independent SA for each protocol. An SA is uniquely identified by a triplet, which consists of the security parameter index (SPI), destination IP address, and security protocol identifier (AH or ESP). An SPI is a 32-bit number for uniquely identifying an SA. It is transmitted in the AH/ESP header. A manually configured SA requires an SPI to be specified manually for it; an IKE created SA will have an SPI generated at random. A manually configured SA never ages out. An IKE created SA has a specified period of lifetime, which comes in two types: Time-based lifetime, which defines how long the SA can be valid after it is created. Traffic-based lifetime, which defines the maximum traffic that the SA can process. The SA becomes invalid when either of the lifetime timers expires. Before the SA expires, IKE negotiates a new SA, which takes over immediately after its creation. Encapsulation modes IPsec supports the following IP packet encapsulation modes: Tunnel mode IPsec protects the entire IP packet, including both the IP header and the payload. It uses the entire IP packet to calculate an AH or ESP header, and then encapsulates the original IP packet and the AH or ESP header with a new IP header. If you use ESP, an ESP trailer is also encapsulated. Tunnel mode is typically used for protecting gateway-to-gateway communications. Transport mode IPsec protects only the IP payload. It uses only the IP payload to calculate the AH or ESP header, and inserts the calculated header between the original IP header and payload. If you use ESP, an ESP trailer is also encapsulated. The transport mode is typically used for protecting host-to-host or host-to-gateway communications. Figure 95 shows how the security protocols encapsulate an IP packet in different encapsulation modes. 149

158 Figure 95 Encapsulation by security protocols in different modes Authentication algorithms and encryption algorithms 1. Authentication algorithms IPsec uses hash algorithms to perform authentication. A hash algorithm produces a fixed-length digest for an arbitrary-length message. IPsec peers respectively calculate message digests for each packet. If the resulting digests are identical, the packet is considered intact. IPsec supports the following hash algorithms for authentication: MD5, which takes as input a message of arbitrary length and produces a 128-bit message digest. SHA-1, which takes as input a message of a maximum length less than the 64th power of 2 in bits and produces a 160-bit message digest. Compared with SHA-1, MD5 is faster but less secure. 2. Encryption algorithms IPsec mainly uses symmetric encryption algorithms, which encrypt and decrypt data by using the same keys. The following encryption algorithms are available for IPsec on the firewall: Data Encryption Standard (DES), which encrypts a 64-bit plain text block with a 56-bit key. DES is the least secure but the fastest algorithm. It is sufficient for general security requirements. Triple DES (3DES), which encrypts plain text data with three 56-bit DES keys. The key length totals up to 168 bits. It provides moderate security strength and is slower than DES. Advanced Encryption Standard (AES), which encrypts plain text data with a 128-bit, 192-bit, or 256-bit key. AES provides the highest security strength and is slower than 3DES. IPsec SA setup modes IPsec tunnel There are two IPsec SA setup modes: Manual mode. In this mode, you manually configure and maintain all SA settings. Advanced features like periodical key update are not available. However, this mode implements IPsec independently of IKE. ISAKMP mode. In this mode, IKE automatically negotiates and maintains IPsec SAs for IPsec. If the number of IPsec tunnels in your network is small, use the manual mode. If the number of IPsec tunnels is large, use the ISAKMP mode. An IPsec tunnel is a bidirectional channel created between two peers. An IPsec tunnel comprises one or more pairs of SAs. 150

159 IPsec tunnel interface IPsec tunnel interface overview An IPsec tunnel interface is a Layer 3 logical interface. It supports dynamic routing. All packets including multicast packets that are routed to an IPsec tunnel interface are IPsec protected. The IPsec tunnel interface has the following advantages: Simplified configuration. The IPsec tunnel interface is easier to configure compared to using access control lists (ACLs) to identify protected packets. The IPsec tunnel interface improves network scalability and reduces maintenance costs. Reduced payload. The IPsec tunnel interface requires less protocol costs and uses less bandwidth than IPsec over GRE and IPsec over L2TP, which require a GRE header or L2TP header to be added to each packet. Flexible service application. You can apply a service such as NAT or QoS to packets before or after they are encrypted by IPsec. To handle packets prior to IPsec encryption, apply the service to the IPsec tunnel interface. To handle IPsec encrypted packets, apply the service to the physical outbound interface. IPsec tunnel interface operation IPsec encapsulation and de-encapsulation occur on IPsec tunnel interfaces.figure 96 shows how a clear text packet arriving at a router is forwarded to the IPsec tunnel interface, encapsulated, and forwarded out. Figure 96 Encapsulation process of a clear text packet 1. The router forwards a clear text packet received on the inbound interface to the forwarding module. 2. The forwarding module looks up the routing table and, if the packet must be IPsec protected, forwards the packet to the IPsec tunnel interface. The original IP packet is encapsulated into to form a new IP packet. The source and destination of the new packet are respectively the source and destination address of the tunnel interface. 3. The IPsec tunnel interface encapsulates the packet, and then sends the packet to the forwarding module. 4. The forwarding module looks up the routing table again and forwards the IPsec-encrypted packet out of the physical outbound interface that is associated with the tunnel interface. Figure 97 shows how an IPsec packet is de-encapsulated on an IPsec tunnel interface. 151

160 Figure 97 De-encapsulation process of an IPsec packet 5. The router forwards an IPsec packet received on the inbound interface to the forwarding module. 6. Identifying that the destination address of the packet is the tunnel interface and the protocol is AH or ESP, the forwarding module forwards the packet to the IPsec tunnel interface for de-encapsulation. 7. The IPsec tunnel interface de-encapsulates the packet, and then delivers the resulting clear text packet back to the forwarding module. 8. The forwarding module looks up the routing table, and then forwards the clear text packet out of the physical outbound interface associated with the tunnel interface. IPsec for IPv6 routing protocols IPsec RRI You can use IPsec to protect routing information and defend attacks for these IPv6 routing protocols: OSPFv3, IPv6 BGP, and RIPng. IPsec enables these IPv6 routing protocols to encapsulate outbound protocol packets and de-encapsulate inbound protocol packets with the AH or ESP protocol. If an inbound protocol packet is not IPsec protected, or fails to be de-encapsulated, for example, due to decryption or authentication failure, the routing protocol discards that packet. You must manually configure SA parameters in an IPsec policy for IPv6 routing protocols. The IKE key exchange mechanism is applicable only to one-to-one communications. IPsec cannot implement automatic key exchange for one-to-many communications on a broadcast network, where routers must use the same SA parameters (SPI and key) to process packets for a routing protocol. IPsec Reverse Route Inject (RRI) enables an IPsec tunnel gateway to automatically add static routes destined for protected private networks or peer IPsec tunnel gateways to a routing table. In a VPN network, IPsec RRI can add static routes to VPN instances routing tables. IPsec RRI is applicable to gateways for example, a headquarters gateway that must provide many IPsec tunnels. It frees you from the tedious work of manually configuring and maintaining static routes for IPsec tunnels. For example, if you enable RRI on Device A in Figure 98, Device A can automatically create a static route to branch network /24 for the IPsec protected traffic from the headquarters to the branch. The result is the same as configuring a static route with the destination address /24 and the next hop

161 Figure 98 An IPsec VPN You can advertise the static routes created by IPsec RRI in the internal network. IPsec RRI can quickly create new routes for forwarding IPsec VPN traffic when an active link fails in a load balanced or stateful failover environment, or when IPsec VPN traffic cannot reach the peer gateway through the default local gateway. IPsec stateful failover The IPsec stateful failover function enables hot backup of IPsec service data between two devices and is usually deployed on two devices at the headquarters to improve the availability of IPsec service. The IPsec stateful failover function is based on the Virtual Router Redundancy Protocol (VRRP). The two devices configured for this function join the same VRRP group and act as a single virtual device. They use the virtual IP address of the virtual device to communicate with remote devices. The IPsec stateful failover function can work only in standard VRRP mode. In this mode, only one device (the master) processes and forwards IPsec traffic; the other device (the backup) only receives IPsec service data synchronized from the master. When the master fails, the backup immediately takes over to forward IPsec traffic. This switchover process is transparent to remote devices. No extra configuration is required on remote devices and no IPsec re-negotiation is required after the switchover. Figure 99 IPsec stateful failover IPsec tunnel As shown in Figure 99, Device A and Device B form a stateful failover system through a backup link. After the election process supported by the VRRP mechanism, Device A becomes the master. When Device A works normally, it establishes an IPsec tunnel to Device C, and synchronizes its IPsec service data to 153

162 Device B. The synchronized IPsec service data includes the IKE SA, IPsec SAs, the anti-replay sequence number and window, the SA lifetime in units of bytes, and the DPD packet sequence number. Based on the IPsec service data, Device B generates its own IKE SA and IPsec SAs, which are called the standby IKE SA and standby IPsec SAs, in contrast with the active IKE SA and active IPsec SAs on Device A. When Device A fails, the VRRP mechanism switches IPsec traffic from Device A to Device B. Because Device B has a copy of Device A s IPsec service data, Device B can process IPsec traffic immediately, providing uninterrupted IPsec service. Protocols and standards Protocols and standards relevant to IPsec are as follows: RFC 2401, Security Architecture for the Internet Protocol RFC 2402, IP Authentication Header RFC 2406, IP Encapsulating Security Payload RFC 4552, Authentication/Confidentiality for OSPFv3 Configuring IPsec IPsec can be implemented based on ACLs, tunnel interfaces, or applications: ACL-based IPsec uses ACLs to identify the data flows to be protected. To implement ACL-based IPsec, configure IPsec policies, reference ACLs in the policies, and apply the policies to physical interfaces (see Configuring ACL-based IPsec in the web interface ). By using ACLs, you can customize IPsec policies as needed, implementing IPsec flexibly. Tunnel interface-based IPsec, or routing-based IPsec, depends on the routing mechanism to select the data flows to be protected. To implement tunnel interface-based IPsec, configure IPsec profiles and apply them to IPsec tunnel interfaces (see Configuring tunnel interface-based IPsec ). By using IPsec profiles, this IPsec implementation method simplifies IPsec VPN configuration and management, and improves the scalability of large VPN networks. Application-based IPsec protects the packets of a service. This IPsec implementation method can be used to protect IPv6 routing protocols. It does not require any ACL, nor does it depend on the routing mechanism. To configure service-based IPsec, configure manual IPsec policies and bind the policies to an IPv6 routing protocol. See Configuring IPsec for IPv6 routing protocols. Configuring ACL-based IPsec in the web interface Configuration considerations 1. Configure ACLs for identifying data flows to be protected. 2. Configure IPsec proposals to specify the security protocols, authentication and encryption algorithms, and encapsulation mode. 3. Configure IPsec policies to associate data flows with IPsec proposals and specify the SA negotiation mode, the peer IP addresses (the start and end points of the IPsec tunnel), the required keys, and the SA lifetime. 4. Apply the IPsec policies to interfaces to finish IPsec configuration. 154

163 Recommended configuration procedure Step Remarks Required Configure ACLs to identify the data flows to be protected by IPsec. 1. Configuring ACLs 2. Configuring an IPsec proposal 3. Configuring an IPsec policy template 4. Configuring an IPsec policy 5. Applying an IPsec policy group 6. Viewing IPsec SAs 7. Viewing packet statistics IMPORTANT: This document introduces only how to reference ACLs in IPsec. To create ACLs, select Firewall > ACL from the navigation tree. For more information about the procedure, see Access Control Configuration Guide. Required An IPsec proposal defines a set of security parameters for IPsec SA negotiation, including the security protocol, encryption and authentication algorithms, and encapsulation mode. IMPORTANT: Changes to an IPsec proposal affect only SAs negotiated after the changes are made. Required if you are using an IPsec policy template group to create an IPsec policy. An IPsec policy template group is a collection of IPsec policy templates with the same name but different sequence numbers. In an IPsec policy template group, an IPsec policy template with a smaller sequence number has a higher priority. Required Configure an IPsec policy by specifying the parameters directly or using a created IPsec policy template. The firewall supports only IPsec policies that use IKE. An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers. The smaller the sequence number, the higher the priority of the IPsec policy in the policy group. IMPORTANT: An IPsec policy referencing a template cannot be used to initiate SA negotiations but can be used to respond to a negotiation request. The parameters specified in the IPsec policy template must match those of the remote end. The parameters not defined in the template are determined by the initiator. Required Apply an IPsec policy group to an interface (logical or physical) to protect certain data flows. Optional View brief information about established IPsec SAs to verify your configuration. Optional View packet statistics to verify your configuration. 155

164 Configuring ACLs 1. Use of the Permit/Deny Actions in ACLs IPsec uses ACLs to identify data flows. An ACL is a collection of ACL rules. Each ACL rule is a deny or permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement identifies a data flow that is not protected by IPsec. IPsec uses referenced ACL to match against packets. The matching process stops once a match is found or ends with no match hit. The packet is handled as follows: Each ACL rule matches both the outbound traffic and the returned inbound traffic. Suppose there is a rule as shown in Figure 100. This rule matches both traffic from to and returned traffic from to Figure 100 An ACL referenced in an IPsec policy In the outbound direction, if a permit statement is matched, IPsec considers the packet as requiring protection and continues to process it. If a deny statement is matched or no match is found, IPsec considers the packet as not requiring protection and delivers it to the next function module. In the inbound direction, if the packet is an IPsec packet and matches a permit statement, IPsec receives and processes the packet. If the packet is not an IPsec packet and matches a permit statement, it is discarded. CAUTION: When defining ACL rules for IPsec, follow these guidelines: Make sure that only the data flows to be protected by IPsec are defined in permit statements. If a packet is protected at the entry of the IPsec tunnel but not at the exit of the IPsec tunnel, it will be dropped. Avoid statement conflicts in the scope of IPsec policy groups. When creating a deny statement, be careful with its matching scope and matching order relative to permit statements. The policies in an IPsec policy group have different match priorities. ACL rule conflicts between them are prone to cause mistreatment of packets. For example, when you configure a permit statement for an IPsec policy to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches a deny statement in a higher priority IPsec policy. Otherwise, the packets will be sent out as normal packets; if they match a permit statement at the receiving end, they will be dropped by IPsec. The following uses a configuration example to show how a statement conflict causes packet drop. In this example, only the ACL-related configurations are presented. Device A connects the segment /24 and Device B connects the segment /24. On Device A, apply the IPsec policy group test to the outbound interface to Device B. The IPsec policy group contains two policies, test 1 and test 2. The ACLs referenced by the two policies each contain a rule that matches traffic from /24 to /24. The one referenced in policy test 1 is a deny statement and the one referenced in policy test 2 is a permit statement. Because test 1 is matched prior to test 2, traffic from /24 to /24 will match the deny statement and sent as normal traffic. When the 156

165 traffic arrives at Device B, it will be dropped if it matches a permit statement in the ACL referenced in the applied IPsec policy. The configurations on Device A are shown in Figure 101, Figure 102, and Figure 103. Figure 101 ACL 3000 configuration on Device A Figure 102 ACL 3001 configuration on Device A Figure 103 IPsec policy configuration on Device A The configurations on Device B are shown in Figure 104, and Figure 105. Figure 104 ACL 3001 configuration on Device B 157

166 Figure 105 IPsec policy configuration on Device B 2. Mirror image ACLs To make sure that SAs can be set up and the traffic protected by IPsec locally can be processed correctly at the remote peer, on the remote peer, create a mirror image ACL rule for each ACL rule created at the local peer. As shown in Figure 106, ACL rules on Device B are mirror images of the rules on Device A. This makes sure that SAs can be created successfully for the traffic between Host A and Host C and the traffic between Network 1 and Network 2. Figure 106 Mirror image ACLs If the ACL rules on the peers do not form mirror images of each other, SAs can be set up only when both of the following requirements are met: The range specified by an ACL rule on one peer is covered by its counterpart ACL rule on the other peer. As shown in Figure 107, the range specified by the ACL rule configured on Device A is covered by its counterpart on Device B. The peer with the narrower rule initiates SA negotiation. If a wider ACL rule is used by the SA initiator, the negotiation request may be rejected because the matching traffic is beyond the scope of the responder. As shown in Figure 107, the SA negotiation initiated by Host A to Host C is accepted but the SA negotiation from Host C to Host B or from Host D to Host A is rejected. 158

167 Figure 107 Non-mirror image ACLs 3. Protection modes Data flows can be protected in two modes: Standard mode, in which one tunnel is used to protect one data flow. The data flow permitted by each ACL rule is protected by one tunnel that is established separately for it. Aggregation mode, in which one tunnel is used to protect all data flows permitted by all the rules of an ACL. This mode applies to only scenarios that use IKE for negotiation. NOTE: For more information about ACL configuration, see Access Control Configuration Guide. To use IPsec in combination with QoS, make sure that IPsec s ACL classification rules match the QoS classification rules. If the rules do not match, QoS may classify the packets of one IPsec SA to different queues, causing packets to be sent out of order. When the anti-replay function is enabled, IPsec will discard the packets beyond the anti-replay window in the inbound direction, resulting in packet loss. For more information about QoS classification rules, see Network Management Configuration Guide. Configuring an IPsec proposal 1. Select VPN > IPSec > Proposal from the navigation tree to enter the IPsec proposal management page. Figure 108 IPsec proposal list 2. Click Add to enter the IPsec proposal configuration wizard page. The Web interface provides two modes for configuring an IPsec proposal: suite mode and custom mode. The suite mode allows you to select a pre-defined encryption suite. The custom mode allows you to configure IPsec proposal parameters discretionarily. 159

168 Figure 109 IPsec proposal configuration wizard page 3. Click Suite mode to configure an IPsec proposal as described in Table 13, or click Custom mode to configure an IPsec proposal as described in Table Click Apply. Figure 110 IPsec proposal configuration in suite mode Table 13 Configuration items in suite mode Item Proposal Name Description Enter a name for the IPsec proposal. Select an encryption suite for the proposal. An encryption suite specifies the IP packet encapsulation mode, security protocol, and authentication and encryption algorithms to be used. Encryption Suite Available encryption suites include: Tunnel-ESP-DES-MD5 Uses the ESP security protocol, the DES encryption algorithm, and the MD5 authentication algorithm. Tunnel-ESP-3DES-MD5 Uses the ESP security protocol, the 3DES encryption algorithm, and the MD5 authentication algorithm. Tunnel-AH-MD5-ESP-DES Uses the ESP and AH security protocols successively, making ESP use the DES encryption algorithm and perform no authentication and making AH use the MD5 authentication algorithm Tunnel-AH-MD5-ESP-3DES Uses the ESP and AH security protocols successively, making ESP use the 3DES encryption algorithm and perform no authentication, and making AH use the MD5 authentication algorithm. All these suites use the tunnel mode for IP packet encapsulation. 160

169 Figure 111 IPsec proposal configuration in custom mode Table 14 Configuration items in custom mode Item Proposal Name Encapsulation Mode Security Protocol AH Authentication Algorithm ESP Authentication Algorithm Description Enter a name for the IPsec proposal. Select an IP packet encapsulation mode for the IPsec proposal. Options include: Tunnel Uses the tunnel mode. Transport Uses the transport mode. Select a security protocol setting for the proposal. Options include: AH Uses the AH protocol. ESP Uses the ESP protocol. AH-ESP Uses ESP first and then AH. Select an authentication algorithm for AH when the security protocol setting is AH or AH-ESP. Available authentication algorithms include MD5 and SHA1. Select an authentication algorithm for ESP when the security protocol setting is ESP or AH-ESP. You can select MD5 or SHA1, or leave it null so the ESP performs no authentication. IMPORTANT: The ESP authentication algorithm and ESP encryption algorithm cannot be both null. ESP Encryption Algorithm Select an encryption algorithm for ESP when the security protocol is ESP or AH-ESP. Options include: DES Uses the DES algorithm and 56-bit keys for encryption. 3DES Uses the 3DES algorithm and 168-bit keys for encryption. AES128 Uses the AES algorithm and 128-bit keys for encryption. AES192 Uses the AES algorithm and 192-bit keys for encryption. AES256 Uses the AES algorithm and 256-bit keys for encryption. Leave it null so the ESP performs no encryption. IMPORTANT: Higher security means increased complexity and decreased speed. DES is sufficient for general security requirements. Use 3DES if you require very high confidentiality and security. The ESP authentication and encryption algorithms cannot be both null. 161

170 Configuring an IPsec policy template 1. Select VPN > IPSec > Policy-Template from the navigation tree to enter IPsec policy template management page. Figure 112 IPsec policy template list 2. Click Add to enter the IPsec policy template configuration page. 3. Configure an IPsec policy template as described in Table Click Apply. Figure 113 IPsec policy template configuration page 162

171 Table 15 Configuration items Item Template Name Sequence Number IKE Peer Description Enter a name for the IPsec policy template. Enter a sequence number for the IPsec policy template. In an IPsec policy template group, an IPsec policy template with a smaller sequence number has a higher priority. Select an IKE peer for the IPsec policy template. You configure IKE peers by selecting VPN > IKE > Peer from the navigation tree. Select up to six IPsec proposals for the IPsec policy template. IPSec Proposal PFS IPsec SAs can be set up only when the IPsec peers have at least one matching IPsec proposal. If no matching IPsec proposal is available, the IPsec SAs cannot be established and the packets that need to be protected are discarded. Enable and configure the Perfect Forward Secrecy (PFS) feature or disable the feature. Options include: dh-group1 Uses the 768-bit Diffie-Hellman group. dh-group2 Uses the 1024-bit Diffie-Hellman group. dh-group5 Uses the 1536-bit Diffie-Hellman group. dh-group14 Uses the 2048-bit Diffie-Hellman group. IMPORTANT: dh-group14, dh-group5, dh-group2, and dh-group1 are in descending order of security and calculation time. When IPsec uses an IPsec policy configured with PFS to initiate negotiation, an additional key exchange is performed in phase 2 for higher security. Two peers must use the same Diffie-Hellman. Otherwise, negotiation will fail. Select an ACL for identifying protected traffic. The specified ACL must be created already and contains at least one rule. ACL ACL configuration supports VPN multi-instance. SA Lifetime Time Based Traffic Based Make sure that this ACL has been created and contains at least one rule. You can use an ACL to identify traffic between VPN instances. Enter the time-based and traffic-based SA lifetime values. IMPORTANT: When negotiating IPsec SAs, IKE uses the smaller one between the lifetime set locally and the lifetime proposed by the peer. Enable or disable IPsec RRI. When enabling IPsec RRI, you can specify a next hop and change the preference of the static routes. After an outbound IPsec SA is created, IPsec RRI automatically creates a static route to the peer private network. You do not have to manually configure the static route. Reverse Route Injection IMPORTANT: If you enable IPsec RRI and do not configure the static route, the SA negotiation must be initiated by the remote gateway. IPsec RRI creates static routes when IPsec SAs are set up, and delete the static routes when the IPsec SAs are deleted. To view the static routes created by IPsec RRI, select Network > Routing Management > Routing Info from the navigation tree. 163

172 Item Next Hop Priority Description Specify a next hop for the static routes. If you do not specify any next hop, the remote tunnel endpoint s address learned during IPsec SA negotiation is used. Change the preference of the static routes. Change the route preference for equal-cost multipath (ECMP) routing or route backup. If multiple routes to the same destination have the same preference, traffic is balanced among them. If multiple routes to the same destination have different preference values, the route with the highest preference forwards traffic and all other routes are backup routes. Configuring an IPsec policy 1. Select VPN > IPSec > Policy from the navigation tree to enter the IPsec policy management page. Figure 114 IPsec policy list 2. Click Add to enter the IPsec policy configuration page. 3. Configure an IPsec policy as described in Table Click Apply. 164

173 Figure 115 IPsec policy configuration page Table 16 Configuration items Item Policy Name Sequence Number Description Enter a name for the IPsec policy. Enter a sequence number for the IPsec policy. In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority. Select an IPsec policy template. Template IKE Peer IMPORTANT: If you select an IPsec policy template, all subsequent configuration items but the aggregation setting are unavailable. Select an IKE peer for the IPsec policy. You configure IKE peers by selecting VPN > IKE > Peer from the navigation tree. 165

174 Item Description Select up to six IPsec proposals for the IPsec policy. IPSec Proposal PFS IPsec SAs can be set up only when the IPsec peers have at least one matching IPsec proposal. If no matching IPsec proposal is available, the IPsec SAs cannot be established and the packets that need to be protected are discarded. Enable and configure the Perfect Forward Secrecy (PFS) feature or disable the feature. Options include: dh-group1 Uses the 768-bit Diffie-Hellman group. dh-group2 Uses the 1024-bit Diffie-Hellman group. dh-group5 Uses the 1536-bit Diffie-Hellman group. dh-group14 Uses the 2048-bit Diffie-Hellman group. IMPORTANT: dh-group14, dh-group5, dh-group2, and dh-group1 are in descending order of security and calculation time. When IPsec uses an IPsec policy configured with PFS to initiate negotiation, an additional key exchange is performed in phase 2 for higher security. Two peers must use the same Diffie-Hellman. Otherwise, negotiation will fail. Select an ACL for identifying protected traffic. ACL Make sure that this ACL has been created and contains at least one rule. You can use an ACL to identify traffic between VPN instances. Aggregation Select this option if you are using one tunnel to protect all data flows permitted by the ACL. If you do not select the aggregation mode, the standard mode applies and one tunnel is set up for each data flow permitted by the ACL. This configuration item is available after you specify an ACL. IMPORTANT: The two ends of a tunnel must work in the same mode. SA Lifet ime Time Based Traffic Based Enter the time-based and traffic-based SA lifetime values. IMPORTANT: When negotiating IPsec SAs, IKE uses the smaller one between the lifetime set locally and the lifetime proposed by the peer. Enable or disable IPsec RRI. When enabling IPsec RRI, you can specify a next hop and change the preference of the static routes. After an outbound IPsec SA is created, IPsec RRI automatically creates a static route to the peer private network. You do not have to manually configure the static route. Reverse Route Injection Next Hop IMPORTANT: If you enable IPsec RRI and do not configure the static route, the SA negotiation must be initiated by the remote gateways. IPsec RRI creates static routes when IPsec SAs are set up, and delete the static routes when the IPsec SAs are deleted. To view the static routes created by IPsec RRI, select Network > Routing Management > Routing Info from the navigation tree. Specify a next hop for the static routes. If you do not specify any next hop, the remote tunnel endpoint s address learned during IPsec SA negotiation is used. 166

175 Item Priority Description Change the preference of the static routes. Change the route preference for equal-cost multipath (ECMP) routing or route backup. If multiple routes to the same destination have the same preference, traffic is balanced among them. If multiple routes to the same destination have different preference values, the route with the highest preference forwards traffic and all other routes are backup routes. Applying an IPsec policy group 1. Select VPN > IPSec > IPSec Application from the navigation tree to enter the IPsec policy application configuration page. Figure 116 IPsec policy application 2. Click the icon for an interface. 3. Select an IPsec policy for the interface. 4. Click Apply. Figure 117 IPsec policy application page Table 17 Configuration items Item Interface Policy Description Displays the interface you selected. Select an IPsec policy group for the interface. Viewing IPsec SAs Select VPN > IPSec > IPSec SA from the navigation tree to display brief information about established IPsec SAs, as shown in Figure 118. Table 18 describes the fields of IPsec SA information. 167

176 Figure 118 IPsec SAs Table 18 Field description Field Local IP Remote IP SPI Security Protocol Authentication Algorithm Encryption Algorithm Description Local IP address of the IPsec SA Remote IP address of the IPsec SA SPI of the IPsec SA Security protocol that the IPsec SA uses Authentication algorithm that the security protocol uses. Encryption algorithm that the security protocol uses. Viewing packet statistics Select VPN > IPSec > Statistics from the navigation tree to view packet statistics. Figure 119 Packet statistics Configuring ACL-based IPsec at the CLI Configuration task list Task Configuring ACLs Remarks Required 168

177 Task Configuring an IPsec proposal Remarks Basic IPsec configuration Applying an IPsec policy group to an interface Enabling the encryption engine Enabling ACL checking of de-encapsulated IPsec packets Configuring the IPsec anti-replay function Configuring packet information pre-extraction Enabling invalid SPI recovery Configuring IPsec RRI Configuring IPsec stateful failover Required Optional Optional Optional Optional Optional Optional CAUTION: Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and 50 respectively. Make sure that flows of these protocols are not denied on the interfaces with IKE or IPsec configured. Configuring ACLs ACLs can be used to identify traffic. They are widely used in scenarios where traffic identification is desired, such as QoS and IPsec. 1. Keywords in ACL rules IPsec uses ACLs to identify data flows. An ACL is a collection of ACL rules. Each ACL rule is a deny or permit statement. A permit statement identifies a data flow protected by IPsec, and a deny statement identifies a data flow that is not protected by IPsec. With IPsec, a packet is matched against the referenced ACL rules and processed according to the first rule that it matches: Each ACL rule matches both the outbound traffic and the returned inbound traffic. Suppose there is a rule rule 0 permit ip source destination This rule matches both traffic from to and traffic from to In the outbound direction, if a permit statement is matched, IPsec considers that the packet requires protection and continues to process it. If a deny statement is matched or no match is found, IPsec considers that the packet does not require protection and delivers it to the next function module. In the inbound direction, all IPsec packets matching a permit statement are processed by IPsec, and all non-ipsec packets that match a permit statement are discarded. When defining ACL rules for IPsec, follow these guidelines: Permit only data flows that need to be protected and use the any keyword with caution. With the any keyword specified in a permit statement, all outbound traffic matching the permit statement will be protected by IPsec and all inbound IPsec packets matching the permit statement will be received and processed, but all inbound non-ipsec packets will be dropped. This will cause the inbound traffic that does not need IPsec protection to be all dropped. Avoid statement conflicts in the scope of IPsec policy groups. When creating a deny statement, be careful with its matching scope and matching order relative to permit statements. The policies in an IPsec policy group have different match priorities. ACL rule conflicts between them are prone to cause mistreatment of packets. For example, when you configure a permit statement for an IPsec 169

178 policy to protect an outbound traffic flow, you must avoid the situation that the traffic flow matches a deny statement in a higher priority IPsec policy. Otherwise, the packets will be sent out as normal packets; if they match a permit statement at the receiving end, they will be dropped by IPsec. The following configuration example shows how an improper statement causes unexpected packet dropping. Only the ACL-related configurations are presented. Router A connects the segment /24 and Router B connects the segment /24. On Router A, apply the IPsec policy group test to the outbound interface of Router A. The IPsec policy group contains two policies, test 1 and test 2. The ACLs referenced by the two policies each contain a rule that matches traffic from /24 to /24. The one referenced in policy test 1 is a deny statement and the one referenced in policy test 2 is a permit statement. Because test 1 is matched prior to test 2, traffic from /24 to /24 will match the deny statement and sent as normal traffic. When the traffic arrives at Router B, it will be dropped if it matches a permit statement in the ACL referenced in the applied IPsec policy. Configuration on Router A: acl number 3000 rule 0 permit ip source destination rule 1 deny ip acl number 3001 rule 0 permit ip source destination rule 1 deny ip # ipsec policy test 1 isakmp security acl 3000 ike-peer aa proposal 1 # ipsec policy test 2 isakmp security acl 3001 ike-peer bb proposal 1 Configuration on Router B: acl number 3001 rule 0 permit ip source destination rule 1 deny ip # ipsec policy test 1 isakmp security acl 3001 ike-peer aa proposal 1 2. Mirror image ACLs See Mirror image ACLs. 3. Protection modes See Protection modes. 170

179 Configuring an IPsec proposal An IPsec proposal, part of an IPsec policy or an IPsec profile, defines the security parameters for IPsec SA negotiation, including the security protocol, the encryption and authentication algorithms, and the encapsulation mode. Follow these steps to configure an IPsec proposal: To do Use the command Remarks Enter system view system-view Create an IPsec proposal and enter its view Specify the security protocol for the proposal Specify the encryption algorithm for ESP ipsec proposal proposal-name transform { ah ah-esp esp } esp encryption-algorithm { 3des aes [ key-length ] des } Required By default, no IPsec proposal exists. Optional ESP by default Optional DES by default Specify the security algorithms Specify the authentication algorithm for ESP esp authentication-algorithm { md5 sha1 } Optional MD5 by default Specify the authentication algorithm for AH ah authentication-algorithm { md5 sha1 } Optional MD5 by default Specify the IP packet encapsulation mode for the IPsec proposal encapsulation-mode { transport tunnel } Optional Tunnel mode by default Transport mode applies only when the source and destination IP addresses of data flows match those of the IPsec tunnel. IPsec for IPv6 routing protocols supports only the transport mode. NOTE: Changes to an IPsec proposal affect only SAs negotiated after the changes. To apply the changes to existing SAs, execute the reset ipsec sa command to clear the SAs so that they can be set up using the updated parameters. Only when a security protocol is selected, can you configure security algorithms for it. For example, you can specify the ESP-specific security algorithms only when you select ESP as the security protocol. ESP supports three IP packet protection schemes: encryption only, authentication only, or both encryption and authentication. You can configure up to IPsec proposals. Configuring a manual IPsec policy IPsec policies define which IPsec proposals should be used to protect which data flows. An IPsec policy is uniquely identified by its name and sequence number. IPsec policies fall into two categories: 171

180 Manual IPsec policy The parameters are configured manually, such as the keys, the SPIs, and the IP addresses of the two ends in tunnel mode. IPsec policy that uses IKE The parameters are automatically negotiated through IKE. This section describes how to configure a manual IPsec policy. Configuration guidelines To ensure successful SA negotiations, follow these guidelines when you configure manual IPsec policies at the two ends of an IPsec tunnel: The IPsec policies at the two ends must have IPsec proposals that use the same security protocols, security algorithms, and encapsulation mode. The remote IP address configured on the local end must be the same as the IP address of the remote end. At each end, configure parameters for both the inbound SA and the outbound SA and make sure that different SAs use different SPIs. The local inbound SA must use the same SPI and keys as the remote outbound SA. The same is true of the local outbound SA and remote inbound SA. The keys for the local and remote inbound and outbound SAs must be in the same format. For example, if the local inbound SA uses a key in characters, the local outbound SA and remote inbound and outbound SAs must use keys in characters. Follow these guidelines when you configure an IPsec policy for an IPv6 routing protocol: You do not need to configure ACLs or IPsec tunnel addresses. Within a certain routed network scope, the IPsec proposals used by the IPsec policies on all routers must have the same security protocols, security algorithms, and encapsulation mode. For OSPFv3, the scope can be directly connected neighbors or an OSPFv3 area. For RIPng, the scope can be directly connected neighbors or a RIPng process. For IPv6 BGP, the scope can be directly connected neighbors or a neighbor group. All SAs (both inbound and outbound) within the routed network scope must use the same SPI and keys. Configure the keys on all routers within the routed network scope in the same format. For example, if you enter the keys in hexadecimal format on one router, do so across the routed network scope. Configuration prerequisites Configure ACLs used for identifying protected traffic and IPsec proposals. ACLs are not required for IPsec policies for an IPv6 protocol. Configuration procedure Follow these steps to configure a manual IPsec policy: To do Use the command Remarks Enter system view system-view Create a manual IPsec policy and enter its view ipsec policy policy-name seq-number manual Required By default, no IPsec policy exists. 172

181 To do Use the command Remarks Assign an ACL to the IPsec policy Assign an IPsec proposal to the IPsec policy security acl acl-number proposal proposal-name Not needed for IPsec policies to be applied to IPv6 routing protocols and required for other applications. By default, an IPsec policy references no ACL. The ACL supports match criteria of the VPN instance attribute. Required By default, an IPsec policy references no IPsec proposal. Configure the two ends of the IPsec tunnel Configure the local address of the tunnel Configure the remote address of the tunnel tunnel local ip-address tunnel remote ip-address Not needed for IPsec policies to be applied to IPv6 routing protocols and required for other applications. Not configured by default Required Not configured by default Configure the SPIs for the SAs Configure an authentication key in hexadecimal for AH Configure an authentication key in characters for AH sa spi { inbound outbound } { ah esp } spi-number sa authentication-hex { inbound outbound } ah hex-key sa string-key { inbound outbound } ah string-key Required Required Use either command Configure keys for the SAs Configure a key in characters for ESP Configure an authentication key in hexadecimal for ESP Configure an encryption key in hexadecimal for ESP sa string-key { inbound outbound } esp string-key sa authentication-hex { inbound outbound } esp hex-key sa encryption-hex { inbound outbound } esp hex-key Required Configure at least one command. If you configure a key in characters for ESP, the router automatically generates an authentication key and an encryption key for ESP. 173

182 NOTE: An IPsec policy can reference only one ACL. If you apply multiple ACLs to an IPsec policy, only the last one takes effect. A manual IPsec policy can reference only one IPsec proposal. To change an IPsec proposal for an IPsec policy, you must remove the proposal reference first. If you configure a key in two modes: string and hexadecimal, only the last configured one will be used. You cannot change the creation mode of an IPsec policy from manual to through IKE, or vise versa. To create an IPsec policy that uses IKE, delete the manual IPsec policy, and then use IKE to configure an IPsec policy. Configuring an IPsec policy that uses IKE IPsec policies define which IPsec proposals should be used to protect which data flows. An IPsec policy is uniquely identified by its name and sequence number. IPsec policies fall into two categories: Manual IPsec policy The parameters are configured manually, such as the keys, the SPIs, and the IP addresses of the two ends in tunnel mode. IPsec policy that uses IKE The parameters are automatically negotiated through IKE. This section describes how to configure a manual IPsec policy. Configuration guidelines To configure an IPsec policy that uses IKE, use either of the following methods: Directly configure it by configuring the parameters in IPsec policy view. Configure it by referencing an existing IPsec policy template with the parameters to be negotiated configured. A device referencing an IPsec policy that is configured in this way cannot initiate SA negotiation but can respond to a negotiation request. The parameters not defined in the template will be determined by the initiator. This approach applies to scenarios where the remote end's information, such as the IP address, is unknown. The parameters configurable for an IPsec policy template are the same as those you configure when directly configuring an IPsec policy that uses IKE. The difference is that more parameters are optional: Required configuration: The IPsec proposals and IKE peer. Optional configuration: The ACL, PFS feature, and SA lifetime. Unlike the direct configuration, ACL configuration to be referenced by an IPsec policy is optional. The responder without ACL configuration accepts the initiator's ACL configuration. Configuration prerequisites Configure the ACLs and the IKE peer for the IPsec policy. For more information about IKE configuration, see the chapter IKE configuration. The parameters for the local and remote ends must match. Configuration procedure To directly configure an IPsec policy that uses IKE: To do Use the command Remark Enter system view system-view 174

183 To do Use the command Remark Create an IPsec policy that uses IKE and enter its view Configure an IPsec connection name Assign an ACL to the IPsec policy Assign IPsec proposals to the IPsec policy Specify an IKE peer for the IPsec policy Enable and configure the perfect forward secrecy feature for the IPsec policy ipsec policy policy-name seq-number isakmp connection-name name security acl acl-number [ aggregation ] proposal proposal-name&<1-6> ike-peer peer-name pfs { dh-group1 dh-group2 dh-group5 dh-group14 } Required By default, no IPsec policy exists. Optional By default, no IPsec connection name is configured. Required By default, an IPsec policy references no ACL. Required By default, an IPsec policy references no IPsec proposal. Required An IPsec policy cannot reference any IKE peer that is already referenced by an IPsec profile, and vice versa. Optional By default, the PFS feature is not used for negotiation. For more information about PFS, see the chapter IKE configuration. Set the SA lifetime sa duration { time-based seconds traffic-based kilobytes } Optional By default, the global SA lifetime is used. Set the anti-replay information synchronization intervals in IPsec stateful failover mode Enable the IPsec policy synchronization anti-replay-interval inbound inbound-number outbound outbound-number policy enable Optional By default, the inbound anti-replay window information is synchronized whenever 1000 packets are received, and the outbound anti-replay sequence number is synchronized whenever packets are sent. Optional Enabled by default. Return to system view quit 175

184 To do Use the command Remark Set the global SA lifetime ipsec sa global-duration { time-based seconds traffic-based kilobytes } Optional 3600 seconds for time-based SA lifetime by default kilobytes for traffic-based SA lifetime by default. To configure an IPsec policy that uses IKE by referencing an IPsec policy template: To do Use the command Remark Enter system view system-view Create an IPsec policy template and enter its view Specify the ACL for the IPsec policy to reference Specify the IPsec proposals for the IPsec policy to reference Specify the IKE peer for the IPsec policy to reference Enable and configure the perfect forward secrecy feature for the IPsec policy Configure the SA lifetime Set the anti-replay information synchronization intervals in IPsec stateful failover mode Enable the IPsec policy ipsec policy-template template-name seq-number security acl acl-number proposal proposal-name&<1-6> ike-peer peer-name pfs { dh-group1 dh-group2 dh-group5 dh-group14 } sa duration { time-based seconds traffic-based kilobytes } synchronization anti-replay-interval inbound inbound-number outbound outbound-number policy enable Required By default, no IPsec policy template exists. Optional By default, an IPsec policy references no ACL. Required By default, an IPsec policy references no IPsec proposal. Required An IPsec policy cannot reference any IKE peer that is already referenced by an IPsec profile, and vice versa. Optional By default, the PFS feature is not used for negotiation. For more information about PFS, see the chapter IKE configuration. Optional By default, the global SA lifetime settings are used. Optional By default, the inbound anti-replay window information is synchronized whenever 1000 packets are received, and the outbound anti-replay sequence number is synchronized whenever packets are sent. Optional Enabled by default. Return to system view quit 176

185 To do Use the command Remark Configure the global SA lifetime ipsec sa global-duration { time-based seconds traffic-based kilobytes } Optional 3600 seconds for time-based SA lifetime by default kilobytes for traffic-based SA lifetime by default Create an IPsec policy by referencing an IPsec policy template ipsec policy policy-name seq-number isakmp template template-name Required By default, no IPsec policy exists. NOTE: You cannot change the parameters of an IPsec policy created by referencing an IPsec policy template directly in IPsec policy view. You can perform the required changes in IPsec policy template view. An IPsec policy can reference only one ACL. If you apply multiple ACLs to an IPsec policy, only the last one takes effect. With SAs to be established through IKE negotiation, an IPsec policy can reference up to six IPsec proposals. During negotiation, IKE searches for a fully matched IPsec proposal at the two ends of the expected IPsec tunnel. If no match is found, no SA can be set up and the packets expecting to be protected will be dropped. During IKE negotiation for an IPsec policy with PFS enabled, an additional key exchange is performed. If the local end uses PFS, the remote end must also use PFS for negotiation and both ends must use the same Diffie-Hellman (DH) group; otherwise, the negotiation will fail. You can set both the time-based SA lifetime and the traffic-based SA lifetime. Once the time-based lifetime or traffic-based lifetime of an SA elapses, the SA is aged. An SA uses the global lifetime settings when it is not configured with lifetime settings in IPsec policy view. When negotiating to set up SAs, IKE uses the local lifetime settings or those proposed by the peer, whichever are smaller. You cannot change the creation mode of an IPsec policy between the two, directly configuration and configuration by referencing an IPsec policy template. To create an IPsec policy in another creation mode, delete the current one and then configure a new IPsec policy. Applying an IPsec policy group to an interface An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers. In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority. You can apply an IPsec policy group to a logical or physical interface to protect certain data flows. To cancel the IPsec protection, remove the application of the IPsec policy group. For each packet to be sent out an IPsec protected interface, the system looks through the IPsec policies in the IPsec policy group in ascending order of sequence numbers. If an IPsec policy matches the packet, the system uses the IPsec policy to protect the packet. If no match is found, the system sends the packet out without IPsec protection. In addition to physical interfaces like serial and Ethernet ports, you can apply an IPsec policy to virtual interfaces, such as tunnel and virtual template interfaces, to tunnel applications such as GRE and L2TP. 177

186 Follow these steps to apply an IPsec policy group to an interface: To do Use the command Remarks Enter system view system-view Enter interface view Apply an IPsec policy group to the interface interface interface-type interface-number ipsec policy policy-name Required NOTE: An interface can reference only one IPsec policy group. An IPsec policy that uses IKE can be applied to more than one interface, but a manual IPsec policy can be applied to only one interface. Enabling the encryption engine The encryption engine is a coprocessor that provides an encryption/decryption algorithm interface for IPsec processing. When enabled, the encryption engine performs IPsec processing. Follow these steps to enable the encryption engine: To do Use the command Remarks Enter system view system-view Enable the encryption engine cryptoengine enable Optional Enabled by default Enabling ACL checking of de-encapsulated IPsec packets In tunnel mode, the IP packet that was encapsulated in an inbound IPsec packet may not be an object that is specified by an ACL to be protected. For example, a forged packet is not an object to be protected. If you enable ACL checking of de-encapsulated IPsec packets, all packets failing the checking will be discarded, improving the network security. Follow these steps to enable ACL checking of de-encapsulated IPsec packets: To do Use the command Remarks Enter system view system-view Enable ACL checking of de-encapsulated IPsec packets ipsec decrypt check Optional Enabled by default Configuring the IPsec anti-replay function The IPsec anti-replay function protects networks against anti-replay attacks by using a sliding window mechanism called anti-replay window. This function checks the sequence number of each received IPsec packet against the current IPsec packet sequence number range of the sliding window. If the sequence number is not in the current sequence number range, the packet is considered a replayed packet and is discarded. 178

187 IPsec packet de-encapsulation involves complicated calculation. De-encapsulation of replayed packets not only makes no sense, but also consumes large amounts of resources and degrades performance, resulting in DoS. IPsec anti-replay checking, when enabled, is performed before the de-encapsulation process, reducing resource waste. In some cases, however, the sequence numbers of some normal service data packets may be out of the current sequence number range, and the IPsec anti-replay function may drop them as well, affecting the normal communications. If this happens, disable IPsec anti-replay checking or adjust the size of the anti-replay window as required. Follow these steps to configure IPsec anti-replay checking: To do Use the command Remarks Enter system view system-view Enable IPsec anti-replay checking Set the size of the IPsec anti-replay window ipsec anti-replay check ipsec anti-replay window width Optional Enabled by default Optional 32 by default CAUTION: IPsec anti-replay checking is enabled by default. Do not disable it unless it needs to be disabled. A wider anti-replay window results in higher resource cost and more system performance degradation, which is against the original intention of the IPsec anti-replay function. Specify an anti-replay window size that is as small as possible. NOTE: IPsec anti-replay checking does not affect manually created IPsec SAs. According to the IPsec protocol, only IPsec SAs negotiated by IKE support anti-replay checking. Configuring packet information pre-extraction If you apply both an IPsec policy and QoS policy to an interface, by default, the interface first uses IPsec and then QoS to process IP packets, and QoS classifies packets by the headers of IPsec-encapsulated packets. If you want QoS to classify packets by the headers of the original IP packets, enable the packet information pre-extraction feature. For more information about QoS policy and classification, see Network Management Configuration Guide. Follow these steps to configure packet information pre-extraction: To do Use the command Remarks Enter system view system-view Enter IPsec policy view or IPsec policy template view Enable packet information pre-extraction ipsec policy policy-name seq-number [ isakmp manual ] ipsec policy-template template-name seq-number qos pre-classify Required Configure either command Required Disabled by default 179

188 Enabling invalid SPI recovery When the security gateway at one end of an IPsec tunnel loses its SAs due to rebooting or any other reason, its peer security gateway may not know the problem and send IPsec packets to it. These packets will be discarded by the receiver because the receiver cannot find appropriate SAs for them, resulting in a traffic blackhole. This situation changes only after the concerned SAs on the sender get aged out and new SAs are established between the two peers. To prevent such service interruption, configure the invalid SPI recovery feature. The invalid SPI recovery feature allows the receiver to send an INVALID SPI NOTIFY message to tell the sender the invalid SPIs. Upon receiving the message, the sender immediately deletes the corresponding SAs. The subsequent traffic triggers the two peers to set up new SAs for data transmission. Because attackers may exploit INVALID SPI NOTIFY messages to attack the IPsec packet sender (DoS attack), the invalid SPI recovery feature is disabled by default, making the receiver discard packets with invalid SPIs. Follow these steps to enable invalid SPI recovery: To do Use the command Remarks Enter system view system-view Enable invalid SPI recovery ipsec invalid-spi-recovery enable Optional Disabled by default Configuring IPsec RRI IPsec RRI works in static mode or dynamic mode. 1. Static IPsec RRI Static IPsec RRI creates static routes based on the destination address information in the ACL that the IPsec policy references. The next hop address of the route is a user specified remote peer address, or the IP address of the remote tunnel endpoint. Static IPsec RRI creates static routes immediately after you enable IPsec RRI in an IPsec policy and apply the IPsec policy. When you disable RRI, or remove the ACL or the peer gateway IP address from the policy, IPsec RRI deletes all static routes it has created. The static mode applies to scenarios where the topologies of branch networks seldom change. 2. Dynamic IPsec RRI Dynamic IPsec RRI dynamically creates static routes based on IPsec SAs. In each static route, the destination address is the address of a protected branch network, and the next hop is the user-specified remote peer address or the remote tunnel endpoint s address learned during IPsec SA negotiation. Dynamic IPsec RRI creates static routes when the IPsec SAs are established, and deletes the static routes when the IPsec SAs are deleted. The dynamic mode applies to scenarios where the topologies of branch networks change frequently. For example, when branches have dial-in users, you can configure dynamic IPsec RRI to avoid frequent configuration changes that are otherwise required on the headquarters gateway. A good practice is to configure IPsec RRI on a headquarters gateway to create static routes for the IPsec tunnels to branches. For the static routes, you can perform the following operations: 180

189 Change their route preference for equal-cost multipath (ECMP) routing or route backup. If multiple routes to the same destination have the same preference, traffic is balanced among them. If multiple routes to the same destination have different preference values, the route with the highest preference forwards traffic and all other routes are backup routes. Change their tag value so the gateway can control the use of the static routes based on routing policies. Follow these steps to configure IPsec RRI: To do Use the command Remarks Enter system view system-view Enter IPsec policy view or IPsec policy template view Enable IPsec RRI Change the preference of the static routes created by IPsec RRI Set a tag for the static routes created by IPsec RRI ipsec policy policy-name seq-number [ isakmp manual ] ipsec policy-template template-name seq-number reverse-route [ remote-peer ip-address [ gateway static ] static ] reverse-route preference preference-value reverse-route tag tag-value Required Configure either command Required Disabled by default. To enable static IPsec RRI, specify the static keyword. If the keyword is not specified, dynamic IPsec RRI is enabled. Optional 60 by default Optional 0 by default NOTE: IPsec RRI can work in both tunnel mode and transport mode. When you change the route attributes, static IPsec RRI deletes all static routes it has created and creates new static routes. In contrast, dynamic IPsec RRI applies the new attributes only to subsequent static routes. It does not delete or modify static routes it has created. Configuring tunnel interface-based IPsec NOTE: The tunnel interface-based IPsec configuration is available only at the CLI. Configuration task list The following is the generic configuration procedure for implementing tunnel interface-based IPsec: 1. Configure an IPsec proposal to specify the security protocols, authentication and encryption algorithms, and encapsulation mode. 2. Configure an IPsec profile to associate data flows with the IPsec proposal, and to specify the IKE peer parameters and the SA lifetime. 3. Configure an IPsec tunnel interface and apply the IPsec profile to the interface. 181

190 NOTE: Because packets routed to the IPsec tunnel interface are all protected, the data protection scope, which is required for IPsec policy configuration, is not needed in the IPsec profile. Complete the following tasks to configure tunnel interface-based IPsec: Task Configuring an IPsec proposal Configuring an IPsec profile Configuring an IPsec tunnel interface Enabling packet information pre-extraction on the IPsec tunnel interface Applying a QoS policy to an IPsec tunnel interface Enabling the encryption engine Configuring the IPsec anti-replay function Configuring IPsec stateful failover Remarks Required An IPsec proposal for the IPsec tunnel interface to reference supports tunnel mode only. Required Required Optional Optional Optional Optional Optional Configuring an IPsec profile As described previously, an IPsec policy is uniquely identified by its name and sequence number. An IPsec policy group is a collection of IPsec policies with the same name but different sequence numbers. In an IPsec policy group, an IPsec policy with a smaller sequence number has a higher priority. After an IPsec policy group is applied to an interface, for each packet arriving at the interface, the system checks the IPsec policies of the IPsec policy group in the ascending order of sequence numbers. One IPsec tunnel will be established for each data flow to be protected, and multiple IPsec tunnels may exist on an interface. An IPsec profile is similar to an IPsec policy. The difference is that an IPsec profile is uniquely identified by its name and it does not support ACL configuration. An IPsec profile defines the IPsec proposal to be used for protecting data flows, and specifies the parameters for IKE negotiation. After an IPsec profile is applied to an IPsec tunnel interface, only one IPsec tunnel is set up to protect all data flows that are routed to the tunnel. IPsec profiles can be applied to only IPsec tunnel interfaces. The IPsec tunnel established using an IPsec profile protects all IP data routed to the tunnel interface. Before configuring an IPsec profile, complete the following tasks: IPsec proposal configuration. For more information, see Configuring an IPsec proposal. IKE peer configuration. For more information, see the chapter IKE configuration. The parameters for the local and remote ends must match. 182

191 NOTE: During an IKE negotiation based on an IPsec profile, the source and destination addresses of the IPsec tunnel interface are used as the local and remote addresses; the local-address and remote-address commands configured for IKE negotiation do not take effect. If you do not configure the destination address of the IPsec tunnel interface, the local peer can only be an IKE negotiation responder; it cannot initiate an IKE negotiation. Follow these steps to configure an IPsec profile: To do Use the command Remarks Enter system view system-view Create an IPsec profile and enter its view ipsec profile profile-name Required By default, no IPsec profile exists. Specify the IPsec proposals for the IPsec profile to reference Specify the IKE peer for the IPsec profile to reference Enable and configure the PFS feature for the IPsec profile Set the SA lifetime Set the anti-replay information synchronization intervals in IPsec stateful failover mode proposal proposal-name&<1-6> ike-peer peer-name pfs { dh-group1 dh-group2 dh-group5 dh-group14 } sa duration { time-based seconds traffic-based kilobytes } synchronization anti-replay-interval inbound inbound-number outbound outbound-number Required By default, an IPsec profile references no IPsec proposals. Required An IPsec profile cannot reference any IKE peer that is already referenced by an IPsec policy, and vice versa. Optional By default, the PFS feature is not used. For more information about PFS, see the chapter IKE configuration. Optional By default, the SA lifetime of an IPsec profile equals the current global SA lifetime. Optional By default, the inbound anti-replay window information is synchronized whenever 1000 packets are received, and the outbound anti-replay sequence number is synchronized whenever packets are sent. Return to system view quit Set the global SA lifetime ipsec sa global-duration { time-based seconds traffic-based kilobytes } Optional 3600 seconds for time-based SA lifetime by default kilobytes for traffic-based SA lifetime by default. 183

192 Configuring an IPsec tunnel interface An IPsec tunnel interface uses IPsec as the encapsulation protocol. To configure an IPsec tunnel interface, complete the following tasks: 1. Create a tunnel interface and set the tunnel mode to IPsec over IPv4. 2. Specify the source address or source interface of the IPsec tunnel interface, which will be used as the local address in IKE negotiation. 3. Configure the destination addresses of the tunnel interface for the local peer to initiate an IKE negotiation. If you want the local peer to act only as an IKE negotiation responder, omit this configuration. 4. Apply an IPsec profile to the IPsec tunnel interface. After the link layer of the IPsec tunnel interface comes up, packets routed to the tunnel interface will be protected by IPsec. To make sure that the link layer of the IPsec tunnel interface comes up, make sure the following requirements are met: The source address of the tunnel interface is the IP address of the local physical interface that connects to the remote. The IPsec tunnel interfaces of the IPsec tunnel are configured with proper IPsec profiles. The expected IKE SA and IPsec SAs are established between the local security gateway and the peer gateway. Use the display ike sa command to view the status the IKE SA and the IPsec SAs. Follow these steps to configure an IPsec tunnel interface: To do Use the command Remarks Enter system view system-view Create a tunnel interface and enter its view Assign an IPv4 address to the tunnel interface Set the tunnel mode of the tunnel interface to IPsec over IPv4 Specify the source address or interface of the tunnel interface Specify the destination address of the tunnel interface Apply an IPsec profile to the tunnel interface interface tunnel number ip address ip-address { mask mask-length } [ sub ] tunnel-protocol ipsec ipv4 source { ip-address interface-type interface-number } destination ip-address ipsec profile profile-name Required By default, no tunnel interface exists on the device. Required By default, no IPv4 address is assigned to a tunnel interface. Required Required By default, no source address or interface is specified for a tunnel interface. If you specify an interface, the tunnel interface will take the primary IP address of the source interface. Optional for an IKE negotiation responder, and required for an IKE negotiation initiator By default, no tunnel destination address is configured. Required 184

193 NOTE: An IPsec profile can be applied to an IPsec tunnel interface only. An IPsec tunnel interface can reference only one IPsec profile. Apply an IPsec profile to only one IPsec tunnel interface. Although an IPsec profile can be applied to multiple IPsec tunnel interfaces, it takes effect only on the IPsec tunnel interface that goes up first. Enabling packet information pre-extraction on the IPsec tunnel interface Because packets that an IPsec tunnel interface passes to a physical interface are encapsulated, the QoS module cannot obtain the 5-tuple (source IP, destination IP, source port, destination port, and protocol) of the original packets. To address this problem, enable packet information pre-extraction on the tunnel interface. With packet information pre-extraction enabled, an IPsec tunnel interface buffers the IP 5-tuple data in the original packets, so that the corresponding physical interface can perform QoS processing such as traffic classification, IP precedence setting, rate limit, and congestion avoidance. To implement QoS for IPsec packets, however, you also need to apply a QoS policy to the physical outbound interface. For more information about how to apply a QoS policy to a physical interface, see Network Management Configuration Guide. Follow these steps to enable packet information pre-extraction on an IPsec tunnel interface: To do Use the command Remarks Enter system view system-view Enter tunnel interface view interface tunnel number Enable packet information pre-extraction qos pre-classify Required Disabled by default. CAUTION: When the QoS policy applied to the physical outbound interface provides congestion management, IPsec packets arriving at the destination may be out of order. This may cause IPsec out of order to be dropped by the IPsec anti-replay function. For more information, see Configuring the IPsec anti-replay function. Applying a QoS policy to an IPsec tunnel interface The device allows you to apply a QoS policy to the IPsec tunnel interface. In this case, QoS is performed before IPsec encapsulation, and the priority of a resulting packet is the same as that of the original packet. In addition, the QoS congestion management is done to the packets before encapsulation, avoiding the disorder of IPsec packets. This method is much more explicit and flexible than the QoS implementation method of enabling packet information pre-extraction on the IPsec tunnel interface, which requires applying a QoS policy to the physical outbound interface. Follow these steps to apply a QoS policy to an IPsec tunnel interface: 185

194 To do Use the command Remarks Enter system view system-view Enter tunnel interface view interface tunnel number Apply a QoS policy to the IPsec tunnel interface qos apply policy policy-name { inbound outbound } Required Configuring IPsec for IPv6 routing protocols NOTE: The IPsec for IPv6 routing protocols configuration is available only at the CLI. The following is the generic configuration procedure for configuring IPsec for IPv6 routing protocols: 1. Configure an IPsec proposal to specify the security protocols, authentication and encryption algorithms, and encapsulation mode. 2. Configure a manual IPsec policy to specify the keys and SPI. 3. Apply the IPsec policy to an IPv6 routing protocol. Complete the following tasks to configure IPsec for IPv6 routing protocols: Task Configuring an IPsec proposal Configuring a manual IPsec policy Applying an IPsec policy to an IPv6 routing protocol Remarks Required Required ACLs and IPsec tunnel addresses are not needed. Required See Network Management Configuration Guide. Configuring IPsec stateful failover CAUTION: In an IPsec stateful failover scenario, these restrictions apply: VRRP must work in the standard protocol mode. Only the active/standby stateful failover mode is supported; the active/active mode is not. RSA signature authentication is not supported in IKE negotiation. The keepalive mechanism for IKE to maintain the link status of ISAKMP SAs is not supported. The IPsec stateful failover configuration is available only at the CLI. Configuration prerequisites Before you configure IPsec stateful failover, complete the following configurations on the two devices. 1. Configure stateful failover Configure the devices to work in the active/standby mode. 186

195 Specify the failover interface for transferring state negotiation messages and backing up IPsec service data. For more information about stateful failover, see High Availability Configuration Guide. Configure VRRP On each device, configure a VRRP group for the uplink interface and a VRRP group for the downlink interface, and assign virtual IP addresses to the groups. Set the priorities of the devices in the groups, making sure that one of the devices is the master in both VRRP groups. Configure the devices to work in the same mode (preemption mode or non-preemptive mode) in both the VRRP groups. To deploy the preemption mode, set the preemption delay of the backup to 0 so that the backup can immediately take over when the priority of the master comes down, and set the preemption delay of the backup to a bigger value such as 255 seconds so that the master has enough time to synchronize IPsec service data from the backup after it recovers. For more information about VRRP, see High Availability Configuration Guide. 2. Configure IPsec and IKE Create and configure the same IKE peers on the two devices. The local gateway addresses of the IKE peers must be the virtual IP address of the VRRP group for the uplink interface. Create and configure the same IPsec policies or IPsec profiles that use IKE on the two devices. Apply the IPsec policies or IPsec profiles to the uplink interfaces on the two devices. If you change the virtual IP address after applying the IPsec policy to an interface, be sure to re-apply the IPsec policy to the interface. Configuration procedure To implement IPsec stateful failover on two devices, you must make sure that IPsec stateful failover is enabled on both devices. Follow these steps to enable IPsec stateful failover on a device: To do Use the command Remarks Enter system view system-view Enable IPsec stateful failover ipsec synchronization enable Optional By default, IPsec stateful failover is enabled. Displaying and maintaining IPsec To do Use the command Remarks Display IPsec policy information Display IPsec policy template information display ipsec policy [ brief name policy-name [ seq-number ] ] [ { begin exclude include } regular-expression ] display ipsec policy-template [ brief name template-name [ seq-number ] ] [ { begin exclude include } regular-expression ] Available in any view Available in any view 187

196 To do Use the command Remarks Display the configuration of IPsec profiles Display IPsec proposal information Display IPsec SA information Display IPsec packet statistics Display IPsec tunnel information Clear SAs display ipsec profile [ name profile-name ] [ { begin exclude include } regular-expression ] display ipsec proposal [ proposal-name ] [ { begin exclude include } regular-expression ] display ipsec sa [ brief policy policy-name [ seq-number ] remote ip-address ] [ { begin exclude include } regular-expression ] display ipsec statistics [ tunnel-id integer ] [ { begin exclude include } regular-expression ] display ipsec tunnel [ { begin exclude include } regular-expression ] reset ipsec sa [ parameters dest-address protocol spi policy policy-name [ seq-number ] remote ip-address ] Available in any view Available in any view Available in any view Available in any view Available in any view Available in user view Clear IPsec statistics reset ipsec statistics Available in user view IPsec configuration examples Manual mode IPsec tunnel for IPv4 packets configuration example in the web interface Network requirements As shown in Figure 120, configure an IPsec tunnel between Device A and Device B to protect traffic between subnet /24 and subnet /24. Configure the tunnel to use the security protocol ESP, the encryption algorithm DES, and the authentication algorithm SHA-1. Enable IPsec RRI on Device A and specify the next hop as Figure 120 Network diagram 188

197 Configuring Device A # Assign IP addresses for the interfaces and then add them to target zones. (Details not shown) # Define ACL 3101 to permit packets from subnet /24 to subnet /24. Select Firewall > ACL from the navigation tree, click Add, and then perform the configurations shown in Figure 121. Figure 121 Create ACL 3101 Enter 3101 as the ACL number. Select the match order of Config. Click Apply. From the ACL list, select ACL 3101 and click the icon. Then, click Add to enter the ACL rule configuration page and perform the configurations shown in Figure 122. Figure 122 Configure a rule to permit packets from /24 to /24 Select Permit from the Operation drop-down box. Select Source IP Address and enter and respectively in the following fields. 189

198 Select Destination IP Address and enter and respectively in the following fields. Click Apply. # Configure an IPsec proposal named tran1, and configure the proposal as follows. Select VPN > IPSec > Proposal from the navigation tree, click Add, select Custom mode from the IPSec Proposal Configuration Wizard page, and perform the configurations shown in Figure 123. Figure 123 Configure IPsec proposal tran1 Enter tran1 as the name of the IPsec proposal. Select Tunnel as the packet encapsulation mode. Select ESP as the security protocol. Select SHA1 as the ESP authentication algorithm. Select DES as the ESP encryption algorithm. Click Apply. # Configure the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add to enter the IKE peer configuration page. Perform the configurations shown in Figure

199 Figure 124 Configure an IKE peer Enter peer as the peer name. Select Main as the negotiation mode. Enter as the IP address of the remote gateway. Select Pre-Shared Key and enter abcde as the pre-shared key. Click Apply. # Configure an IPsec policy. Select VPN > IPSec > Policy from the navigation tree and then click Add to enter the IPsec policy configuration page appears. Perform the configurations shown in Figure

200 Figure 125 Configure an IPsec policy Enter map1 as the policy name. Enter 10 as the sequence number. Select the IKE peer of peer. Select the IPsec proposal of tran1 and click <<. Enter 3101 as the ACL. Select Enable for RRI. Enter as the next hop. Click Apply. # Apply the IPsec policy to interface GigabitEthernet 0/1. Select VPN > IPSec > IPSec Application from the navigation tree, and then click the icon of interface Serial 2/1 to enter the IPsec application page. Perform the configurations shown in Figure

201 Figure 126 Apply IPsec policy to interface GigabitEthernet 0/1 Select the policy of map1. Click Apply. Configuring Device B NOTE: The configuration steps on Device B are similar to those on Device A. The configuration pages are not shown. # Assign IP addresses for the interfaces and then add them to the target zones. (Details not shown) # Define an ACL to permit traffic from subnet /24 to subnet /24. Select Firewall > ACL from the navigation tree, and then click Add. Enter 3101 as the ACL number. Select the match order of Config. Click Apply. From the ACL list, select ACL 3101 and click the icon. Then, click Add to enter the ACL rule configuration page. Select Permit from the Operation drop-down box. Select Source IP Address and enter and respectively in the following fields. Select Destination IP Address and enter and respectively in the following fields. Click Apply. # Configure a static route to Host A. Select Network > Routing Management > Static Routing from the navigation tree, and then click Add. Enter as the destination IP address. Enter as the mask. Select GigabitEthernet0/1 as the outbound interface. Click Apply. # Configure an IPsec proposal named tran1. Select VPN > IPSec > Proposal from the navigation tree and then click Add. Select Custom mode from the IPSec Proposal Configuration Wizard page. Enter tran1 as the name of the IPsec proposal. Select Tunnel as the packet encapsulation mode. Select ESP as the security protocol. 193

202 Select SHA1 as the ESP authentication algorithm. Select DES as the ESP encryption algorithm. Click Apply. # Configure IKE peer peer. Select VPN > IKE > Peer from the navigation tree and then click Add. Enter peer as the peer name. Select Main as the negotiation mode. Enter as the IP address of the remote gateway. Select Pre-Shared Key and enter abcde as the pre-shared key. Click Apply. # Configure IPsec policy map1. Select VPN > IPSec > Policy from the navigation tree and then click Add. Enter map1 as the policy name. Enter 10 as the sequence number. Select the IKE peer of peer. Select the IPsec proposal of tran1 and click <<. Enter 3101 as the ACL. Click Apply. # Apply IPsec policy map1 to GigabitEthernet 0/1. Select VPN > IPSec > IPSec Application from the navigation tree, and then click the icon of interface GigabitEthernet 0/1. Select the policy of map1. Click Apply. Verifying the configuration After you complete the configuration, packets to be exchanged between subnet /24 and subnet /24 triggers the negotiation of SAs by IKE. After IKE negotiation succeeds and the IPsec SAs are established, a static route to subnet /24 via is added to the routing table on Device A, and traffic between subnet /24 and subnet /24 is protected by IPsec. Manual mode IPsec tunnel for IPv4 packets configuration example at the CLI Network requirements As shown in Figure 127, configure an IPsec tunnel between Firewall A and Firewall B to protect data flows between subnet /24 and subnet /24. Configure the tunnel to use the security protocol ESP, the encryption algorithm DES, and the authentication algorithm SHA1-HMAC

203 Figure 127 Network diagram Configuring Firewall A # Define an ACL to identify data flows from subnet /24 to subnet /24. <FirewallA> system-view [FirewallA] acl number 3101 [FirewallA-acl-adv-3101] rule permit ip source destination [FirewallA-acl-adv-3101] quit # Configure a static route to Host B. [FirewallA] ip route-static GigabitEthernet 0/2 # Create an IPsec proposal named tran1. [FirewallA] ipsec proposal tran1 # Specify the encapsulation mode as tunnel. [FirewallA-ipsec-proposal-tran1] encapsulation-mode tunnel # Specify the security protocol as ESP. [FirewallA-ipsec-proposal-tran1] transform esp # Specify the algorithms for the proposal. [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Create manual IPsec policy map1. [FirewallA] ipsec policy map1 10 manual # Apply the ACL. [FirewallA-ipsec-policy-manual-map1-10] security acl 3101 # Apply the IPsec proposal. [FirewallA-ipsec-policy-manual-map1-10] proposal tran1 # Configure the remote IP address of the tunnel. [FirewallA-ipsec-policy-manual-map1-10] tunnel remote # Configure the local IP address of the tunnel. [FirewallA-ipsec-policy-manual-map1-10] tunnel local # Configure the SPIs. [FirewallA-ipsec-policy-manual-map1-10] sa spi outbound esp [FirewallA-ipsec-policy-manual-map1-10] sa spi inbound esp

204 # Configure the keys. [FirewallA-ipsec-policy-manual-map1-10] sa string-key outbound esp abcdefg [FirewallA-ipsec-policy-manual-map1-10] sa string-key inbound esp gfedcba [FirewallA-ipsec-policy-manual-map1-10] quit # Configure the IP address of the GigabitEthernet interface. [FirewallA] interface GigabitEthernet 0/2 [FirewallA-GigabitEthernet0/2] ip address # Apply the IPsec policy group to the interface. [FirewallA-GigabitEthernet0/2] ipsec policy map1 Configuring Firewall B # Define an ACL to identify data flows from subnet /24 to subnet /24. <FirewallB> system-view [FirewallB] acl number 3101 [FirewallB-acl-adv-3101] rule permit ip source destination [FirewallB-acl-adv-3101] quit # Configure a static route to Host A. [FirewallB] ip route-static GigabitEthernet 0/2 # Create an IPsec proposal named tran1. [FirewallB] ipsec proposal tran1 # Specify the encapsulation mode as tunnel. [FirewallB-ipsec-proposal-tran1] encapsulation-mode tunnel # Specify the security protocol as ESP. [FirewallB-ipsec-proposal-tran1] transform esp # Specify the algorithms for the proposal. [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit # Create a manual IPsec policy. [FirewallB] ipsec policy use1 10 manual # Apply the ACL. [FirewallB-ipsec-policy-manual-use1-10] security acl 3101 # Apply the IPsec proposal. [FirewallB-ipsec-policy-manual-use1-10] proposal tran1 # Configure the remote IP address of the tunnel. [FirewallB-ipsec-policy-manual-use1-10] tunnel remote # Configure the local IP address of the tunnel. [FirewallB-ipsec-policy-manual-use1-10] tunnel local # Configure the SPIs. [FirewallB-ipsec-policy-manual-use1-10] sa spi outbound esp [FirewallB-ipsec-policy-manual-use1-10] sa spi inbound esp # Configure the keys. [FirewallB-ipsec-policy-manual-use1-10] sa string-key outbound esp gfedcba 196

205 [FirewallB-ipsec-policy-manual-use1-10] sa string-key inbound esp abcdefg [FirewallB-ipsec-policy-manual-use1-10] quit # Configure the IP address of the GigabitEthernet interface. [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address # Apply the IPsec policy group to the interface. [FirewallB-GigabitEthernet0/2] ipsec policy use1 Verifying the configuration After the configuration, an IPsec tunnel between Firewall A and Firewall B should be established, and the traffic between subnet /24 and subnet /24 should be IPsec protected. IKE-based IPsec tunnel for IPv4 packets configuration example Network requirements As shown in Figure 127, configure an IPsec tunnel between Firewall A and Firewall B to protect data flows between subnet /24 and subnet /24. Configure the tunnel to use the security protocol ESP, the encryption algorithm DES, and the authentication algorithm SHA1-HMAC-96. Configuring Firewall A # Define an ACL to identify data flows from subnet /24 to subnet /24. <FirewallA> system-view [FirewallA] acl number 3101 [FirewallA-acl-adv-3101] rule permit ip source destination [FirewallA-acl-adv-3101] quit # Configure a static route to Host B. [FirewallA] ip route-static GigabitEthernet 0/2 # Create an IPsec proposal named tran1. [FirewallA] ipsec proposal tran1 # Specify the encapsulation mode as tunnel. [FirewallA-ipsec-proposal-tran1] encapsulation-mode tunnel # Specify the security protocol as ESP. [FirewallA-ipsec-proposal-tran1] transform esp # Specify the algorithms for the proposal. [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Configure the IKE peer. [FirewallA] ike peer peer [FirewallA-ike-peer-peer] pre-shared-key abcde [FirewallA-ike-peer-peer] remote-address [FirewallA-ike-peer-peer] quit # Create an IPsec policy that uses IKE for IPsec SA negotiation. [FirewallA] ipsec policy map1 10 isakmp 197

206 # Apply the IPsec proposal. [FirewallA-ipsec-policy-isakmp-map1-10] proposal tran1 # Apply the ACL. [FirewallA-ipsec-policy-isakmp-map1-10] security acl 3101 # Apply the IKE peer. [FirewallA-ipsec-policy-isakmp-map1-10] ike-peer peer [FirewallA-ipsec-policy-isakmp-map1-10] quit # Configure the IP address of the GigabitEthernet interface. [FirewallA] interface GigabitEthernet 0/2 [FirewallA-GigabitEthernet0/2] ip address # Apply the IPsec policy group to the interface. [FirewallA-GigabitEthernet0/2] ipsec policy map1 Configuring Firewall B # Define an ACL to identify data flows from subnet /24 to subnet /24. <FirewallB> system-view [FirewallB] acl number 3101 [FirewallB-acl-adv-3101] rule permit ip source destination [FirewallB-acl-adv-3101] quit # Configure a static route to Host A. [FirewallB] ip route-static GigabitEthernet 0/2 # Create an IPsec proposal named tran1. [FirewallB] ipsec proposal tran1 # Specify the encapsulation mode as tunnel. [FirewallB-ipsec-proposal-tran1] encapsulation-mode tunnel # Specify the security protocol as ESP. [RouterB-ipsec-proposal-tran1] transform esp # Specify the algorithms for the proposal. [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit # Configure the IKE peer. [FirewallB] ike peer peer [FirewallB-ike-peer-peer] pre-shared-key abcde [FirewallB-ike-peer-peer] remote-address [FirewallB-ike-peer-peer] quit # Create an IPsec policy that uses IKE for IPsec SA negotiation. [FirewallB] ipsec policy use1 10 isakmp # Apply the ACL. [FirewallB-ipsec-policy-isakmp-use1-10] security acl 3101 # Apply the IPsec proposal. [FirewallB-ipsec-policy-isakmp-use1-10] proposal tran1 # Apply the IKE peer. 198

207 [FirewallB-ipsec-policy-isakmp-use1-10] ike-peer peer [FirewallB-ipsec-policy-isakmp-use1-10] quit # Configure the IP address of the GigabitEthernet interface. [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ip address # Apply the IPsec policy group to the interface. [FirewallB-GigabitEthernet0/2] ipsec policy use1 Verifying the configuration After the configuration, IKE negotiation will be triggered to set up SAs when there is traffic between subnet /24 and subnet /24. If IKE negotiation is successful and SAs are set up, the traffic between the two subnets will be IPsec protected. IPsec with IPsec tunnel interfaces configuration example Network requirements As shown in Figure 128, the gateway of the branch accesses the Internet through a dial-up line and obtains the IP address dynamically. The headquarters accesses the Internet by using a fixed IP address. Configure an IPsec tunnel to protect the traffic between the branch and the headquarters. Make sure that the IPsec configuration of the headquarters gateway remains relatively stable despite of changes of the branch's private IP address segment. Figure 128 Network diagram Configuation considerations To meet the requirements, configure an IPsec tunnel interface on each Firewall and configure a static route on each Firewall to route the packets destined to the peer to the IPsec tunnel interface for IPsec protection. Configuring Firewall A # Name the local gateway Firewalla. <FirewallA> system-view [FirewallA] ike local-name Firewalla # Configure an IKE peer named atob. As the local peer obtains the IP address automatically, set the IKE negotiation mode to aggressive. [FirewallA] ike peer atob [FirewallA-ike-peer-atob] exchange-mode aggressive [FirewallA-ike-peer-atob] pre-shared-key simple aabb 199

208 [FirewallA-ike-peer-atob] id-type name [FirewallA-ike-peer-atob] remote-name Firewallb [FirewallA-ike-peer-atob] quit # Create an IPsec proposal named method1. This proposal uses the default settings: the security protocol of ESP, the encryption algorithm of DES, and the authentication algorithm of MD5. [FirewallA] ipsec proposal method1 [FirewallA-ipsec-proposal-method1] quit # Create an IPsec profile named atob. [FirewallA] ipsec profile atob # Configure the IPsec profile to reference the IKE peer. [FirewallA-ipsec-profile-atob] ike-peer atob # Configure the IPsec profile to reference the IPsec proposal method1. [FirewallA-ipsec-profile-atob] proposal method1 [FirewallA-ipsec-profile-atob] quit # Create tunnel interface Tunnel 1. [FirewallA] interface tunnel 1 # Assign IPv4 address /24 to tunnel interface Tunnel 1. [FirewallA Tunnel1] ip address # Set the tunnel mode of tunnel interface Tunnel 1 to IPsec over IPv4. [FirewallA Tunnel1] tunnel-protocol ipsec ipv4 # Set the source interface of the tunnel to GigabitEthernet 0/1 on Tunnel 1. [FirewallA Tunnel1] source GigabitEthernet 0/1 # Set the tunnel destination address to , the source address of the remote peer. [FirewallA Tunnel1] destination # Apply IPsec profile atob to tunnel interface Tunnel 1. [FirewallA Tunnel1] ipsec profile atob [FirewallA Tunnel1] quit # Configure a static route to Firewall B. [FirewallA] ip route-static tunnel 1 Configuring Firewall B # Assign an IP address to interface GigabitEthernet 0/1. <FirewallB> system-view [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ip address [FirewallB-GigabitEthernet0/1] quit # Name the local gateway Firewallb. [FirewallB] ike local-name Firewallb # Configure an IKE peer named btoa. As the remote peer obtains the IP address automatically, set the IKE negotiation mode to aggressive. [FirewallB] ike peer btoa [FirewallB-ike-peer-btoa] exchange-mode aggressive [FirewallB-ike-peer-btoa] pre-shared-key simple aabb [FirewallB-ike-peer-btoa] id-type name 200

209 [FirewallB-ike-peer-btoa] remote-name Firewalla [FirewallB-ike-peer-btoa] quit # Create an IPsec proposal named method1. This proposal uses the default settings: the security protocol of ESP, the encryption algorithm of DES, and the authentication algorithm of MD5. [FirewallB] ipsec proposal method1 [FirewallB-ipsec-proposal-method1] quit # Create an IPsec profile named btoa. [FirewallB] ipsec profile btoa # Configure the IPsec profile to reference the IKE peer. [FirewallB-ipsec-profile-btoa] ike-peer btoa # Configure the IPsec profile to reference the IPsec proposal method1. [FirewallB-ipsec-profile-btoa] proposal method1 [FirewallB-ipsec-profile-btoa] quit # Create tunnel interface Tunnel 1. This interface will be used to protect the data flows between Firewall B and Firewall A. As the public IP address of the remote peer is not known, you do not need to configure the destination address on the tunnel interface. [FirewallB] interface tunnel 1 # Assign IPv4 address /24 to tunnel interface Tunnel 1. [FirewallB Tunnel1] ip address # Set the tunnel mode of tunnel interface Tunnel 1 to IPsec over IPv4. [FirewallB Tunnel1] tunnel-protocol ipsec ipv4 # Set the source interface of the tunnel to GigabitEthernet 0/1 on Tunnel 1. [FirewallB Tunnel1] source GigabitEthernet 0/1 # Apply IPsec profile btoa to tunnel interface Tunnel 1. [FirewallB Tunnel1] ipsec profile btoa [FirewallB Tunnel1] quit # Configure a static route to Firewall A. [FirewallB] ip route-static tunnel 1 Verifying the configuration After the configuration, IKE negotiation will be triggered to set up SAs when GigabitEthernet 0/1 on Firewall A complements the dial-up process. If IKE negotiation is successful and SAs are set up, the IPsec tunnel between Firewall A and Firewall B is up, and provides protection for packets traveling through it. Using the display brief interface command on Firewall B, you will see the link status of the IPsec tunnel interface is up. [FirewallB] display brief interface tunnel 1 The brief information of interface(s) under route mode: Interface Link Protocol-link Protocol type Main IP Tun1 UP UP TUNNEL Using the display ike sa command on Firewall B, you will see that the SAs of two phases are established. [FirewallB] display ike sa total phase-1 SAs: 1 connection-id peer flag phase doi RD 2 IPSEC 201

210 RD 1 IPSEC flag meaning RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO TIMEOUT You can also view the IPsec SA information. [FirewallB] display ipsec sa =============================== Interface: Tunnel1 path MTU: 1443 =============================== IPsec policy name: "btoa" sequence number: 1 mode: tunnel connection id: 3 encapsulation mode: tunnel perfect forward secrecy: tunnel: local address: remote address: flow : sour addr: / port: 0 protocol: IP dest addr: / port: 0 protocol: IP [inbound ESP SAs] spi: (0x75b6ef44) proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3503 max received sequence-number: 5 anti-replay check enable: Y anti-replay window size: 32 udp encapsulation used for nat traversal: N [outbound ESP SAs] spi: (0x8cf16c54) proposal: ESP-ENCRYPT-DES ESP-AUTH-MD5 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3503 max sent sequence-number: 6 udp encapsulation used for nat traversal: N On Firewall B, ping the IP address of the interface on Firewall A that connects to the branch. [FirewallB] ping -a PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=15 ms Reply from : bytes=56 Sequence=2 ttl=255 time=10 ms 202

211 Reply from : bytes=56 Sequence=3 ttl=255 time=10 ms Reply from : bytes=56 Sequence=4 ttl=255 time=5 ms Reply from : bytes=56 Sequence=5 ttl=255 time=4 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 4/8/15 ms Similarly, you can view the information on Firewall A. (Details not shown) IPsec for RIPng configuration example NOTE: The IPsec configuration procedures for protecting OSPFv3 and IPv6 BGP are similar. For more information about RIPng, OSPFv3, and IPv6 BGP, see Network Management Configuration Guide. Network requirements As shown in Figure 129, Firewall A, Firewall B, and Firewall C are connected. They learn IPv6 routing information through RIPng. Configure IPsec for RIPng so that RIPng packets exchanged between the routers are transmitted through an IPsec tunnel. Configure IPsec to use the security protocol ESP, the encryption algorithm DES, and the authentication algorithm SHA1-HMAC-96. Figure 129 Network diagram Configuation considerations To meet the requirements, perform the following configuration tasks: Configure basic RIPng parameters. Configure a manual IPsec policy. Apply the IPsec policy to a RIPng process to protect RIPng packets in this process or to an interface to protect RIPng packets traveling through the interface. Configuring Firewall A # Assign an IPv6 address to each interface. (Details not shown) # Create a RIPng process and enable it on GigabitEthernet 0/1. <FirewallA> system-view [FirewallA] ripng 1 [FirewallA-ripng-1] quit [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ripng 1 enable [FirewallA-GigabitEthernet0/1] quit 203

212 # Create an IPsec proposal named tran1, and set the encapsulation mode to transport mode, the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1-HMAC-96. [FirewallA] ipsec proposal tran1 [FirewallA-ipsec-proposal-tran1] encapsulation-mode transport [FirewallA-ipsec-proposal-tran1] transform esp [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Create an IPsec policy named policy001, specify the manual mode for it, set the SPIs of the inbound and outbound SAs to , and the keys for the inbound and outbound SAs using ESP to abcdefg. [FirewallA] ipsec policy policy manual [FirewallA-ipsec-policy-manual-policy001-10] proposal tran1 [FirewallA-ipsec-policy-manual-policy001-10] sa spi outbound esp [FirewallA-ipsec-policy-manual-policy001-10] sa spi inbound esp [FirewallA-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg [FirewallA-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg [FirewallA-ipsec-policy-manual-policy001-10] quit # Apply IPsec policy policy001 to the RIPng process. [FirewallA] ripng 1 [FirewallA-ripng-1] enable ipsec-policy policy001 [FirewallA-ripng-1] quit Configuring Firewall B # Assign an IPv6 address to each interface. (Details not shown) # Create a RIPng process and enable it on GigabitEthernet 0/1 and GigabitEthernet 0/2. <FirewallB> system-view [FirewallB] ripng 1 [FirewallB-ripng-1] quit [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ripng 1 enable [FirewallB-GigabitEthernet0/1] quit [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ripng 1 enable [FirewallB-GigabitEthernet0/2] quit # Create an IPsec proposal named tran1, and set the encapsulation mode to transport mode, the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1-HMAC-96. [FirewallB] ipsec proposal tran1 [FirewallB-ipsec-proposal-tran1] encapsulation-mode transport [FirewallB-ipsec-proposal-tran1] transform esp [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit # Create an IPsec policy named policy001, specify the manual mode for it, configure the SPIs of the inbound and outbound SAs as , and the keys for the inbound and outbound SAs using ESP as abcdefg. [FirewallB] ipsec policy policy manual [FirewallB-ipsec-policy-manual-policy001-10] proposal tran1 204

213 [FirewallB-ipsec-policy-manual-policy001-10] sa spi outbound esp [FirewallB-ipsec-policy-manual-policy001-10] sa spi inbound esp [FirewallB-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg [FirewallB-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg [FirewallB-ipsec-policy-manual-policy001-10] quit # Apply IPsec policy policy001 to the RIPng process. [FirewallB] ripng 1 [FirewallB-ripng-1] enable ipsec-policy policy001 [FirewallB-ripng-1] quit Configuring Firewall C # Assign an IPv6 address to each interface. (Details not shown) # Create a RIPng process and enable it on GigabitEthernet 0/1. <FirewallC> system-view [FirewallC] ripng 1 [FirewallC-ripng-1] quit [FirewallC] interface GigabitEthernet 0/1 [FirewallC-GigabitEthernet0/1] ripng 1 enable [FirewallC-GigabitEthernet0/1] quit # Create an IPsec proposal named tran1, and set the encapsulation mode to transport mode, the security protocol to ESP, the encryption algorithm to DES, and authentication algorithm to SHA1-HMAC-96. [FirewallC] ipsec proposal tran1 [FirewallC-ipsec-proposal-tran1] encapsulation-mode transport [FirewallC-ipsec-proposal-tran1] transform esp [FirewallC-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallC-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallC-ipsec-proposal-tran1] quit # Create an IPsec policy named policy001, specify the manual mode for it, and configure the SPIs of the inbound and outbound SAs as , and the keys for the inbound and outbound SAs using ESP as abcdefg. [FirewallC] ipsec policy policy manual [FirewallC-ipsec-policy-manual-policy001-10] proposal tran1 [FirewallC-ipsec-policy-manual-policy001-10] sa spi outbound esp [FirewallC-ipsec-policy-manual-policy001-10] sa spi inbound esp [FirewallC-ipsec-policy-manual-policy001-10] sa string-key outbound esp abcdefg [FirewallC-ipsec-policy-manual-policy001-10] sa string-key inbound esp abcdefg [FirewallC-ipsec-policy-manual-policy001-10] quit # Apply IPsec policy policy001 to the RIPng process. [FirewallC] ripng 1 [FirewallC-ripng-1] enable ipsec-policy policy001 [FirewallC-ripng-1] quit Verifying the configuration After the configuration, Firewall A, Firewall B, and Firewall C learn IPv6 routing information through RIPng. SAs are set up successfully, and the IPsec tunnel between two peers is up for protecting the RIPng packets. 205

214 Using the display ripng command on Firewall A, you will see the running status and configuration information of the specified RIPng process. The output shows that IPsec policy policy001 is applied to this process successfully. <FirewallA> display ripng 1 RIPng process : 1 Preference : 100 Checkzero : Enabled Default Cost : 0 Maximum number of balanced paths : 8 Update time : 30 sec(s) Timeout time : 180 sec(s) Suppress time : 120 sec(s) Garbage-Collect time : 120 sec(s) Number of periodic updates sent : 186 Number of trigger updates sent : 1 IPsec policy name: policy001, SPI: Using the display ipsec sa command on Firewall A, you will see the information about the inbound and outbound SAs. <FirewallA> display ipsec sa =============================== Protocol: RIPng =============================== IPsec policy name: "policy001" sequence number: 10 mode: manual connection id: 1 encapsulation mode: transport perfect forward secrecy: tunnel: flow: [inbound ESP SAs] spi: (0x3039) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 No duration limit for this sa [outbound ESP SAs] spi: (0x3039) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 No duration limit for this sa Similarly, you can view the information on Firewall B and Firewall C. (Details not shown) 206

215 IPsec RRI configuration example Network requirements As shown in Figure 130, configure an IPsec tunnel between Firewall A and Firewall B to protect the traffic between the headquarters and the branch. Configure the tunnel to use the security protocol ESP, the encryption algorithm DES, and the authentication algorithm SHA1-HMAC-96. Use IKE for automatic SA negotiation. Configure IPsec RRI on Firewall A to automatically create a static route to the branch based on the established IPsec SAs. Specify the next hop of the route as Figure 130 Network diagram Configuring Firewall A NOTE: Assign IPv4 Address to the interfaces. Make sure that Firewall A and Firewall B have IP connectivity between them. # Configure ACL 3101 to identify traffic from subnet /24 to subnet /24. <FirewallA> system-view [FirewallA] acl number 3101 [FirewallA-acl-adv-3101] rule permit ip source destination [FirewallA-acl-adv-3101] quit # Create IPsec proposal tran1. [FirewallA] ipsec proposal tran1 # Set the packet encapsulation mode to tunnel. [FirewallA-ipsec-proposal-tran1] encapsulation-mode tunnel # Use ESP as the security protocol. [FirewallA-ipsec-proposal-tran1] transform esp # Use DES as the encryption algorithm and SHA1-HMAC-96 as the authentication algorithm. [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Create IKE peer peer. 207

216 [FirewallA] ike peer peer # Set the pre-shared key. [FirewallA-ike-peer-peer] pre-shared-key abcde # Specify the IP address of the peer security gateway. [FirewallA-ike-peer-peer] remote-address [FirewallA-ike-peer-peer] quit # Create an IPsec policy that uses IKE. [FirewallA] ipsec policy map1 10 isakmp # Reference IPsec proposal tran1. [FirewallA-ipsec-policy-isakmp-map1-10] proposal tran1 # Reference ACL 3101 to identify the protected traffic. [FirewallA-ipsec-policy-isakmp-map1-10] security acl 3101 # Reference IKE peer peer. [FirewallA-ipsec-policy-isakmp-map1-10] ike-peer peer # Enable dynamic IPsec RRI and use as the next hop of the static route. [FirewallA-ipsec-policy-isakmp-map1-10] reverse-route remote-peer [FirewallA-ipsec-policy-isakmp-map1-10] quit # Apply IPsec policy map1 to interface GigabitEthernet 0/1. [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] ipsec policy map1 [FirewallA-GigabitEthernet0/1] quit Configuring Firewall B NOTE: Assign IPv4 Address to the interfaces. Make sure that Firewall A and Firewall B have IP connectivity between them. # Configure ACL 3101 to identify traffic from subnet /24 to subnet /24. <FirewallB> system-view [FirewallB] acl number 3101 [FirewallB-acl-adv-3101] rule permit ip source destination [FirewallB-acl-adv-3101] quit # Configure a static route to subnet /24. [FirewallB] ip route-static # Create IPsec proposal tran1. [FirewallB] ipsec proposal tran1 # Set the packet encapsulation mode to tunnel. [FirewallB-ipsec-proposal-tran1] encapsulation-mode tunnel # Use ESP as the security protocol. [FirewallB-ipsec-proposal-tran1] transform esp # Use DES as the encryption algorithm and SHA1-HMAC-96 as the authentication algorithm. [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des 208

217 [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit # Create IKE peer peer. [FirewallB] ike peer peer # Set the pre-shared key. [FirewallB-ike-peer-peer] pre-shared-key abcde # Specify the IP address of the peer security gateway. [FirewallB-ike-peer-peer] remote-address [FirewallB-ike-peer-peer] quit # Create an IPsec policy that uses IKE. [FirewallB] ipsec policy use1 10 isakmp # Reference ACL 3101 to identify the protected traffic. [FirewallB-ipsec-policy-isakmp-use1-10] security acl 3101 # Reference IPsec proposal tran1. [FirewallB-ipsec-policy-isakmp-use1-10] proposal tran1 # Reference IKE peer peer. [FirewallB-ipsec-policy-isakmp-use1-10] ike-peer peer [FirewallB-ipsec-policy-isakmp-use1-10] quit # Apply IPsec policy use1 to interface GigabitEthernet 0/1. [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] ipsec policy use1 Verifying the configuration # Send traffic from subnet /24 to subnet /24 or from subnet /24 to /24. IKE negotiation is triggered to establish IPsec SAs between Firewall A and Firewall B. # Display the routing table on Firewall A. [FirewallA] display ip routing-table Routing Tables: Public Destinations : 8 Routes : 8 Destination/Mask Proto Pre Cost NextHop Interface /16 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /24 Direct GE0/ /32 Direct InLoop /24 Static GE0/ /8 Direct InLoop /32 Direct InLoop0 The output shows that IPsec RRI has created a static route to subnet /24 with the next hop # Delete the IPsec SAs. The static route is automatically deleted. 209

218 IPsec stateful failover configuration example Network requirements As shown in Figure 131, a network has two gateways, Firewall A and Firewall B, at the headquarters. Configure an IPsec tunnel between the headquarters and the branch to ensure secure communication. Configure IPsec stateful failover on the firewalls for high availability of the IPsec tunnel: Deploy a physical link for IPsec service data backup between Firewall A and Firewall B. On Firewall A and Firewall B, add the uplink interface to VRRP group 2 and the downlink interface to VRRP group 1, and assign the virtual IP address /24 to VRRP group 2 and the virtual IP address /2 to VRRP group 1. Use Firewall A to establish an IPsec tunnel with Router when it works normally, and make sure that IPsec traffic is switched to Firewall B when Firewall A fails. Figure 131 Network diagram Host A IP: /24 Gateway: Firewall A G0// /24 GE0/3 Virtual IP address 1: /24 Backup link GE0/3 GE0/ /24 Firewall B G0// /24 Virtual IP address 2: /24 GE0/ /24 Headquarters Eth1/ /24 Eth1/ /24 Router Branch Host B IP: /24 Gateway: Configuring Firewall A 210

219 NOTE: Assign IPv4 Address to the interfaces. Make sure that Firewall A, Firewall B, and Router have IP connectivity between them. Configure stateful failover # Log in to the web interface of Firewall A, select High Reliability > Stateful Failover from the navigation tree to enter the Stateful Failover Configuration page, and click the Modify Backup Interface button. Then, select and add GigabitEthernet 0/3 to the Backup Interface(s) list as shown in Figure 132. Figure 132 Configure a backup interface # Click Apply to return to the Stateful Failover Configuration page and perform the configurations shown in Figure 133. Figure 133 Configure stateful failover Configure VRRP # Create VRRP group 1 and assign a virtual IP address to the group. <FirewallA> system-view 211

220 [FirewallA] interface GigabitEthernet 0/1 [FirewallA-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the priority of Firewall A in VRRP group 1 to 150. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 priority 150 # Configure Firewall A to work in preemption mode in VRRP group 1 and set the preemption delay to 255 seconds. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 255 # Configure Firewall A to monitor the status of the uplink interface GigabitEthernet 0/2 and, when the interface becomes unavailable, reduce its own priority in VRRP group 1 to a value lower than the priority value of Firewall B so that Firewall B can become the master. In this example, the priority value decrement is 60. [FirewallA-GigabitEthernet0/1] vrrp vrid 1 track interface GigabitEthernet 0/2 reduced 60 [FirewallA-GigabitEthernet0/1] quit # Create VRRP group 2 and assign a virtual IP address to the group. [FirewallA] interface GigabitEthernet 0/2 [FirewallA-GigabitEthernet0/2] vrrp vrid 2 virtual-ip # Set the priority of Firewall A in VRRP group 2 to 150. [FirewallA-GigabitEthernet0/2] vrrp vrid 2 priority 150 # Configure Firewall A to work in preemption mode in VRRP group 2 and set the preemption delay to 255 seconds. [FirewallA-GigabitEthernet0/2] vrrp vrid 2 preempt-mode timer delay 255 # Configure Firewall A to monitor the status of the downlink interface GigabitEthernet 0/1 and, when the interface becomes unavailable, reduce its own priority in VRRP group 2 to a value lower than the priority value of Firewall B so that Firewall B can become the master. In this example, the priority value decrement is 60. [FirewallA-GigabitEthernet0/2] vrrp vrid 2 track interface GigabitEthernet 0/1 reduced 60 [FirewallA-GigabitEthernet0/2] quit Configure IPsec and enable IPsec stateful failover # Create ACL 3101, and add a rule to permit traffic from subnet /24 to subnet /24. [FirewallA] acl number 3101 [FirewallA-acl-adv-3101] rule permit ip source destination [FirewallA-acl-adv-3101] quit # Configure a static route to Host B. [FirewallA] ip route-static # Create IPsec proposal tran1. [FirewallA] ipsec proposal tran1 # Configure the proposal to use the tunnel encapsulation mode. [FirewallA-ipsec-proposal-tran1] encapsulation-mode tunnel # Configure the proposal to use the ESP security protocol. [FirewallA-ipsec-proposal-tran1] transform esp # Configure ESP to use the DES encryption algorithm and the SHA1 authentication algorithm. 212

221 [FirewallA-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallA-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallA-ipsec-proposal-tran1] quit # Create and configure IKE peer branch. [FirewallA] ike peer branch [FirewallA-ike-peer-branch] pre-shared-key abcde [FirewallA-ike-peer-branch] local-address [FirewallA-ike-peer-branch] remote-address [FirewallA-ike-peer-branch] quit # Create an IPsec policy that use IKE, naming it map1 and setting its sequence number to 10. [FirewallA] ipsec policy map1 10 isakmp # Reference IPsec proposal tran1. [FirewallA-ipsec-policy-isakmp-map1-10] proposal tran1 # Reference ACL [FirewallA-ipsec-policy-isakmp-map1-10] security acl 3101 # Reference IKE peer branch. [FirewallA-ipsec-policy-isakmp-map1-10] ike-peer branch [FirewallA-ipsec-policy-isakmp-map1-10] quit # Apply IPsec policy group map1 to interface GigabitEthernet 0/2. [FirewallA] interface GigabitEthernet 0/2 [FirewallA-GigabitEthernet0/2] ipsec policy map1 [FirewallA-GigabitEthernet0/2] quit # Enable IPsec stateful failover. [FirewallA] ipsec synchronization enable Configuring Firewall B NOTE: Assign IPv4 Address to the interfaces. Make sure that Firewall A, Firewall B, and Router have IP connectivity between them. Configure stateful failover # Log in to the web interface of Firewall B and configure stateful failover. The required configuration is the same to the configuration on Firewall A, except that you must leave the Main Device for Configuration Synchronization and Auto Synchronization options cleared on the Stateful Failover Configuration page. See Figure 132 and Figure 133. Configure VRRP # Create VRRP group 1 and assign a virtual IP address to the group. <FirewallB> system-view [FirewallB] interface GigabitEthernet 0/1 [FirewallB-GigabitEthernet0/1] vrrp vrid 1 virtual-ip # Set the priority of Firewall B in VRRP group 1 to 110. [FirewallB-GigabitEthernet0/1] vrrp vrid 1 priority 110 # Configure Firewall B to work in preemption mode in VRRP group 1 and set the preemption delay to 0 seconds. The default setting is the same. This step is optional. 213

222 [FirewallB-GigabitEthernet0/1] vrrp vrid 1 preempt-mode timer delay 0 [FirewallB-GigabitEthernet0/1] quit # Create VRRP group 2 and assign a virtual IP address to the group. [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] vrrp vrid 2 virtual-ip # Set the priority of Firewall B in VRRP group B to 110. [FirewallB-GigabitEthernet0/2] vrrp vrid 2 priority 110 # Configure Firewall B to work in preemption mode in VRRP group 2 and set the preemption delay to 0 seconds. The default setting is the same. This step is optional. [FirewallB-GigabitEthernet0/2] vrrp vrid 2 preempt-mode timer delay 0 [FirewallB-GigabitEthernet0/2] quit Configure IPsec and enable IPsec stateful failover # Create ACL 3101, and add a rule to permit traffic from subnet /24 to subnet /24. [FirewallB] acl number 3101 [FirewallB-acl-adv-3101] rule permit ip source destination [FirewallB-acl-adv-3101] quit # Configure a static route to Host B. [FirewallB] ip route-static # Create IPsec proposal tran1. [FirewallB] ipsec proposal tran1 # Configure the proposal to use the tunnel encapsulation mode. [FirewallB-ipsec-proposal-tran1] encapsulation-mode tunnel # Configure the proposal to use the ESP security protocol. [FirewallB-ipsec-proposal-tran1] transform esp # Configure ESP to use the DES encryption algorithm and the SHA1 authentication algorithm. [FirewallB-ipsec-proposal-tran1] esp encryption-algorithm des [FirewallB-ipsec-proposal-tran1] esp authentication-algorithm sha1 [FirewallB-ipsec-proposal-tran1] quit # Create and configure IKE peer branch. [FirewallB] ike peer branch [FirewallB-ike-peer-branch] pre-shared-key abcde [FirewallB-ike-peer-branch] local-address [FirewallB-ike-peer-branch] remote-address # Create an IPsec policy that use IKE, naming it map1 and setting its sequence number to 10. [FirewallB] ipsec policy map1 10 isakmp # Reference IPsec proposal tran1. [FirewallB-ipsec-policy-isakmp-map1-10] proposal tran1 # Reference ACL [FirewallB-ipsec-policy-isakmp-map1-10] security acl 3101 # Reference IKE peer branch. [FirewallB-ipsec-policy-isakmp-map1-10] ike-peer branch [FirewallB-ipsec-policy-isakmp-map1-10] quit 214

223 # Apply IPsec policy group map1 to interface GigabitEthernet 0/2. [FirewallB] interface GigabitEthernet 0/2 [FirewallB-GigabitEthernet0/2] ipsec policy map1 [FirewallB-GigabitEthernet0/2] quit # Enable IPsec stateful failover. [FirewallB] ipsec synchronization enable Configuring Router NOTE: Assign IPv4 Address to the interfaces. Make sure that Firewall A, Firewall B, and Router have IP connectivity between them. # Create ACL 3101, and add a rule to permit traffic from subnet /24 to subnet /24. <Router> system-view [Router] acl number 3101 [Router-acl-adv-3101] rule permit ip source destination [Router-acl-adv-3101] quit # Configure a static route to Host A. [Router] ip route-static # Create IPsec proposal tran1. [Router] ipsec proposal tran1 # Configure the proposal to use the tunnel encapsulation mode. [Router-ipsec-proposal-tran1] encapsulation-mode tunnel # Configure the proposal to use the ESP security protocol. [Router-ipsec-proposal-tran1] transform esp # Configure ESP to use the DES encryption algorithm and the SHA1 authentication algorithm. [Router-ipsec-proposal-tran1] esp encryption-algorithm des [Router-ipsec-proposal-tran1] esp authentication-algorithm sha1 [Router-ipsec-proposal-tran1] quit # Create and configure IKE peer center. [Router] ike peer center [Router-ike-peer-center] pre-shared-key abcde [Router-ike-peer-center] remote-address # Enable IPsec anti-replay. [Router] ipsec anti-replay check # Create an IPsec policy that use IKE, naming it map1 and setting its sequence number to 10. [Router] ipsec policy map1 10 isakmp # Reference IPsec proposal tran1. [Router-ipsec-policy-isakmp-map1-10] proposal tran1 # Reference ACL [Router-ipsec-policy-isakmp-map1-10] security acl 3101 # Reference IKE peer center. 215

224 [Router-ipsec-policy-isakmp-map1-10] ike-peer center [Router-ipsec-policy-isakmp-map1-10] quit # Apply IPsec policy group map1 to interface Ethernet1/1. [Router] interface ethernet 1/1 [Router-Ethernet1/1] ipsec policy map1 [Router-Ethernet1/1] quit Verifying the configuration After the configuration, traffic between Host A ( ) and Host B ( ) should be able to trigger IKE negotiation. After IPsec SAs are established, traffic between Host A and Host B should be transferred through the IPsec tunnel, and Firewall A should synchronize its IKE SA and IPsec SAs to Firewall B. # Display the active IPsec SAs on Firewall A. <FirewallA> display ipsec sa active =============================== Interface: GE0/2 path MTU: 1500 =============================== IPsec policy name: "map1" sequence number: 10 mode: isakmp connection id: encapsulation mode: tunnel perfect forward secrecy: tunnel: local address: remote address: flow: sour addr: / port: 0 protocol: IP dest addr: / port: 0 protocol: IP [inbound ESP SAs] spi: (0x404cbbdb) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3412 max received sequence-number: 1 anti-replay check enable: Y anti-replay window size: 32 udp encapsulation used for nat traversal: N status: active [outbound ESP SAs] spi: (0x1be6720f) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3412 max received sequence-number: 1 216

225 udp encapsulation used for nat traversal: N status: active # Display the summary information of the active IKE SA on Firewall A. <FirewallA> display ike sa active total phase-1 SAs: 1 connection-id peer flag phase doi status RD 1 IPSEC ACTIVE RD 2 IPSEC ACTIVE flag meaning RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT # On Firewall A, display the IPsec SAs synchronized from Firewall B. <FirewallA> display ipsec sa standby =============================== Interface: GE0/2 path MTU: 1500 =============================== IPsec policy name: "map1" sequence number: 10 mode: isakmp connection id: encapsulation mode: tunnel perfect forward secrecy: tunnel: local address: remote address: flow: sour addr: / port: 0 protocol: IP dest addr: / port: 0 protocol: IP [inbound ESP SAs] spi: (0x404cbbdb) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3412 max received sequence-number: 1 anti-replay check enable: Y anti-replay window size: 32 udp encapsulation used for nat traversal: N status: standby [outbound ESP SAs] spi: (0x1be6720f) proposal: ESP-ENCRYPT-DES ESP-AUTH-SHA1 sa duration (kilobytes/sec): /3600 sa remaining duration (kilobytes/sec): /3412 max received sequence-number: 1 udp encapsulation used for nat traversal: N 217

226 status: standby # On Firewall A, display the summary information of the IKE SA synchronized from Firewall B. <FirewallA> display ike sa standby total phase-1 SAs: 1 connection-id peer flag phase doi status RD 1 IPSEC STANDBY RD 2 IPSEC STANDBY flag meaning RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT IPsec configuration guidelines When you configure IPsec, follow these guidelines: Typically, IKE uses UDP port 500 for communication, and AH and ESP use the protocol numbers 51 and 50 respectively. You must make sure that flows of these protocols are not denied on the interfaces with IKE or IPsec configured. If you enable both IPsec and QoS on an interface, traffic of an IPsec SA may be put into different queues by QoS, causing some packets to be sent out of order. As IPsec performs anti-replay operation, packets outside the anti-replay window in the inbound direction may be discarded, resulting in packet loss. When using IPsec together with QoS, make sure that they use the same classification rules. IPsec classification rules depend on the referenced ACL rules. 218

227 IPSec VPN configuration wizard NOTE: The IPSec VPN configuration wizard is available only in the web interface. IPSec VPN configuration wizard overview The IPsec VPN policy configuration wizard provides a way to configure IPsec VPNs easily. For more information about IPsec and IKE, see the chapters IPsec configuration and IKE configuration. IPsec VPN supports two networking modes: center-branch mode and peer-peer mode. Center-branch mode applies to one-to-many networks as shown in Figure 134. A network in this mode uses the aggressive mode for IKE negotiation and uses the security gateway name or IP address as the ID type at the local end. The center node never initiates IPsec SA negotiation; the branch nodes must take the responsibility. Figure 134 Center-branch networking mode Peer-peer mode applies to one-to-one networks as shown in Figure 135. A network in this mode uses the main mode for IKE negotiation and can use only the ID type of IP address at the local end. Either of the two peers can initiate IPsec SA negotiation. Figure 135 Peer-peer networking mode Internet Peer node Peer node Configuring an IPsec VPN Launching the IPsec VPN policy configuration wizard 1. Select Wizard from the navigation tree to enter the Configuration Wizard page. 2. Click the IPSec VPN Deployment hyperlink to enter the first page of the IPsec VPN policy configuration page. 219

228 Figure 136 IPsec VPN policy configuration wizard: 1/4 Configuring a center node 1. Select Center Node from the first page of the IPsec VPN policy configuration wizard. 2. Click Next Figure 137 IPsec VPN policy configuration wizard: 2/4 (center node) 220

229 3. Perform configurations as described in Table 19. Table 19 Configuration items Item Description Enter the name for the IPsec VPN. IMPORTANT: IPSec VPN Name IPSec Interface Branch Gateway Name If you enter abc here, the wizard will create an IKE peer named abc_peer, an IPsec proposal named abc_prop, an IPsec template named abc_temp and numbered 1, and an IPsec policy named abc_poli and numbered 1. The IKE peer and IPsec proposal will be referenced in the IPsec template, and the template will be referenced in the IPsec policy. Select the interface to which you want to apply the IPsec policy. Enter the name of the remote gateway at the branch node, which will be used during IKE negotiation. Identity Configuration Local IP Address Local Gateway Name Specify the ID type of the local end for IKE negotiation phase 1. Options include: Local IP Address Uses the IP address of the local gateway as the ID. If you do not specify the IP address, the default (the primary IP address of the interface using the security policy) is used. Local Gateway Name Uses the name of the local gateway as the ID. If you do not specify the gateway name, the default (the device name) is used. 4. Click Next. Figure 138 IPsec VPN policy configuration wizard: 3/4 (center node) 5. Perform configuration as described in Table

230 Table 20 Configuration items Item Encryption Suite Pre-Shared Key PKI Domain Description Select the encryption suite for the IPsec proposal. An encryption suite specifies the IP packet encapsulation mode, security protocol, and authentication and encryption algorithms to be used. Options include: TUNNEL-ESP-SHA1-3DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, SHA1 for authentication, and 3DES for encryption. TUNNEL-ESP-MD5-DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, MD5 for authentication, and DES for encryption. TUNNEL-AH-MD5-ESP-DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and DES for ESP encryption. TUNNEL-AH-MD5-ESP-3DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and 3DES for ESP encryption. Select the authentication method for IKE negotiation and specify the required argument. Options include: Pre-Shared Key Uses the pre-shared key authentication method. PKI Domain Uses the RSA signature authentication method. Available PKI domains are those configured by selecting VPN > Certificate Manager > Domain from the navigation tree. IMPORTANT: If you select PKI Domain, an IKE proposal numbered 1 will be created. Enable DPD Select this box to enable dead peer detection (DPD). If you enable DPD and the name of the IPsec VPN is abc, the wizard will create a DPD named abc_dpd and apply it to peer abc_peer. 6. Click Next. 222

231 Figure 139 IPsec VPN policy configuration wizard: 4/4 (center node) 7. Click Finish to complete the configuration. The system will jump to the page that you can enter by selecting VPN > IPSec > IPSec Application from the navigation tree. Configuring a branch node 1. Select Branch Node from the first page of the IPsec VPN policy configuration wizard. 2. Click Next. 223

232 Figure 140 IPsec VPN policy configuration wizard: 2/4 (branch node) 3. Perform configuration as described in Table 21. Table 21 Configuration items Item Description Enter the name for the IPsec VPN. IMPORTANT: IPSec VPN Name IPSec Interface If you enter abc here, the wizard will create an IKE peer named abc_peer, an IPsec proposal named abc_prop, and an IPsec policy named abc_poli and numbered 1. The IKE peer and IPsec proposal will be referenced in the IPsec policy. Select the interface to which you want to apply the IPsec policy. Enter the IP address of the center node, which will be used during IKE negotiation. Center IP Address IMPORTANT: The IP address specified here must match the local IP address specified on the peer. Center Gateway Name Enter the name of the remote gateway at the center node, which will be used during IKE negotiation. Identity Configuration Local IP Address Local Gateway Name Specify the ID type of the local end for IKE negotiation phase 1. Options include: Local IP Address Uses the IP address of the local gateway as the ID. If you do not specify the IP address, the default (the primary IP address of the interface using the security policy) is used. Local Gateway Name Uses the name of the local gateway as the ID. If you do not specify the gateway name, the default (the device name) is used. 224

233 4. Click Next. Figure 141 IPsec VPN policy configuration wizard: 3/4 (branch node) 5. Perform configuration as described in Table 22. Table 22 Configuration items Item Source IP Address/Wildcard Destination IP Address/Wildcard Protocol Type Encryption Suite Pre-Shared Key Description Specify the traffic to be protected by giving the source IP address and wildcard, destination IP address and wildcard, and the protocol type. IMPORTANT: Based on these configurations, the wizard will create an advanced ACL that permit packets matching these criteria and apply this ACL to the IPsec policy. The ACL number will be the smallest, available number in the range of 3000 to If there is no number available for the ACL, the wizard will notify you that the IPsec VPN policy configuration fails. Select the encryption suite for the IPsec proposal. An encryption suite specifies the IP packet encapsulation mode, security protocol, and authentication and encryption algorithms to be used. Options include: TUNNEL-ESP-SHA1-3DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, SHA1 for authentication, and 3DES for encryption. TUNNEL-ESP-MD5-DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, MD5 for authentication, and DES for encryption. TUNNEL-AH-MD5-ESP-DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and DES for ESP encryption. TUNNEL-AH-MD5-ESP-3DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and 3DES for ESP encryption. Select the authentication method for IKE negotiation and specify the required argument. Options include: 225

234 Item PKI Domain Description Pre-Shared Key Uses the pre-shared key authentication method. PKI Domain Uses the RSA signature authentication method. Available PKI domains are those configured by selecting VPN > Certificate Manager > Domain from the navigation tree. IMPORTANT: If you select PKI Domain, an IKE proposal numbered 1 will be created. Select this box to enable dead peer detection (DPD). Enable DPD IMPORTANT: If you enable DPD and the name of the IPsec VPN is abc, the wizard will create a DPD named abc_dpd and apply it to peer abc_peer. 6. Click Next. Figure 142 IPsec VPN policy configuration wizard: 4/4 (branch node) 7. Click Finish to complete the configuration. The system will jump to the page that you can enter by selecting VPN > IPSec > IPSec Application from the navigation tree. Configuring a peer node 1. Select Peer Node from the first page of the IPsec VPN policy configuration wizard. 2. Click Next. 226

235 Figure 143 IPsec VPN policy configuration wizard: 2/4 (peer node) 3. Perform configuration as described in Table 23. Table 23 Configuration items Item Description Enter the name for the IPsec VPN. IMPORTANT: IPSec VPN Name IPSec Interface If you enter abc here, the wizard will create an IKE peer named abc_peer, an IPsec proposal named abc_prop, and an IPsec policy named abc_poli and numbered 1. The IKE peer and IPsec proposal will be referenced in the IPsec policy. Select the interface to which you want to apply the IPsec policy. Enter the remote IP address for IKE negotiation. Remote IP Address IMPORTANT: The IP address specified here must match the local IP address specified on the peer. Identity Configuration Local IP Address Local Gateway Name Specify the ID type of the local end for IKE negotiation phase 1. Options include: Local IP Address Uses the IP address of the local gateway as the ID. If you do not specify the IP address, the default (the primary IP address of the interface using the security policy) is used. Local Gateway Name Uses the name of the local gateway as the ID. This option is not available because the local end cannot use its local gateway name for IKE negotiation when the peer node uses the negotiation mode of main. 4. Click Next. 227

236 Figure 144 IPsec VPN policy configuration wizard: 3/4 (peer node) 5. Perform configurations as described in Table 24. Table 24 Configuration items Item Source IP Address/Wildcard Destination IP Address/Wildcard Protocol Type Description Specify the traffic to be protected by giving the source IP address and wildcard, destination IP address and wildcard, and the protocol type. IMPORTANT: Based on these configurations, the wizard will create an advanced ACL that permit packets matching these criteria and apply this ACL to the IPsec policy. The ACL number will be the smallest, available number in the range of 3000 to If there is no number available for the ACL, the wizard will notify you that the IPsec VPN policy configuration fails. Select the encryption suite for the IPsec proposal. An encryption suite specifies the IP packet encapsulation mode, security protocol, and authentication and encryption algorithms to be used. Encryption Suite Options include: TUNNEL-ESP-SHA1-3DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, SHA1 for authentication, and 3DES for encryption. TUNNEL-ESP-MD5-DES Uses the tunnel mode for IP packet encapsulation, ESP for packet protection, MD5 for authentication, and DES for encryption. TUNNEL-AH-MD5-ESP-DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and DES for ESP encryption. TUNNEL-AH-MD5-ESP-3DES Uses the tunnel mode for IP packet encapsulation, ESP and AH for packet protection, MD5 for AH authentication, and 3DES for ESP encryption. 228

237 Item Pre-Shared Key PKI Domain Description Select the authentication method for IKE negotiation and specify the required argument. Options include: Pre-Shared Key Uses the pre-shared key authentication method. PKI Domain Uses the RSA signature authentication method. Available PKI domains are those configured by selecting VPN > Certificate Manager > Domain from the navigation tree. IMPORTANT: If you select PKI Domain, an IKE proposal numbered 1 will be created. Select this box to enable dead peer detection (DPD). Enable DPD IMPORTANT: If you enable DPD and the name of the IPsec VPN is abc, the wizard will create a DPD named abc_dpd and apply it to peer abc_peer. 6. Click Next. Figure 145 IPsec VPN policy configuration wizard: 4/4 (peer node) 7. Click Finish to complete the configuration. The system will jump to the page that you can enter by selecting VPN > IPSec > IPSec Application from the navigation tree. 229

238 L2TP configuration NOTE: The term router in this document refers to both routers and Layer 3 firewalls. Overview A virtual private dial-up network (VPDN) is a virtual private network (VPN) that utilizes the dial-up function of public networks such as ISDN or PSTN networks to provide access services for enterprises, small Internet service providers (ISPs), and mobile users. VPDN provides an economical and effective, point-to-point way for remote users to connect to their home LANs. The VPDN technology uses a specialized network communication protocol to build secure VPNs across public networks for enterprises. Branches away from the headquarters and staff on business can remotely access the intranet resources in the headquarters through a virtual tunnel over public networks; other users on the public networks cannot. A VPDN tunnel can be NAS-initiated or client-initiated: NAS-initiated VPDN tunnel. The network access server (NAS) connects a user s PPP connection to the corporate VPDN gateway through a VPDN tunneling protocol, establishing a tunnel with the VPDN gateway. The tunneling is transparent to users. A user only needs to perform login operation once to access the enterprise network, which authenticates the user and assigns the user a private IP address, eliminating the necessity of the user for a public address. This mode requires that the NAS support VPDN and the authentication system support VPDN attributes. Client-initiated VPDN tunnel. A user accesses the Internet first, and then establishes a tunnel with the VPDN gateway through dedicated client software, such as the L2TP client software offered by Windows In this mode, a user can access the enterprise network anytime from any place, without the involvement of any ISP. However, users must install dedicated software, which means that users must use platforms supporting the L2TP client. Usually, Windows 2000 platform is used. In general, a VPDN gateway can be a router or a dedicated VPN server. There are primarily three VPDN tunneling protocols: Point-to-Point Tunneling Protocol (PPTP) Layer 2 Forwarding (L2F) Layer 2 Tunneling Protocol (L2TP) L2TP is the most widely-used VPDN tunneling protocol. Typical networking application of L2TP Figure 146 shows a typical VPDN built by using L2TP. 230

239 Figure 146 VPDN built by using L2TP Remote user LAC LNS PPPoE/ISDN Internet L2TP tunnel Remote branch Internal server A VPDN built by using L2TP consists of three components: Remote system A remote system is usually the host of a remote user or the routing device of a remote branch that needs to access the VPDN network. LAC An L2TP access concentrator (LAC) is a device that is attached to a packet-switched network and has a PPP end system and the L2TP capability. An LAC is usually a NAS located at a local ISP, which provides access services mainly for PPP users. An LAC lies between LNSs and remote systems. Upon receiving a packet from a remote system, it encapsulates the packet by using L2TP and sends the encapsulated packet to the LNS. Upon receiving a packet from an LNS, it de-encapsulates the packet and sends it to the intended remote system. Between an LAC and a remote system is a local connection or a PPP link. Usually, a PPP link is used in a VPDN application. LNS An L2TP network server (LNS) is a PPP end system as well as the L2TP protocol server. It is usually an edge device of an enterprise network. As an end system of an L2TP tunnel, an LNS is the peer of an LAC. It is the logical termination point of a PPP session that is tunneled by the LAC. That is, with L2TP, the PPP termination point of a remote system is logically extended from the LAC to the LNS, which resides on the enterprise network. Basic concepts of L2TP Background of L2TP The point-to-point Protocol (PPP) defines an encapsulation mechanism that allows a point-to-point link to carry packets of various protocols. When PPP runs between a user and a NAS, the PPP session terminates at the same physical device where the Layer 2 link terminates the NAS. L2TP (RFC 2661) is intended to tunnel PPP packets. It extends the PPP model by allowing the Layer 2 link and the PPP session endpoints to reside on different devices interconnected by a packet-switched network. This makes PPP sessions be able to traverse frame relay networks or the Internet. Combining the advantages of L2F and PPTP, L2TP has become the Layer 2 tunneling industry standard of the Internet Engineering Task Force (IETF). 231

240 L2TP architecture Figure 147 shows the relationship between the PPP frame, control channel, and data channel. PPP frames are transferred over the unreliable L2TP data channels. Control messages are transferred within the reliable L2TP control channels. Figure 147 L2TP architecture Figure 148 L2TP packet encapsulation structure Figure 148 depicts the encapsulation structure of an L2TP data packet between the LAC and the LNS. Usually, L2TP data is transferred in the form of User Data Protocol (UDP) packets. The well-known UDP port for L2TP is 1701, which is only used in the initial tunnel creation stage. The L2TP tunnel initiator selects an idle port (which may not be 1701) to send a packet to port 1701 of the receiver. After receiving the packet, the receiver also selects an idle port (which may not be 1701 either) to return a packet to the specified port of the initiator. From then on, the two parties use the negotiated ports to communicate until the tunnel is disconnected. Tunnel and session Two types of connections are present between an LNS and an LAC: tunnel and session. A tunnel is between an LNS and an LAC. A session is multiplexed on a tunnel and represents a PPP session on the tunnel. Multiple L2TP tunnels can be established between an LNS and an LAC. A tunnel consists of a control connection and one or more sessions. A session can be set up only after the tunnel is created. A session corresponds to one PPP data stream between the LAC and the LNS. Both control messages and PPP frames are transferred on the tunnel. L2TP uses Hello packets to check the connectivity of a tunnel. The LAC and LNS regularly send Hello packets to each other. If no response packet is received in a certain period of time, the tunnel is torn down. Control message and data message L2TP supports two types of messages: control messages and data messages. Control messages are intended for establishment and maintenance of tunnels and sessions and for transmission control. Control messages are transmitted over a reliable channel, which supports flow control and congestion control. Data messages are intended to encapsulate PPP frames to be tunneled. Data messages are transmitted over an unreliable channel without flow control, congestion control, and retransmission mechanisms. Control messages and data messages share the same header structure. An L2TP header contains a tunnel ID and a session ID, which are used to identify the tunnel and session respectively. Packets with the 232

241 same tunnel ID but different session IDs are multiplexed to the same tunnel. The tunnel ID and session ID in a header are those of the intended receiver, not the sender. L2TP tunnel modes and tunnel establishment process Typical L2TP tunnel modes Typical L2TP tunnel modes include NAS-initiated, client-initiated, and LAC-Auto-Initiated. NAS-initiated In this mode, a remote system dials in the LAC through a PPPoE/ISDN network, and the LAC initiates a tunneling request to the LNS over the Internet, as shown in Figure 149. The LNS will assign the remote system a private IP address. Authentication and accounting of the remote system can be implemented on the LAC by an agent or on the LNS. Figure 149 NAS-initiated tunnel mode Client-initiated In this mode, after obtaining the access right to the Internet, a remote system running the L2TP client software (LAC client) initiates a tunneling request to the LNS directly without requiring a separate LAC. The LNS will assign the LAC client a private IP address. An LAC client needs a public IP address to communicate with the LNS directly through the Internet. Figure 150 Client-initiated tunnel mode LAC-auto-initiated In NAS-initiated mode, a remote system must successfully dial in to the LAC through PPPoE or ISDN to trigger the LAC to initiate a tunneling request to the LNS. In LAC-auto-initiated mode, you can create a virtual PPP user and execute the l2tp-auto-client enable command on the LAC. Then, the LAC automatically initiates a tunneling request to the LNS to establish an L2TP tunnel for the virtual PPP user. Then, when a remote system accesses the internal network, the LAC forwards data through the L2TP tunnel. In this mode, the connection between a remote system and the LAC is not confined to a dial-up connection and can be any IP-based connection. 233

242 Figure 151 LAC-auto-initiated tunneling mode L2TP tunnel establishment process Figure 152 Typical L2TP network Figure 153 shows the setup procedure of an L2TP call in NAS-initiated mode. 234

243 Figure 153 L2TP call setup procedure Remote system Host A LAC Device A LAC RADIUS server LNS Device B LNS RADIUS server (1) Call setup (2) PPP LCP setup (3) PPP or CHAP authenticaion (4) Access request (5) Access accept (6) Tunnel setup (7) CHAP authentication (challenge/response) (8) Authentication passes (9) User CHAP response, PPP negotiation parameter (12) CHAP authentication twice (challenge/response) (15) Authentication passes (10) Access request (11) Acesss accept (13) Access request (14) Acesss accept An L2TP call is set up in the following procedure: 1. The remote user (Host) makes a PPP call. 2. The remote user and the LAC (Device A) perform PPP LCP negotiation. 3. The LAC authenticates the remote user using the Password Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP). 4. The LAC sends the authentication information (the username and password) to its RADIUS server for authentication. 5. The LAC RADIUS server authenticates the user. 6. If the user passes authentication, the LAC initiates a tunneling request to the LNS. 7. If authentication of the tunnel is required, the LAC sends a CHAP challenge to the LNS. The LNS returns a CHAP response and sends its CHAP challenge to the LAC. Accordingly, the LAC returns a CHAP response to the LNS. 8. The tunnel passes authentication. 9. The LAC sends the CHAP response, response identifier, and PPP negotiation parameters of the user to the LNS. 10. The LNS sends an access request to its RADIUS server for authentication. 11. The RADIUS server authenticates the access request and returns a response if the user passes authentication. 12. If the LNS is configured to perform a mandatory CHAP authentication of the user, the LNS sends a CHAP challenge to the user and the user returns a CHAP response. 13. The LNS resends the access request to its RADIUS server for authentication. 235

244 14. The RADIUS server authenticates the access request and returns a response if the user passes authentication. 15. The LNS assigns an internal IP address to the remote user. Now, the user can access the internal resources of the enterprise network. L2TP features 1. Flexible identity authentication mechanism and high security L2TP itself does not provide security for connections. However, it has all the security features of PPP for it allows for PPP authentication (CHAP or PAP). L2TP can also cooperate with IPsec to guarantee data security, making tunneled data more resistant to attacks. In addition, tunnel encryption, end-to-end data encryption, and end-to-end application-layer data encryption technologies can be used together with L2TP for higher data security as required. 2. Multi-protocol transmission L2TP tunnels PPP frames, which can be used to encapsulate packets of multiple network layer protocols. 3. RADIUS authentication An LAC and LNS can send the username and password of a remote user to a RADIUS server for authentication. 4. Private address allocation An LNS can reside behind the firewall of a corporate network, dynamically allocating private addresses to remote users and managing the corporate private addresses (RFC 1918). This facilitates address management and improves security. 5. Accounting flexibility Accounting can be carried out on the LAC and LNS simultaneously, allowing bills to be generated on the ISP side and charging and auditing to take place on the enterprise gateway. L2TP can provide such accounting data as statistics on inbound and outbound traffic (in packets and bytes) and connection start time and end time. All these enable flexible accounting. 6. Reliability L2TP supports LNS backup. When the connection to the primary LNS is torn down, an LAC can establish a new one with a secondary LNS, enhancing the reliability and fault tolerance of VPN services. Protocols and standards RFC 1661, The Point-to-Point Protocol (PPP) RFC 1918, Address Allocation for Private Internets RFC 2661, Layer Two Tunneling Protocol "L2TP" Configuring L2TP in the web interface NOTE: Only the LNS configuration is available in the web interface. 236

245 L2TP configuration task list Table 25 L2TP configuration task list Task Enabling L2TP Adding an L2TP group Displaying L2TP tunnel information Remarks Required By default, L2TP is disabled. Required Create a L2TP group and configure L2TP group related parameters. By default, no L2TP group is created. Optional View the L2TP tunnel information. Enabling L2TP Select VPN > L2TP > L2TP Config from the navigation tree to enter the L2TP configuration page, as shown in Figure 154. On the upper part of the page, you can enable or disable L2TP. Figure 154 L2TP configuration page Table 26 Configuration item Item Enable L2TP Description Specify whether to enable L2TP globally. Adding an L2TP group Select VPN > L2TP > L2TP Config from the navigation tree to enter the L2TP configuration page, as shown in Figure 154. On the lower part of the page, you can view and configure L2TP groups. Click Add to add an L2TP group, as shown in Figure

246 Figure 155 Add an L2TP group Table 27 Configuration items Item L2TP Group Name Peer Tunnel Name Local Tunnel Name Tunnel Authentication Description Specify the name of the L2TP group. Specify the peer name of the tunnel. Specify the local name of the tunnel. Enable or disable L2TP tunnel authentication in the group. If you enable tunnel authentication, you need to set the authentication 238

247 Item Authentication Password Authentication Method Description password. The tunnel authentication request can be initiated by the LAC or LNS. Once tunnel authentication is enabled on one end, a tunnel can be established if tunnel authentication is also enabled on the other end and the passwords configured on the two ends are the same and not null; if these requirements cannot be satisfied, the tunnel initiator will tear down the tunnel connection automatically. If tunnel authentication is disabled on both ends, the tunnel authentication passwords configured will not take effect. IMPORTANT: HP recommends enabling tunnel authentication on both ends of the tunnel for security. You can disable tunnel authentication if you want to test the network connectivity or let the local end receive connections initiated by unknown peers. If you modify the tunnel authentication password when the tunnel is working, you need to tear down the tunnel, so that the modified authentication password can take effect when the tunnel is reestablished. Select the authentication method for PPP users on the local end. You can select PAP or CHAP. If you do not select an authentication method, no authentication will be performed. PPP Authentication Configuration PPP Address ISP Domain PPP Server IP/Mask PPP Server Zone Specify the ISP domain for PPP user authentication. You can perform the following configurations: Click Add to enter the page for adding an ISP domain, as shown in Figure 156. See Table 28 for further details. Select an ISP domain and click Modify to enter the ISP domain modification page. See Table 28 for configuration details. Select an ISP domain and click Delete to delete the ISP domain. IMPORTANT: If you specify an ISP domain, the specified domain will be used for authentication, and IP addresses must be assigned from the address pool configured in the specified domain. See description on the User Address parameter for details. If you do not specify any ISP domain, the system will check whether domain information is carried in a username. If yes, the domain will be used for authentication (if the domain does not exist, the authentication will fail); otherwise, the default domain (system by default) will be used for authentication. Specify the IP address and mask of the local end. Specify the security zone to which the local end belongs. If you do not select a zone, the global address pool will be used. 239

248 Item Description Specify the address pool for assigning IP addresses to users on the peer end, or assign an IP address to a user directly. User Address Assign Address Forcibly If you have specified an ISP domain in PPP authentication configuration, the address pools in the ISP domain will be listed in the User Address list. You can perform the following configurations: Click Add to add an address pool, as shown in Figure 157. See Table 29 for further details. Select an address pool and click Modify to enter the address pool modification page. See Table 29 for configuration details. Select an address pool and click Delete to delete the address pool. Specify whether to force the peer end to use the IP address assigned by the local end. If you enable this function, the peer end is not allowed to use its locally configured IP address. Advanced Configuration Hello Interval AVP Hidden Flow Control Mandatory CHAP Specify the interval between sending hello packets. To check the connectivity of a tunnel, the LAC and LNS regularly send Hello packets to each other. Upon receipt of a Hello packet, the LAC/LNS returns a response packet. If the LAC or LNS receives no Hello response packet from the peer within a specific period of time, it retransmits the Hello packet. If it receives no response packet from the peer after transmitting the Hello packet for three times, it considers that the L2TP tunnel is down and tries to re-establish a tunnel with the peer. The Hello intervals on the LAC and LNS ends of the tunnel can be different. Specify whether to transfer attribute value pair (AVP) data in hidden mode. With L2TP, some parameters are transferred as AVP data. You can configure an LAC to transfer AVP data in hidden mode, so that AVP data is encrypted before transmission for higher security. This configuration takes effect only on an LAC. Specify whether to enable flow control for the L2TP tunnel. The L2TP tunnel flow control function is for control of data packets in transmission. The flow control function helps in buffering and adjusting the received out-of-order data packets. Specify user authentication on the LNS end. 240

249 Item Mandatory LCP Description After the LAC authenticates the client, the LNS may re-authenticate the client for higher security. In this case, only when both the authentications succeed can an L2TP tunnel be set up. On an L2TP network, an LNS authenticates users in three ways: mandatory CHAP authentication, LCP re-negotiation, and proxy authentication. Mandatory CHAP authentication: With mandatory CHAP authentication configured, a VPN user that depends on a NAS to initiate tunneling requests is authenticated twice: once when accessing the NAS and once on the LNS by using CHAP. LCP re-negotiation: For a PPP user that depends on a NAS to initiate tunneling requests, the user first performs PPP negotiation with the NAS. If the negotiation succeeds, the NAS initiates an L2TP tunneling request and sends the user s authentication information to the LNS. The LNS then determines whether the user is valid according to the user authentication information received. Under some circumstances (when authentication and accounting are required on the LNS for example), another round of Link Control Protocol (LCP) negotiation is required between the LNS and the user. In this case, the user authentication information from the NAS will be neglected. Proxy authentication: If neither LCP re-negotiation nor mandatory CHAP authentication is configured, an LNS performs proxy authentication of users. In this case, the LAC sends to the LNS all authentication information from users as well as the authentication mode configured on the LAC itself. IMPORTANT: Among these three authentication methods, LCP re-negotiation has the highest priority. If both LCP re-negotiation and mandatory CHAP authentication are configured, the LNS uses LCP re-negotiation and the PPP authentication method configured in the L2TP group, Some PPP clients may not support re-authentication, in which case LNS side CHAP authentication will fail. With LCP re-negotiation, if no PPP authentication method is configured in the L2TP group, the LNS will not re-authenticate users; it will assign public addresses to the PPP users immediately. In other words, the users are authenticated only once at the LAC end. When the LNS uses proxy authentication and the user authentication information passed from the LAC to the LNS is valid: if the authentication method configured in the L2TP group is PAP, the proxy authentication succeeds and a session can be established for the user; if the authentication method configured in the L2TP group is CHAP but that configured on the LAC is PAP, the proxy authentication will fail and no session can be set up. This is because the level of CHAP authentication, which is required by the LNS, is higher than that of PAP authentication, which the LAC provides. 241

250 Figure 156 Add an ISP domain Table 28 Configuration items Item ISP Domain Authentication Methods Authorization Methods Primary Backup Primary Server Type Scheme Server Type Scheme Description Specify the name of the ISP domain. Select the authentication server type for PPP users. HWTACACS: Uses HWTACACS authentication. Local: Uses local authentication. None: All users are trusted and no authentication is performed. Generally, this method is not recommended. RADIUS: Uses RADIUS authentication. If you do not select any authentication method, the default authentication method of the ISP domain will be used, which is Local by default. Scheme for the primary authentication method, which is displayed when you select HWTACACS or RADIUS as the server type. The scheme is always system. Specify whether to enable the backup authentication method. Select the authorization server type for PPP users. HWTACACS: Uses HWTACACS authorization. Local: Uses local authorization. None: No authorization exchange is performed. Every user is trusted and has the corresponding default rights of the system. RADIUS: Uses RADIUS authorization. If you do not select any authorization method, the default authorization method of the ISP domain will be used, which is Local by default. Scheme for the primary authorization method, which is displayed when you select HWTACACS or RADIUS as the server type. The scheme is always system. 242

251 Item Description Backup Accounting Optional Specify whether to enable the backup authorization method. Specify whether to enable the accounting optional function. For an online user, with the accounting optional function disabled, if no accounting server is available or communication with the current accounting server fails, the user will be disconnected. However, with the accounting optional function enabled, the user can still use the network resources in such case, but the system will not send the accounting information of the user to the accounting server any more. Select the accounting server type for PPP users. HWTACACS: Uses HWTACACS accounting. Local: Uses local accounting. None: The system does not perform accounting for the users. RADIUS: Uses RADIUS accounting. If you do not select any accounting method, the default accounting method of the ISP domain will be used, which is Local by default. Accounting Methods Primary Server Type Scheme Scheme for the primary accounting method, which is displayed when you select HWTACACS or RADIUS as the server type. The scheme is always system. Backup Specify whether to enable the backup accounting method. Max. Number of Users Specify the maximum number of users the ISP domain can accommodate. If you do not specify the maximum number, the system will not limit the number of users of the ISP domain. As users may compete for resources, setting a proper limit on the number of users of an ISP domain helps guarantee performance for the users of the ISP domain. Figure 157 Add an address pool Table 29 Configuration items Item ISP Domain Description Select the ISP domain for the IP address pool to be created. 243

252 Item IP Address Pool Number Start IP End IP Description Specify the number of the IP address pool. If you set the IP address pool number to 1, the name of the IP address pool is pool1. Specify the start IP address and end IP address of the IP address pool. The number of addresses between the start IP address and end IP address must not exceed If you specify only the start IP address, the IP address pool will contain only one IP address the start IP address. Displaying L2TP tunnel information Select VPN > L2TP > Tunnel Info from the navigation tree to enter the L2TP tunnel information page, as shown in Figure 158. Figure 158 L2TP tunnel information Table 30 Field description Field Local Tunnel ID Peer Tunnel ID Peer Tunnel Port Peer Tunnel IP Session Count Peer Tunnel Name Description Local ID of the tunnel Peer ID of the tunnel Peer port of the tunnel Peer IP address of the tunnel Number of sessions on the tunnel Peer name of the tunnel L2TP configuration example Network requirements As shown in Figure 159, a VPN user and the corporate headquarters communicate in the following steps: 1. The user first connects to the Internet, and then initiates a tunneling request to the LNS directly. 2. After the LNS accepts the connection request, an L2TP tunnel is set up between the LNS and the VPN user. 3. The VPN user communicates with the headquarters over the tunnel. 244

253 Figure 159 Network diagram Configuring the VPN user. On the user host, create a virtual private network connection using the Windows operating system, or install L2TP client software such as WinVPN Client and connect to the Internet in dial-up mode. Assign an IP address ( in this example) to the user host and then configure a route to ensure the connectivity between the user host and the LNS ( ). Perform the following configurations on the user host (the configuration procedure depends on the client software): Specify the VPN username as vpdnuser and the password as Hello. Set the Internet interface address of the security gateway as the IP address of the LNS. In this example, the Ethernet interface on the LNS, the interface for the tunnel, has an IP address of Modify the connection attributes, setting the protocol to L2TP, the encryption attribute to customized and the authentication mode to CHAP. Configuring the LNS # Configure IP addresses for interfaces. (Details not shown) # Configure a route to ensure the reachability of the LNS to the user host. # Create a local user named vpdnuser, and set the password to Hello and the service type to PPP. Select User > Local User from the navigation tree and then click Add. Perform the configurations shown in Figure 160. Figure 160 Add a local user Enter vpdnuser as the username. Select PPP as the user type. 245

254 Enter password Hello. Enter Hello to confirm the password. Click Apply. # Enable L2TP. Select VPN > L2TP > L2TP Config from the navigation tree. Then, perform the configurations shown in Figure 161. Figure 161 Enable L2TP Select the Enable L2TP box. Click Apply. # Add an L2TP group On the L2TP configuration page, click Add and then perform the following configurations. Enter the L2TP group name test. Enter the peer tunnel name vpdnuser. Enter the local tunnel name LNS. Select Disable for Tunnel Authentication. Select CHAP as the PPP authentication method. Select ISP domain system (the default ISP domain). Click the Modify button of the ISP domain to perform the configurations shown in Figure

255 Figure 162 Configure local authentication method for VPN users Select the server type Local as the PPP authentication method. Click Apply to return to the L2TP group configuration page. Enter / as the PPP server IP address/mask. Select Trust from the PPP Server Zone list. (Select a security zone according to your network configuration.) Click the Add button of the User Address parameter and then perform the configurations shown in Figure 163. Figure 163 Add an IP address pool Select domain system. Enter 1 as the IP address pool number. Enter the start IP address Enter the end IP address

256 Click Apply to finish the IP address pool configuration and return to the L2TP group configuration page. Select pool1 from the User Address list. Select Enable from the Assign Address Forcibly list. Figure 164 shows the L2TP group configuration page after the configurations. Click Apply. Figure 164 L2TP group configurations Verifying the configuration # On the user host, initiate an L2TP connection to the LNS. The host will obtain an IP address ( ) and will be able to ping the private address of the LNS ( ). # On the LNS, select VPN > L2TP > Tunnel Info from the navigation tree. Information of the established L2TP tunnel will appear, as shown in Figure 165. Figure 165 L2TP tunnel information 248

257 Configuring L2TP at the CLI L2TP configuration task list When configuring L2TP, perform the following operations: 1. Determine the network device(s) needed according to the networking environment. For NAS-initiated mode and LAC-auto-initiated mode, you need to configure both the LAC and the LNS. For client-initiated mode, you only need to configure the LNS. 2. Configure the firewall(s) accordingly based on the intended role (LAC or NAS) on the network. To configure the firewall as an LAC in NAS-initiated or LAC-auto-initiated mode, complete the following tasks: Task Configuring basic L2TP capability Configuring an LAC Configuring L2TP connection parameters Enable L2TP Create an L2TP group Specify the local name of the tunnel Configuring an LAC to initiate tunneling requests for specified users Configuring an LAC to transfer AVP data in hidden mode Configuring AAA authentication for VPN users on LAC side Configuring an LAC to establish an L2TP tunnel Configuring L2TP tunnel authentication Setting the hello interval Enabling tunnel flow control Disconnecting tunnels by force Remarks Required Required Optional Required Required in LAC-auto-initiated mode. No need to configure in NAS-initiated mode. Optional To configure the firewall as an LNS in NAS-initiated, client-initiated, or LAC-auto-initiated mode, complete the following tasks: Task Configuring basic L2TP capability Configuring an LNS Enable L2TP Create an L2TP group Specify the local name of the tunnel Creating a virtual template interface Configuring the local address and the address pool for allocation Remarks Required Required Required 249

258 Task Configuring L2TP connection parameters Configuring an LNS to grant certain L2TP tunneling requests Configuring user authentication on an LNS Configuring AAA authentication for VPN users on an LNS Enabling L2TP multi-instance Specifying to send ACCM Configuring L2TP tunnel authentication Setting the hello interval Enabling tunnel flow control Disconnecting tunnels by force Remarks Required Optional Optional Optional Optional Optional Configuring basic L2TP capability An L2TP group is intended to represent a group of parameters and corresponds to one VPN user or one group of VPN users. This enables not only flexible L2TP configuration on devices, but also one-to-one and one-to-many networking applications for LACs and LNSs. An L2TP group only has local significance. However, you must make sure that the relevant settings of the L2TP groups on the LAC and LNS match. For example, the local tunnel name configured on the LAC must match the remote tunnel name configured on the LNS. L2TP must be enabled for L2TP configuration to take effect. Tunnel names are used during tunnel negotiation between an LAC and an LNS. Follow these steps to configure basic L2TP capability: To do Use the command Remarks Enter system view system-view Enable L2TP Create an L2TP group and enter its view Specify the local name of the tunnel l2tp enable l2tp-group group-number tunnel name name Required Disabled by default Required By default, no L2TP group exists. Optional The system name of the firewall is used by default. Configuring an LAC An LAC is responsible for establishing tunnels with LNSs for users and sends user packets to LNSs through the tunnels. Before configuring an LAC, enable L2TP and create an L2TP group. 250

259 Configuring an LAC to initiate tunneling requests for specified users An LAC initiates tunneling requests only to specified LNSs for specified users. You can specify the users to be serviced and the LNSs that will be connected. Users can be specified by their fully qualified name or the domain name. Follow these steps to configure the LAC: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Enable the firewall to initiate tunneling requests to one or more IP addresses for one or more specified VPN users start l2tp { ip ip-address }&<1-5> { domain domain-name fullusername user-name } Required NOTE: Up to five LNSs can be configured. The LAC initiates an L2TP tunneling request to its specified LNSs consecutively in their configuration order until it receives an acknowledgement from an LNS, which then becomes the tunnel peer. Configuring an LAC to transfer AVP data in hidden mode With L2TP, some parameters are transferred as attribute value pair (AVP) data. To improve security, you can configure an LAC to transfer AVP data in hidden mode to encrypt AVP data before transmission. Follow these steps to configure an LAC to transfer AVP data in hidden mode: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Specify that AVP data be transferred in hidden mode tunnel avp-hidden Optional By default, AVP data is transferred in plain text. Configuring AAA authentication for VPN users on LAC side You can configure an LAC to perform AAA authentication for VPN users and initiate a tunneling request only for qualified users. No tunnel will be established for unqualified users. The firewall supports both local AAA authentication and remote AAA authentication: For local AAA authentication, create a local user and configure a password for each remote user on the LAC. The LAC authenticates a remote user by matching the provided username and password against those configured locally. For remote AAA authentication, configure the username and password of each user on the RADIUS/HWTACACS server. The LAC sends the remote user s username and password to the server to authenticate. Follow these steps to configure local authentication, authorization, and accounting: To do Use the command Remarks Enter system view system-view 251

260 To do Use the command Remarks Create a local user and enter its view Configure a password for the local user Authorize the user to use the PPP service local-user username password { simple cipher } password service-type ppp Required By default, no local user or password is configured on an LAC. Required Return to system view quit Create an ISP domain and enter its view Configure the domain to use local authentication/authorization/acc ounting for its PPP users domain isp-name authentication ppp local authorization ppp local accounting ppp local Required Optional Local authentication/authorization/acc ounting is used by default. NOTE: For successful user authentication, configure PPP on the LAC s corresponding interface, for example, the asynchronous serial interface that connects with users. For PPP configuration information, see Network Management Configuration Guide. Configure the authentication type of PPP users as PAP, CHAP, or MS-CHAP on the user access interfaces. For information about AAA configuration commands and remote AAA authentication method configuration, see Access Control Configuration Guide. Configuring an LAC to establish an L2TP tunnel To establish an L2TP tunnel in LAC-auto-initiated mode, you need to create a virtual PPP user on the LAC. LAC performs PPP authentication for the virtual PPP user, that is, LAC is both the side that performs PPP authenticator and the side that is authenticated by PPP. To configure an LAC to establish an L2TP tunnel, you must: Create a virtual template interface and configure an IP address for the interface. In virtual template interface view, configure the side that performs PPP authentication: use the ppp authentication-mode command to specify the authentication method that the LAC uses to authenticate the virtual PPP user. In virtual template interface view, configure the side that is authenticated by PPP: use the ppp pap command or the ppp chap command to specify the PPP authentication method supported by the virtual PPP user, and the username and password of the virtual PPP user. The authentication method to be used by the LAC and that supported by the virtual PPP user must be consistent. Configure AAA authentication for VPN users on the LAC. The configured username and password for AAA authentication must be the same as those of the virtual PPP user configured on the virtual template interface. Trigger the LAC to establish an L2TP tunnel. Follow these steps to trigger an LAC to establish an L2TP tunnel: To do Use the command Remarks Enter system view system-view 252

261 To do Use the command Remarks Create a virtual template interface and enter its view Assign an IP address to the virtual template interface Enable IP address negotiation so that the virtual template interface accepts the IP address negotiated with the peer Configure the authentication method for the LAC to use to authenticate the virtual PPP user interface virtual-template virtual-template-number ip address address mask ip address ppp-negotiate ppp authentication-mode { chap pap } * [ domain isp-name ] Required By default, no virtual template interface exists. Required Use either command Not assigned an IP address by default Required By default, no authentication is performed for PPP users. Required Configure the username and password for PAP authentication Configure the username for CHAP authentication Configure the password for CHAP authentication ppp pap local-user username password { cipher simple } password ppp chap user username ppp chap password { cipher simple } password No PAP username and password are configured for PPP users. Required No CHAP username and password are configured for PPP users. Use one approach according to the authentication method configured on the LAC for virtual PPP users Configure AAA authentication for VPN users on the LAC side See Configuring AAA authentication for VPN users on LAC side. Required Trigger the LAC to establish an L2TP tunnel with the LNS l2tp-auto-client enable Required By default, an LAC does not establish an L2TP tunnel. NOTE: An L2TP tunnel established in LAC-auto-initiated mode exists until you remove the tunnel by using the undo l2tp-auto-client enable command. Configuring an LNS An LNS responds the tunneling requests from an LAC, authenticates users, and assigns IP addresses to users. Before configuring an LNS, enable L2TP and create an L2TP group. Creating a virtual template interface A virtual template interface is intended to provide parameters for virtual access interfaces to be dynamically created by the firewall, such as logical MP interfaces and logical L2TP interfaces. 253

262 After an L2TP session is established, a virtual access interface is needed for data exchange with the peer. An LNS can use different virtual access (VA) interfaces to exchange data with different LACs. You need to specify the virtual template interface for receiving calls. The system will dynamically create a VA interface based on the configuration parameters in the specified virtual template interface. Follow these steps to create a virtual template interface: To do Use the command Remarks Enter system view system-view Create a virtual template interface and enter its view interface virtual-template virtual-template-number Required By default, no virtual template interface exists. Configuring the local address and the address pool for allocation After an L2TP tunnel is set up between an LAC and an LNS, the LNS needs to assign an IP address to a VPN user. For this purpose, you can directly specify an IP address, or specify an address pool. Before specifying an address pool, use the ip pool command in system view or ISP domain view to define the address pool. For a VPN user to be authenticated, an IP address will be selected from the address pool configured in ISP domain view. For a VPN user not requiring authentication, the IP address will be selected from the global address pool defined in system view. Follow these steps to configure a local address and address pool: To do Use the command Remarks Enter system view system-view Enter virtual template interface view Configure the local IP address Configure the authentication mode for PPP users Specify the address pool for allocating an IP address to a PPP user, or assign an IP address to the user directly interface virtual-template virtual-template-number ip address ip-address { mask mask-length } [ sub ] ppp authentication-mode { chap ms-chap pap } * [ [ call-in ] domain isp-name ] remote address { pool [ pool-number ] ip-address } Required Optional By default, no authentication is performed for PPP users. Optional By default, address pool 0 (the default address pool) is used. Configuring an LNS to grant certain L2TP tunneling requests When receiving a tunneling request, an LNS determines whether to grant the tunneling request by checking whether the tunnel name of the LAC matches the one configured, and determines the virtual template interface to be used to create the VA interface. Follow these steps to configure an LNS to grant certain L2TP tunneling requests: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number 254

263 To do Use the command Remarks Specify the virtual template interface for receiving calls, the tunnel name on the LAC, and the domain name If the L2TP group number is 1 (the default) If the L2TP group number is not 1 allow l2tp virtual-template virtual-template-number [ remote remote-name ] [ domain domain-name ] allow l2tp virtual-template virtual-template-number remote remote-name [ domain domain-name ] Required Use either command. By default, an LNS denies all incoming calls. If the L2TP group number is 1, you do not need to specify the LAC side tunnel name. In L2TP group 1, the LNS allows the LAC to initiate a tunneling request by using any tunnel name. NOTE: The start l2tp command and the allow l2tp command are mutually exclusive. Configuring one of them automatically disables the other one. The LAC side tunnel name configured on the LNS must be consistent with the local tunnel name configured on the LAC. Configuring user authentication on an LNS An LNS may be configured to authenticate a user that has passed authentication on the LAC to increase security. In this case, the user is authenticated twice, once on the LAC and once on the LNS. Only when the two authentications succeed can an L2TP tunnel be set up. This helps raise security. An LNS authenticates users by using one of the following methods: Proxy authentication: The LNS uses the LAC as an authentication proxy. The LAC sends the LNS all user authentication information from users and the authentication mode configured on the LAC itself. The LNS then checks the user validity according to the received information and the locally configured authentication method. Mandatory CHAP authentication: The LNS uses CHAP authentication to re-authenticate users who have passed authentication on the LAC. LCP re-negotiation: The LNS ignores the LAC proxy authentication information and performs a new round of LCP negotiation with the user. The three authentication methods have different priorities, where LCP re-negotiation has the highest priority and proxy authentication has the lowest priority. Which method the LNS uses depends on your configuration: If you configure both LCP re-negotiation and mandatory CHAP authentication, the LNS uses LCP re-negotiation. If you configure only mandatory CHAP authentication, the LNS performs CHAP authentication of users. If you configure neither LCP re-negotiation nor mandatory CHAP authentication, the LNS uses the LAC for proxy authentication of users. 1. Configuring mandatory CHAP authentication With mandatory CHAP authentication configured, a VPN user that depends on a NAS to initiate tunneling requests is authenticated twice: once by the NAS and once through CHAP on the LNS. Follow these steps to configure mandatory CHAP authentication: 255

264 To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Configure mandatory CHAP authentication mandatory-chap Required By default, CHAP authentication is not performed on an LNS. NOTE: Some PPP clients may not support re-authentication, in which case LNS side CHAP authentication will fail. 2. Configuring LCP re-negotiation In an NAS-initiated dial-up VPDN, a user first negotiates with the NAS at the start of a PPP session. If the negotiation succeeds, the NAS initiates an L2TP tunneling request and sends user information to the LNS. The LNS then determines whether the user is valid according to the proxy authentication information received. Under some circumstances, for example, when authentication and accounting are needed on the LNS, a new round of Link Control Protocol (LCP) negotiation is required between the LNS and the user, and the LNS authenticates the user by using the authentication method configured on the corresponding virtual template interface. If you enable LCP re-negotiation but configure no authentication for the corresponding virtual template interface, the LNS does not perform an additional authentication of users. Instead, the LNS directly allocates addresses from the global address pool to PPP users authenticated by the LAC. Follow these steps to specify the LNS to perform LCP re-negotiation with users: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Specify the LNS to perform LCP re-negotiation with users mandatory-lcp Required By default, an LNS does not perform LCP re-negotiation with users. Configuring AAA authentication for VPN users on an LNS Configure AAA on the LNS in the following cases: Proxy authentication is configured on the LNS Mandatory CHAP authentication is configured on the LNS Mandatory LCP re-negotiation authentication is configured on the LNS and the virtual template interface requires PPP user authentication. After you configure AAA on the LNS, the LNS can authenticate the identities (usernames and passwords) of VPN users for a second time. If a user passes AAA authentication, the user can communicate with the LNS. Otherwise, the L2TP session will be removed. LNS side AAA configurations are similar to those on an LAC (see Configuring AAA authentication for VPN users on LAC side ). 256

265 Enabling L2TP multi-instance If multiple enterprises share the same LNS device and use the same name for the tunnel peers (LAC devices), the LNS device is unable to differentiate which users belong to which enterprises. The L2TP multi-instance function can solve this problem. With this function, an LNS can differentiate multiple VPN domains and service users of different enterprises simultaneously. In an L2TP multi-instance application, specify the domain to which VPN users belong by using the domain keyword in the allow l2tp virtual-template command. After an L2TP tunnel is established, the LNS obtains the domain name from the session negotiation packet and searches for the same domain among those locally configured for VPN users. If an L2TP group s tunnel peer name and domain name match, the LNS establishes a session according to the group configuration. Thus, different sessions can be established for VPN users of different domains. Follow these steps to enable the L2TP multi-instance function: To do Use the command Remarks Enter system view system-view Enable the L2TP multi-instance function l2tpmoreexam enable Required Disabled by default NOTE: If multiple L2TP groups on the LNS are configured with the same remote tunnel name, make sure that their tunnel authentication settings are the same. Mismatching tunnel authentication passwords will result in tunnel establishment failure. Specifying to send ACCM According to RFC 2661, the Asynchronous Control Character Map (ACCM) AVP enables an LNS to inform the LAC of the ACCM that the LNS has negotiated with the PPP peer. Not every LAC supports ACCM. Therefore, an LNS needs to know whether it should send ACCM. By default, an LNS sends ACCM. If the LAC does not support ACCM, configure the LNS not to send ACCM. Follow these steps to configure an LNS to send ACCM: To do Use the command Remarks Enter system view system-view Specify to send ACCM l2tp sendaccm enable Required By default, an LNS sends ACCM. Configuring L2TP connection parameters These L2TP connection parameter configuration tasks apply to both LACs and LNSs and are optional. Configuring L2TP tunnel authentication You can enable tunnel authentication to allow the LAC and LNS to authenticate each other. Either the LAC or the LNS can initiate a tunnel authentication request. To implement tunnel authentication, enable tunnel authentication on both the LAC and LNS, and configure the same non-null password on them. Follow these steps to configure L2TP tunnel authentication: 257

266 To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Enable L2TP tunnel authentication Configure the tunnel authentication password tunnel authentication tunnel password { simple cipher } password Optional Enabled by default Required The password is null by default. NOTE: To ensure tunnel security, enable tunnel authentication. To change the tunnel authentication password, do so after tearing down the tunnel. Otherwise, your change does not take effect. Setting the hello interval To check the connectivity of a tunnel, the LAC and LNS regularly send each other hello packets. On receipt of a hello packet, the LAC or LNS returns a response packet. If the LAC or LNS receives no hello response packet from the peer within a specific period of time, it retransmits the hello packet. If it receives no response packet from the peer after transmitting the hello packet three times, it considers the L2TP tunnel is down and tries to re-establish a tunnel with the peer. Follow these steps to set the hello interval: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Set the hello interval tunnel timer hello hello-interval Optional 60 seconds by default Enabling tunnel flow control The L2TP tunnel flow control function controls data packet transmission by buffering and adjusting data packets that arrive out of order. Follow these steps to enable tunnel flow control: To do Use the command Remarks Enter system view system-view Enter L2TP group view l2tp-group group-number Enable the tunnel flow control function tunnel flow-control Optional Disabled by default Disconnecting tunnels by force Either the LAC or the LNS can initiate a tunnel disconnection request. You can also disconnect a tunnel when no users are online or a network failure occurs. Once a tunnel is disconnected, the control connection and all the sessions within the tunnel are removed. When a user dials in, a new tunnel is established. 258

267 Follow these steps to disconnect tunnels by force: To do Use the command Remarks Disconnect tunnels by force reset l2tp tunnel { id tunnel-id name remote-name } Available in user view Displaying and maintaining L2TP To do Use the command Remarks Display information about L2TP tunnels Display information about L2TP sessions display l2tp tunnel [ { begin exclude include } regular-expression ] display l2tp session [ { begin exclude include } regular-expression ] Available in any view Available in any view Configuration example for NAS-initiated VPN Network requirements A VPN user accesses the corporate headquarters in the following procedure: 1. The user dials in to the NAS (LAC). 2. The NAS determines whether the user is a valid VPN client. If so, it initiates a tunneling request to the LNS. 3. After a tunnel is set up between the NAS and the LNS, the NAS transfers the results of its negotiation with the VPN user to the LNS. 4. The LNS decides whether to accept the connection request according to the negotiated results. 5. The user communicates with the headquarters over the tunnel between the NAS and the LNS. Figure 166 Network diagram Configuration procedure 1. Configure the LAC (NAS). # Configure IP addresses for interfaces. (Details not shown) # Create a local user named vpdnuser, set the password, and enable the PPP service. <LAC> system-view [LAC] local-user vpdnuser [LAC-luser-vpdnuser] password simple Hello [LAC-luser-vpdnuser] service-type ppp [LAC-luser-vpdnuser] quit # Configure interface Async 1/0. 259

268 [LAC] interface async 1/0 [LAC-Async1/0] ip address [LAC-Async1/0] ppp authentication-mode chap [LAC-Async1/0] quit # Enable L2TP. [LAC] l2tp enable # Create an L2TP group and configure its attributes. [LAC] l2tp-group 1 [LAC-l2tp1] tunnel name LAC [LAC-l2tp1] start l2tp ip fullusername vpdnuser # Enable tunnel authentication and specify the tunnel authentication password. [LAC-l2tp1] tunnel authentication [LAC-l2tp1] tunnel password simple aabbcc 2. Configure the LNS. # Configure IP addresses for the interfaces. (Details not shown) # Create a local user named vpdnuser, set the password, and enable the PPP service. The username and password must match those configured on the client. <LNS> system-view [LNS] local-user vpdnuser [LNS-luser-vpdnuser] password simple Hello [LNS-luser-vpdnuser] service-type ppp [LNS-luser-vpdnuser] quit # Configure local authentication for the VPN user. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] ip pool [LNS-isp-system] quit # Enable L2TP. [LNS] l2tp enable # Configure the virtual template interface. [LNS] interface virtual-template 1 [LNS-virtual-template1] ip address [LNS-virtual-template1] ppp authentication-mode chap domain system [LNS-virtual-template1] remote address pool 1 [LNS-virtual-template1] quit # Create an L2TP group, specify the virtual template interface for receiving calls and specify the name of the tunnel on the peer. [LNS] l2tp-group 1 [LNS-l2tp1] tunnel name LNS [LNS-l2tp1] allow l2tp virtual-template 1 remote LAC # Enable tunnel authentication and specify the tunnel authentication password. [LNS-l2tp1] tunnel authentication [LNS-l2tp1] tunnel password simple aabbcc 3. Configure the user. 260

269 In the dial-up network window, enter vpdnuser as the username, and Hello as the password. 4. Verify the configuration. # After the dial-up connection is established, the user host can obtain an IP address (for example, ) and can ping the private IP address of the LNS ( ). # On the LNS, use the display l2tp tunnel command to check the established L2TP tunnels. [LNS] dis l2tp tunnel Total tunnel = 1 LocalTID RemoteTID RemoteAddress Port Sessions RemoteName LAC # On the LNS, use the display l2tp session command to check the established L2TP sessions. [LNS] display l2tp session Total session = 1 LocalSID RemoteSID LocalTID Configuration example for client-initiated VPN Network requirements As shown in Figure 167, a VPN user accesses the corporate headquarters in the following procedure: 1. Configure an IP address and route for the user host, making sure that the host is reachable to the LNS. 2. The user initiates a tunneling request to the LNS. 3. After the LNS accepts the connection request, an L2TP tunnel is set up between the LNS and the VPN user. 4. The VPN user communicates with the headquarters over the tunnel. Figure 167 Network diagram Configuration procedure 1. Configure the LNS. # Configure IP addresses for the interfaces. (Details not shown) # Configure the route between the LNS and the user host. (Details not shown) # Create a local user named vpdnuser, set the password, and enable the PPP service. The username and password must match those configured on the client. <LNS> system-view [LNS] local-user vpdnuser [LNS-luser-vpdnuser] password simple Hello 261

270 [LNS-luser-vpdnuser] service-type ppp [LNS-luser-vpdnuser] quit # Configure local authentication for the VPN user. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] ip pool [LNS-isp-system] quit # Enable L2TP. [LNS] l2tp enable # Configure the virtual template interface. [LNS] interface virtual-template 1 [LNS-virtual-template1] ip address [LNS-virtual-template1] ppp authentication-mode chap domain system [LNS-virtual-template1] remote address pool 1 [LNS-virtual-template1] quit # Create an L2TP group and specify the virtual template interface for receiving calls. [LNS] l2tp-group 1 [LNS-l2tp1] tunnel name LNS [LNS-l2tp1] allow l2tp virtual-template 1 2. Configure the VPN user host Configure the IP address of the user host as , and configure a route to the LNS ( ). Create a virtual private network connection by using the Windows system, or install the L2TP client software, such as WinVPN Client. Complete the following configuration procedure (the procedure depends on the client software): # Specify the VPN username as vpdnuser and the password as Hello. # Specify the Internet interface address of the security gateway as the IP address of the LNS. In this example, the GigabitEthernet interface for the tunnel on the LNS has an IP address of # Modify the connection attributes, setting the protocol to L2TP, the encryption attribute to customized and the authentication mode to CHAP. 3. Verify the configuration. # On the user host, initiate the L2TP connection. After the connection is established, the user host can obtain the IP address and ping the private IP address of the LNS ( ). # On the LNS, use the display l2tp session command to check the established L2TP session. [LNS-l2tp1] display l2tp session Total session = 1 LocalSID RemoteSID LocalTID # On the LNS, use the display l2tp tunnel command to check the established L2TP tunnel. [LNS-l2tp1] display l2tp tunnel Total tunnel = 1 LocalTID RemoteTID RemoteAddress Port Sessions RemoteName l2tpuser 262

271 Configuration example for LAC-auto-initiated VPN Network requirements Create a virtual PPP user on the LAC and configure the LAC to initiate a tunneling request to the LNS to establish an L2TP tunnel for the virtual PPP user. When a VPN user accesses the corporate network, all packets between the VPN user and the corporate network are transmitted through the L2TP tunnel. A VPN user accesses the corporate network in the following procedure: 1. The VPN user sends a packet to the LAC through the LAN. 2. The LAC encapsulates the packet and then forwards the packet through the L2TP tunnel to the LNS. Figure 168 Network diagram Configuraton procedure 1. Configure the LNS. # Configure IP addresses for interfaces. (Details not shown) # Create a local user, configure a username and password for the user, and specify the service type as PPP. <LNS> system-view [LNS] local-user vpdnuser [LNS-luser-vpdnuser] password simple Hello [LNS-luser-vpdnuser] service-type ppp [LNS-luser-vpdnuser] quit # Configure a virtual template interface. [LNS] interface virtual-template 1 [LNS-virtual-template1] ip address [LNS-virtual-template1] remote address pool 1 [LNS-virtual-template1] ppp authentication-mode pap # Configure the virtual template interface to not check the next hop of a packet to be sent. [LNS-Virtual-Template1] ppp ignore match-next-hop [LNS-virtual-template1] quit # Configure local authentication for VPN users. [LNS] domain system [LNS-isp-system] authentication ppp local [LNS-isp-system] ip pool [LNS-isp-system] quit # Enable L2TP and create an L2TP group. [LNS] l2tp enable [LNS] l2tp-group 1 # Configure the local tunnel name and specify the virtual template interface for receiving packets and the tunnel name on the LAC. 263

272 [LNS-l2tp1] tunnel name LNS [LNS-l2tp1] allow l2tp virtual-template 1 remote LAC # Enable tunnel authentication and configure the authentication password. [LNS-l2tp1] tunnel authentication [LNS-l2tp1] tunnel password simple aabbcc [LNS-l2tp1] quit # Configure a static route so that packets destined for the VPN will be forwarded through the L2TP tunnel. [LNS] ip route-static virtual-template 1 2. Configure the LAC. # Configure IP addresses for the interfaces. (Details not shown) # Enable L2TP and create an L2TP group. <LAC> system-view [LAC] l2tp enable [LAC] l2tp-group 1 # Configure the local tunnel name and specify the IP address of the tunnel peer (LNS). [LAC-l2tp1] tunnel name LAC [LAC-l2tp1] start l2tp ip fullusername vpdnuser # Enable tunnel authentication and configure the authentication password. [LAC-l2tp1] tunnel authentication [LAC-l2tp1] tunnel password simple aabbcc [LAC-l2tp1] quit # Configure the PPP authentication method PAP, authentication username vpdnuser, and password Hello for the virtual PPP user. [LAC] interface virtual-template 1 [LAC-Virtual-Template1] ip address ppp-negotiate [LAC-Virtual-Template1] ppp pap local-user vpdnuser password simple Hello [LAC-Virtual-Template1] ppp authentication-mode pap # Configure the virtual template interface to not check the next hop of a packet to be sent. [LAC-Virtual-Template1] ppp ignore match-next-hop [LAC-Virtual-Template1] quit # Configure a static route so that packets destined for the corporate will be forwarded through the L2TP tunnel. [LAC] ip route-static virtual-template 1 # Create a local user, configure the username and password, and specify the service type as PPP. [LAC] local-user vpdnuser [LAC-luser-vpdnuser] password simple Hello [LAC-luser-vpdnuser] service-type ppp # Trigger the LAC to establish an L2TP tunnel with the LNS. [LAC] interface virtual-template 1 [LAC-virtual-template1] l2tp-auto-client enable NOTE: On each host connected to the LAC or LNS, configure the gateway as the LAC or LNS. 264

273 3. Verify the configuration. # On the LNS, perform the display l2tp session command to view the established L2TP session. [LNS] display l2tp session Total session = 1 LocalSID RemoteSID LocalTID # On the LNS, perform the display l2tp tunnel command to view the established L2TP tunnel. [LNS] display l2tp tunnel Total tunnel = 1 LocalTID RemoteTID RemoteAddress Port Sessions RemoteName LAC # On the LNS, you should be able to ping , a private network address on the LAC side. This indicates that hosts on /16 and those on /16 can communicate with each other through the L2TP tunnel. [LNS] ping -a PING : 56 data bytes, press CTRL_C to break Reply from : bytes=56 Sequence=1 ttl=255 time=2 ms Reply from : bytes=56 Sequence=2 ttl=255 time=2 ms Reply from : bytes=56 Sequence=3 ttl=255 time=2 ms Reply from : bytes=56 Sequence=4 ttl=255 time=2 ms Reply from : bytes=56 Sequence=5 ttl=255 time=2 ms ping statistics packet(s) transmitted 5 packet(s) received 0.00% packet loss round-trip min/avg/max = 2/2/2 ms Configuration example for L2TP multi-domain application Network requirements Multiple enterprises share an LNS and use the same tunnel name for the LAC end. Users of different enterprises access their corporate servers through L2TP VPDNs. Host A is a user from enterprise 1, which has the domain name aaa.net. Host B is a user from enterprise 2, which has the domain name bbb.net. 265

274 Figure 169 Network diagram Corporate network 1 Host A GE0/ /24 GE0/ /24 GE0/ /24 WAN L2TP tunnel GE0/ /24 LAC LNS Corporate network 2 Host B Configuration procedure 1. Configure the LAC. In this example, GigabitEthernet 0/1 and GigabitEthernet 0/3 on the LAC are both user access interfaces. The IP address of GigabitEthernet 0/2 through which the LAC connects to the tunnel is The IP address of GigabitEthernet 0/1 through which the LNS connects to the tunnel is # Create two local users, set the passwords, and enable the PPP service. <LAC> system-view [LAC] local-user vpdn1 [LAC-luser-vpdn1] password simple [LAC-luser-vpdn1] service-type ppp [LAC-luser-vpdn1] quit [LAC] local-user vpdn2 [LAC-luser-vpdn2] password simple [LAC-luser-vpdn2] service-type ppp [LAC-luser-vpdn2] quit # Configure local authentication for the users. [LAC] domain aaa.net [LAC-isp-aaa.net] authentication ppp local [LAC-isp-aaa.net] quit [LAC] domain bbb.net [LAC-isp-bbb.net] authentication ppp local [LAC-isp-bbb.net] quit # Configure PPPoE servers on interface GigabitEthernet 0/1 and GigabitEthernet 0/3. [LAC] interface GigabitEthernet 0/3 [LAC-GigabitEthernet0/3] pppoe-server bind virtual-template 100 [LAC-GigabitEthernet0/3] quit [LAC] interface GigabitEthernet 0/1 [LAC-GigabitEthernet0/1] pppoe-server bind virtual-template 101 [LAC-GigabitEthernet0/1] quit # Configure an IP address for interface GigabitEthernet 0/2. [LAC] interface GigabitEthernet 0/2 [LAC-GigabitEthernet0/2] ip address [LAC-GigabitEthernet0/2] quit # Create the virtual template interfaces and configure CHAP authentication. 266

275 [LAC] interface virtual-template 100 [LAC-Virtual-Template100] ppp authentication-mode chap domain aaa.net [LAC-Virtual-Template100] quit [LAC] interface virtual-template 101 [LAC-Virtual-Template101] ppp authentication-mode chap domain bbb.net [LAC-Virtual-Template101] quit # Create two L2TP groups and configure the related attributes. [LAC] l2tp enable [LAC] l2tp-group 1 [LAC-l2tp1] tunnel name LAC-1 [LAC-l2tp1] start l2tp ip domain aaa.net [LAC-l2tp1] quit [LAC] l2tp-group 2 [LAC-l2tp2] tunnel name LAC-1 [LAC-l2tp2] start l2tp ip domain bbb.net # Enable the tunnel authentication and specify a tunnel authentication password. [LAC-l2tp2] tunnel authentication [LAC-l2tp2] tunnel password simple [LAC-l2tp2] quit [LAC] l2tp-group 1 [LAC-l2tp1] tunnel authentication [LAC-l2tp1] tunnel password simple Configure the LNS. # Enable L2TP. <LNS> system-view [LNS] l2tp enable # Enable L2TP multi-instance. [LNS] l2tpmoreexam enable # Create two local users, set the passwords, and enable the PPP service. [LNS] local-user vpdn1 [LNS-luser-vpdn1] password simple [LNS-luser-vpdn1] service-type ppp [LNS-luser-vpdn1] quit [LNS] local-user vpdn2 [LNS-luser-vpdn2] password simple [LNS-luser-vpdn2] service-type ppp [LNS-luser-vpdn2] quit # Specify the IP address of GigabitEthernet 0/1 through which the LNS connects to the tunnel as [LNS] interface GigabitEthernet 0/1 [LNS-GigabitEthernet0/1] ip address [LNS-GigabitEthernet0/1] quit # Create two address pools. [LNS] domain aaa.net [LNS-isp-aaa.net] authentication ppp local [LNS-isp-aaa.net] ip pool [LNS-isp-aaa.net] quit 267

276 [LNS] domain bbb.net [LNS-isp-bbb.net] authentication ppp local [LNS-isp-bbb.net] ip pool [LNS-isp-bbb.net] quit # Create two virtual template interfaces. [LNS] interface virtual-template 1 [LNS-Virtual-Template1] ip address [LNS-Virtual-Template1] remote address pool 1 [LNS-Virtual-Template1] ppp authentication-mode chap domain aaa.net [LNS-Virtual-Template1] quit [LNS] interface virtual-template 2 [LNS-Virtual-Template2] ip address [LNS-Virtual-Template2] remote address pool 1 [LNS-Virtual-Template2] ppp authentication-mode chap domain bbb.net [LNS-Virtual-Template2] quit # Create two L2TP groups. [LNS] l2tp-group 3 [LNS-l2tp3] tunnel name LNS [LNS-l2tp3] tunnel authentication [LNS-l2tp3] allow l2tp virtual-template 1 remote LAC-1 domain aaa.net [LNS-l2tp3] tunnel password simple [LNS-l2tp3] quit [LNS] l2tp-group 4 [LNS-l2tp4] tunnel name LNS [LNS-l2tp4] tunnel authentication [LNS-l2tp4] allow l2tp virtual-template 2 remote LAC-1 domain bbb.net [LNS-l2tp4] tunnel password simple If RADIUS authentication is required on the LNS, modify the AAA configurations as needed. For more information about AAA configuration, see Access Control Configuration Guide. 3. Configure the users. Create a dial-up connection on each host. On Host A, enter vpdn1@aaa.net as the username and as the password in the dial-up terminal window. On Host B, enter vpdn2@aaa.net as the username and as the password in the dial-up terminal window. 4. Verify the configuration. # After Host A establishes a dial-up connection with enterprise 1, Host A obtains the IP address and can ping the private address of the LNS ( ). # After Host B establishes a dial-up connection with enterprise 2, Host B obtains the IP address and can ping the private address of the LNS ( ). # On the LNS, use the display l2tp session command to check the established L2TP sessions. [LNS-l2tp1] display l2tp session Total session = 2 LocalSID RemoteSID LocalTID 268

277 # On the LNS, use the display l2tp tunnel command to check the established L2TP tunnels. [LNS-l2tp1] display l2tp tunnel Total tunnel = 2 LocalTID RemoteTID RemoteAddress Port Sessions RemoteName LAC LAC-1 Complicated network application A security gateway can simultaneously serve as an LAC and an LNS. Additionally, it can support more than one incoming call. If memory and physical lines are enough, L2TP can receive and make multiple calls at the same time. For such a complicated network, you can see through the previous configuration examples and consider them comprehensively to find a configuration solution. Pay attention to static route configuration. Many L2TP applications rely on static routes to initiate connection requests. Troubleshooting L2TP Symptom 1 The VPN connection setup process is complex. The following presents an analysis of some common faults that may occur in the process. Before troubleshooting the VPN, make sure that the LAC and LNS are connected properly across the public network. Users cannot log in. Analysis and solution Possible reasons for login failure include: 1. Tunnel setup failure, which may occur in the following cases: The address of the LNS is set incorrectly on the LAC. No L2TP group is configured on the LNS (usually a router) to receive calls from the tunnel peer. For details, see the description of the allow command. Tunnel authentication fails. Tunnel authentication must be enabled on both the LAC and LNS and the tunnel authentication passwords configured on the two sides must match. If the tunnel is torn down by force on the local end but the remote end has not received the notification packet for reasons such as network delay, a new tunnel cannot be set up. 2. PPP negotiation failure, which may occur because: Usernames, passwords, or both are incorrectly configured on the LAC or are not configured on the LNS. The LNS cannot allocate addresses. This may be because the address pool is too small or no address pool is configured. The authentication type is inconsistent. For example, the default authentication type for a VPN connection created on Windows 2000 is Microsoft Challenge Handshake Authentication Protocol (MSCHAP). If the remote end does not support MSCHAP, the PPP negotiation will fail. HP recommends using CHAP. 269

278 Symptom 2 Data transmission fails. A connection is setup but data cannot be transmitted. For example, the LAC and LNS cannot ping each other. Analysis and solution Possible reasons for data transmission failure include: 1. No route is available. The LAC (or LAC client) must have a route to the private network behind the LNS and the LNS must have a route to the private network behind the LAC. Otherwise, data transmission fails. You can use the display ip routing-table command on the LAC (LAC client) and LNS to check whether the expected routes are present. If not, configure a static route or configure a dynamic routing protocol. 2. Congestion occurs on the Internet backbone and packet loss ratio is high. L2TP data transmission is based on UDP, which does not provide the packet error control function. If the line is unstable, the LAC and LNS may be unable to ping each other and L2TP applications may fail. 270

279 Certificate management PKI overview PKI terms Digital certificate CRL CA policy The Public Key Infrastructure (PKI) is a general security infrastructure for providing information security through public key technologies. PKI, also called asymmetric key infrastructure, uses a key pair to encrypt and decrypt the data. The key pair consists of a private key and a public key. The private key must be kept secret but the public key needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other. A key problem of PKI is how to manage the public keys. Currently, PKI employs the digital certificate mechanism to solve this problem. The digital certificate mechanism binds public keys to their owners, helping distribute public keys in large networks securely. With digital certificates, the PKI system provides network communication and e-commerce with security services such as user authentication, data non-repudiation, data confidentiality, and data integrity. HP's PKI system provides certificate management for IP Security (IPsec) and Secure Sockets Layer (SSL). A digital certificate is a file signed by a certificate authority (CA) for an entity. It includes mainly the identity information of the entity, the public key of the entity, the name and signature of the CA, and the validity period of the certificate, where the signature of the CA guarantees the validity and authority of the certificate. A digital certificate must comply with the international standard of ITU-T X.509. Currently, the most common standard is X.509 v3. This document involves local certificate and CA certificate. A local certificate is a digital certificate signed by a CA for an entity, and a CA certificate is the certificate of a CA. If multiple CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the top level. The root CA has a CA certificate signed by itself and each lower level CA has a CA certificate signed by the CA at the next higher level. An existing certificate may need to be revoked when, for example, the username changes, the private key leaks, or the user stops the business. Revoking a certificate is to remove the binding of the public key with the user identity information. In PKI, the revocation is made through certificate revocation lists (CRLs). Whenever a certificate is revoked, the CA publishes one or more CRLs to show all certificates that have been revoked. The CRLs contain the serial numbers of all revoked certificates and provide an effective way for checking the validity of certificates. A CA may publish multiple CRLs when the number of revoked certificates is so large that publishing them in a single CRL may degrade network performance. In this case, CRL distribution points indicate the URLs of these CRLs. A CA policy is a set of criteria that a CA follows in processing certificate requests, issuing and revoking certificates, and publishing CRLs. Usually, a CA advertises its policy in the form of certification practice 271

280 statement (CPS). A CA policy can be acquired through out-of-band means such as phone, disk, and . As different CAs may use different methods to check the binding of a public key with an entity, make sure that you understand the CA policy before selecting a trusted CA for certificate request. Architecture of PKI A PKI system consists of entities, a CA, a registration authority (RA) and a PKI repository, as shown in Figure 170. Figure 170 PKI architecture Entity CA RA PKI repository An entity is an end user of PKI products or services, such as a person, an organization, a device like a router or a switch, or a process running on a computer. A certificate authority (CA) is a trusted authority responsible for issuing and managing digital certificates. A CA issues certificates, specifies the validity periods of certificates, and revokes certificates as needed by publishing CRLs. A registration authority (RA) is an extended part of a CA or an independent authority. An RA can implement functions including identity authentication, CRL management, key pair generation and key pair backup. It receives registration requests, examines the qualifications of users, and decides whether the CA can assign digital certificates to the users. Sometimes, a CA assumes the registration management responsibility and no independent RA exists. The PKI standard recommends that an independent RA be used for registration management to achieve higher security of application systems. A PKI repository can be a Lightweight Directory Access Protocol (LDAP) server or a common database. It stores and manages information like certificate requests, certificates, keys, CRLs and logs and it provides a simple query function. LDAP is a protocol for accessing and managing PKI information. An LDAP server stores user information and digital certificates from the RA server and provides directory navigation service. From an LDAP server, an entity can retrieve digital certificates of its own and other entities. 272

281 Applications of PKI VPN Secure Web security The PKI technology can satisfy the security requirements of online transactions. As an infrastructure, PKI has a wide range of applications. Here are some application examples. A virtual private network (VPN) is a private data communication network built on the public communication infrastructure. A VPN can leverage network layer security protocols (for instance, IPsec) in conjunction with PKI-based encryption and digital signature technologies to achieve confidentiality. s require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. The secure protocol that is currently developing rapidly is Secure/Multipurpose Internet Mail Extensions (S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature. For Web security, two peers can establish a Secure Sockets Layer (SSL) connection first for transparent and secure communications at the application layer. With PKI, SSL enables encrypted communications between a browser and a server. Both the communication parties can verify the identity of each other through digital certificates. Operation of PKI In a PKI-enabled network, an entity can request a local certificate from the CA and the device can check the validity of certificate. The following describes how it works: 1. An entity submits a certificate request to the CA. 2. The RA verifies the identity of the entity and then sends the identity information and the public key with a digital signature to the CA. 3. The CA verifies the digital signature, approves the application, and issues a certificate. 4. The RA receives the certificate from the CA, sends it to the LDAP server to provide directory navigation service, and notifies the entity that the certificate is successfully issued. 5. The entity retrieves the certificate. With the certificate, the entity can communicate with other entities safely through encryption and digital signature. 6. The entity makes a request to the CA when it needs to revoke its certificate. The CA approves the request, updates the CRLs and publishes the CRLs on the LDAP server. Configuring PKI in the web interface Configuration task list The firewall supports the following PKI certificate request modes: Manual In manual mode, you need to retrieve a CA certificate, generate a local RSA key pair, and submit a local certificate request for an entity. Auto In auto mode, an entity automatically requests a certificate through Simple Certification Enrollment Protocol (SCEP, a dedicated protocol for an entity to communicate with a CA) when it has no local certificate or the present certificate is about to expire. 273

282 You can specify the PKI certificate request mode for a PKI domain. Different PKI certificate request modes require different configurations. Requesting a certificate manually Table 31 Configuration task list for requesting a certificate manually Task Remarks Required Create a PKI entity and configure the identity information. Creating a PKI entity A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. The identity settings of an entity must be compliant to the CA certificate issue policy. Otherwise, the certificate request may be rejected. Required Creating a PKI domain Create a PKI domain, setting the certificate request mode to Manual. Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. Required Generate a local RSA key pair. By default, no local RSA key pair exists. Generating an RSA key pair Generating an RSA key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user, and the public key is transferred to the CA along with some other information. IMPORTANT: If a local certificate already exists, remove the certificate before generating a new key pair to keep the consistency between the key pair and the local certificate. Required Obtain the CA certificate and save it locally. For more information, see Retrieving and displaying a certificate. Retrieving the CA certificate Certificate retrieval serves the following purposes: Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count, Prepare for certificate verification. IMPORTANT: If a local CA certificate already exists, you cannot perform the CA certificate retrieval operation. This is to avoid possible mismatch between certificates and registration information resulting from relevant changes. To retrieve the CA certificate, you need to remove the CA certificate and local certificate first. 274

283 Task Remarks Required When requesting a certificate, an entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. Requesting a local certificate A certificate request can be submitted to a CA in online mode or offline mode. In online mode, if the request is granted, the local certificate will be retrieved to the local system automatically. In offline mode, you need to retrieve the local certificate by an out-of-band means. IMPORTANT: If a local certificate already exists, you cannot perform the local certificate retrieval operation. This is to avoid possible mismatch between the local certificate and registration information resulting from relevant changes. To retrieve a new local certificate, you need to remove the CA certificate and local certificate first. Optional Destroying the RSA key pair Destroy the existing RSA key pair and the corresponding local certificate. If the certificate to be retrieved contains an RSA key pair, you need to destroy the existing RSA key pair. Otherwise, the retrieving operation will fail. Optional Retrieving and displaying a certificate Retrieving and displaying a CRL Retrieve an existing certificate and display its information. IMPORTANT: Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. Optional Retrieve a CRL and display its contents. Requesting a Certificate Automatically Table 32 Configuration task list for requesting a certificate automatically Task Remarks Required Create a PKI entity and configure the identity information. Creating a PKI entity A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. The identity settings of an entity must be compliant to the CA certificate issue policy. Otherwise, the certificate request may be rejected. Required Creating a PKI domain Create a PKI domain, setting the certificate request mode to Auto. Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other applications like IKE and SSL, and has only local significance. 275

284 Task Remarks Optional Destroying the RSA key pair Destroy the existing RSA key pair and the corresponding local certificate. If the certificate to be retrieved contains an RSA key pair, you need to destroy the existing RSA key pair. Otherwise, the retrieving operation will fail. Optional Retrieve an existing certificate and display its information. Retrieving and displaying a certificate Retrieving and displaying a CRL IMPORTANT: Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This is in order to avoid inconsistency between the certificate and registration information due to related configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and local certificate first. Optional Retrieve a CRL and display its contents. Creating a PKI entity Select VPN > Certificate Management > Entity from the navigation tree to display existing PKI entities, as shown in Figure 171. Then, click Add to enter the PKI entity configuration page, as shown in Figure 172. Figure 171 PKI entity list 276

285 Figure 172 PKI entity configuration page Table 33 Configuration items Item Entity Name Common Name IP Address FQDN Country/Region Code State Locality Organization Organization Unit Description Type the name for the PKI entity. Type the common name for the entity. Type the IP address of the entity. Type the fully qualified domain name (FQDN) for the entity. An FQDN is a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, is an FQDN, where www indicates the host name and whatever.com the domain name. Type the country code for the entity. Type the state or province for the entity. Type the locality for the entity. Type the organization name for the entity. Type the unit name for the entity. Creating a PKI domain Select VPN > Certificate Management > Domain from the navigation tree to display existing PKI domains, as shown in Figure 173. Then, click Add to enter the PKI domain configuration page, as shown in Figure

286 Figure 173 PKI domain list Figure 174 PKI domain configuration page Table 34 Configuration items Item Domain Name Description Type the name for the PKI domain. Type the identifier of the trusted CA. An entity requests a certificate from a trusted CA. The trusted CA takes the responsibility of certificate registration, distribution, and revocation, and query. CA Identifier IMPORTANT: In offline mode, this item is optional. In other modes, this item is required. The CA identifier is required only when you retrieve a CA certificate. It is not used during local certificate request. Select the local PKI entity. Entity Name When submitting a certificate request to a CA, an entity needs to show its identity information. Available PKI entities are those that have been configured on the Web interface you can enter by selecting VPN > Certificate Management > Entity. Institution Select the authority for certificate request. CA Indicates that the entity requests a certificate from a CA. RA Indicates that the entity requests a certificate from an RA. 278

287 Item Description Type the URL of the RA. Requesting URL The entity will submit the certificate request to the server at this URL through the SCEP protocol. The SCEP protocol is intended for communication between an entity and an authentication authority. In offline mode, this item is optional. In other modes, this item is required. IMPORTANT: In offline mode, this item is optional. In other modes, this item is required. Currently, this item does not support domain name resolution. LDAP IP Port Version Request Mode Password Encrypt Password Type the IP address, port number, and version number of the LDAP server. Usually, an LDAP server stores certificates and CRL information. The LDAP server must be configured properly. Select the online certificate request mode, which can be Auto or Manual. When the certificate request mode is set to Auto, type a password for certificate revocation and select the box to display the password in cipher text. Specify the fingerprint used for verifying the CA root certificate. Fingerprint Hash Fingerprint After receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate. If you specify MD5 as the hash algorithm, type an MD5 fingerprint. The fingerprint must a string of 32 characters in hexadecimal notation. If you specify SHA1 as the hash algorithm, type an SHA1 fingerprint. The fingerprint must a string of 40 characters in hexadecimal notation. If you do not specify the fingerprint hash, do not type any fingerprint. The entity will not verify the CA root certificate, and you yourself must make sure that the CA server is trusted. IMPORTANT: The fingerprint must be configured if you specify the certificate request mode as Auto. If you specify the certificate request mode as Manual, you can leave the fingerprint settings null. If you do not configure the fingerprint, the entity will not verify the CA root certificate and you yourself must make sure that the CA server is trusted. Polling Count Polling Interval Enable CRL Checking Set the polling interval and attempt limit for querying the certificate request status. After an entity makes a certificate request, the CA may need a long period of time if it verifies the certificate request in manual mode. During this period, the applicant needs to query the status of the request periodically to get the certificate as soon as possible after the certificate is signed. These two items dictate the polling operation. Select this box to specify that CRL checking is required during certificate verification. 279

288 Item CRL Update Period CRL URL Description Type the CRL update period, that is, the interval at which the PKI entity downloads the latest CRLs. This item is available when the Enable CRL Checking box is selected. By default, the CRL update period depends on the next update field in the CRL file. IMPORTANT: The manually configured CRL update period takes precedent over that specified in the CRL file. Type the URL of the CRL distribution point. This item is available when the Enable CRL Checking box is selected. When the URL of the CRL distribution point is not set, you should acquire the CA certificate and a local certificate, and then acquire a CRL through SCEP. IMPORTANT: Currently, this item does not support domain name resolution. Generating an RSA key pair Select VPN > Certificate Management > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 175. Click Create Key to enter the RSA key pair generation page, as shown in Figure 176. Figure 175 Certificate list Figure 176 RSA key pair generation page 280

289 Table 35 Configuration items Item Key Length Description Type the length of the RSA keys. Destroying the RSA key pair Select VPN > Certificate Management > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 175. Click Destroy Key to enter the RSA key pair destruction page, as shown in Figure 177. Then, click Apply to destroy the existing RSA key pair and the corresponding local certificate. Figure 177 RSA key pair destruction page Retrieving and displaying a certificate You can download an existing CA certificate or local certificate from the CA server and save it locally. To do so, you can use offline mode or online mode. In offline mode, you need to retrieve a certificate by an out-of-band means like FTP, disk, and then import it into the local PKI system. Select VPN > Certificate Management > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 175. Click Retrieve Cert to enter the PKI certificate retrieval page, as shown in Figure 178. Figure 178 PKI certificate retrieval page Table 36 Configuration items Item Domain Name Certificate Type Enable Offline Mode Get File From Device Description Select the PKI domain for the certificate. Select the type of the certificate to be retrieved, which can be CA or local. Select this box to retrieve a certificate in offline mode (that is, by an out-of-band means like FTP, disk, or ) and then import the certificate into the local PKI system. Specify the path and name of the certificate file. 281

290 Item Get File From PC Password Description If the certificate file is saved on the firewall, select Get File From Device and then specify the path of the file on the firewall. If the certificate file is saved on a local PC, select Get File From PC and. then specify the path to the file and select the partition of the firewall for saving the file. Enter the password for protecting the private key, which was specified when the certificate was exported. After retrieving a certificate, you can click View Cert corresponding to the certificate from the PKI certificates list to display the contents of the certificate, as shown in Figure 179. Figure 179 Certificate information Requesting a local certificate Select VPN > Certificate Management > Certificate from the navigation tree to display existing PKI certificates, as shown in Figure 175. Click Request Cert to enter the local certificate request page, as shown in Figure 180. Figure 180 Local certificate request page 282

291 Table 37 Configuration items Item Domain Name Password Enable Offline Mode Description Select the PKI domain for the certificate. Type the password for certificate revocation. Select this box to request a certificate in offline mode, that is, by an out-of-band means like FTP, disk, or . If you cannot request a certificate from the CA through the SCEP protocol, you can enable the offline mode. In this case, after clicking Apply, the offline certificate request information page appears, as shown in Figure 181. Submit the information to the CA to request a local certificate. Figure 181 Offline certificate request information page Retrieving and displaying a CRL Select VPN > Certificate Management > CRL from the navigation tree to display CRLs, as shown in Figure 182. Figure 182 CRL Click Retrieve CRL to retrieve the CRL of a domain. Then, click View CRL for the domain to display the contents of the CRL, as shown in Figure

292 Figure 183 CRL information PKI configuration examples in the web interface Configuring a PKI entity to request a certificate from a CA (method i) Network requirements As shown in Figure 184, configure Firewall to work as the PKI entity, so that: Firewall submits a local certificate request to the CA server, which runs Windows 2003 server operating system. Firewall acquires CRLs for certificate verification. Figure 184 Network diagram Configuring the CA server # Install the CA server component. 284

293 From the start menu, select Control Panel > Add or Remove Programs, and then select Add/Remove Windows Components. Then in the pop-up dialog box, select Certificate Services and click Next to begin the installation. # Install the SCEP add-on. Because a CA server running Windows 2003 server operating system does not support SCEP by default, you must install the SCEP add-on to provide the device with automatic certificate registration and retrieval. After the add-on is installed, a prompt dialog box appears, displaying the URL of the registration server configured on the device. # Modify the certificate service properties. From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If the CA server and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA. Right-click CA server and select Properties from the shortcut menu, and select the Policy Module tab in the CA server Properties dialog box. Select the option of Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. Then click OK. # Modify the IIS attributes. From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager and then select Web Sites from the navigation tree. Right-click Default Web Site and select Properties. Then select the Home Directory tab. Specify the path for certificate service in the Local path field. To avoid conflicts with existing services, change the TCP port number to an unused one on the Web Site tab. After the configuration, make sure that the system clock of the device and that of the CA are synchronized, so that the device can request certificate correctly. Configuring Firewall # Create a PKI entity Select VPN > Certificate Management > Entity from the navigation tree and then click Add to perform the configurations shown in Figure 185. Figure 185 Add a PKI entity Type aaa as the PKI entity name. 285

294 Type device as the common name. Click Apply. # Create a PKI domain. Select VPN > Certificate Management > Domain from the navigation tree and then click Add to perform the configurations shown in Figure 186. Figure 186 Add a PKI domain Type torsa as the PKI domain name. Type CA server as the CA identifier. Select aaa as the local entity. Select RA as the authority for certificate request. Type as the URL for certificate request. The URL must be in the format of where host and port are the host address and port number of the CA server. Select Manual as the certificate request mode. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?, click OK to confirm. # Generate an RSA key pair. Select VPN > Certificate Management > Certificate from the navigation tree and then click Create Key to perform the configurations shown in Figure 187. Figure 187 Generate an RSA key pair 286

295 Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Retrieve Cert to perform the configurations shown in Figure 188. Figure 188 Retrieve the certificate Select torsa as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Request Cert to perform the configurations shown in Figure 189. Figure 189 Request a certificate Select torsa as the PKI domain. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. Verifying the configuration After the configuration, select VPN > Certificate Management > Certificate from the navigation tree, and then click View Cert corresponding to the certificate of PKI domain torsa to view the certificate information, as shown in Figure 190. You can also click View Cert corresponding to the CA certificate of PKI domain torsa to view the CA certificate information. 287

296 Figure 190 Detailed information about the local certificate 288

297 289

298 Configuring a PKI entity to request a certificate from a CA (method ii) Network requirements As shown in Figure 191, configure Firewall working as the PKI entity, so that: Firewall submits a local certificate request to the CA server, which runs the RSA Keon software. Firewall acquires CRLs for certificate verification. Figure 191 Network diagram Configuring the CA server # Create a CA server named myca. In this example, you need to configure the basic attributes of Nickname and Subject DN on the CA server at first: Nickname Name of the trusted CA Subject DN DN information of the CA, including the Common Name (CN) Organization Unit (OU) Organization (O) Country (C) The other attributes may use the default values. # Configure extended attributes After configuring the basic attributes, you need to perform configuration on the Jurisdiction Configuration page of the CA server. This includes selecting the proper extension profiles, enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting. # Configure the CRL publishing behavior After completing the configuration, you need to perform CRL related configurations. In this example, select the local CRL publishing mode of HTTP and set the HTTP URL to After the configuration, make sure that the system clock of the device is synchronous to that of the CA, so that the device can request certificates and retrieve CRLs properly. Configuring Firewall # Create a PKI entity. Select VPN > Certificate Management > Entity from the navigation tree and then click Add to perform the configurations shown in Figure

299 Figure 192 Add a PKI entity Type aaa as the PKI entity name. Type device as the common name. Click Apply. # Create a PKI domain. Select VPN > Certificate Management > Domain from the navigation tree and then click Add to perform the configurations shown in Figure

300 Figure 193 Add a PKI domain Type torsa as the PKI domain name. Type myca as the CA identifier. Select aaa as the local entity. Select CA as the authority for certificate request. Type as the URL for certificate request. The URL must be in the format of Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA. Select Manual as the certificate request mode. Click Advanced Configuration to display the advanced configuration items. Select the Enable CRL Checking box. Type as the CRL URL. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?, click OK to confirm. # Generate an RSA key pair. Select VPN > Certificate Management > Certificate from the navigation tree and then click Create Key to perform the configurations shown in Figure

301 Figure 194 Generate an RSA key pair Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Retrieve Cert to perform the configurations shown in Figure 195. Figure 195 Retrieve the certificate Select torsa as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Request Cert to perform the configurations shown in Figure 196. Figure 196 Request a certificate Select torsa as the PKI domain. Select Password and then type challenge-word as the password. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. # Retrieve the CRL. 293

302 After retrieving a local certificate, select VPN > Certificate Management > CRL from the navigation tree. Figure 197 Retrieve CRL Click Retrieve CRL of the PKI domain of torsa. Verifying the configuration After the configuration, select VPN > Certificate Management > Certificate from the navigation tree to view detailed information about the retrieved CA certificate and local certificate, or select VPN > Certificate Management > CRL from the navigation tree to view detailed information about the retrieved CRL. Applying RSA digital signature in IKE negotiation NOTE: In this configuration example, either Device A or Device B is the firewall. Network requirements As shown in Figure 198, An IPsec tunnel is set up between Device A and Device B to secure the traffic between Host A on subnet /24 and Host B on subnet /24. Device A and Device B use IKE for IPsec tunnel negotiation and RSA digital signature of a PKI certificate system for identity authentication. Device A and Device B use different CAs. They may also use the same CA as required. 294

303 Figure 198 Network diagram Configuring Device A # Create a PKI entity. Select VPN > Certificate Management > Entity from the navigation tree and then click Add to perform the configurations shown in Figure

304 Figure 199 Add PKI entity Type en as the PKI entity name. Type device-a as the common name. Type as the IP address of the entity. Click Apply. # Create a PKI domain. Select VPN > Certificate Management > Domain from the navigation tree and then click Add to perform the configurations shown in Figure

305 Figure 200 Add PKI domain Type 1 as the PKI domain name. Type CA1 as the CA identifier. Select en as the local entity. Select RA as the authority for certificate request. Type as the URL for certificate request. (The RA URL given here is just an example. Configure the RA URL as required.) Type as the IP address of the LDAP server, 389 as the port number, and select 2 as the version number. Select Manual as the certificate request mode. Click Advanced Configuration to display the advanced configuration items. Select the Enable CRL Checking box. Type ldap:// as the URL for CRLs. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?, click OK to confirm. # Generate an RSA key pair. Select VPN > Certificate Management > Certificate from the navigation tree and then click Create Key to perform the configurations shown in Figure

306 Figure 201 Generate an RSA key pair Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Retrieve Cert to perform the configurations shown in Figure 202. Figure 202 Retrieve the CA certificate Select 1 as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Request Cert to perform the configurations shown in Figure 203. Figure 203 Request a local certificate Select 1 as the PKI domain. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. # Retrieve the CRL. 298

307 After retrieving a local certificate, select VPN > Certificate Management > CRL from the navigation tree. Figure 204 Retrieve the CRL Click Retrieve CRL of the PKI domain of 1. # Configure IKE proposal 1, using RSA signature for identity authentication. Select VPN > IKE > Proposal from the navigation tree and then click Add to perform the configurations shown in Figure 205. Figure 205 Add an IKE proposal Type 1 as the IKE proposal number. Select RSA Signature as the authentication method. Click Apply. # Configure an IKE peer and reference the configuration of the PKI domain for the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add to perform the configurations shown in Figure

308 Figure 206 Add an IKE peer Type peer as the peer name. Select PKI Domain and then select the PKI domain of 1. Click Apply. Configuring Device B The configuration pages for Device B are similar to those of Device A, and are not shown. # Create a PKI entity. Select VPN > Certificate Management > Entity from the navigation tree and then click Add. Type en as the PKI entity name. Type device-b as the common name. Type as the IP address of the entity. Click Apply. # Create a PKI domain. Select VPN > Certificate Management > Domain from the navigation tree and then click Add. Type 1 as the PKI domain name. Type CA2 as the CA identifier. Select en as the local entity. 300

309 Select RA as the authority for certificate request. Type as the URL for certificate request. Type as the IP address of the LDAP server, 389 as the port number, and 2 as the version number. Select Manual as the certificate request mode. Click Advanced Configuration to display the advanced configuration items. Select the Enable CRL Checking box. Type ldap:// as the URL for CRLs. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue?, click OK to confirm. # Generate an RSA key pair. Select VPN > Certificate Management > Certificate from the navigation tree and then click Create Key. Click Apply to generate an RSA key pair. # Retrieve the CA certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Retrieve Cert. Select 1 as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. Select VPN > Certificate Management > Certificate from the navigation tree and then click Request Cert. Select 1 as the PKI domain. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm. # Retrieve the CRL. After retrieving a local certificate, select VPN > Certificate Management > CRL from the navigation tree. Click Retrieve CRL of the PKI domain of 1. # Configure IKE proposal 1, using RSA signature for identity authentication. Select VPN > IKE > Proposal from the navigation tree and then click Add. Type 1 as the IKE proposal number. Select RSA Signature as the authentication method. Click Apply. # Configure an IKE peer and reference the configuration of the PKI domain for the IKE peer. Select VPN > IKE > Peer from the navigation tree and then click Add. Type peer as the peer name. Select PKI Domain and then select the PKI domain of 1. Click Apply. 301

310 NOTE: The preceding configuration procedure covers only the configurations for IKE negotiation using RSA digital signature. For an IPsec tunnel to be established, you also need to perform IPsec configurations. For information about IPsec configuration, see the chapter IPsec configuration. Configuring PKI at the CLI PKI configuration task list Complete the following tasks to configure PKI: Task Configuring an entity DN Configuring a PKI domain Submitting a PKI certificate request Retrieving a certificate manually Configuring PKI certificate verification Destroying a local RSA key pair Deleting a certificate Configuring an access control policy Submitting a certificate request in auto mode Submitting a certificate request in manual mode Remarks Required Required Required Use either approach Optional Optional Optional Optional Optional Configuring an entity DN A certificate is the binding of a public key and the identity information of an entity, where the identity information is identified by an entity distinguished name (DN). A CA identifies a certificate applicant uniquely by entity DN. An entity DN is defined by these parameters: Common name of the entity. Country code of the entity, a standard 2-character code. For example, CN represents China and US represents the United States. Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network. It consists of a host name and a domain name and can be resolved to an IP address. For example, is an FQDN, where www is a host name and whatever.com a domain name. IP address of the entity. Locality where the entity resides. Organization to which the entity belongs. Unit of the entity in the organization. State where the entity resides. 302

311 NOTE: The configuration of an entity DN must comply with the CA certificate issue policy. You need to determine, for example, which entity DN parameters are mandatory and which are optional. Otherwise, certificate requests might be rejected. Follow these steps to configure an entity DN: To do Use the command Remarks Enter system view system-view Create an entity and enter its view Configure the common name for the entity Configure the country code for the entity Configure the FQDN for the entity Configure the IP address for the entity Configure the locality for the entity Configure the organization name for the entity Configure the unit name for the entity Configure the state or province for the entity pki entity entity-name common-name name country country-code-str fqdn name-str ip ip-address locality locality-name organization org-name organization-unit org-unit-name state state-name Required No entity exists by default. Optional No common name is specified by default. Optional No country code is specified by default. Optional No FQDN is specified by default. Optional No IP address is specified by default. Optional No locality is specified by default. Optional No organization is specified by default. Optional No unit is specified by default. Optional No state or province is specified by default. NOTE: Up to two entities can be created on a device. The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the entity DN in a certificate request goes beyond a certain limit, the server will not respond to the certificate request. Configuring a PKI domain Before requesting a PKI certificate, an entity needs to be configured with some enrollment information, which is referred to as a PKI domain. A PKI domain is intended only for convenience of reference by other 303

312 applications like IKE and SSL, and has only local significance. The PKI domain configured on a device is invisible to the CA and other devices, and each PKI domain has its own parameters. A PKI domain is defined by these parameters: Trusted CA An entity requests a certificate from a trusted CA. Entity A certificate applicant uses an entity to provide its identity information to a CA. RA Generally, an independent RA is in charge of certificate request management. It receives the registration request from an entity, checks its qualification, and determines whether to ask the CA to sign a digital certificate. The RA only checks the application qualification of an entity; it does not issue any certificate. Sometimes, the registration management function is provided by the CA, in which case no independent RA is required. HP recommends you to deploy an independent RA. URL of the registration server An entity sends a certificate request to the registration server through Simple Certification Enrollment Protocol (SCEP), a dedicated protocol for an entity to communicate with a CA. Polling interval and count After an applicant makes a certificate request, the CA might need a long period of time if it verifies the certificate request manually. During this period, the applicant needs to query the status of the request periodically to get the certificate as soon as possible after the certificate is signed. You can configure the polling interval and count to query the request status. IP address of the LDAP server An LDAP server is usually deployed to store certificates and CRLs. If this is the case, you need to configure the IP address of the LDAP server. Fingerprint for root certificate verification After receiving the root certificate of the CA, an entity needs to verify the fingerprint of the root certificate, namely, the hash value of the root certificate content. This hash value is unique to every certificate. If the fingerprint of the root certificate does not match the one configured for the PKI domain, the entity will reject the root certificate. Follow these steps to configure a PKI domain: To do Use the command Remarks Enter system view system-view Create a PKI domain and enter its view Specify the trusted CA Specify the entity for certificate request Specify the authority for certificate request Configure the URL of the server for certificate request Configure the polling interval and attempt limit for querying the certificate request status pki domain domain-name ca identifier name certificate request entity entity-name certificate request from { ca ra } certificate request url url-string certificate request polling { count count interval minutes } Required No PKI domain exists by default. Required No trusted CA is specified by default. Required No entity is specified by default. The specified entity must exist. Required No authority is specified by default. Required No URL is configured by default. Optional The polling is executed for up to 50 times at the interval of 20 minutes by default. 304

313 To do Use the command Remarks Specify the LDAP server Configure the fingerprint for root certificate verification ldap-server ip ip-address [ port port-number ] [ version version-number ] root-certificate fingerprint { md5 sha1 } string Optional No LDP server is specified by default. Required when the certificate request mode is auto and optional when the certificate request mode is manual. In the latter case, if you do not configure this command, the fingerprint of the root certificate must be verified manually. No fingerprint is configured by default. NOTE: Up to two PKI domains can be created on a device. The CA name is required only when you retrieve a CA certificate. It is not used when in local certificate request. The URL of the server for certificate request does not support domain name resolution. Submitting a PKI certificate request When requesting a certificate, an entity introduces itself to the CA by providing its identity information and public key, which will be the major components of the certificate. A certificate request can be submitted to a CA in offline mode or online mode. In offline mode, a certificate request is submitted to a CA by an out-of-band means such as phone, disk, or . Online certificate request falls into manual mode and auto mode. Submitting a certificate request in auto mode In auto mode, an entity automatically requests a certificate from the CA server if it has no local certificate for an application working with PKI. For example, when PKI certificate authentication is used, if no local certificate is available during IKE negotiation, the entity automatically requests one. Follow these steps to configure an entity to submit a certificate request in auto mode: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Set the certificate request mode to auto certificate request mode auto [ key-length key-length password { cipher simple } password ] * Required Manual by default NOTE: If a certificate will expire or has expired, the entity does not initiate a re-request automatically, and the service using the certificate might be interrupted. To have a new local certificate, request one manually. 305

314 Submitting a certificate request in manual mode In manual mode, you need to retrieve a CA certificate, generate a local RSA key pair, and submit a local certificate request for an entity. The goal of retrieving a CA certificate will verify the authenticity and validity of a local certificate. Generating an RSA key pair is an important step in certificate request. The key pair includes a public key and a private key. The private key is kept by the user. The public key is transferred to the CA along with some other information. For more information about RSA key pair configuration, see the chapter Public key configuration. Follow these steps to submit a certificate request in manual mode: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Set the certificate request mode to manual certificate request mode manual Optional Manual by default Return to system view quit Retrieve a CA certificate manually See Retrieving a certificate manually Required Generate a local RSA key pair public-key local create rsa Required Submit a local certificate request manually pki request-certificate domain domain-name [ password ] [ pkcs10 [ filename filename ] ] Required NOTE: If a PKI domain already has a local certificate, creating an RSA key pair will result in inconsistency between the key pair and the certificate. To generate a new RSA key pair, delete the local certificate and then issue the public-key local create command. A newly created key pair will overwrite the existing one. If you perform the public-key local create command in the presence of a local RSA key pair, the system will ask you whether you want to overwrite the existing one. If a PKI domain already has a local certificate, you cannot request another certificate for it. This helps avoid inconsistency between the certificate and the registration information resulting from configuration changes. Before requesting a new certificate, use the pki delete-certificate command to delete the existing local certificate and the CA certificate stored locally. When it is impossible to request a certificate from the CA through SCEP, you can print the request information or save the request information to a local file, and then send the printed information or saved file to the CA by an out-of-band means. To print the request information, use the pki request-certificate domain command with the pkcs10 keyword. To save the request information to a local file, use the pki request-certificate domain command with the pkcs10 filename filename option. Make sure the clocks of the entity and the CA are synchronous. Otherwise, the validity period of the certificate will be abnormal. The pki request-certificate domain configuration will not be saved in the configuration file. 306

315 Retrieving a certificate manually You can download CA certificates, or local certificates from the CA server and save them locally. To do so, use either the offline mode or the online mode. In offline mode, you must retrieve a certificate by an out-of-band means like FTP, disk, or , and then import it into the local PKI system. Certificate retrieval serves the following purposes: Locally store the certificates associated with the local security domain for improved query efficiency and reduced query count Prepare for certificate verification Before retrieving a local certificate in online mode, be sure to complete LDAP server configuration. Follow these steps to retrieve a certificate manually: To do Use the command Remarks Enter system view system-view Retrieve a certificate manually Online Offline pki retrieval-certificate { ca local } domain domain-name pki import-certificate { ca local } domain domain-name { der p12 pem } [ filename filename ] Required Use either command CAUTION: If a PKI domain already has a CA certificate, you cannot retrieve another CA certificate for it. This restriction helps avoid inconsistency between the certificate and registration information resulted from configuration changes. To retrieve a new CA certificate, use the pki delete-certificate command to delete the existing CA certificate and the local certificate first. The pki retrieval-certificate configuration will not be saved in the configuration file. Be sure that the device system time falls in the validity period of the certificate so that the certificate is valid. Configuring PKI certificate verification A certificate needs to be verified before being used. Verifying a certificate will check that the certificate is signed by the CA and that the certificate has neither expired nor been revoked. You can specify whether CRL checking is required in certificate verification. If you enable CRL checking, CRLs will be used in verification of a certificate. In this case, be sure to retrieve the CA certificate and CRLs to the local device before the certificate verification. If you disable CRL checking, you only need to retrieve the CA certificate. Configuring CRL-checking-enabled PKI certificate verification Follow these steps to configure CRL-checking-enabled PKI certificate verification: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name 307

316 To do Use the command Remarks Specify the URL of the CRL distribution point Set the CRL update period Enable CRL checking crl url url-string crl update-period hours crl check enable Optional No CRL distribution point URL is specified by default. Optional By default, the CRL update period depends on the next update field in the CRL file. Optional Enabled by default Return to system view quit Retrieve the CA certificate Retrieve CRLs Verify the validity of a certificate See Retrieving a certificate manually pki retrieval-crl domain domain-name pki validate-certificate { ca local } domain domain-name Required Required Required NOTE: The CRL update period defines the interval at which the entity downloads CRLs from the CRL server. The CRL update period setting manually configured on the device is prior to that carried in the CRLs. The pki retrieval-crl domain command cannot be saved in the configuration file. The URL of the CRL distribution point does not support domain name resolution. Configuring CRL-checking-disabled PKI certificate verification Follow these steps to configure CRL-checking-disabled PKI certificate verification: To do Use the command Remarks Enter system view system-view Enter PKI domain view pki domain domain-name Disable CRL checking crl check disable Required Enabled by default Return to system view quit Retrieve the CA certificate Verify the validity of the certificate See Retrieving a certificate manually pki validate-certificate { ca local } domain domain-name Required Required Destroying a local RSA key pair A certificate has a lifetime, which is determined by the CA. When the private key leaks or the certificate is about to expire, you can destroy the old RSA key pair and then create a pair to request a new certificate. 308

317 Follow these steps to destroy a local RSA key pair: To do Use the command Remarks Enter system view system-view Destroy a local RSA key pair public-key local destroy rsa Required Deleting a certificate When a certificate requested manually is about to expire or you want to request a new certificate, you can delete the current local certificate or CA certificate. Follow these steps to delete a certificate: To do Use the command Remarks Enter system view system-view Delete certificates pki delete-certificate { ca local } domain domain-name Required Configuring an access control policy By configuring a certificate attribute-based access control policy, you can further control access to the server, providing additional security for the server. Follow these steps to configure a certificate attribute-based access control policy: To do Use the command Remarks Enter system view system-view Create a certificate attribute group and enter its view Configure an attribute rule for the certificate issuer name, certificate subject name, or alternative subject name pki certificate attribute-group group-name attribute id { alt-subject-name { fqdn ip } { issuer-name subject-name } { dn fqdn ip } } { ctn equ nctn nequ } attribute-value Required No certificate attribute group exists by default. Optional No restriction exists on the issuer name, certificate subject name and alternative subject name by default. Return to system view quit Create a certificate attribute-based access control policy and enter its view Configure a certificate attribute-based access control rule pki certificate access-control-policy policy-name rule [ id ] { deny permit } group-name Required No access control policy exists by default. Required No access control rule exists by default. A certificate attribute group must exist to be associated with a rule. 309

318 Displaying and maintaining PKI To do Use the command Remarks Display the contents or request status of a certificate Display CRLs Display information about one or all certificate attribute groups Display information about one or all certificate attribute-based access control policies display pki certificate { { ca local } domain domain-name request-status } [ { begin exclude include } regular-expression ] display pki crl domain domain-name [ { begin exclude include } regular-expression ] display pki certificate attribute-group { group-name all } [ { begin exclude include } regular-expression ] display pki certificate access-control-policy { policy-name all } [ { begin exclude include } regular-expression ] Available in any view Available in any view Available in any view Available in any view PKI configuration examples at the CLI CAUTION: The SCEP add-on is required when you use the Windows Server as the CA. In this case, when you configure the PKI domain, use the certificate request from ra command to specify that the entity requests a certificate from an RA. The SCEP add-on is not required when RSA Keon is used. In this case, when you configure a PKI domain, use the certificate request from ca command to specify that the entity requests a certificate from a CA. Requesting a certificate from a CA server running RSA Keon Network requirements As a PKI entity, Firewall submits a local certificate request to the CA server. Firewall acquires the CRLs for certificate verification. Figure 207 Request a certificate from a CA server running RSA Keon Configuration procedure 1. Configure the CA server # Create a CA server named myca. 310

319 In this example, you need to configure these basic attributes on the CA server at first: Nickname Name of the trusted CA. Subject DN DN information of the CA, including the Common Name (CN), Organization Unit (OU), Organization (O), and Country (C). The other attributes might be left using the default values. # Configure extended attributes. After configuring the basic attributes, you need to perform configuration on the jurisdiction configuration page of the CA server. This includes selecting the proper extension profiles, enabling the SCEP autovetting function, and adding the IP address list for SCEP autovetting. # Configure the CRL distribution behavior. After completing the configuration, you need to perform CRL related configurations. In this example, select the local CRL distribution mode of HTTP and set the HTTP URL to After the configuration, make sure that the system clock of the device is synchronous to that of the CA, so that the device can request certificates and retrieve CRLs properly. 2. Configure Firewall Configure the entity DN # Configure the entity name as aaa and the common name as Firewall. <Firewall> system-view [Firewall] pki entity aaa [Firewall-pki-entity-aaa] common-name Firewall [Firewall-pki-entity-aaa] quit Configure the PKI domain # Create PKI domain torsa and enter its view. [Firewall] pki domain torsa # Configure the name of the trusted CA as myca. [Firewall-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of Jurisdiction ID, where Issuing Jurisdiction ID is a hexadecimal string generated on the CA server. [Firewall-pki-domain-torsa] certificate request url # Set the registration authority to CA. [Firewall-pki-domain-torsa] certificate request from ca # Specify the entity for certificate request as aaa. [Firewall-pki-domain-torsa] certificate request entity aaa # Configure the URL for the CRL distribution point. [Firewall-pki-domain-torsa] crl url [Firewall-pki-domain-torsa] quit Generate a local key pair using RSA [Firewall] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. 311

320 Input the bits in the modulus [default = 1024]: Generating Keys Apply for certificates # Retrieve the CA certificate and save it locally. [Firewall] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:ede A273 B61A F1B A0B1 F9AB SHA1 fingerprint: 77F9 A077 2FB8 088C 550B A33C 2410 D354 23B2 73A8 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. # Retrieve CRLs and save them locally. [Firewall] pki retrieval-crl domain torsa Connecting to server for retrieving CRL. Please wait a while... CRL retrieval success! # Request a local certificate manually. [Firewall] pki request-certificate domain torsa challenge-word Certificate is being requested, please wait... [Router] Enrolling the local certificate,please wait a while... Certificate request Successfully! Saving the local certificate to device... Done! Verifying the configuration # Use the following command to view information about the local certificate acquired. [Firewall] display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 9A96A48F 9A509FD7 05FFF4DF 104AD094 Signature Algorithm: sha1withrsaencryption Issuer: C=cn O=org OU=test CN=myca Validity 312

321 Not Before: Jan 8 09:26: GMT Not After : Jan 8 09:26: GMT Subject: CN=Firewall Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00D67D F6A CA6C4B11 F8F89138 E4E905BD 43953BA2 623A54C0 EA3CB6E0 B04649CE C9CDDD E96D9 FF4F7B73 A E583AC61 D3A5C849 CBDE350D 2A1926B7 0AE5EF5E D1D8B08A DBF C2A F EB0549 A65D9E74 0F2953F2 D4F0042F D4F FB59F3 8D4B2F6C 2B Exponent: (0x10001) X509v3 extensions: X509v3 CRL Distribution Points: URI: Signature Algorithm: sha1withrsaencryption A4 F2F74C1A 50F4100D B764D6CE B30C0133 C4363F2F 73454D51 E9F95962 EDE9E590 E7458FA6 765A0D3F C4047BC2 9C391FF0 7383C4DF 9A0CCFA AF 987B029C C857AD96 E4C E798 8FCC1E4A 3E598D E2F86C33 75B51661 B6556C5E 8F546E B C8C29AC7 E427C8E4 B9AAF5AA 80A75B3C You can also use the display pki certificate ca domain and display pki crl domain commands to view detailed information about the CA certificate and CRLs. Requesting a certificate from a CA server running Windows 2003 Server Network requirements Configure PKI entity Firewall to request a local certificate from the CA server. Figure 208 Request a certificate from a CA server running Windows 2003 server 313

322 Configuration procedure 1. Configure the CA server Install the certificate service suites From the start menu, select Control Panel > Add or Remove Programs, and then select Add/Remove Windows Components > Certificate Services and click Next to begin the installation. Install the SCEP add-on As a CA server running the Windows 2003 server does not support SCEP by default, you need to install the SCEP add-on so that the router can register and obtain its certificate automatically. After the SCEP add-on installation completes, a URL is displayed, which you need to configure on the router as the URL of the server for certificate registration. Modify the certificate service attributes From the start menu, select Control Panel > Administrative Tools > Certificate Authority. If the CA server and SCEP add-on have been installed successfully, there should be two certificates issued by the CA to the RA. Right-click the CA server in the navigation tree and select Properties > Policy Module. Click Properties and then select Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate. Modify the Internet Information Services (IIS) attributes From the start menu, select Control Panel > Administrative Tools > Internet Information Services (IIS) Manager and then select Web Sites from the navigation tree. Right-click Default Web Site and select Properties > Home Directory. Specify the path for certificate service in the Local path field. To avoid conflict with existing services, specify an available port number as the TCP port number of the default website. After completing the configuration, check that the system clock of the router is synchronous to that of the CA server, making sure that the router can request a certificate normally. 2. Configure Firewall Configure the entity DN # Configure the entity name as aaa and the common name as Firewall. <Firewall> system-view [Firewall] pki entity aaa [Firewall-pki-entity-aaa] common-name Firewall [Firewall-pki-entity-aaa] quit Configure the PKI domain # Create PKI domain torsa and enter its view. [Firewall] pki domain torsa # Configure the name of the trusted CA as myca. [Firewall-pki-domain-torsa] ca identifier myca # Configure the URL of the registration server in the format of certsrv/mscep/mscep.dll, where host:port indicates the IP address and port number of the CA server. [Firewall-pki-domain-torsa] certificate request url # Set the registration authority to RA. [Firewall-pki-domain-torsa] certificate request from ra # Specify the entity for certificate request as aaa. 314

323 [Router-pki-domain-torsa] certificate request entity aaa Generate a local key pair using RSA [Firewall] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits in the modulus [default = 1024]: Generating Keys Apply for certificates # Retrieve the CA certificate and save it locally. [Firewall] pki retrieval-certificate ca domain torsa Retrieving CA/RA certificates. Please wait a while... The trusted CA's finger print is: MD5 fingerprint:766c D2C8 9E46 845B 4DCE 439C 1C1F 83AB SHA1 fingerprint:97e5 DDED AB FB DB5C E7F8 D7D7 7C9B 97B4 Is the finger print correct?(y/n):y Saving CA/RA certificates chain, please wait a moment... CA certificates retrieval success. # Request a local certificate manually. [Firewall] pki request-certificate domain torsa challenge-word Certificate is being requested, please wait... [Firewall] Enrolling the local certificate,please wait a while... Certificate request Successfully! Saving the local certificate to device... Done! Verifying the configuration # Use the following command to view information about the local certificate acquired. [Firewall] display pki certificate local domain torsa Certificate: Data: Version: 3 (0x2) Serial Number: 48FA0FD C Signature Algorithm: sha1withrsaencryption Issuer: CN=myca Validity 315

324 Not Before: Nov 21 12:32: GMT Not After : Nov 21 12:42: GMT Subject: CN=Firewall Subject Public Key Info: Public Key Algorithm: rsaencryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00A6637A 8CDEA1AC B2E04A59 F7F6A9FE 5AEE52AE 14A392E4 E0E5D458 0D BF91E57 FA8C67AC 6CE8FEBB B 10242FDD D3947F5E 2DA70BD9 1FAF07E5 1D167CE1 FC20394F 476F5C08 C5067DF9 CB4D05E6 55DC11B6 9F4C014D EA D403CF 2D93BC5A 8AF3224D 1125E439 78ECEFE1 7FA9AE7B 877B50B F 6B Exponent: (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: B68E D7C44C 7ABCE3BA 9BF385F8 A448F4E1 X509v3 Authority Key Identifier: keyid:9d EADFEFA2 4A663E75 F416B6F6 D41EE4FE X509v3 CRL Distribution Points: URI: URI:file://\\l00192b\CertEnroll\CA server.crl Authority Information Access: CA Issuers - URI: CA Issuers - URI:file://\\l00192b\CertEnroll\l00192b_CA server.crt :.0.I.P.S.E.C.I.n.t.e.r.m.e.d.i.a.t.e.O.f.f.l.i.n.e Signature Algorithm: sha1withrsaencryption BFA1CBD B068840B (Omitted) You can also use some other display commands to view more information about the CA certificate. Applying RSA digital signature in IKE negotiation Network requirements An IPsec tunnel is set up between Firewall A and Firewall B to secure the traffic between Host A on subnet /24 and Host B on subnet /24. Firewall A and Firewall B use IKE for IPsec tunnel negotiation and RSA digital signature of a PKI certificate system for identity authentication. 316

325 As shown in Figure 209, Firewall A and Firewall B use different CAs. They might also use the same CA as required. Figure 209 Apply RSA digital signature in IKE negotiation PKI certificate system CA /32 CA /32 RA /32 LDAP /32 RA /32 LDAP /32 Firewall A GE0/ /24 Internet GE0/ /24 Firewall B GE0/ /24 GE0/ /24 Host A Host B / /24 Configuration procedure 1. Configure Firewall A # Configure the entity DN. <FirewallA> system-view [FirewallA] pki entity en [FirewallA-pki-entity-en] ip [FirewallA-pki-entity-en] common-name Firewalla [FirewallA-pki-entity-en] quit # Configure the PKI domain. The URL of the registration server varies with the CA server. [FirewallA] pki domain 1 [FirewallA-pki-domain-1] ca identifier CA1 [FirewallA-pki-domain-1] certificate request url [FirewallA-pki-domain-1] certificate request entity en [FirewallA-pki-domain-1] ldap-server ip # Set the registration authority to RA. [FirewallA-pki-domain-1] certificate request from ra # Configure the CRL distribution URL. This is not necessary if CRL checking is disabled. [FirewallA-pki-domain-1] crl url ldap://

326 [FirewallA-pki-domain-1] quit # Create a local key pair using RSA. [FirewallA] public-key local create rsa # Request a certificate. [FirewallA] pki retrieval-certificate ca domain 1 [FirewallA] pki retrieval-crl domain 1 [FirewallA] pki request-certificate domain 1 # Configure IKE proposal 1, using RSA signature for identity authentication. [FirewallA] ike proposal 1 [FirewallA-ike-proposal-1] authentication-method rsa-signature [FirewallA-ike-proposal-1] quit # Specify the PKI domain for the IKE peer. [FirewallA] ike peer peer [FirewallA-ike-peer-peer] certificate domain 1 2. Configure Firewall B # Configure the entity DN. <FirewallB> system-view [FirewallB] pki entity en [FirewallB-pki-entity-en] ip [FirewallB-pki-entity-en] common-name Firewallb [FirewallB-pki-entity-en] quit # Configure the PKI domain. The URL of the registration server varies with the CA server. [FirewallB] pki domain 1 [FirewallB-pki-domain-1] ca identifier CA2 [FirewallB-pki-domain-1] certificate request url [FirewallB-pki-domain-1] certificate request entity en [FirewallB-pki-domain-1] ldap-server ip # Set the registration authority to RA. [FirewallB-pki-domain-1] certificate request from ra # Configure the CRL distribution URL. This is not necessary if CRL checking is disabled. [FirewallB-pki-domain-1] crl url ldap:// [FirewallB-pki-domain-1] quit # Create a local key pair using RSA. [FirewallB] public-key local create rsa # Request a certificate. [FirewallB] pki retrieval-certificate ca domain 1 [FirewallB] pki retrieval-crl domain 1 [FirewallB] pki request-certificate domain 1 # Configure IKE proposal 1, using RSA signature for identity authentication. [FirewallB] ike proposal 1 [FirewallB-ike-proposal-1] authentication-method rsa-signature [FirewallB-ike-proposal-1] quit # Specify the PKI domain for the IKE peer. 318

327 [FirewallB] ike peer peer [FirewallB-ike-peer-peer] certificate domain 1 NOTE: The configuration procedure covers only the configurations for IKE negotiation using RSA digital signature. For an IPsec tunnel to be established, you also need to perform IPsec configurations. For more information about IPsec configuration commands, see VPN Command Reference. Configuring a certificate attribute-based access control policy Network requirements The client accesses the remote HTTP Security (HTTPS) server through the HTTPS protocol. Configure SSL to make sure that only legal clients log into the HTTPS server. Create a certificate attribute-based access control policy to control access to the HTTPS server. Figure 210 Configure a certificate attribute-based access control policy Configuration procedure NOTE: For more information about SSL configuration, see Network Management Configuration Guide. For more information about HTTPS configuration, see Getting Started Guide. The PKI domain to be referenced by the SSL policy must be created in advance. For how to configure a PKI domain, see Configure the PKI domain. 1. Configure the HTTPS server # Configure the SSL policy for the HTTPS server to use. <Firewall> system-view [Firewall] ssl server-policy myssl [Firewall-ssl-server-policy-myssl] pki-domain 1 [Firewall-ssl-server-policy-myssl] client-verify enable [Firewall-ssl-server-policy-myssl] quit 2. Configure the certificate attribute group # Create certificate attribute group mygroup1 and add two attribute rules. The first rule defines that the DN of the subject name includes the string aabbcc, and the second rule defines that the IP address of the certificate issuer is [Firewall] pki certificate attribute-group mygroup1 319

328 [Firewall-pki-cert-attribute-group-mygroup1] attribute 1 subject-name dn ctn aabbcc [Firewall-pki-cert-attribute-group-mygroup1] attribute 2 issuer-name ip equ [Firewall-pki-cert-attribute-group-mygroup1] quit # Create certificate attribute group mygroup2 and add two attribute rules. The first rule defines that the FQDN of the alternative subject name does not include the string of apple, and the second rule defines that the DN of the certificate issuer name includes the string aabbcc. [Firewall] pki certificate attribute-group mygroup2 [Firewall-pki-cert-attribute-group-mygroup2] attribute 1 alt-subject-name fqdn nctn apple [Firewall-pki-cert-attribute-group-mygroup2] attribute 2 issuer-name dn ctn aabbcc [Firewall-pki-cert-attribute-group-mygroup2] quit 3. Configure the certificate attribute-based access control policy # Create the certificate attribute-based access control policy of myacp and add two access control rules. [Firewall] pki certificate access-control-policy myacp [Firewall-pki-cert-acp-myacp] rule 1 deny mygroup1 [Firewall-pki-cert-acp-myacp] rule 2 permit mygroup2 [Firewall-pki-cert-acp-myacp] quit 4. Apply the SSL server policy and certificate attribute-based access control policy to HTTPS service and enable HTTPS service. # Apply SSL server policy myssl to HTTPS service. [Firewall] ip https ssl-server-policy myssl # Apply the certificate attribute-based access control policy of myacp to HTTPS service. [Firewall] ip https certificate access-control-policy myacp # Enable HTTPS service. [Firewall] ip https enable Troubleshooting PKI Failed to retrieve a CA certificate Symptom Analysis Solution Failed to retrieve a CA certificate. Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. The system clock of the device is not synchronized with that of the CA. Make sure that the network connection is physically proper. Check that the required commands are configured properly. 320

329 Use the ping command to check that the RA server is reachable. Specify the authority for certificate request. Synchronize the system clock of the device with that of the CA. Failed to request a local certificate Symptom Failed to request a local certificate. Analysis Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No CA certificate has been retrieved. The current key pair has been bound to a certificate. No trusted CA is specified. The URL of the registration server for certificate request is not correct or not configured. No authority is specified for certificate request. Some required parameters of the entity DN are not configured. Solution Make sure that the network connection is physically proper. Retrieve a CA certificate. Regenerate a key pair. Specify a trusted CA. Use the ping command to check that the RA server is reachable. Specify the authority for certificate request. Configure the required entity DN parameters. Failed to retrieve CRLs Symptom Failed to retrieve CRLs. Analysis Possible reasons include: The network connection is not proper. For example, the network cable might be damaged or loose. No CA certificate has been retrieved before you try to retrieve CRLs. The IP address of LDAP server is not configured. The CRL distribution URL is not configured. The LDAP server version is wrong. Solution Make sure that the network connection is physically proper. Retrieve a CA certificate. 321

330 Specify the IP address of the LDAP server. Specify the CRL distribution URL. Re-configure the LDAP version. Configuration guidelines When you configure PKI, note the following guidelines: Make sure the clocks of entities and the CA are synchronous. Otherwise, the validity period of certificates will be abnormal. The Windows 2000 CA server has some restrictions on the data length of a certificate request. If the PKI entity identity information in a certificate request goes beyond a certain limit, the server will not respond to the certificate request. The SCEP add-on is required when you use the Windows Server as the CA. In this case, specify RA as the authority for certificate request when you configure the PKI domain. The SCEP add-on is not required when you use the RSA Keon software as the CA. In this case, specify CA as the authority for certificate request when you configure the PKI domain. 322

331 Public key configuration NOTE: The public key configuration is available only at the CLI. Asymmetric key algorithm overview Basic concepts Algorithm: A set of transformation rules for encryption and decryption. Plain text: Information without being encrypted. Cipher text: Encrypted information. Key: A string of characters that controls the transformation between plain text and cipher text. It is used in both the encryption and decryption. Key algorithm types As shown in Figure 211, the information in plain text is encrypted by an algorithm with the help of a key before being sent. The resulting cipher text is transmitted across the network to the receiver, where it is decrypted by the same algorithm also with the help of a key to obtain the original plain text. Figure 211 Encryption and decryption The following types of key algorithms are available, based on whether the keys for encryption and decryption are the same: Symmetric key algorithm The keys for encryption and decryption are the same. Commonly used symmetric key algorithms include Advanced Encryption Standard (AES) and Data Encryption Standard (DES). Asymmetric key algorithm The keys for encryption and decryption are different, one is the public key, and the other is the private key. The information encrypted with the public key can only be decrypted with the corresponding private key, and vice versa. The private key is kept secret, and the public key may be distributed widely. The private key cannot be practically derived from the public key. Asymmetric key algorithm applications Asymmetric key algorithms can be used for encryption/decryption and digital signature. 323

332 Encryption/decryption the sender uses the public key of the intended receiver to encrypt the information to be sent. Only the intended receiver, the holder of the paired private key, can decrypt the information. This mechanism guarantees confidentiality. Digital signature the sender "signs" the information to be sent by encrypting the information with its own private key. A receiver decrypts the information with the sender's public key and, based on whether the information can be decrypted, determines the authenticity of the information. The Revest-Shamir-Adleman Algorithm (RSA), and the Digital Signature Algorithm (DSA) are asymmetric key algorithms. RSA can be used for data encryption/decryption and signature, whereas DSA isused for signature only. NOTE: Symmetric key algorithms are often used to encrypt/decrypt data for security. Asymmetric key algorithms are usually used in digital signature applications for peer identity authentication because they involve complex calculations and are time-consuming. In digital signature applications, only the digests, which are relatively short, are encrypted. Configuring the local asymmetric key pair You can create and destroy a local asymmetric key pair, and export the host public key of a local asymmetric key pair. Creating an asymmetric key pair Follow these steps to create an asymmetric key pair: To do Use the command Remarks Enter system view system-view Create a local DSA key pair, or RSA key pairs public-key local create { dsa rsa } Required By default, no key pair is created. The public-key local create rsa command generates two key pairs: one server key pair and one host key pair. Each key pair comprises a public key and a private key. The public-key local create dsa command generates only one key pair, the host key pair. After you enter the command, you are asked to specify the modulus length. The length of an RAS or DSA key modulus ranges from 512 to 2048 bits. To achieve higher security, specify a modulus at least 768 bits. NOTE: Key pairs created with the public-key local create command are saved automatically and can survive system reboots. Displaying or exporting the local RSA or DSA host public key Display the local RSA or DSA host public key on the screen or export it to a specified file. Then, you can configure the local RSA or DSA host public key on the peer device so that the peer device can use the host public key to authenticate the local end through digital signature. Follow these steps to display or export the local RSA or DSA host public key: 324

333 To do Use the command Remarks Enter system view system-view Display the local RSA host public key on the screen in a specified format, or export it to a specified file Display the local DSA host public key on the screen in a specified format or export it to a specified file public-key local export rsa { openssh ssh1 ssh2 } [ filename ] public-key local export dsa { openssh ssh2 } [ filename ] Select a command according to the type of the key to be exported. Destroying an asymmetric key pair You may need to destroy an asymmetric key pair and generate a new pair when an intrusion event has occurred, the storage media of the device is replaced, the asymmetric key has been used for a long time, or the certificate from the Certificate Authority (CA) expires. To check the certificate status, use the display pki certificate command. For more information about the CA and certificate, see the chapter Certificate management. Follow these steps to destroy an asymmetric key pair: To do Use the command Remarks Enter system view system-view Destroy an asymmetric key pair public-key local destroy { dsa rsa } Required Configuring a peer public key To enable your local host to authenticate a peer device, configure the peer RSA or DSA public key on the local host. The following methods are available: Import it from a public key file Obtain a copy of the peer public key file through FTP or TFTP (in binary mode) first, and then import the public key from the file. During the import process, the system automatically converts the public key to a string in PKCS (Public Key Cryptography Standards) format. HP recommends that you follow this method to configure the peer public key. Configure it manually If the peer device is an HP device, you can use the display public-key local public command to view and record its public key. On the local host, input or copy the key data in public key code view. A public key displayed by other methods may not in the PKCS format, and the system cannot save the format-incompliant key. NOTE: The device supports up to 20 peer pubic keys. Follow these steps to import a peer host public key from the public key file: To do Use the command Remarks Enter system view system-view Import the peer host public key from the public key file public-key peer keyname import sshkey filename Required 325

334 Follow these steps to configure a peer public key manually: To do Use the command Remarks Enter system view system-view Specify a name for a peer public key and enter public key view public-key peer keyname Required Enter public key code view public-key-code begin Configure the peer server or host public key Return to public key view Type or copy the key public-key-code end Required Spaces and carriage returns are allowed between characters. Required When you exit public key code view, the system automatically saves the public key. Return to system view peer-public-key end NOTE: Do not configure a peer RSA server public key for identity authentication in SSH applications. Authentication in SSH applications uses the RSA host public key. For more information about SSH, see System Management and Maintenance Configuration Guide. Displaying and maintaining public keys To do Use the command Remarks Display the local public keys Display the peer public keys display public-key local { dsa rsa } public [ { begin exclude include } regular-expression ] display public-key peer [ brief name publickey-name ] [ { begin exclude include } regular-expression ] Available in any view Public key configuration examples NOTE: In this configuration example, either Device A or Device B is the firewall. Configuring a peer public key manually Network requirements As shown in Figure 212, to prevent illegal access, Device B authenticates Device A through a digital signature. Before configuring authentication parameters on Device B, configure the public key of Device A on Device B. 326

335 Configure Device B to use the asymmetric key algorithm of RSA for identity authentication of Device A. Manually configure the host public key of Device A on Device B. Figure 212 Network diagram Configuration procedure 1. Configure Device A # Create RSA key pairs on Device A. <DeviceA> system-view [DeviceA] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: Generating Keys # Display the public keys of the created RSA key pairs. [DeviceA] display public-key local rsa public ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87BB61 58E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3 CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F Configure Device B 327

336 # Configure the host public key of Device A on Device B. In public key code view, input the host public key of Device A. The host public key is the content of HOST_KEY displayed on Device A using the display public-key local dsa public command. <DeviceB> system-view [DeviceB] public-key peer devicea Public key view: return to System View with "peer-public-key end". [DeviceB-pkey-public-key] public-key-code begin Public key code view: return to last view with "public-key-code end". [DeviceB-pkey-key-code]30819F300D06092A864886F70D D D900 03FA95F5A44A2A2CD3F814F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E 353B3A9AB16C9E766BD995C669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB EA DC078B2BAA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A [DeviceB-pkey-key-code] public-key-code end [DeviceB-pkey-public-key] peer-public-key end # Display the host public key of Device A saved on Device B. [DeviceB] display public-key peer name devicea ===================================== Key Name : devicea Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A Importing a peer public key from a public key file Network requirements As shown in Figure 213, to prevent illegal access, Device B authenticates Device A through a digital signature. Before configuring authentication parameters on Device B, configure the public key of Device A on Device B. Configure Device B to use the asymmetric key algorithm of RSA for identity authentication of Device A. Import the host public key of Device A from the public key file to Device B. Figure 213 Network diagram Configuration procedure 1. Create key pairs on Device A and export the host public key # Create RSA key pairs on Device A. <DeviceA> system-view 328

337 [DeviceA] public-key local create rsa The range of public key size is (512 ~ 2048). NOTES: If the key modulus is greater than 512, It will take a few minutes. Press CTRL+C to abort. Input the bits of the modulus[default = 1024]: Generating Keys # Display the public keys of the created RSA key pairs. [DeviceA] display public-key local rsa public ===================================================== Time of Key pair created: 09:50: /08/07 Key name: HOST_KEY Key type: RSA Encryption Key ===================================================== Key code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A ===================================================== Time of Key pair created: 09:50: /08/07 Key name: SERVER_KEY Key type: RSA Encryption Key ===================================================== Key code: 307C300D06092A864886F70D B E7AEE D9EB2D0433B87BB61 58E35000AFB3FF310E42F109829D65BF70F BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3 CFA9E84B9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F # Export the RSA host public key to a file named devicea.pub. [DeviceA] public-key local export rsa ssh2 devicea.pub [DeviceA] quit 2. Enable the FTP server function on Device B # Enable the FTP server function, create an FTP user with the username ftp, password 123, and user level 3. <DeviceB> system-view [DeviceB] ftp server enable [DeviceB] local-user ftp [DeviceB-luser-ftp] password simple 123 [DeviceB-luser-ftp] service-type ftp [DeviceB-luser-ftp] authorization-attribute level 3 [DeviceB-luser-ftp] quit 3. Upload the public key file of Device A to Device B 329

338 # FTP the public key file devicea.pub to Device B with the file transfer mode of binary. <DeviceA> ftp Trying Press CTRL+K to abort Connected to FTP service ready. User( :(none)):ftp 331 Password required for ftp. Password: 230 User logged in. [ftp] binary 200 Type set to I. [ftp] put devicea.pub 227 Entering Passive Mode (10,1,1,2,5,148). 125 BINARY mode data connection already open, transfer starting for /devicea.pub. 226 Transfer complete. FTP: 299 byte(s) sent in second(s), 1.00Kbyte(s)/sec. 4. Import the host public key of Device A to Device B # Import the host public key of Device A from the key file devicea.pub to Device B. [DeviceB] public-key peer devicea import sshkey devicea.pub # Display the host public key of Device A saved on Device B. [DeviceB] display public-key peer name devicea ===================================== Key Name : devicea Key Type : RSA Key Module: 1024 ===================================== Key Code: 30819F300D06092A864886F70D D D90003FA95F5A44A2A2CD3F814F 9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C 669A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA DC078B2B AA3BC3BCA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A

339 SSL VPN configuration NOTE: To implement SSL VPN, you must perform some configuration in the web interface and some configuration at the CLI. SSL VPN overview SSL VPN is a VPN technology based on Secure Sockets Layer (SSL). It works between the transport layer and the application layer. Using the certificate-based identity authentication, data encryption, and integrity verification mechanisms that SSL provides, SSL VPN can establish secure connections for communications at the application layer. SSL VPN has been widely used for secure, remote web-based access. For example, it can allow remote users to access the corporate network securely. Figure 214 shows a typical SSL VPN network. On the SSL VPN gateway, you can create resources to represent the resources on the servers in the internal network. To access an internal server, a remote user first needs to establish a Hypertext Transfer Protocol Secure (HTTPS) connection with the SSL VPN gateway and selects the resources to be accessed. Then, the SSL VPN gateway forwards the resource access request to the internal server. In the SSL VPN deployed network, the SSL VPN gateway will establish an SSL connection to a remote user and then authenticate the user before allowing the user to access an internal server, protecting the internal servers. Figure 214 Network diagram for SSL VPN configuration Administrator Internet SSL VPN gateway Internal servers Remote user How SSL VPN works SSL VPN works in the following procedure: 1. The administrator logs in to the web interface of the SSL VPN gateway, and then creates resources to represent resources on the internal servers. 331

340 2. A remote user establishes an HTTPS connection to the SSL VPN gateway. The SSL VPN gateway and the remote user authenticate each other by using the certificate-based authentication function provided by SSL. 3. After the HTTPS connection is established, the user can try to log in to the Web interface of the SSL VPN gateway by entering the username and password and selecting the authentication method (RADIUS authentication, for example). The SSL VPN gateway will verify the user information. 4. After logging in to the web interface, the user finds the resources of interest on the web interface and then the user client sends an access request to the SSL VPN gateway through an SSL connection. 5. The SSL VPN gateway resolves the request, interacts with the corresponding server, and then forwards the server s reply to the user. Advantages of SSL VPN SSL VPN provides these advantages: 1. Support for various application protocols Any application can be secured by SSL VPN without knowing the details. SSL VPN classifies the service resources provided by applications into three categories: Web proxy server resources Web-based access enables users to establish HTTPS connections to the SSL VPN gateway through a browser and thereby access the web proxy server resources of the servers. TCP application resources TCP-based access allows users to use their applications to access the open service ports of the server securely. Such resources include remote access services, desktop sharing services, services, Notes mail services, and common application service resources. IP network resources IP-based access allows user hosts to communicate with servers at Layer 3 securely, supporting all IP-based applications to communicate with the servers. 2. Simple deployment SSL has been integrated into most browsers, such as IE. Almost every PC installed with a browser supports SSL. To access web-based resources, users only need to launch a browser that supports SSL. When a user tries to access TCP-based or IP-based resources, the SSL VPN client software will be run automatically, without requiring any manual intervention. 3. Support for multiple authentication methods In addition to the certificate authentication method provided by SSL, SSL VPN also supports the following authentication methods and any combination of two of the following methods: Local authentication RADIUS authentication LDAP authentication AD authentication 4. Granular access control of network resources On the SSL VPN gateway, you can configure multiple resources and users, add resources to resource groups, add users to user groups, and assign resource groups to user groups. After a user logs in, the SSL VPN gateway finds the user groups to which the user belongs, and checks the resource groups assigned to the user groups to determine which resources to provide for the user. 332

341 CLI configuration required to implement SSL VPN To configure SSL VPN, you must perform the following operations at the CLI: Specify the SSL server policy to be used by the SSL VPN service. To access the SSL VPN gateway or the internal resources, remote users need to log in to the web interface of the SSL VPN gateway through HTTPS. Therefore, you must specify an SSL server policy on the SSL VPN gateway so that the gateway can determine the SSL parameters to be used for providing the SSL VPN service. Specify the TCP port number to be used by the SSL VPN service. The SSL VPN gateway acts as the HTTPS server to provide the web interface for remote users to log in. Enable the SSL VPN service. Remote users can access the web interface of the SSL VPN gateway only after the SSL VPN service is enabled on the gateway. This section describes the configuration that you must perform at the CLI. For the SSL VPN to function normally, you must also perform the configuration in the web interface, such as configuring access resources, users, and domains. For more information about the web configuration, see Web configuration required to implement SSL VPN. Configuration prerequisites Before you configure SSL VPN, create an SSL server policy. For information about SSL server policy configuration, see Network Management Configuration Guide. Configuration procedure Follow these steps to configure SSL VPN: To do Use the command Remarks Enter system view system-view Specify the SSL server policy and port to be used by the SSL VPN service Enable the SSL VPN service ssl-vpn server-policy server-policy-name [ port port-number ] ssl-vpn enable Required By default, no SSL server policy is specified for the SSL VPN service and the SSL VPN service uses TCP port 443. Required Disabled by default NOTE: If the HTTPS service and the SSL VPN service use the same port number, the two services must use the same SSL server policy. Otherwise, you cannot enable both the services. When both the HTTPS service and the SSL VPN service are enabled and they use the same port number, to change the SSL server policy that the services use, you must first disable the two services, specify another SSL server policy, and then enable the services again. When the SSL VPN service is enabled, your change to the port number or SSL server policy for the service does not take effect. To make your change take effect, disable the SSL VPN service and then enable it again. 333

342 Example of the CLI configuration required for SSL VPN Network requirements As shown in Figure 215, configure SSL and enable SSL VPN service on the SSL VPN gateway, so that users can log in to the Web interface of the SSL VPN gateway through HTTPS and then access the internal resources of the corporate network through the SSL VPN gateway. In this configuration example: The IP address of the SSL VPN gateway is /24. The IP address of the Certificate Authority (CA) is /24. The name of the CA is CA server, which is used to issue certificates to the SSL VPN gateway and remote users. Figure 215 Network diagram Configuration procedure NOTE: In this example, the Windows Server is used as the CA. Install the Simple Certificate Enrollment Protocol (SCEP) plugin on the CA. Before the following configurations, make sure that the intended SSL VPN gateway, the CA, and the host used by the remote user can reach each other, and the CA is enabled with the CA service and can issue certificates to the Firewall (SSL VPN gateway) and the host. 1. Apply for a certificate for the SSL VPN gateway (Firewall). # Configure a PKI entity named en and specify the common name of the entity as http-server. <Firewall> system-view [Firewall] pki entity en [Firewall-pki-entity-en] common-name http-server [Firewall-pki-entity-en] quit # Configure a PKI domain named sslvpn, and specify the trusted CA as ca server, the URL of the RA server as registration authority for certificate requesting as RA, and the entity as en. [Firewall] pki domain sslvpn [Firewall-pki-domain-sslvpn] ca identifier ca server [Firewall-pki-domain-sslvpn] certificate request url [Firewall-pki-domain-sslvpn] certificate request from ra 334

343 [Firewall-pki-domain-sslvpn] certificate request entity en [Firewall-pki-domain-sslvpn] quit # Generate the local RSA key pair. [Firewall] public-key local create rsa # Retrieve the CA certificate. [Firewall] pki retrieval-certificate ca domain sslvpn # Apply for a certificate for the Firewall. [Firewall] pki request-certificate domain sslvpn 2. Configure an SSL server policy for the SSL VPN service. # Configure an SSL server policy named myssl, and specify the policy to use PKI domain sslvpn. [Firewall] ssl server-policy myssl [Firewall-ssl-server-policy-myssl] pki-domain sslvpn [Firewall-ssl-server-policy-myssl] quit 3. Configure SSL VPN. # Specify the SSL server policy myssl and port 443 (default) for the SSL VPN service. [Firewall] ssl-vpn server-policy myssl # Enable the SSL VPN service. [Firewall] ssl-vpn enable 4. Verify the configuration. On the user host, launch the IE browser and input in the address bar. You can open the web login interface of the SSL VPN gateway. NOTE: For more information about PKI configuration commands, see VPN Command Reference. For more information about SSL configuration commands, see Network Management Command Reference. Web configuration required to implement SSL VPN SSL VPN gateway configuration task list Table 38 SSL VPN gateway configuration task list Task Configuring the SSL VPN service Configuring web proxy server resources Configuring TCP application resources Configuring IP network resources Remarks Required Enable SSL VPN, and configure the port number for the SSL VPN service and the PKI domain to be used. Configure at least one type of resources. By default, no resources are configured. 335

344 Task Configuring a resource group Configuring local users Configuring a user group Viewing user information Performing basic configurations for the SSL VPN domain Configuring authentication policies Configuring a security policy Partially customizing the SSL VPN interface Fully customizing the SSL VPN interface Remarks Required Configure a resource group and add resources to the resource group. By default, resource groups named autohome and autostart exist. Required Configure local SSL VPN users users that need to pass local authentication to log in to the SSL VPN system. By default, a local user named guest (without a password) exists, in denied state. Required Configure a user group, add local users to the user group, and select the resource groups that the user group can access. By default, a user group named Guests exists, and no users and resource groups are assigned for it. IMPORTANT: You can also add a local user to existing user groups when creating the local user. Optional View the online user information and the history user information, and log out online users. Optional Configure the domain policy, caching policy, and bulletin information for the SSL VPN domain. Optional Configure authentication methods and authentication parameters for an SSL VPN domain. IMPORTANT: Local authentication is always enabled. To use other authentication methods, you need to manually enable them. Optional Configure the check items and protected resources for a security policy. Only user hosts that pass the security policy s check can access the configured resources. IMPORTANT: To perform security check for user hosts, you must also enable security check in the domain policy. Optional Customize service interfaces for SSL VPN users. 336

345 Configuring the SSL VPN service Before you configure the SSL VPN service, go to VPN > Certificate Management to configure a PKI domain and get a certificate for the SSL VPN gateway. An administrator or user uses the certificate to authenticate the SSL VPN gateway to avoid logging in to an invalid SSL VPN gateway. For more information about certificates, see the chapter Certificate and Public Key Configuration. Select VPN > SSL VPN > Service Management from the navigation tree to enter the service management page. Figure 216 Service management Table 39 Configuration items Item Enable SSL VPN Port PKI Domain Description Select the box before this item to enable the SSL VPN service. Specify the port for providing the SSL VPN service. The default port number is 443. Select a PKI domain for the SSL VPN service. Configuring web proxy server resources Web servers provide services usually in web pages. Users can get desired information by clicking the links on the pages. On the Internet, information exchanged between web servers and users is transmitted in plain text. The HTTP data may be intercepted in transit. SSL VPN provides secure connections for users to access web servers and can prevent illegal users from accessing the protected web servers. Select VPN > SSL VPN > Resource Management > Web Proxy from the navigation tree. A page that lists the web proxy server resources appears, as shown in Figure 217. Click Add to enter the page for adding a web proxy server resource, as shown in Figure

346 Figure 217 Web proxy server resources list Figure 218 Add a web proxy server resource Table 40 Configuration items Item Resource Name Website Address Default Page Description Enter a name for the web proxy server source. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. Specify the website address for providing web services. It must start with and end with /, for example, The website address can be an IP address or a domain name. If you specify a domain name, make sure that you configure domain name resolution on Network Management > DNS. Specify the home page to be displayed after an SSL VPN user logs in. For example, index.htm. 338

347 Item Website Matching Mode Enable page protection Description Specify website matching patterns to determine which web pages a user can access through the website specified in the Website Address field. Website matching supports fuzzy match based on wildcard *. Use vertical bars ( ) to separate multiple matching patterns. Assume that you have specified a website address in the Website Address field. To allow access to specific web pages provided at the website, for example, the web pages and you can specify as the matching patterns. Select the box to enable page protection. With page protection enabled, a login user cannot capture screen shots, save pages, or printing pages. Select the box to enable single login. After you enable single login and configure single login parameters, when a user access the resource through the SSL VPN service interface, the user can automatically log in to the specified website if the user s username and password for accessing the website are the same as those for logging in to the SSL VPN service interface. After you enable single login, you can configure the subsequent items. Single login Use IP network Login Request Path Username Parameter Name IMPORTANT: Another way to configure the single login function is as follows: Click the icon of a resource on the web proxy server resource list, as shown in Figure 217. Enter a username and a password (the password must be different from the username) on the popup page, and click Apply. Then, the login page for the website in the resource pops up. Enter the username and password again and log in. A message will tell you that the single login function is configured successfully. During this process, the system automatically obtains the username parameter name and the password parameter name. When the website login page requires parameters other than the username and password, you may not configure single login in this method. Select the box to allow IP access to the resource. If you select this item, you must configure an IP network resource for a website and associate the IP network resource with the relevant users. When such a user accesses the website from the SSL VPN web interface, the system automatically logs the user in to the website through the IP network resource. If you do not select this item, users access the resource through the web proxy. When you select the IP network mode, this item specifies the path that the system submits during single login. If you leave this field blank, the system uses the address that is specified in the Website Address field. When the IP network mode is not selected, this item specifies the relative path of the web proxy website. If you leave this field blank, the SSL VPN system uses the default page specified in the Default Page field. Specify the username parameter name that the system submits during automatic login. 339

348 Item Password Parameter Name Other parameters Description Specify the password parameter name that the system submits during automatic login. Specify the other parameters for the system to submit during automatic login. To add a parameter other than the username and password, click Add, enter the parameter name and parameter value on the popup page and click Apply. Configuring TCP application resources You can configure the following types of TCP application resources: Remote access service resources Desktop sharing service resources service resources Notes mail service resources Common TCP service resources Configuring a remote access service resource The remote access service includes remote character terminal services (such as Telnet and SSH) and traditional terminal services (such as IBM3270). These services each simulate a server s terminal window on a local host through which you can control a remote host as if you were sitting before it. Between the local and remote hosts, data is transmitted in plain text over the Internet. To ensure the security of data transmission, SSL VPN uses the SSL encryption technology to encrypt service data. Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. The Remote Access Service page appears, as shown in Figure 219. Click Add to enter the page for adding a remote access service, as shown in Figure 220. Figure 219 Remote access service resource list 340

349 Figure 220 Add a remote access service Table 41 Configuration items Item Resource Name Remote Host Remote Port Local Host Local Port Command Description Enter a name for the remote access service resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. IMPORTANT: If you do not configure the command for Command, HP recommends including the resource type, local address, and local port in the resource name so that users can view the desired information after they log in to the SSL VPN system. Specify the host name or IP address of the remote host that provides the remote access service. Specify the port number that the remote host uses for the remote access service. Specify a loopback address or a character string that represents a loopback address. Specify the port number that the local host uses for the remote access service. HP recommends using a port number greater than 1024 that is rarely used. Configure the Windows command for the resource. After you configure the command, users can start the related application to access the remote server by clicking the resource name on the SSL VPN service interface. For example, you can configure the command for a Telnet service in the format telnet <local address> <local port>, such as telnet If you specified the default port number of the remote access service as the local port number, you can omit the local port in the command. Configuring a desktop sharing service resource Desktop sharing, or remote desktop, allows users to access the sessions on a remote host from your local host. With desktop sharing, you can connect the computer in office, and access all the applications, files, and network resources at home as if you were working on the computer at the office. Common desktop sharing services include Windows remote desktop, Virtual Network Computing (VNC) desktop sharing, and Citrix desktop sharing. For some desktop sharing applications, data is transmitted in plain text and can be easily intercepted. SSL VPN can encrypt the data to ensure data security. Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. Click the Desktop Sharing Service tab to view existing desktop sharing services, as shown in Figure 221. Click Add to enter the page for adding a desktop sharing service, as shown in Figure

350 Figure 221 Desktop sharing services Figure 222 Add a desktop sharing service resource Table 42 Configuration items Item Resource Name Remote Host Remote Port Local Host Local Port Command Description Enter a name for the desktop sharing service resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. IMPORTANT: If you do not configure the command for Command, HP recommends including the resource type, local address, and local port in the resource name so that users can view the desired information after they log in to the SSL VPN system. Specify the host name or IP address of the remote host that provides the desktop sharing service. Specify the port number that the remote host uses for the desktop sharing service. Specify a loopback address or a character string that represents a loopback address. Specify the port number that the local host uses for the remote access service. HP recommends using a port number greater than 1024 that is rarely used. Configure the Windows command for the resource. For example, you can configure the command for a Windows desktop sharing service in the format mstsc /v <local address> <local port>, such as mstsc /v If you specified the default port number of the desktop sharing service as the local port number, you can omit the local port in the command. 342

351 Configuring an service resource The service is widely used to exchange texts and graphics over the network. Generally, s are transmitted in plain text on the network. Users can encrypt s to protect the content of s, but this method cannot ensure transmission security. SSL VPN can ensure the transmission security of s. NOTE: For an service, you must configure at least two resources: a receiving server and a sending server. Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. Click the Service tab to view existing services, as shown in Figure 223. Click Add to enter the page for adding an service, as shown in Figure 224. Figure 223 services Figure 224 Add an service resource Table 43 Configuration items Item Resource Name Service Type Remote Host Description Enter a name for the service resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. IMPORTANT: If you do not configure the command for Command, HP recommends including the resource type, local address, and local port in the resource name so that users can view the desired information after they log in to the SSL VPN system. Select an service type, which can be POP3, IMAP, or SMTP. Enter the host name or IP address of the server. 343

352 Item Remote Port Local Address Local Port Command Description Enter the service port number of the server. Enter a loopback address or a character string that represents a loopback address. Enter the local port number. It must be the default port number for the service of the specified type. Configure the Windows command for the resource. Users must manually start the service application. You do not need to configure this item. Configuring a Notes service resource Notes, a platform for implementing office automation, provides services in a client/server model. SSL VPN can improve the security of Notes mail services. Hereafter, the term Notes service refers to Notes mail services. Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. Click the Notes Service tab to view existing notes services, as shown in Figure 225. Then, click Add to enter the page for adding a Notes service, as shown in Figure 226. Figure 225 Notes services Figure 226 Add a Notes service resource 344

353 Table 44 Configuration items Item Resource Name Remote Host Remote Port Description Enter a name for the Notes service resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. IMPORTANT: If you do not configure the command for Command, HP recommends including the resource type, local address, and local port in the resource name so that users can view the desired information after they log in to the SSL VPN system. Enter the host name or IP address of the Notes mail server. Enter the service port number of the Notes mail server. Enter a loopback address or a character string that represents a loopback address. Local Host Local Port Command IMPORTANT: The local host character string must be the same as the mail server name in the Notes application. Otherwise, the Notes service resource cannot be used normally. Enter the local port number. It must be the default port number of the Notes service. Configure the command for the resource. Users must manually start the Notes service application. You do not need to configure this item. Configuring a common TCP service resource The common TCP service of SSL VPN is designed to support various client/server applications. It is widely used to access client/server TCP applications other than the previously mentioned ones. Generally, you can configure all network ports that are possibly used by applications in common TCP services. To access an application provided by a common TCP service, a user only needs to configure the corresponding IP address and port number listed on the common TCP service page as the access address and port number for the application. Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. Click the TCP Service tab to view existing TCP services, as shown in Figure 227. Then, click Add to enter the page for adding a common TCP service, as shown in Figure 228. Figure 227 TCP services 345

354 Figure 228 Add a TCP service resource Table 45 Configuration items Item Resource Name Service Type Remote Host Remote Port Local Host Local Port Command Description Enter a name for the common TCP service resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. IMPORTANT: If you do not configure the command for Command, HP recommends including the resource type, local address, and local port in the resource name so that users can view the desired information after they log in to the SSL VPN system. Enter the type for the TCP service. Enter the host name or IP address of the remote host that provides the common TCP service. Enter the port number that the remote host uses for the common TCP service. Enter a loopback address or a character string that represents a loopback address. Enter the port number that the local host uses for the common TCP service. Configure the Windows command for the resource. Configuring IP network resources The SSL VPN IP network access service supports all applications that operate at the IP layer and above, providing secure communication between users and servers. Users do not need to know the application types and configurations. After they log in to the SSL VPN service interface, the ActiveX SSL VPN client will be automatically downloaded and started, and the users can access authorized services of certain hosts securely. Table 46 IP network resource configuration task list Task Configuring global parameters Remarks Required Configure global parameters, such as the IP address pool, gateway address, timeout time, WINS server, and DNS server, for IP network resources. 346

355 Task Configuring host resources Configuring a user-ip binding Configuring a predefined domain name Remarks Required Configure the host resources that users can access from the IP networks list of the SSL VPN interface. Optional Configure user-ip bindings. After a user is bound with an IP address, when the user accesses IP network resource, the system does not assign a virtual network adapter IP address to the user from the global IP pool but assigns the bound IP address to the user. Optional With a predefined domain name configured, the gateway sends the mapping between the predefined domain name and the IP address to clients. When accessing this domain, a client directly uses the corresponding IP address, eliminating the requirement for DNS resolution. Configuring global parameters Select VPN > SSL VPN > Resource Management > IP Network from the navigation tree. The Global Configuration tab appears, as shown in Figure 229. Figure 229 Global configuration page Table 47 Configuration items Item Start IP End IP Subnet Mask Gateway IP Timeout Description Specify the IP address pool from which the gateway assigns IP addresses for clients virtual network adapters. Enter the subnet mask to be assigned to a client s virtual network adapter. Enter the default gateway IP address to be assigned to a client s virtual network adapter. Set an idle timeout for client connections. If the gateway does not receive any packet from a client during this period, the gateway disconnects the client. 347

356 Item WINS Server IP DNS Server IP Allow clients to intercommunicate Permit only access to VPN Show Network Services by Description Enter the WINS server IP addresses to be assigned to a client s virtual network adapter. Enter the DNS server IP addresses to be assigned to a client s virtual network adapter. Select this item to allow IP access between online users. Select this item to allow online users to access only the VPN. If you do not select this item, online users can access both the VPN and the Internet. Specify how to display network services for online users. Description: Shows the description information of the network services that host resources allow users to access. IP address: Shows the destination address, subnet mask, and protocol type of the network services that host resources allow users to access. Configuring host resources Select VPN > SSL VPN > Resource Management > IP Network from the navigation tree. Click the Host Configuration tab to view existing host resources, as shown in Figure 230. Click Add to enter the page for adding a host resource, as shown in Figure 231. Figure 230 Host configuration 348

357 Figure 231 Add a host resource Table 48 Configuration items Item Resource Name Network Services Shortcuts Description Enter a name for the host resource. The resource name must be unique in the SSL VPN system. Resources are uniquely identified by their names. Configure the network services that the host resource provides for users (see To configure an accessible network service ). Configure the network services that the host resource provides for users in the form of shortcuts (see To configure a shortcut ). 1. To configure an accessible network service: On the page shown in Figure 231, click the Add button under the network services list to enter the page for adding a network service, as shown in Figure

358 Figure 232 Add an available network service Table 49 Configuration items Item Destination IP Subnet Mask Protocol Description Enter the destination address of the network service. Enter the subnet mask of the network service. Specify the protocol type of the network service, which can be IP, TCP, or UDP. Enter a description for the network service. Description IMPORTANT: If you have configured the system to show network services by description, HP recommends that you include the network services network information (subnet IP/mask) in the description so that users can view desired information after they log in to the SSL VPN system. 2. To configure a shortcut: On the page shown in Figure 231, click the Add button under the shortcuts list to enter the page for adding a network service shortcut, as shown in Figure 233. Figure 233 Add a network service shortcut Table 50 Configuration items Item Shortcut Name Command Description Enter a name for the shortcut. Specify the Windows command of the shortcut. 350

359 Configuring a user-ip binding Select VPN > SSL VPN > Resource Management > IP Network from the navigation tree. Click the User-IP Binding tab to view existing user-ip bindings, as shown in Figure 234. Click Add to enter the page for adding a user-ip binding, as shown in Figure 235. Figure 234 User-IP bindings Figure 235 Add a user-ip binding Table 51 Configuration items Item Username IP Address Description Specify the username to be bound with an IP address. The username must contain the domain name. For example, aaa@local. Specify the IP address to be bound with the username. The specified IP address must be in the same network segment as the global IP address pool and must not be the gateway address or any address in the global IP pool. Configuring a predefined domain name Select VPN > SSL VPN > Resource Management > IP Network from the navigation tree. Click the Predefined Domain Name tab to view existing predefined domain names, as shown in Figure 236. Click Add to enter the page for adding a predefined domain name, as shown in Figure

360 Figure 236 Predefined domain names Figure 237 Add a predefined domain name Table 52 Configuration items Item Domain Name IP Setting Method IP Description Enter a domain name to be issued to clients. Select the IP setting method, including Dynamic and Static. Dynamic: To use this method, you also need to navigate to page Network Management > DNS to configure domain name resolution. The gateway will first resolve the domain name to get an IP address and then issue the IP address to clients. Static: To use this method, you must specify an IP address in the next field. The gateway will issue the domain name-ip address mapping to clients. Specify an IP address for the domain name when the IP setting method is Static. When the IP setting method is Dynamic, this IP setting does not take effect. Configuring a resource group Select VPN > SSL VPN > Resource Management > Resource Group from the navigation tree. The Resource Group page appears, listing all existing resource groups, as shown in Figure 238. Click Add to enter the page for adding a resource group, as shown in Figure

361 Figure 238 Resource groups Figure 239 Add a resource group Table 53 Configuration items Item Resource Group Name Selected Resources Available Resources Description Enter a name for the resource group. Select resources for the resource group. 353

362 Configuring local users Configure SSL VPN users for local authentication in the following methods: Configure local users one by one in the SSL VPN system. Write the information of the users into a text file, and then import the users to the SSL VPN system. Adding a local user manually Select VPN > SSL VPN > User Management > Local User from the navigation tree. The local user list appears, as shown in Figure 240. Click Add to enter the page for adding a local user, as shown in Figure 241. Figure 240 Local users 354

363 Figure 241 Add a local user Table 54 Configuration items Item Username Description Password Confirm Password Certificate SN Enable public account Max Number of Users User Status Expiry Date Description Enter a name for the local user. Enter a description for the local user. Specify a password for the local user and enter the password again to confirm the password. Specify a certificate sequence number for the local user. The certificate sequence number will be used for identity authentication of the local user. Select this item to set the local user account as a public account. A public account can be concurrently used by multiple users to log in to the SSL VPN system. If you do not select this item, only one user can use the local user account to log in to the SSL VPN system at a time. Set the maximum number of concurrent users that can log in to the SSL VPN system by using the public account. Select a user status, which can be Permitted, Permitted When Valid, and Denied. Set the expiry date for the user when the user status is set to Permitted When Valid. 355

364 Item MAC Address Enable MAC address learning Selected User Groups Available User Groups Description Specify the MAC addresses to be bound with the username. The MAC addresses are used for user identity authentication. Select this item to enable MAC address learning. With this function enabled, when a user uses this user account to log in, the SSL VPN system automatically learns the MAC address of the user host and records the MAC address for the account. The SSL VPN can record up to three MAC addresses for an account. The recorded MAC addresses are still effective after you disable the MAC address learning function. Specify the user groups to which the local user belongs. IMPORTANT: To implement the two functions, you must also enable the MAC address binding function in the domain policy (see Configuring the domain policy ). Importing local users in bulk Select VPN > SSL VPN > User Management > Batch Import from the navigation tree. The batch import page appears, as shown in Figure 242. Click Browse to locate the local file that saves the user information, and then click Apply to import local users into the SSL VPN. To import local users from a file, you must edit the file in the correct format beforehand. For file format requirements, see the note information in Figure 242. Figure 242 Batch import of local users Configuring a user group Select VPN > SSL VPN > User Management > User Group from the navigation tree. The user group list page appears, as shown in Figure 243. Click Add to add a user group, as shown in Figure

365 Figure 243 User groups Figure 244 Add a user group 357

366 Table 55 Configuration items Item User Group Name Selected Resource Groups Available Resources Selected Local Users Available Local Users Description Enter a name for the user group. Select resource groups for the user group. Users in the user group will be able to access the resources in the selected resource groups. Select local users for the user group. Viewing user information Viewing online user information and logging out an online user Select VPN > SSL VPN > User Management > User Information from the navigation tree. The Online Users tab appears, as shown in Figure 245. To log out a user, select the box before the user and click the Log Out button, or click the icon for the user. Figure 245 Online users Table 56 Field description Field Login Time Username IP Address Description Time when the user logged in to the SSL VPN system Username of the user, with the domain name IP address of the user host Viewing history user information Select VPN > SSL VPN > User Management > User Information from the navigation tree and click the History Information tab. The tab displays the history maximum number of concurrent users and the history maximum number of concurrent connections. 358

367 Figure 246 History information Performing basic configurations for the SSL VPN domain Configure a domain policy, caching policy, and a bulletin for the SSL VPN domain: Domain policy Defines the common parameters and functions for the SSL VPN domain. Caching policy Specifies which cached contents to clear from user hosts when users log out from the SSL VPN system. Bulletin management Allows you to provide different information to different users. Configuring the domain policy Select VPN > SSL VPN > Domain Management > Basic Configuration from the navigation tree. The Domain Policy tab appears, as shown in Figure 247. Figure 247 Basic domain policy Table 57 Configuration items Item Enable security check Description Select this item to enable security check. With security check enabled, the SSL VPN system checks a user host based on the security policy and determines whether to allow the user to access resources according to the check result. IMPORTANT: To implement user host security check, you must also configure the security policy. See Configuring a security policy. 359

368 Item Use verification code Enable separate client Enable MAC address binding Description Select this item to use verification codes. After you select this item, users must enter the correct verification codes to log in to the SSL VPN system. Select this item to enable the separate client function. After a user logs in to SSL VPN, the SSL VPN client automatically runs. With separate client enabled, the system automatically closes the SSL VPN web interface, leaving the client software running alone. Select this item to enable MAC address binding. With MAC address binding enabled, the SSL VPN system obtains the MAC address of a user when the user logs in, for user identity authentication or MAC address learning. Select this item to enable automatic login. Enable automatic login User Timeout With automatic login enabled, when a user enters the SSL VPN login page, the system will automatically log the user in by using the guest account or the certificate account, depending on the authentication policy specified in the default authentication method. When the authentication policy is password, the system uses the guest account for automatic login. When the authentication policy is certificate, the system uses the username carried in the client certificate for automatic login. When the authentication policy is password+certificate, the system uses the guest account for automatic login and requires that the user have the client certificate for the guest account. Set an idle timeout for users. If a login user does not perform any operation during this period, the system logs out the user. Select the default authentication method used on the SSL VPN login page. Default Authentication Method Certificate s Username Field Verification Code Timeout IMPORTANT: To specify an authentication method other than local authentication as the default authentication method, you must also enable the authentication method (see Configuring authentication policies ). Select the certificate field to be used as the username when the authentication policy is certificate. Options include the Common-Name filed and the -Address field. Set a timeout for the verification code displayed on the SSL VPN login page. If a user does not enter the displayed verification code in this period, the verification code becomes invalid. The user can refresh the login page to get a new verification code. Configuring the caching policy Select VPN > SSL VPN > Domain Management > Basic Configuration from the navigation tree and click the Caching Policy tab. The caching policy configuration page appears, as shown in Figure 248. Select the operations to be done on a user host when the user logs out. Downloaded programs refer to the SSL VPN client software that was automatically downloaded and run when the users logged in to the SSL VPN system. Configuration files refer to the configuration file that was automatically saved when a user changed the settings of the SSL VPN client software, if any. 360

369 Figure 248 Caching policy Configuring a bulletin Select VPN > SSL VPN > Domain Management > Basic Configuration from the navigation tree and click the Bulletin Management tab. The bulletin management page appears, as shown in Figure 249. Click Add to add a new bulletin, as shown in Figure 250. Figure 249 Bulletin management 361

370 Figure 250 Add a bulletin Table 58 Configuration items Item Title Content Selected User Groups Available User Groups Description Enter a name for the bulletin. Enter the contents of the bulletin. Select the user groups that can view the bulletin. Configuring authentication policies SSL VPN supports local authentication, RADIUS authentication, LDAP authentication, AD authentication, and combined authentication of any two of the previous four authentication methods. Local authentication, LDAP authentication, and AD authentication each supports three authentication policies: Password Authenticates only a user s password. Password+Certificate Authenticates a user s password and client certificate. 362

371 Certificate Authenticates only a user s client certificate. RADIUS authentication supports only two authentication policies: password and password+certificate. Configuring local authentication Local authentication authenticates users by using the user information saved on the SSL VPN gateway. This authentication method is the fastest because user information is locally saved, and the SSL VPN gateway does not need to exchange information with an external authentication server. However, the number of local users is limited by the capacity of the SSL VPN gateway. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree. The Local Authentication tab appears, as shown in Figure 251. Figure 251 Local authentication Table 59 Configuration item Item Authentication Policy Description Select an authentication policy for local authentication. Options include Password, Password+Certificate, and Certificate. Configuring RADIUS authentication The Remote Authentication Dial-In User Service (RADIUS) protocol is a distributed, client/server mode information exchange protocol for protecting networks against unauthorized access. It is usually deployed in networks that require secure remote access. The SSL VPN system can cooperate with the existing RADIUS server of an enterprise seamlessly to provide RADIUS authentication. Users in the enterprise can use their original accounts for RADIUS authentication through SSL VPN. NOTE: To enable RADIUS authentication in the SSL VPN system, navigate to User > RADIUS page to configure a RADIUS scheme named system. For more configuration information, see Access Control Configuration Guide. For successful RADIUS authentication of a user, you must also configure the account information and the user group attribute information for the user on the RADIUS authentication server, and make sure that the user groups configured on the RADIUS authentication server exist on the SSL VPN gateway. Otherwise, the user cannot log in. The gateway supports up to 16 user groups for a user. Make sure that the number of user groups specified for a user on the authentication server is equal to or less than the limit. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree. Click the RADIUS Authentication tab to enter the RADIUS authentication configuration page, as shown in Figure

372 Figure 252 RADIUS authentication Table 60 Configuration items Item Enable RADIUS authentication Authentication policy Enable RADIUS accounting Upload virtual address Description Select this item to enable RADIUS authentication. Select an authentication policy for RADIUS authentication. Options include Password and Password+Certificate. Select this item to enable RADIUS accounting. With this item selected, the system uploads the IP address of the client s virtual network adapter to the RADIUS server after RADIUS accounting succeeds. Configuring LDAP authentication The Lightweight Directory Access Protocol (LDAP) is a cross-platform, standard directory service system that is based on TCP/IP. It is developed on the basis of the X.500 protocol but is better than X.500 in data reading, browsing, and search. LDAP is suitable for saving data that will not change frequently. A typical application of LDAP is to save user information of a system. For example, Microsoft Windows operating systems use an Active Directory Server to save user information and user group information, providing LDAP based authentication and authorization for Windows users. The SSL VPN system can cooperate with an LDAP server to provide LDAP authentication and obtain resource access rights for users. NOTE: For successful LDAP authentication of a user, you must also configure the account information and the user group attribute information for the user on the LDAP server, and make sure that the user groups configured on the authentication server exist on the SSL VPN gateway. Otherwise, the user cannot log in. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree and click the LDAP Authentication tab. The LDAP authentication configuration page appears, as shown in Figure

373 Figure 253 LDAP authentication Table 61 Configuration items Item Enable LDAP authentication LDAP Sever IP Server Port Version Authentication Policy User Group Attribute Specify conditions to query user DN Admin DN Password Confirm Password Search Base DN Search Template Use a template to query user DN User DN template Description Select this item to enable LDAP authentication. Specify the IP address of the LDAP server. Specify the TCP port number used by the LDAP server. Specify the supported LDAP protocol version. Select an authentication policy for LDAP authentication. Options include Password, Password+Certificate, and Certificate. Specify the name of the user group attribute configured on the LDAP server. Select this option to query user DN by specified conditions, including the administrator DN, password, search base DN, and search template. Enter a user DN that has the administrator rights, which include the right to view the login user information. Enter a user password that has the administrator right and enter the password again to confirm the password. Specify a search base DN. Specify a search template. Select this option to query the user DN by a template. Specify the user DN template to be used to query the user DN. Configuring AD authentication Active Directory (AD) is a directory service provided by Windows 2000 Server and later versions. It saves information of objects on a network and allows administrators and users to query the information. 365

374 AD uses structured data storage, which is the basis of the directory information logical structure. The SSL VPN system can cooperate with the existing AD server of an enterprise seamlessly to provide AD authentication for users in the enterprise. NOTE: For successful AD authentication of a user, you must also configure the user information on the AD authentication server, create user groups, and add the user to the user groups. Make sure that the user groups configured on the authentication server exist on the SSL VPN gateway. Otherwise, the user cannot log in. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree and click the AD Authentication tab. The LDAP authentication configuration page appears, as shown in Figure 254. Figure 254 AD authentication Table 62 Configuration items Item Enable AD authentication AD Domain Name AD Server IP Authentication Policy Server Recovery Time Admin Username Password Confirm Password Username Format Description Select this item to enable AD authentication. Enter the name of the AD domain. Enter the IP addresses of the AD servers. You can specify four AD servers at most. When one server fails, the system uses another server to authenticate users. The system selects the specified servers in the configuration order of the servers. The first configured server has the highest priority. Select an authentication policy for AD authentication. Options include Password, Password+Certificate, and Certificate. Set the interval at which the system checks whether the failed AD server recovers. Set an administrator account. It must be a user account that has the directory search right in the User directory in the AD domain. Set a password for the administrator account, and enter the password again to confirm the password. Set the username format used to log in to the AD server. Options include Without the AD domain name, With the AD domain name, and Login name. 366

375 Configuring combined authentication A combination authentication method can combine any two of the four authentication methods (local authentication, RADIUS authentication, LDAP authentication, and AD authentication) in any order. With combined authentication configured, the system authenticates a user twice by using the two specified authentication methods. You can specify which method is used first, and specify whether to ask for a password during the second authentication. NOTE: Which resources are available for a user who has passed a combined authentication and the online username used are both determined by the first authentication. When the user accesses single login resources, the system takes the password used in the first authentication as the login password. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree and click the Combined Authentication tab. The combined authentication configuration page appears, as shown in Figure 255. Figure 255 Combined authentication Table 63 Configuration items Item Enable combined authentication First-Time Authentication Method Second-Time Authentication Method Ask password again on the second authentication Description Select this item to enable combined authentication. Select an authentication method as the first-time authentication method. Select an authentication method as the second-time authentication method. With this item selected, the system provides the login page and asks a user for a password again after the user passes the first authentication. If you do not select this item, the system automatically uses the password for the first authentication for the second authentication. IMPORTANT: This function takes effect only when you enable full customization of the user interface and the customized user interface can provide a login page twice. Configuring a security policy Insecure user hosts may bring potential security threats to the internal network. You can configure security policies for the SSL VPN system so that when a user logs in, the SSL VPN system checks the user host s 367

376 operating systems, browsers, antivirus software, firewall software, files and processes, and determines which resources to provide for the user according to the check result. A security policy defines multiple check categories, each of which contains multiple check rules. To pass the check of a category, a host must satisfy at least one rule of the category. To pass the check of a security policy, a host must satisfy all categories of the policy. Select VPN > SSL VPN > Domain Management > Security Policy from the navigation tree. The security policy list page appears, as shown in Figure 256. Click Add to add a new security policy, as shown in Figure 257. Figure 256 Security policies Figure 257 Add a security policy Table 64 Security policy configuration items Item Name Description Enter a name for the security policy. 368

377 Item Description Set a level for the security policy. A larger number means a higher level. Level If multiple security policies are defined, the system first uses the security policy with the highest priority to check the user host. If the host does not satisfy the security policy, the system uses the security policy with the second highest priority, and so forth until the host satisfies a security policy or fails security check. The resources that the user can access are those defined in the security policy that the user first passes. Therefore, when you configure security policies, specify more resources for a security policy that has a higher level. Description Enter a description for the security policy. Set check rules for the security policy. Check rules fall into seven categories: operating system, browser, antivirus software, firewall, certificate, file, and process. Policy Configuration Resource Configuration To pass the check of a category, a host needs to satisfy at least one rule of the category. To pass the check of a security policy, a host must satisfy all categories of the policy. Click the expansion button before a category to view the rule information. Click the Add button to add a rule for the category. For more information about rule configuration, see Table 65. Specify the resources that can be accessed by user hosts that satisfy the security policy. You can select All Web Proxies, All TCP Applications, and all IP Networks. To select specific web proxies, TCP applications, or IP networks, click the corresponding expansion button. Table 65 Rule configuration items Item Description Operating System Browser Rule Name Type Version Patch Rule Name Type Operator Enter a name for the operating system rule. Specify the operating system type. A user host must run the specified type of operating system to pass security check. Specify the operating system version. The operating system of a user host must satisfy the version requirement to pass security check. Specify the operating system patches. The operating system of a user host must have the specified patches installed to pass security check. Enter a name for the browser rule. Specify the browser type. A user host must use the specified type of browser to pass security check. Set an operator for the browser version check. >=: A user host must use the specified version or a later version. >: A user host must use a version later than the specified version. =: A user host must use the specified version. <=: A user host must use the specified version or an earlier version. <: A user host must use a version earlier than the specified version. 369

378 Item Description Specify the browser version. Antivirus Software Firewall Certificate File Process Version Patch Rule Name Type Operator Version Virus Definitions Version Rule Name Type Operator Version Rule Name Issuer Rule Name File Name Rule Name Process Name IMPORTANT: An IE browser version must be a floating point number with up to two digits after the radix point. Specify the browser patches. The browser of a user host must have the specified patches installed to pass security check. Enter a name for the antivirus software rule. Specify the antivirus software type. A user host must use the specified type of antivirus software to pass security check. Set an operator for antivirus software version check and virus definitions version check. >=: The antivirus software and its virus definitions must be of the specified version or a later version. >: The antivirus software and its virus definitions must have a version later than the specified version. =: The antivirus software and its virus definitions must be of the specified version. <=: The antivirus software and its virus definitions must be of the specified version or an earlier version. <: The antivirus software and its virus definitions must have a version earlier than the specified version. Specify the antivirus software version. Specify the virus definitions version. Enter a name for the firewall rule. Specify the firewall type. A user host must use the specified type of firewall to pass security check. Set an operator for firewall version check. >=: A user host must use the specified version or a later version. >: A user host must use a version later than the specified version. =: A user host must use the specified version. <=: A user host must use the specified version or an earlier version. <: A user host must use a version earlier than the specified version. Specify the firewall version. Enter a name for the certificate rule. Specify the certificate issuer. A user host must have a client certificate issued by the specified issuer to pass security check. Enter a name for the file rule. Specify the files. A user host must have the specified files to pass security check. Enter a name for the process rule. Specify the processes. A user host must have the specified processes to pass security check. 370

379 Customizing the SSL VPN user interface The SSL VPN system allows you to customize the user interface partially or fully as desired: Partial customization You can use the web page files provided by the system and edit some contents in the files as needed, including the login page title, login page welcome information, login page logo, service page banner information, service page logo, and service page background. For the locations of the information items, see the red boxes in Figure 258 and Figure 259. Full customization You can edit a web page file of your own to provide a fully customized user access interface. Figure 258 Customizable information on the login page 371

380 Figure 259 Customizable information on the service page Partially customizing the SSL VPN interface 1. Configure the text information. Select VPN > SSL VPN > Page Customization > Partial Customization from the navigation tree. The Text Information tab appears. You can configure the service page banner information, login page welcome information, and login page title on the page, as shown in Figure 260. Figure 260 Text information 2. Configure the login page logo. Select VPN > SSL VPN > Page Customization > Partial Customization from the navigation tree. Click the Login Page Logo tab to enter the page shown in Figure 261. Click Browse to select a local picture file and click Apply. The picture will be uploaded to the SSL VPN system and will be used as the logo picture on the login page. 372

381 Figure 261 Specify a login page logo picture 3. Configure the service page logo. Select VPN > SSL VPN > Page Customization > Partial Customization from the navigation tree. Click the Service Page Logo tab to enter the page shown in Figure 262. Click Browse to select a local picture file and click Apply. The picture will be uploaded to the SSL VPN system and will be used as the logo picture on the service page. Figure 262 Specify a service page logo picture 4. Configure the service page background. Select VPN > SSL VPN > Page Customization > Partial Customization from the navigation tree. Click the Service Page Background tab to enter the page shown in Figure 263. Click Browse to select a local picture file and click Apply. The picture will be uploaded to the SSL VPN system and will be used as the service page background picture. Figure 263 Specify a service page background picture Fully customizing the SSL VPN interface NOTE: Before full customization of the SSL VPN interface, upload the customized page file to the SSL VPN gateway through FTP or TFTP. Select VPN > SSL VPN > Page Customization > Full Customization from the navigation tree. The full customization page appears, as shown in Figure

382 Figure 264 Full customization Table 66 Full customization configuration page Item Enable full customization Directory Page File Description Select this item to enable the full customization function. Enter the directory where the customized page files are saved on the SSL VPN gateway. Enter the name of the customized login page file. 374

383 User access to SSL VPN NOTE: This section introduces user access to the SSL VPN service interface provided by the system. It is not suitable for user access to a fully customized SSL VPN service interface. After you finishes configuration on the SSL VPN gateway, remote users can establish HTTPS connections to the SSL VPN gateway, and access resources through the user service interface provided by the SSL VPN gateway. Logging in to the SSL VPN service interface To log in to the SSL VPN service interface, a user needs to complete the following steps: 1. Launch a browser and enter in the address bar to enter the SSL VPN login page, as shown in Figure 265. host and port are the SSL VPN gateway s host address and service port number, and port can be omitted when the SSL VPN service port number is 443, the default value. Figure 265 SSL VPN login page 2. On the login page, enter the username and password, select an authentication method, and click Login to enter the SSL VPN service interface, as shown in Figure 266. If you have specified TCP applications or IP network resources for the user, the system automatically runs the SSL VPN client software for the user, as shown in Figure 267. CAUTION: If you have enabled verification code authentication, the login page also provides the verification code and the user must enter the correct the verification code to log in. 375

384 Figure 266 SSL VPN service interface Figure 267 SSL VPN client software Accessing SSL VPN resources After logging in to the SSL VPN service interface, a user can see all resources that you have authorized the user to access, and perform the following operations: Clicking a resource name under Websites to access the website. 376

385 Clicking a resource name under TCP Applications to run the command you configured for the resource (if any), or performing configurations according to the information provided by the resource name and then access the resource. For example, a user can configure the Outlook receiving and sending servers according to the resource name, logs in by using the username and password, and then uses the service. For an IP network resource, the user can access any host in any accessible network segment and can click a shortcut name to execute the corresponding command of the shortcut. NOTE: If the SSL VPN gateway is not the firewall, to access TCP application resources and IP network resources, you must configure NAT properly on the outgoing interface of the firewall. Getting help information To get help information, a user only needs to click the Help link in the right upper corner of the SSL VPN service interface. A popup window appears, showing the SSL VPN system help information, as shown in Figure

386 Figure 268 About SSL VPN Changing the login password To Change the login password, a user only needs to click the Configure button in the upper right corner of the SSL VPN service interface to enter the page shown in Figure 269, enter the new password, confirm the new password, and click Apply. When the user logs in again, the user must enter the new password. 378

387 Figure 269 Change login password 379

388 SSL VPN configuration example Network requirements As shown in Figure 270, request a certificate and enable SSL VPN service on the SSL VPN gateway so that users can use HTTPS to log in to the SSL VPN gateway to access the internal resources of the corporate network. In this configuration example: The Certificate Authority (CA) runs the Windows Server and the Simple Certificate Enrollment Protocol (SCEP) plugin is required on the CA. The IP address of the SSL VPN gateway is /24. The IP address of the CA is /24, and the name of the CA is CA server. The CA is used to issue certificates to the SSL VPN gateway and remote users. Perform RADIUS authentication for SSL VPN users. The IP address of the RADIUS server (an IMC server) is /24. After passing authentication, an SSL VPN user can access the internal technology website whose IP address is , all hosts on subnet /24, and the security sever whose IP address is through the FTP shortcut. Configure a public account named usera. Specify that only one user can use the public account to log in at a time. Configure local authentication for the public account and authorize a user who logs in by using the public account to access the shared desktop provided by internal host Specify the default authentication method as RADIUS for the SSL VPN domain and enable verification code authentication. Figure 270 Network diagram NOTE: Before performing the following configurations, make sure that: The SSL VPN gateway, the CA, and the hosts used by remote users can reach each other. The CA is enabled with the CA service and can issue certificates to the SSL VPN gateway and the hosts. The RADIUS server is properly configured to provide normal authentication function for users. In this example, you need to configure the shared key as expert, configure the user account and user group information, and add users to user group user_gr2. Configuring the SSL VPN service 1. Request a certificate for the SSL VPN gateway. 380

389 # Configure a PKI entity named en. Select VPN > Certificate Management > Entity from the navigation tree. Click Add to add a PKI entity. Figure 271 Configure a PKI entity named en Enter the PKI entity name en. Enter common name http-server for the entity. Click Apply. # Configure a PKI domain named sslvpn. Select VPN > Certificate Management > Domain from the navigation tree. Click Add to add a PKI domain. 381

390 Figure 272 Configure a PKI domain named sslvpn Enter the PKI domain name sslvpn. Enter the CA identifier CA server. Select en as the local entity. Select RA as the registration authority. Enter the certificate requesting URL Select Manual as the certificate request mode. Click Apply. When the system displays Fingerprint of the root certificate not specified. No root certificate validation will occur. Continue? click OK to continue. # Generate an RSA key pair. Select VPN > Certificate Management > Certificate from the navigation tree. Click Create Key to add a PKI domain. Figure 273 Generate an RSA key pair Click Apply. # Retrieve the CA certificate. After the key pair is generated, click the Retrieve Cert button. 382

391 Figure 274 Retrieve the CA certificate to the local device Select sslvpn as the PKI domain. Select CA as the certificate type. Click Apply. # Request a local certificate. After the CA certificate retrieval operation is complete, click Request Cert. Figure 275 Request a local certificate Select sslvpn as the PKI domain. Click Apply. When the system displays Certificate request has been submitted, click OK to confirm the operation. You can view the retrieved CA certificate and the local certificate on the certificate management page. 383

392 Figure 276 Certificate management page 2. Configure the SSL VPN service. # Enable SSL VPN, and configure a port and a PKI domain for the SSL VPN service. Select VPN > SSL VPN > Service Management from the navigation tree. Figure 277 SSL VPN service management page Select the box before Enable SSL VPN. Set the port number to 443. Select sslvpn as the PKI domain. Click Apply. Configuring SSL VPN resources 1. Configure resources. # Configure a web proxy resource named tech for the internal technology website Select VPN > SSL VPN > Resource Management > Web Proxy from the navigation tree. Click Add. 384

393 Figure 278 Configure a web proxy resource Enter the resource name tech. Enter the website address Click Apply. # Configure a resource named desktop for the desktop sharing service provided by host Select VPN > SSL VPN > Resource Management > TCP Application from the navigation tree. Click the Desktop Sharing Service tab. Figure 279 Configure a desktop sharing service resource Enter the resource name desktop. Enter the remote host address Set the remote port for the server to Enter the local host address Set the local port for the service to Enter the command line mstsc /v :

394 Click Apply. # Configure global parameters for IP network resources. Select VPN > SSL VPN > Resource Management > IP Network from the navigation tree. The Global Configuration tab appears. Figure 280 Configure global parameters for IP network resources Enter the start IP address Enter the end IP address Enter the subnet mask 24. Enter the gateway IP address Click Apply. # Configure a host resource named sec_srv for hosts in subnet /24 in IP network mode. Click the Host Configuration tab, and then click Add. 386

395 Figure 281 Configure a host resource Enter the resource name sec_srv. Click the Add button under the Network Services list. Enter the destination IP address Enter the subnet mask 24. Select IP as the protocol type. Specify the description information as /24. Click Apply. The network service is added to the host resource. Click the Add button under the Shortcuts list. Enter the shortcut name ftp_security-server. Enter the shortcut command ftp Click Apply. The shortcut is added to the host resource. Click Apply. 2. Configure resource groups. # Configure resource group res_gr1, and add resource desktop to it. Select VPN > SSL VPN > Resource Management > Resource Group from the navigation tree. Click Add. 387

396 Figure 282 Configure resource group res_gr1 Enter the resource group name res_gr1. Select desktop on the Available Resources list and click the << button to add it to the Selected Resources list. Click Apply. # Configure resource group res_gr2, and add resources tech and sec_srv to it. Click Add. 388

397 Figure 283 Configure resource group res_gr2 Enter the resource group name res_gr2. Select resources tech and sec_srv on the Available Resources list and click the << button to add them to the Selected Resources list. Click Apply. Configuring SSL VPN users 1. Configure a local user. # Configure a local user account usera. Select VPN > SSL VPN > User Management > Local User from the navigation tree. Click Add. 389

398 Figure 284 Add local user usera Enter the username usera. Enter the password passworda. Confirm the password. Select the box before Enable public account. Set the maximum number of users for the public account to 1. Select Permitted as the user status. Click Apply. 2. Configure user groups. # Configure user group user_gr1, assign resource group res_gr1 to the user group and add local user usera to the user group. Select VPN > SSL VPN > User Management > User Group from the navigation tree. Click Add to perform the following configurations. 390

399 Figure 285 Configure user group user_gr1 Enter the user group name user_gr1. Select res_gr1 on the Available Resource Groups list and click << to add it to the Selected Resource Groups list. Select usera on the Available Local Users list and click << to add the user to the Selected Local Users list. Click Apply. # Configure user group user_gr2, and assign resource group res_gr2 to the user group Click Add to perform the following configurations. 391

400 Figure 286 Configure user group user_gr2 Enter the user group name user_gr2. Select res_gr2 on the Available Resource Groups list and click << to add it to the Selected Resource Groups list. Click Apply. Configuring an SSL VPN domain 1. Configure the domain policy. # Configure the default authentication method for the SSL VPN domain as RADIUS and enable verification code authentication. Select VPN > SSL VPN > Domain Management > Basic Configuration from the navigation tree to perform the following configurations. 392

401 Figure 287 Configure the domain policy Select the box before Use verification code. Select RADIUS as the default authentication method. Click Apply. 2. Configure RADIUS authentication. # Configure a RADIUS scheme named system. Select User > RADIUS from the navigation tree. Click Add to perform the following configurations. 393

402 Figure 288 Configure RADIUS scheme named system Enter the scheme name system. Select Extended as the supported server type. Select Without domain name as the username format. Click the Add button in the RADIUS Server Configuration area. Select Primary Authentication Server as the server type. Select IPv4 and enter IP address Enter port number Enter key expert. Enter expert again to confirm the key. Click Apply. The RADIUS server is then added to the RADIUS server list. Click Apply. # Enable RADIUS authentication. Select VPN > SSL VPN > Domain Management > Authentication Policy from the navigation tree. Click the RADIUS Authentication tab. 394

403 Figure 289 Enable RADIUS authentication Select the box before Enable RADIUS authentication. Click Apply. Verifying the configuration Launch a browser on a host, and enter in the address bar to enter the SSL VPN login page, which uses RADIUS as the default authentication method and requires the verification code. Figure 290 SSL VPN login page Change the authentication mode to Local. Use the public account usera to log in. You can see the resource desktop, as shown in Figure 291. Click the resource name to access the shared desktop of the specified host, as shown in Figure

404 Figure 291 Resource that the public account usera can access Figure 292 Access the desktop sharing resource Assume that a user named userb is configured and added to user group user_gr2 on the RADIUS server. Use this user account and the default authentication method RADIUS to log in. You can see website tech, all hosts in subnet /24, and the security server. Click tech to access the technology webstie. Click shortcut ftp_security-server to access the security server through FTP. 396

405 Figure 293 Resources that a non-public account can access Figure 294 Access the IP network resource 397