Method for IPSEC to traverse dynamic NAT and DVPN network

Abstract

The invention relates to the technical field of communication, and provides a method for an IPSEC to traverse a dynamic NAT and a DVPN network. The method comprises the following steps that: a central device establishes an IPSEC tunnel with a first branch device and a second branch device respectively, and records addresses and port information of the two branch devices before and after being converted by an NAT (Network Address Translation) device; when the central equipment receives a request of acquiring network information of the second branch equipment from the first branch equipment, sending address port information before and after conversion of the second branch equipment to the first branch equipment, and sending address port information before and after conversion of the first branch equipment to the second branch equipment; the second branch device sends a UDP message to the first NAT device after receiving the information, so that the NAT device creates a table item of the first branch device to communicate a communication link of the two branch devices; and after receiving the information, the first branch device carries out Internet key exchange negotiation with the second branch device to establish an IPSEC tunnel of the two branch devices. According to the invention, the traversal of the dynamic NAT in the MGRE over IPSEC scene is realized.

Description

Technical Field

[0001] The invention relates to the field of communication technology, and in particular to an IPSEC traversal method for dynamic NAT and a DVPN network. Background Art

[0002] IP (Internet Protocol) communications may be subject to attacks such as eavesdropping and tampering, and lack security guarantees. IPSEC (Internet Protocol Security) is a technology used to solve the security problem at the IP layer. IPSEC is an IP security protocol standard that supports confidentiality and authentication services by using cryptographic methods, allowing users to use them selectively and obtain the desired security services. IPSEC is designed to provide high-quality, interoperable, cryptographic-based security for IPV4 (Internet Protocol version 4) and IPV6 (Internet Protocol Version 6) data.

[0003] The basic principle of IPSEC is that the two communicating parties negotiate an IPSEC tunnel, determine the security protocol, encryption authentication algorithm, and encapsulation mode used for security protection, and then encrypt the data traffic that needs to be processed securely through this tunnel to achieve the effect of security processing. The security policy associates the protected data flow with the IPSEC tunnel, that is, defines what kind of protection is implemented for what kind of data flow. The global application of IPSEC protects different data flows by matching different security policies. The existing implementation principle is: the administrator clearly defines the five-tuple information (source IP address, destination IP address, source port, destination port, protocol number) of each data flow that needs to be processed securely in advance, and models these five-tuple information into different interested flows, and finally references these interested flows in different security policies, so that the actual data flow will be matched to the corresponding security policy according to different five-tuples, and finally encryption and other security processing will be performed according to the IPSEC tunnel referenced by the policy.

[0004] DVPN (Dymatic Vitual Private Network) is a non-public technology proposed to solve the problem of complex configuration of traditional tunnel technology and inconvenience in responding to changes in network topology and branch address changes. DVPN uses the idea of ​​centralized control, with a central node completing the online, authentication and public and private network address management of branch nodes. The private network routing information is transmitted through the tunnels established between nodes to achieve full network interconnection. MGRE (Multipoint Generic Routing Encapsulation) is a DVPN technology based on NHRP (Next Hop Resolution Protocol). MGRE is a point-to-multipoint GRE tunnel technology, and the message encapsulation and decapsulation are the same as those of GRE tunnels. MGRE tunnels rely on the NHRP protocol to work, and the NHRP protocol can dynamically learn the addresses of other nodes.

[0005] MGRE technology itself is not secure. In actual use, IPSEC is often used to encrypt GRE messages, and the use of MGRE over IPSEC is becoming more and more widespread. However, due to the shortage of domestic IP resources, MGRE over IPSEC must traverse NAT (Network Address Translation) in actual use. Therefore, it is necessary to solve a series of problems encountered by MGRE over IPSEC during NAT traversal. In addition, due to the complex scenarios and diverse configurations of IPSEC traversal of NAT, the application may encounter problems such as IPSEC negotiation failure and data forwarding anomalies. The existing solutions solve some problems encountered in NAT traversal scenarios, but they still cannot solve the problem of NAT table entries changing after traversing the NAT device in the MGRE over IPSEC scenario, resulting in negotiation failure between the initiator and the responder. Summary of the invention

[0006] In view of this, the object of the present invention is to provide a method for IPSEC to traverse dynamic NAT and a DVPN network.

[0007] In order to achieve the above object, the technical solution adopted by the present invention is as follows:

[0008] In a first aspect, the present invention provides a method for IPSEC to traverse dynamic NAT, which is applied to a DVPN network, wherein the DVPN network includes a central device, a first branch device, and a second branch device, wherein a first NAT device is provided on a communication link between the first branch device and the central device, and a second NAT device is provided on a communication link between the second branch device and the central device, wherein the method includes:

[0009] The first branch device and the second branch device respectively establish an IPSEC tunnel with the central device, and the central device records the address port information of the first branch device before and after conversion by the first NAT device and records the address port information of the second branch device before and after conversion by the second NAT device;

[0010] When the central device receives the address resolution request message sent by the first branch device to obtain the address resolution of the second branch device, the central device sends a first address resolution response message carrying the address and port information of the second branch device before and after conversion by the second NAT device to the first branch device, and sends a second address resolution response message carrying the address and port information of the first branch device before and after conversion by the first NAT device to the second branch device;

[0011] The second branch device receives the second address resolution response message and generates a UDP message, and sends the UDP message to the first NAT device through the second NAT device, so that the second NAT device creates a table entry of the first branch device and connects the communication link between the first branch device and the second branch device;

[0012] The first branch device receives the first address resolution response message and performs Internet Key Exchange (IKE) negotiation with the second branch device to establish an IPSEC tunnel between the first branch device and the second branch device.

[0013] In an optional implementation manner, the first branch device and the second branch device respectively establish an IPSEC tunnel with the central device, and the central device records the address port information of the first branch device before and after conversion by the first NAT device and records the address port information of the second branch device before and after conversion by the second NAT device, including:

[0014] The first branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number and sends the message to the first NAT device;

[0015] The first NAT device receives the IKE negotiation message sent by the first branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends it to the central device;

[0016] The central device establishes an IPSEC tunnel with the first branch device according to the received IKE negotiation message sent by the first NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address, and two post-conversion IKE negotiation port numbers of the first branch device obtained from the IKE negotiation process;

[0017] The second branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number and sends it to the second NAT device;

[0018] The second NAT device receives the IKE negotiation message sent by the second branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends it to the central device;

[0019] The central device establishes an IPSEC tunnel with the second branch device based on the IKE negotiation message received from the second NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address and two post-conversion IKE negotiation port numbers of the second branch device obtained from the IKE negotiation process.

[0020] In an optional implementation manner, the central device sends a first address resolution response message carrying the address and port information of the second branch device before and after conversion by the second NAT device to the first branch device, including:

[0021] The central device generates an NHRP protocol message based on the IP address of the second branch device itself, and adds the IP address of the second branch device after conversion by the second NAT device and two converted IKE negotiation port numbers in the extended field of the NHRP protocol message, obtains the first address resolution response message and sends it to the first branch device.

[0022] In an optional implementation manner, the central device sends a second address resolution response message carrying the address and port information of the first branch device before and after conversion by the first NAT device to the second branch device, including:

[0023] The central device generates an NHRP protocol message based on the IP address of the first branch device itself, and adds the IP address of the first branch device converted by the first NAT device and two converted IKE negotiation port numbers in the extended field of the NHRP protocol message, obtains the second address resolution response message and sends it to the second branch device.

[0024] In an optional implementation manner, the second branch device receives the second address resolution response message and generates a UDP message, and sends the UDP message to the first NAT device through the second NAT device, including:

[0025] The second branch device receives the second address resolution response message, and obtains therefrom the IP address of the first branch device after conversion by the first NAT device, the first converted IKE negotiation port number, and the second converted IKE negotiation port number;

[0026] The second branch device generates a first UDP message based on the IP address of the first branch device converted by the first NAT device and the first converted IKE negotiation port number, and sends the first UDP message to the first NAT device through the second NAT device;

[0027] The second branch device generates a second UDP message based on the IP address of the first branch device converted by the first NAT device and the second converted IKE negotiation port number, and sends the second UDP message to the first NAT device through the second NAT device.

[0028] In an optional implementation manner, the first branch device receives the first address resolution response message and performs Internet key exchange (IKE) negotiation with the second branch device, including:

[0029] The first branch device receives the first address resolution response message, and obtains therefrom the IP address of the second branch device after conversion by the second NAT device, the third converted IKE negotiation port number, and the fourth converted IKE negotiation port number;

[0030] The first branch device generates a phase one negotiation message based on the IP address of the second branch device converted by the second NAT device and the third converted IKE negotiation port number, and sends the phase one negotiation message to the second branch device through the first NAT device to negotiate the IKE SA with the second branch device;

[0031] The first branch device generates a second-phase negotiation message based on the IP address of the second branch device converted by the second NAT device and the fourth converted IKE negotiation port number, and sends the second-phase negotiation message to the second branch device through the first NAT device to negotiate IPSEC SA with the second branch device.

[0032] In an optional embodiment, the method further comprises:

[0033] The first branch device periodically generates a keep-alive message and sends the keep-alive message to the second branch device through the IPSEC tunnel between the first branch device and the second branch device to keep alive the table entry corresponding to the IKE negotiation port number used for the first phase negotiation in the first NAT device and the second NAT device.

[0034] In an optional implementation manner, each of the IPSEC tunnels has a tunnel identifier;

[0035] The first branch device periodically generates a keep-alive message, and sends the keep-alive message to the second branch device through the IPSEC tunnel between the first branch device and the second branch device, including:

[0036] The first branch device periodically generates a message according to the ISAKMP protocol based on its own IP address and the IKE negotiation port number used for the first phase negotiation, the IP address of the second branch device itself and the IKE negotiation port number used for the first phase negotiation, and the tunnel identifier of the IPSEC tunnel between it and the second branch device, and encrypts the message using the IKE SA to obtain the keep-alive message and send it to the first NAT device;

[0037] The first NAT device performs address and port conversion on the IP address of the first branch device before conversion by the first NAT device and the IKE negotiation port number used for the first phase of negotiation in the keep-alive message and sends them to the central device;

[0038] The central device receives the keep-alive message sent by the first NAT device and sends it to the second NAT device;

[0039] The second NAT device receives the keep-alive message sent by the central device, and converts the IP address of the second branch device after conversion by the second NAT device and the IKE negotiation port number after the third conversion in the keep-alive message into the IP address before conversion and the IKE negotiation port number used for the first phase negotiation, and then sends it to the second branch device.

[0040] In an optional embodiment, the method further comprises:

[0041] After receiving the keep-alive message sent by the first NAT device, the central device obtains the first converted IKE negotiation port number of the first branch device recorded locally according to the tunnel identifier in the keep-alive message, and compares it with the first converted IKE negotiation port number of the first branch device in the keep-alive message. When the two are inconsistent, the first converted IKE negotiation port number of the first branch device recorded locally is updated.

[0042] In a second aspect, the present invention provides a DVPN network, including a central device and multiple branch devices, each branch device is provided with a NAT device on the communication link with the central device, and the DVPN network is used to implement any one of the methods described in the aforementioned implementation modes.

[0043] The present invention provides a method and DVPN network for IPSEC to traverse dynamic NAT, the method comprising: a first branch device and a second branch device respectively establish an IPSEC tunnel with a central device, the central device records the address port information of the two branch devices before and after conversion by the NAT device; when the central device receives a request from the first branch device to obtain the network information of the second branch device, the address port information of the second branch device before and after conversion by the second NAT device is sent to the first branch device, and the address port information of the first branch device before and after conversion by the first NAT device is sent to the second branch device; the second branch device receives the first address resolution response message, and sends the generated UDP message to the first NAT device through the second NAT device, so that the second NAT device creates a table entry of the first branch device to connect the communication link between the first branch device and the second branch device; the first branch device receives the second address resolution response message and performs Internet key exchange negotiation with the second branch device to establish an IPSEC tunnel with the second branch device. Thus, traversal of dynamic NAT is achieved in the MGRE over IPSEC scenario, ensuring successful negotiation between the initiator and the responder.

[0044] In order to make the above-mentioned objects, features and advantages of the present invention more obvious and easy to understand, preferred embodiments are given below and described in detail with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required for use in the embodiments are briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without creative work.

[0046] Figure 1 An example diagram of a DVPN network provided by an embodiment of the present invention is shown;

[0047] Figure 2 A block diagram of an electronic device provided by an embodiment of the present invention is shown;

[0048] Figure 3 One of the flow diagrams of the method for IPSEC traversing dynamic NAT provided by an embodiment of the present invention is shown;

[0049] Figure 4The second schematic diagram of the method flow of IPSEC traversing dynamic NAT provided by an embodiment of the present invention is shown;

[0050] Figure 5 The third flowchart of the method for IPSEC traversing dynamic NAT provided by an embodiment of the present invention is shown.

[0051] Icon: 100 - electronic device; 110 - processor; 120 - memory; 130 - communication module. DETAILED DESCRIPTION

[0052] The following will be combined with the accompanying drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Generally, the components of the embodiments of the present invention described and shown in the drawings here can be arranged and designed in various different configurations.

[0053] Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the invention claimed for protection, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

[0054] It should be noted that relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0055] See also Figure 1, is an example diagram of a DVPN network provided by an embodiment of the present invention. The DVPN network includes a central device, namely the Hub, and three branch devices, namely branch device 1 (Spoke1), branch device 2 (Spoke2) and branch device 3 (Spoke3). And a NAT device is provided on the communication link between each branch device and the central device, that is, a NAT device 1 (NAT1) is provided on the communication link between the central device and branch device 1, and a NAT device 2 (NAT2) is provided on the communication link between the central device and branch devices 2 and branch devices 3. It should be noted that the number and connection relationship of branch devices and NAT devices in the DVPN network can be set according to actual conditions, and the embodiment of the present invention does not limit this.

[0056] See also Figure 2 , is a block diagram of an electronic device provided by an embodiment of the present invention. The structure of the electronic device can be used to implement the above Figure 1 The electronic device 100 includes a processor 110, a memory 120, and a communication module 130, and each component is electrically connected to each other directly or indirectly to achieve data transmission or interaction. For example, these components can be electrically connected to each other through one or more communication buses or signal lines.

[0057] The processor 110 is used to read / write data or programs stored in the memory 120 and execute corresponding functions. It can be a general-purpose processor, including a CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be a DSP digital signal processor, an ASIC application-specific integrated circuit, an FPGA off-the-shelf programmable gate array or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components.

[0058] The memory 120 is used to store programs or data. The memory 120 can be a RAM (Random Access Memory), a ROM (Read Only Memory), a PROM (Programmable Read-Only Memory), an EPROM (Erasable Programmable Read-Only Memory), an EEPROM (Electric Erasable Programmable Read-Only Memory), etc.

[0059] The communication module 130 is used to perform signaling or data communications with other devices.

[0060] Understandably, Figure 2 The structure shown is only a schematic diagram of the structure of the electronic device 100. The electronic device 100 may also include Figure 2 More or fewer components as shown, or with Figure 2 Different configurations are shown. Figure 2 Each component shown in the figure can be implemented by hardware, software or a combination thereof.

[0061] The following will be Figure 1 As an example, the steps and corresponding technical effects of various methods provided by the embodiments of the present invention are introduced. Figure 3 , is a flow chart of a method for IPSEC traversing dynamic NAT provided by an embodiment of the present invention.

[0062] Step S202: The first branch device and the second branch device establish IPSEC tunnels with the central device respectively. The central device records the address and port information of the first branch device before and after conversion by the first NAT device and the address and port information of the second branch device before and after conversion by the second NAT device.

[0063] For ease of understanding, the embodiments of the present invention are described in detail. Figure 1 In the example, branch device 1 is the first branch device and branch device 2 is the second branch device. The following is an example of a scenario in which branch device 1 (the initiator) requests to communicate with branch device 2 (the responder). Before branch device 1 communicates with branch device 2, they need to establish IPSEC tunnels with the central device respectively.

[0064] The branch device 1 sends an IPSEC tunnel establishment request to the central device through its corresponding NAT device, namely, NAT device 1, and the central device establishes an IPSEC tunnel with the branch device 1 according to the IPSEC tunnel establishment request. Since the IPSEC tunnel establishment request is sent to the central device through NAT device 1, NAT device 1 will convert the original address and port information of the branch device 1 in the internal network (called the pre-conversion address and port information) into the post-conversion address and port information of the external network, and then the central device will record the pre-conversion address and port information and the post-conversion address and port information of the branch device 1.

[0065] Similarly, the branch device 2 sends an IPSEC tunnel establishment request to the central device through its corresponding NAT device, namely, NAT device 2, and the central device establishes an IPSEC tunnel with the branch device 2 according to the IPSEC tunnel establishment request. Since the IPSEC tunnel establishment request is sent to the central device through NAT device 2, NAT device 2 will convert the original address and port information of the branch device 2 in the internal network (called the pre-conversion address and port information) into the post-conversion address and port information of the external network, and then the central device will record the pre-conversion address and port information and the post-conversion address and port information of the branch device 2.

[0066] It is understandable that the first branch device and the second branch device both establish an IPSEC tunnel with the central device through IKE (Internet Key Exchange) negotiation. The address and port information of the branch devices before and after conversion can be sent to the central device through IKE negotiation messages.

[0067] Step S204, when the central device receives the request sent by the first branch device to obtain the network information of the second branch device, it sends a first address resolution response message carrying the address and port information of the second branch device before and after conversion by the second NAT device to the first branch device, and sends a second address resolution response message carrying the address and port information of the first branch device before and after conversion by the first NAT device to the second branch device.

[0068] For ease of understanding, the above example is continued for explanation. After branch device 1 and branch device 2 respectively establish IPSEC tunnels with the central device, branch device 1 may send a request to the central device to obtain network information of branch device 2.

[0069] After receiving the request, the central device generates a first address resolution response message based on the pre-conversion address port information and post-conversion address port information of branch device 2 and sends it to branch device 1, so that branch device 1 obtains the network information of branch device 2. It can be understood that although it is a request sent by branch device 1 to the central device, in order to ensure that branch device 1 and branch device 2 can communicate, the central device also generates a second address resolution response message based on the pre-conversion address port information and post-conversion address port information of branch device 1 and sends it to branch device 2, so that branch device 2 obtains the network information of branch device 1.

[0070] It can be understood that the existing implementation method is that the central device only sends the address and port information before conversion to the branch device, while the central device of the embodiment of the present invention not only sends the address and port information before conversion to the branch device, but also sends the address and port information after conversion by the NAT device to the branch device, so that the IPSEC tunnel established between the first branch device and the second branch device can pass through the dynamic NAT.

[0071] Step S206, the second branch device receives the second address resolution response message and generates a UDP message, and sends the UDP message to the first NAT device through the second NAT device, so that the second NAT device creates an entry for the first branch device and connects the communication link between the first branch device and the second branch device.

[0072] Step S208: The first branch device receives the first address resolution response message and performs Internet key exchange (IKE) negotiation with the second branch device to establish an IPSEC tunnel between the first branch device and the second branch device.

[0073] It is understandable that, since the first branch device requests the central device to obtain the network information of the second branch device, the first NAT device has a table entry of the second branch device. However, the second NAT device does not have a table entry of the first branch device, so the communication link between the first branch device and the second branch device is not connected.

[0074] Therefore, in this embodiment, after receiving the second address resolution response message, the second branch device will also generate a UDP (User Datagram Protocol) message based on the converted address port information of the first branch device, and send the UDP message to the first NAT device through the second NAT device. Then, the second NAT device can create a table entry for the first branch device based on the UDP message, thereby opening up the communication link between the first branch device and the second branch device.

[0075] For ease of understanding, the above example will be used for explanation. After branch device 2 receives the second address resolution response message sent by the central device, it will generate a UDP message based on the converted address port information of branch device 1, and send the UDP message to NAT device 1 through NAT device 2, so that NAT device 2 creates a NAT table entry for branch device 1 based on the UDP message, thereby opening up the communication link between branch device 1 and branch device 2. In addition, after branch device 1 receives the first address resolution response message sent by the central device, it will establish an IPSEC tunnel with branch device 2 through IKE negotiation with branch device 2. Then, after the IPSEC tunnel between branch device 1 and branch device 2 is successfully established, branch device 1 and branch device 2 can communicate through the IPSEC tunnel.

[0076] It can be seen that based on the above steps, the first branch device and the second branch device respectively establish IPSEC tunnels with the central device, and the central device records the address port information of the two branch devices before and after the NAT device conversion; when the central device receives the request from the first branch device to obtain the network information of the second branch device, the address port information of the second branch device before and after the second NAT device conversion is sent to the first branch device, and the address port information of the first branch device before and after the first NAT device conversion is sent to the second branch device; the second branch device receives the first address resolution response message, and sends the generated UDP message to the first NAT device through the second NAT device, so that the second NAT device creates the table entry of the first branch device to connect the communication link between the first branch device and the second branch device; the first branch device receives the second address resolution response message and negotiates the Internet key exchange with the second branch device to establish the IPSEC tunnel between it and the second branch device. Thus, the dynamic NAT is traversed in the MGRE over IPSEC scenario, ensuring the successful negotiation between the initiator and the responder.

[0077] Optionally, for step S202, the present invention provides a possible implementation method, see Figure 4 .

[0078] Step S202-1: The first branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number, and sends the message to the first NAT device.

[0079] Step S202-2: The first NAT device receives the IKE negotiation message sent by the first branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends the result to the central device.

[0080] Step S202-3, the central device establishes an IPSEC tunnel with the first branch device according to the IKE negotiation message sent by the received first NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address, and two post-conversion IKE negotiation port numbers of the first branch device obtained from the IKE negotiation process.

[0081] Step S202-4: The second branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number, and sends the message to the second NAT device.

[0082] Step S202-5: The second NAT device receives the IKE negotiation message sent by the second branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends the result to the central device.

[0083] Step S202-6, the central device establishes an IPSEC tunnel with the second branch device according to the IKE negotiation message sent by the received second NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address, and two post-conversion IKE negotiation port numbers of the second branch device obtained from the IKE negotiation process.

[0084] In this embodiment, the branch device supports the standard IKE protocol, so two standard IKE negotiation port numbers are used, respectively for the two phases of IPSEC negotiation.

[0085] For ease of understanding, the above example is continued for explanation. Assume that the address port information before conversion of branch device 1 and branch device 2 is as shown in Table 1 below.

[0086] Table 1

[0087]

[0088] Based on the contents of Table 1, the following will introduce the process of establishing IPSEC tunnels between branch device 1 and branch device 2 and the central device.

[0089] For steps S202-1 to S202-3, that is, the process of establishing an IPSEC tunnel between branch device 1 and the central device is as follows: First, branch device 1 generates an IKE negotiation message requesting to establish an IPSEC tunnel based on its own IP address, i.e. 1.0.0.1, the first IKE negotiation port number before conversion, i.e. 500, and the second IKE negotiation port number before conversion, i.e. 4500, as well as the IP address of the central device, i.e. 3.0.0.1, and the two IKE negotiation port numbers, i.e. 500 and 4500, and sends it to NAT device 1.

[0090] Then, NAT device 1 receives the IKE negotiation message sent by branch device 1, and converts the pre-conversion IP address of branch device 1, i.e., 1.0.0.1, in the IKE negotiation message into the post-conversion IP address, i.e., 3.0.0.2, converts the first pre-conversion IKE negotiation port number 500 of branch device 1 into the corresponding post-conversion IKE negotiation port number 10001, and converts the second pre-conversion IKE negotiation port number 4500 of branch device 1 into the corresponding post-conversion IKE negotiation port number 10002, and then sends the converted IKE negotiation message to the central device. It should be noted that the two post-conversion IKE negotiation ports 10001 and 10002 used in the embodiment of the present invention are only for illustrative purposes and are not specifically limited.

[0091] Finally, the central device receives the IKE negotiation message sent by NAT device 1, and establishes an IPSEC tunnel with branch device 1. At the same time, the central device obtains the pre-conversion address and port information of branch device 1, i.e., the pre-conversion IP address 1.0.0.1, the first pre-conversion IKE negotiation port number 500, and the second pre-conversion IKE negotiation port number 4500, from the IKE negotiation message, as well as the post-conversion address and port information of branch device 1, i.e., the post-conversion IP address 3.0.0.2, the first post-conversion IKE negotiation port number 10001, and the second post-conversion IKE negotiation port number 10002, and records the pre-conversion address and port information and the post-conversion address and port information of branch device 1.

[0092] For steps S202-4 to S202-6, that is, the process of establishing an IPSEC tunnel between branch device 2 and the central device is as follows: First, branch device 2 generates an IKE negotiation message requesting to establish an IPSEC tunnel based on its own IP address, i.e. 2.0.0.1, the first IKE negotiation port number before conversion, i.e. 500, and the second IKE negotiation port number before conversion, i.e. 4500, as well as the IP address of the central device, i.e. 3.0.0.1, and the two IKE negotiation port numbers, i.e. 500 and 4500, and sends it to NAT device 2.

[0093] Then, NAT device 2 receives the IKE negotiation message sent by branch device 2, and converts the pre-conversion IP address of branch device 2 in the IKE negotiation message, i.e., 2.0.0.1, into the post-conversion IP address, i.e., 4.0.0.2, and converts the first pre-conversion IKE negotiation port number 500 of branch device 2 into the corresponding post-conversion IKE negotiation port number 10001, and converts the second pre-conversion IKE negotiation port number 4500 of branch device 2 into the corresponding post-conversion IKE negotiation port number 10002, and then sends the converted IKE negotiation message to the central device.

[0094] Finally, the central device receives the IKE negotiation message sent by NAT device 2, and establishes an IPSEC tunnel with branch device 2. At the same time, the central device obtains the pre-translation address and port information of branch device 2, i.e., the pre-translation IP address 2.0.0.1, the first pre-translation IKE negotiation port number 500, and the second pre-translation IKE negotiation port number 4500, from the IKE negotiation message, as well as the post-translation address and port information of branch device 2, i.e., the post-translation IP address 4.0.0.2, the first post-translation IKE negotiation port number 10001, and the second post-translation IKE negotiation port number 10002, and records the pre-translation address and port information and the post-translation address and port information of branch device 2.

[0095] After the above-mentioned central device establishes IPSEC tunnels with branch device 1 and branch device 2 respectively, the converted address port information of branch device 1 and branch device 2 recorded by the central device is shown in Table 2 below.

[0096] Table 2

[0097]

[0098] It can be understood that the central device records the pre-conversion address port information and the post-conversion address port information of the first branch device and the second device, so that when the two devices subsequently establish an IPSEC tunnel, they can exchange network information of the two branch devices through the central device.

[0099] Optionally, for the process in step S204 where the central device sends the first address resolution response message to the first branch device, the embodiment of the present invention provides a possible implementation method, see Figure 5 .

[0100] Step S204-1, the central device generates an NHRP protocol message based on the IP address of the second branch device itself, and adds the IP address of the second branch device after conversion by the second NAT device and two converted IKE negotiation port numbers in the extension field of the NHRP protocol message, obtains a first address resolution response message and sends it to the first branch device.

[0101] It can be understood that in the existing implementation method, when the central device receives a request from the first branch device as the initiator to communicate with the second branch device as the responder, the central device will generate a message containing only the IP address of the second branch device itself according to the NHRP protocol, and send it to the first branch device, that is, the message will not contain the port number of the second branch device.

[0102] However, in the scenario of the embodiment of the present invention, the second branch device receives the message through the second NAT device, so the first branch device also needs to obtain the converted address port information of the second branch device, so as to ensure that the message sent to the second branch device can be correctly forwarded to the second branch device through the second NAT device. Therefore, the central device of the embodiment of the present invention uses the extension field of the NHRP protocol message to add the IP address of the second branch device after conversion by the second NAT device and the two converted IKE negotiation port numbers in the message sent to the first branch device, so that the first branch device can obtain the converted address port information of the second branch device.

[0103] For ease of understanding, the above example is continued for explanation. The central device generates a message based on the IP address of branch device 2 itself, namely 2.0.0.1, and adds the IP address of branch device 2 converted by NAT device 2, namely 4.0.0.2, and two converted IKE negotiation port numbers, namely 10001 and 10002, in the extended field of the NHRP protocol message, and then obtains the first address resolution response message. Then the central device sends the first address resolution response message to branch device 1, so that branch device 1 obtains the converted address port information of branch device 2, that is, obtains the converted IP address 4.0.0.2 of branch device 2 and two converted IKE negotiation port numbers, namely 10001 and 10002.

[0104] Optionally, for the process in step S204 where the central device sends the second address resolution response message to the second branch device, the embodiment of the present invention provides a possible implementation method, please continue to refer to Figure 5 .

[0105] Step S204-2, the central device generates an NHRP protocol message based on the IP address of the first branch device itself, and adds the IP address of the first branch device after conversion by the first NAT device and two converted IKE negotiation port numbers in the extension field of the NHRP protocol message, obtains a second address resolution response message and sends it to the second branch device.

[0106] It can be understood that, in addition to the first branch device as the initiator needing to obtain the converted address port information of the second branch device, the second branch device as the responder also needs to obtain the converted address port information of the first branch device, so that the branch devices at both ends can communicate. Therefore, in this embodiment, the central device will also send a message carrying the network information of the first branch device to the second branch device.

[0107] As mentioned above, in the existing implementation method, the message generated by the central device according to the NHRP protocol and sent to the second branch device only contains the IP address of the first branch device itself, that is, the message does not contain the port number of the first branch device. Similarly, in the scenario of the embodiment of the present invention, the first branch device receives the message through the first NAT device, so the second branch device also needs to obtain the converted address and port information of the first branch device, so as to ensure that the message it sends to the first branch device can be correctly forwarded to the first branch device through the first NAT device. Therefore, the central device of the embodiment of the present invention uses the extended field of the NHRP message protocol to add the IP address of the first branch device after conversion by the first NAT device and the two converted IKE negotiation port numbers in the message sent to the second branch device, so that the second branch device can obtain the converted address and port information of the first branch device.

[0108] For ease of understanding, the above example is continued for explanation. The central device generates a message based on the IP address of branch device 1 itself, i.e., 1.0.0.1, and adds the IP address of branch device 1 converted by NAT device 1, i.e., 3.0.0.2, and two converted IKE negotiation port numbers, i.e., 10001 and 10002, in the extended field of the NHRP protocol message, to obtain a second address resolution response message. The central device then sends the second address resolution response message to branch device 2, so that branch device 2 obtains the converted address port information of branch device 1, i.e., obtains the converted IP address 3.0.0.2 of branch device 1 and two converted IKE negotiation port numbers, i.e., 10001 and 10002.

[0109] Optionally, for step S206, the present invention provides a possible implementation method, please continue to refer to Figure 5 .

[0110] Step S206-1: The second branch device receives the second address resolution response message, and obtains the IP address of the first branch device after being converted by the first NAT device, the first converted IKE negotiation port number, and the second converted IKE negotiation port number.

[0111] Step S206-2: The second branch device generates a first UDP message based on the IP address of the first branch device converted by the first NAT device and the first converted IKE negotiation port number, and sends the first UDP message to the first NAT device through the second NAT device.

[0112] Step S206-3: The second branch device generates a second UDP message based on the IP address of the first branch device converted by the first NAT device and the second converted IKE negotiation port number, and sends the second UDP message to the first NAT device through the second NAT device.

[0113] For ease of understanding, we will continue to use the above example for explanation. Since branch device 1 obtains the network information of branch device 2 by requesting the central device, a table entry of branch device 2 is established in NAT device 1. However, there is no table entry of branch device 1 in NAT device 2, so the communication link between branch device 1 and branch device 2 is not yet connected. Therefore, after receiving the second address resolution response message, branch device 2 will obtain the converted IP address of branch device 1, i.e. 3.0.0.2, the first converted IKE negotiation port number, i.e. 10001, and the second converted IKE negotiation port number, i.e. 10002.

[0114] Then, branch device 2 will generate a first UDP message based on the converted IP address 3.0.0.2 of branch device 1 and the first converted IKE negotiation port number 10001, and send the first UDP message to NAT device 1 through NAT device 2, so that NAT device 2 creates a table entry of the first branch device 1 based on the first UDP message, that is, a table entry with IP address 3.0.0.2 and port number 10001.

[0115] Then, branch device 2 will generate a second UDP message based on the converted IP address 3.0.0.2 of branch device 1 and the second converted IKE negotiation port number 10002, and send the second UDP message to NAT device 1 through NAT device 2, so that NAT device 2 creates a table entry for the second branch device 1 based on the second UDP message, that is, a table entry with IP address 3.0.0.2 and port number 10002.

[0116] It can be understood that after NAT device 2 creates the table entry of branch device 1, NAT device 2 can process the message sent from branch device 1 to branch device 2 based on the table entry. Similarly, if NAT device 1 has the table entry of branch device 2, NAT device 1 can process the message sent from branch device 2 to branch device 1 based on the table entry. Then the communication link between branch device 1 and branch device 2 is connected.

[0117] Optionally, for step S208, the present invention provides a possible implementation method, please continue to refer to Figure 5 .

[0118] Step S208-1: The first branch device receives the first address resolution response message, and obtains the IP address of the second branch device after being converted by the second NAT device, the third converted IKE negotiation port number, and the fourth converted IKE negotiation port number.

[0119] Step S208-2: The first branch device generates a phase one negotiation message based on the IP address of the second branch device after conversion by the second NAT device and the third converted IKE negotiation port number, and sends the phase one negotiation message to the second branch device through the first NAT device to negotiate IKE SA with the second branch device.

[0120] Step S208-3, the first branch device generates a second-phase negotiation message based on the IP address of the second branch device converted by the second NAT device and the fourth converted IKE negotiation port number, and sends the second-phase negotiation message to the second branch device through the first NAT device to negotiate IPSEC SA with the second branch device.

[0121] For ease of understanding, the above example is continued for explanation. First, after receiving the first address resolution response message, branch device 1 will obtain the converted IP address of branch device 2, i.e. 4.0.0.2, the third converted IKE negotiation port number, i.e. 10001, and the fourth converted IKE negotiation port number, i.e. 10002.

[0122] Then, the branch device 1 generates a phase 1 negotiation message based on the translated IP address 4.0.0.2 of the branch device 2 and the third translated IKE negotiation port number 10001, and sends the phase 1 negotiation message to the branch device 2 through the NAT device 1 to negotiate the IKE SA with the branch device 2. Next, the branch device 1 generates a phase 2 negotiation message based on the translated IP address 4.0.0.2 of the branch device 2 and the fourth translated IKE negotiation port number 10002, and sends the phase 2 negotiation message to the branch device 2 through the NAT device 1 to negotiate the IPSEC SA with the branch device 2. SA (Security Association) refers to a set of parameters defined to ensure the security of communication.

[0123] It can be understood that the IKE negotiation process between branch device 1 and branch device 2 includes two stages: the first stage is to negotiate IKE SA through port 500 and phase 1 negotiation message, that is, to define the key between the two ends of the communication; the second stage is to negotiate IPSEC SA through port 4500 and phase 2 negotiation message, that is, to define the encryption policy for protecting data packets at the IP layer. After branch device 1 and branch device 2 complete the two-stage negotiation, the IPSEC tunnel between the two is successfully established.

[0124] Optionally, after step S208, the embodiment of the present invention provides a possible implementation manner.

[0125] Step S210, the first branch device periodically generates a keep-alive message, and sends the keep-alive message to the second branch device through the IPSEC tunnel between the first branch device and the second branch device to keep alive the table entry corresponding to the IKE negotiation port number used for the first phase negotiation in the first NAT device and the second NAT device.

[0126] It is understandable that in a DVPN network, a branch device will periodically send a registration message to a central device through port number 4500, which is the IKE negotiation port number used for the second phase of negotiation. Therefore, this registration message can be used as a keep-alive message for port number 4500 to ensure that the table entry corresponding to port number 4500 in the NAT device will not age. However, for port number 500, which is the IKE negotiation port number used for the first phase of negotiation, after it is used in one phase of the IKE negotiation process, the port number will not be used again for a long time. Therefore, an embodiment of the present invention also provides a keep-alive mechanism to keep port number 500 alive.

[0127] For ease of understanding, the above example is continued for explanation. Branch device 1 will periodically generate keep-alive messages for keeping port number 500 alive, and send the keep-alive messages to branch device 2 through its IPSEC tunnel with branch device 2. Since the message sent by branch device 1 to branch device 2 will pass through NAT device 1 and NAT device 2, branch device 1 periodically sends keep-alive messages to branch device 2, so that the table entries corresponding to port number 500 in NAT device 1 and NAT device 2 are always in a valid state, that is, the table entries corresponding to port number 500 in NAT device 1 and NAT device 2 will not age, thereby achieving the effect of keeping port number 500 alive.

[0128] It is understandable that the keep-alive mechanism of port number 500 is of great significance for the IPSEC renegotiation between the initiator and the responder. In order to ensure the security of communication between the initiator and the responder, the initiator and the responder will renegotiate IKE after a period of time, and IKE negotiation is initiated by sending messages from port number 500. Therefore, keeping port number 500 alive can ensure that the initiator and the responder can successfully renegotiate, thereby increasing the success rate of the negotiation between the two ends and realizing dynamic NAT traversal in the MGRE over IPSEC scenario.

[0129] Optionally, for step S210, the embodiment of the present invention also provides a possible implementation method.

[0130] Step S210-1, the first branch device periodically generates a message according to the ISAKMP protocol based on its own IP address and the IKE negotiation port number used for the first phase of negotiation, the second branch device's own IP address and the IKE negotiation port number used for the first phase of negotiation, and the tunnel identifier of the IPSEC tunnel between it and the second branch device, and encrypts the message using the IKE SA to obtain a keep-alive message and send it to the first NAT device.

[0131] Step S210-2: The first NAT device performs address and port conversion on the IP address of the first branch device before conversion by the first NAT device and the IKE negotiation port number used for the first phase of negotiation in the keep-alive message and sends them to the central device.

[0132] Step S210 - 3 : The central device receives the keep-alive message sent by the first NAT device and sends it to the second NAT device.

[0133] Step S210-4, the second NAT device receives the keep-alive message sent by the central device, and converts the IP address of the second branch device after conversion by the second NAT device and the third converted IKE negotiation port number in the keep-alive message into the IP address before conversion and the IKE negotiation port number used for the first phase negotiation and sends them to the second branch device.

[0134] In this embodiment, since a NAT device may be connected to multiple branch devices, and the converted IP addresses of these multiple branch devices are the same, in order to distinguish different IPSEC tunnels, each IPSEC tunnel has a tunnel identifier, namely, a Cookie value. Figure 1 In the DVPN network shown, it is assumed that branch device 1 has established IPSEC tunnels with branch device 2 and branch device 3. Since branch device 2 and branch device 3 are both connected to NAT device 2, the converted IP addresses of branch device 2 and branch device 3 are the same. Therefore, the IPSEC tunnel between branch device 1 and branch device 2 and the IPSEC tunnel between branch device 1 and branch device 3 can be distinguished by the Cookie value.

[0135] For ease of understanding, the above example is continued for explanation. First, branch device 1 periodically generates a message according to the ISAKMP (Internet Security Association and Key Management Protocol) protocol based on its own IP address 1.0.0.1 and the IKE negotiation port number 500 used for the first phase of negotiation, the second branch device's own IP address 4.0.0.2 and the IKE negotiation port number 10001 used for the first phase of negotiation, and the tunnel identifier of its IPSEC tunnel with branch device 2, namely the Cookie value, and uses the key of the first phase of the IKE negotiation between the two, namely the IKE SA, to encrypt the message, and then obtain the keep-alive message and send it to NAT device 1. It can be understood that by encrypting the message, the security of transmitting the keep-alive message can be improved.

[0136] Then, NAT device 1 converts the pre-conversion IP address 1.0.0.1 of branch device 1 in the keep-alive message into the post-conversion IP address 3.0.0.2, and converts the IKE negotiation port number 500 of branch device 1 used for the first phase of negotiation into the first post-conversion IKE negotiation port number 10001, and then sends it to the central device. Then, the central device receives the keep-alive message sent by NAT device 1 and sends it to NAT device 2. Finally, NAT device 2 receives the keep-alive message sent by the central device, and converts the post-conversion IP address 4.0.0.2 of branch device 2 in the keep-alive message into the pre-conversion IP address 2.0.0.1, and converts the third post-conversion IKE negotiation port number 10001 of branch device 2 into the IKE negotiation port number 500 used for the first phase of negotiation, and then sends it to branch device 2, so that branch device 2 receives the keep-alive message.

[0137] Optionally, in step S210, an embodiment of the present invention provides a possible implementation method.

[0138] Step S212, after receiving the keep-alive message sent by the first NAT device, the central device obtains the first converted IKE negotiation port number of the first branch device recorded locally according to the tunnel identifier in the keep-alive message, and compares it with the first converted IKE negotiation port number of the first branch device in the keep-alive message. When the two are inconsistent, the first converted IKE negotiation port number of the first branch device recorded locally is updated.

[0139] It is understandable that the keep-alive mechanism of port number 500 provided in the embodiment of the present invention can also ensure that when an abnormality occurs in the NAT device, the central device can update the port number in time.

[0140] For ease of understanding, the above example is continued for explanation. After receiving the keep-alive message sent by NAT device 1, the central device obtains the first converted IKE negotiation port number of branch device 1 recorded locally based on the tunnel identifier, i.e., the Cookie value, in the keep-alive message, and compares it with the first converted IKE negotiation port number of branch device 1 in the keep-alive message. If the two are inconsistent, the central device will update the first converted IKE negotiation port number of branch device 1 recorded locally to record the latest first converted IKE negotiation port number of branch device 1. In this way, when an abnormality occurs in NAT device 1, the central device can promptly obtain the converted IKE negotiation port number corresponding to the port number 500 reassigned to branch device 1 by NAT device 1, thereby improving the accuracy of the converted IKE negotiation port number recorded by the central device.

[0141] The embodiment of the present invention also provides a DVPN network, including a central device and multiple branch devices, each branch device is provided with a NAT device on the communication link with the central device, and the DVPN network is used to implement the method of IPSEC traversing dynamic NAT disclosed in the embodiment of the present invention.

[0142] In summary, when deploying MGRE over IPSEC scenarios, it is often necessary to traverse NAT, and users do not care whether it is static NAT or dynamic NAT, whether port conversion is required, and whether the port conversion is static or dynamic, and in most cases users cannot change NAT rules. Then, through the method for IPSEC traversing dynamic NAT provided by the embodiment of the present invention, users do not need to care about NAT rules, and can directly use the method for full cone, restricted cone, and port restricted cone NAT scenarios, thereby greatly expanding the deployment scenarios and application scope of MGRE over IPSEC.

[0143] In several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present invention. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of a code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or action, or can be implemented with a combination of dedicated hardware and computer instructions.

[0144] In addition, the functional modules in the various embodiments of the present invention may be integrated together to form an independent part, or each module may exist independently, or two or more modules may be integrated to form an independent part.

[0145] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0146] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. For those skilled in the art, the present invention may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for IPSEC to traverse dynamic NAT, characterized in that: Applied to a DVPN network, the DVPN network includes a central device, a first branch device, and a second branch device, a first NAT device is provided on a communication link between the first branch device and the central device, and a second NAT device is provided on a communication link between the second branch device and the central device, the method includes: The first branch device and the second branch device respectively establish an IPSEC tunnel with the central device, and the central device records the address port information of the first branch device before and after conversion by the first NAT device and records the address port information of the second branch device before and after conversion by the second NAT device; When the central device receives the address resolution request message sent by the first branch device to obtain the address resolution of the second branch device, the central device sends a first address resolution response message carrying the address and port information of the second branch device before and after conversion by the second NAT device to the first branch device, and sends a second address resolution response message carrying the address and port information of the first branch device before and after conversion by the first NAT device to the second branch device; The second branch device receives the second address resolution response message and generates a UDP message, and sends the UDP message to the first NAT device through the second NAT device, so that the second NAT device creates a table entry of the first branch device and connects the communication link between the first branch device and the second branch device; The first branch device receives the first address resolution response message and performs Internet Key Exchange (IKE) negotiation with the second branch device to establish an IPSEC tunnel between the first branch device and the second branch device.

2. The method according to claim 1, characterized in that The first branch device and the second branch device respectively establish an IPSEC tunnel with the central device, and the central device records the address port information of the first branch device before and after conversion by the first NAT device and records the address port information of the second branch device before and after conversion by the second NAT device, including: The first branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number and sends the message to the first NAT device; The first NAT device receives the IKE negotiation message sent by the first branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends it to the central device; The central device establishes an IPSEC tunnel with the first branch device according to the received IKE negotiation message sent by the first NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address, and two post-conversion IKE negotiation port numbers of the first branch device obtained from the IKE negotiation process; The second branch device generates an IKE negotiation message for requesting to establish an IPSEC tunnel based on its own IP address and IKE negotiation port number and sends it to the second NAT device; The second NAT device receives the IKE negotiation message sent by the second branch device, and performs address and port conversion on the IP address and IKE negotiation port number in the IKE negotiation message and sends it to the central device; The central device establishes an IPSEC tunnel with the second branch device based on the IKE negotiation message received from the second NAT device, and records the pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address and two post-conversion IKE negotiation port numbers of the second branch device obtained from the IKE negotiation process.

3. The method according to claim 2, characterized in that The central device sends a first address resolution response message carrying the address and port information of the second branch device before and after conversion by the second NAT device to the first branch device, including: The central device generates an NHRP protocol message based on the IP address of the second branch device itself, and adds the IP address of the second branch device after conversion by the second NAT device and two converted IKE negotiation port numbers in the extended field of the NHRP protocol message, obtains the first address resolution response message and sends it to the first branch device.

4. The method according to claim 2, characterized in that: The central device sends a second address resolution response message carrying the address and port information of the first branch device before and after conversion by the first NAT device to the second branch device, including: The central device generates an NHRP protocol message based on the IP address of the first branch device itself, and adds the IP address of the first branch device converted by the first NAT device and two converted IKE negotiation port numbers in the extended field of the NHRP protocol message, obtains the second address resolution response message and sends it to the second branch device.

5. The method according to claim 2, characterized in that: The second branch device receives the second address resolution response message and generates a UDP message, and sends the UDP message to the first NAT device through the second NAT device, including: The second branch device receives the second address resolution response message, and obtains therefrom the IP address of the first branch device after conversion by the first NAT device, the first converted IKE negotiation port number, and the second converted IKE negotiation port number; The second branch device generates a first UDP message based on the IP address of the first branch device converted by the first NAT device and the first converted IKE negotiation port number, and sends the first UDP message to the first NAT device through the second NAT device; The second branch device generates a second UDP message based on the IP address of the first branch device converted by the first NAT device and the second converted IKE negotiation port number, and sends the second UDP message to the first NAT device through the second NAT device.

6. The method according to claim 5, characterized in that The first branch device receives the first address resolution response message and performs Internet key exchange (IKE) negotiation with the second branch device, including: The first branch device receives the first address resolution response message, and obtains therefrom the IP address of the second branch device after conversion by the second NAT device, the third converted IKE negotiation port number, and the fourth converted IKE negotiation port number; The first branch device generates a phase one negotiation message based on the IP address of the second branch device converted by the second NAT device and the third converted IKE negotiation port number, and sends the phase one negotiation message to the second branch device through the first NAT device to negotiate the IKE SA with the second branch device; The first branch device generates a second-phase negotiation message based on the IP address of the second branch device converted by the second NAT device and the fourth converted IKE negotiation port number, and sends the second-phase negotiation message to the second branch device through the first NAT device to negotiate IPSEC SA with the second branch device.

7. The method according to claim 6, characterized in that The method further comprises: The first branch device periodically generates a keep-alive message and sends the keep-alive message to the second branch device through the IPSEC tunnel between the first branch device and the second branch device to keep alive the table entry corresponding to the IKE negotiation port number used for the first phase negotiation in the first NAT device and the second NAT device.

8. The method according to claim 7, characterized in that Each of the IPSEC tunnels has a tunnel identifier; The first branch device periodically generates a keep-alive message, and sends the keep-alive message to the second branch device through the IPSEC tunnel between the first branch device and the second branch device, including: The first branch device periodically generates a message according to the ISAKMP protocol based on its own IP address and the IKE negotiation port number used for the first phase negotiation, the IP address of the second branch device itself and the IKE negotiation port number used for the first phase negotiation, and the tunnel identifier of the IPSEC tunnel between it and the second branch device, and encrypts the message using the IKE SA to obtain the keep-alive message and send it to the first NAT device; The first NAT device performs address and port conversion on the IP address of the first branch device before conversion by the first NAT device and the IKE negotiation port number used for the first phase of negotiation in the keep-alive message and sends them to the central device; The central device receives the keep-alive message sent by the first NAT device and sends it to the second NAT device; The second NAT device receives the keep-alive message sent by the central device, and converts the IP address of the second branch device after conversion by the second NAT device and the IKE negotiation port number after the third conversion in the keep-alive message into the IP address before conversion and the IKE negotiation port number used for the first phase negotiation, and then sends it to the second branch device.

9. The method according to claim 8, characterized in that The method further comprises: After receiving the keep-alive message sent by the first NAT device, the central device obtains the first converted IKE negotiation port number of the first branch device recorded locally according to the tunnel identifier in the keep-alive message, and compares it with the first converted IKE negotiation port number of the first branch device in the keep-alive message. When the two are inconsistent, the first converted IKE negotiation port number of the first branch device recorded locally is updated.

10. A DVPN network, characterized in that: It comprises a central device and a plurality of branch devices, each branch device is provided with a NAT device on the communication link with the central device, and the DVPN network is used to implement the method described in any one of claims 1 to 9.

Images