IPSEC traversal of dynamic NAT and DVPN network

Abstract

This invention relates to the field of communication technology, providing a method for IPsec traversal of dynamic NAT and a DVPN network. The method includes: a central device establishing IPsec tunnels with a first branch device and a second branch device respectively, and recording the address and port information of these two branch devices before and after NAT translation; when the central device receives a request from the first branch device to obtain network information of the second branch device, it sends the address and port information of the second branch device before and after translation to the first branch device, and vice versa; upon receiving the information, the second branch device sends a UDP packet to the first NAT device, causing the NAT device to create an entry for the first branch device to connect the communication link between the two branch devices; upon receiving the information, the first branch device negotiates an Internet key exchange with the second branch device to establish the IPsec tunnel between the two branch devices. This achieves traversal of dynamic NAT in the MGRE over IPsec scenario.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically, to a method for IPsec traversing dynamic NAT and a DVPN network. Background Art

[0002] IP (Internet Protocol) communication is vulnerable to attacks such as eavesdropping and tampering, lacking security guarantees. IPSEC (Internet Protocol Security) is a technology designed to address IP layer security issues. IPSEC is an IP security protocol standard that uses cryptographic methods to support confidentiality and authentication services, allowing users to selectively use and obtain the desired security services. IPSEC was designed to provide high-quality, interoperable, cryptographically-based security for IPv4 (Internet Protocol version 4) and IPv6 (Internet Protocol version 6) data.

[0003] The basic principle of IPsec is that the communicating parties negotiate an IPsec tunnel, determine the security protocol, encryption and authentication algorithm, and encapsulation mode used for security protection, and then the data traffic requiring secure processing is encrypted and interacted through this tunnel, thereby achieving the effect of secure processing. Security policies associate the data flows to be protected with the IPsec tunnel, that is, they define which protection is applied to which data flows. Globally applied IPsec protection for different data flows is achieved by matching different security policies. The existing implementation principle is: the administrator pre-determines the five-tuple information (source IP address, destination IP address, source port, destination port, protocol number) of each data flow requiring secure processing, models this five-tuple information into different flows of interest, and finally references these flows of interest in different security policies. Thus, the actual data traffic will be matched to the corresponding security policy based on different five-tuples, and finally, encryption and other security processing are performed according to the IPsec tunnel referenced by the policy.

[0004] DVPN (Dymatic Virtual Private Network) is a non-public technology proposed to address the challenges of complex configuration and inconvenience in responding to network topology changes and branch office address changes inherent in traditional tunneling technologies. DVPN employs a centralized control approach, with a central node handling branch node online access, authentication, and public / private network address management. It achieves full network connectivity by transmitting private network routing information through tunnels established between nodes. MGRE (Multipoint Generic Routing Encapsulation) is a DVPN technology based on NHRP (Next Hop Resolution Protocol). MGRE is a point-to-multipoint GRE tunneling technology, with packet encapsulation and decapsulation functions identical to GRE tunnels. MGRE tunnels rely on the NHRP protocol, which dynamically learns the addresses of other nodes.

[0005] MGRE technology itself lacks security, and in practice, IPsec is often used to encrypt GRE packets, leading to the increasingly widespread use of MGRE over IPsec. However, due to the scarcity of IP resources in China, MGRE over IPsec inevitably requires NAT (Network Address Translation) traversal in practical applications. Therefore, it is necessary to address the series of problems encountered during NAT traversal in MGRE over IPsec. Furthermore, IPsec NAT traversal, due to its complex scenarios and diverse configurations, can encounter issues such as IPsec negotiation failure and abnormal data forwarding. Existing solutions address some of the problems encountered in NAT traversal scenarios, but they still cannot resolve the issue of NAT table changes after MGRE over IPsec traversals, leading to negotiation failures between the initiating and responding ends. Summary of the Invention

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

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] In a first aspect, the present invention provides a method for IPsec traversing dynamic NAT, applied to a DVPN network, the DVPN network including a central device, a first branch device, and a second branch device, wherein a first NAT device is configured on the communication link between the first branch device and the central device, and a second NAT device is configured on the communication link between the second branch device and the central device, the method comprising:

[0009] The first branch device and the second branch device respectively establish IPSEC tunnels with the central device. The central device records the address and port information of the first branch device before and after being translated by the first NAT device, and records the address and port information of the second branch device before and after being translated by the second NAT device.

[0010] When the central device receives the address resolution request message for the second branch device sent by the first branch device, it sends a first address resolution response message carrying the address and port information of the second branch device before and after the translation 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 the translation 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 an entry for 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 negotiates Internet Key Exchange (IKE) with the second branch device to establish an IPsec tunnel between them.

[0013] In an optional implementation, the first branch device and the second branch device respectively establish IPsec tunnels with the central device. The central device records the address and port information of the first branch device before and after translation by the first NAT device, and records the address and port information of the second branch device before and after translation by the second NAT device, including:

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

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

[0016] The central device establishes an IPSEC tunnel with the first branch device based on the IKE negotiation message sent by the first NAT device, and records the first branch device's pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address and two post-conversion IKE negotiation port numbers obtained during the IKE negotiation process.

[0017] The second branch device generates an IKE negotiation message requesting the establishment of 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 then performs address and port translation on the IP address and IKE negotiation port number in the IKE negotiation message before sending it to the central device;

[0019] The central device establishes an IPSEC tunnel with the second branch device based on the IKE negotiation message sent by 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 during the IKE negotiation process.

[0020] In an optional implementation, the central device sends a first address resolution response message carrying the address and port information of the second branch device before and after translation 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 being translated by the second NAT device and two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain the first address resolution response message and send it to the first branch device.

[0022] In an optional implementation, the central device sends a second address resolution response message carrying the address and port information of the first branch device before and after translation 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, and adds the IP address of the first branch device after being translated by the first NAT device and two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain the second address resolution response message and send it to the second branch device.

[0024] In an optional implementation, 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 from it the IP address of the first branch device after being translated by the first NAT device, the first translated IKE negotiation port number, and the second translated IKE negotiation port number;

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

[0027] The second branch device generates a second UDP packet based on the IP address of the first branch device after being translated by the first NAT device and the IKE negotiated port number after the second translation, and sends the second UDP packet to the first NAT device through the second NAT device.

[0028] In an optional implementation, 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 from it the IP address of the second branch device after being translated by the second NAT device, the third translated IKE negotiation port number, and the fourth translated 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 after being translated by the second NAT device and the IKE negotiation port number after being translated by the third NAT device, 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;

[0031] The first branch device generates a two-phase negotiation message based on the IP address of the second branch device after being translated by the second NAT device and the IKE negotiation port number after the fourth translation, and sends the two-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 implementation, the method further includes:

[0033] The first branch device periodically generates keep-alive messages and sends the keep-alive messages to the second branch device through its IPSEC tunnel with the second branch device to keep alive the entries in the first NAT device and the second NAT device corresponding to the IKE negotiation port numbers used for the first phase negotiation.

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

[0035] The first branch device periodically generates keep-alive messages and sends these messages to the second branch device through its IPsec tunnel with the second branch device, including:

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

[0037] The first NAT device performs address and port translation on the IP address of the first branch device before it is translated by the first NAT device and the IKE negotiation port number used for the first phase negotiation in the keep-alive message and then sends it 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 being translated by the second NAT device and the IKE negotiation port number after the third translation in the keep-alive message into the IP address before translation 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 implementation, the method further includes:

[0041] After receiving the keep-alive message sent by the first NAT device, the central device obtains the first translated IKE negotiation port number of the first branch device recorded locally based on the tunnel identifier in the keep-alive message, and compares it with the first translated IKE negotiation port number of the first branch device in the keep-alive message. If the two are inconsistent, the central device updates the first translated IKE negotiation port number of the first branch device recorded locally.

[0042] Secondly, the present invention provides a DVPN network, including a central device and multiple branch devices, wherein each branch device is equipped with a NAT device on its communication link with the central device, and the DVPN network is used to implement the method described in any of the foregoing embodiments.

[0043] This invention provides a method for IPsec traversal of dynamic NAT and a DVPN network. The method includes: a first branch device and a second branch device establishing IPsec tunnels with a central device; the central device recording the address and port information of the two branch devices before and after NAT translation; when the central device receives a request from the first branch device to obtain network information of the second branch device, it sends the address and port information of the second branch device before and after NAT translation to the first branch device, and vice versa; the second branch device receives a first address resolution response message and sends a generated UDP message to the first NAT device through the second NAT device, enabling the second NAT device to create an entry for the first branch device to establish a communication link between them; the first branch device receives a second address resolution response message and negotiates an Internet key exchange with the second branch device to establish its IPsec tunnel with the second branch device. This achieves traversal of dynamic NAT in the MGRE over IPsec scenario, ensuring successful negotiation between the initiating and responding ends.

[0044] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

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

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

[0048] Figure 3 This illustration shows one of the flowcharts of the method for traversing dynamic NAT via IPSEC provided in an embodiment of the present invention;

[0049] Figure 4This is a second schematic diagram of the method for traversing dynamic NAT via IPSEC provided in an embodiment of the present invention;

[0050] Figure 5 The third illustration shows a flowchart of the method for traversing dynamic NAT via IPSEC provided in an embodiment of the present invention.

[0051] Icons: 100 - Electronic device; 110 - Processor; 120 - Memory; 130 - Communication module. Detailed Implementation

[0052] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0053] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0054] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0055] Please see Figure 1This is an example diagram of a DVPN network provided in an embodiment of the present invention. The DVPN network includes a central device, namely a Hub, and three branch devices: Branch Device 1 (Spoke1), Branch Device 2 (Spoke2), and Branch Device 3 (Spoke3). Each branch device has a NAT device on its communication link with the central device; specifically, NAT device 1 (NAT1) is installed on the communication link between the central device and Branch Device 1, and NAT device 2 (NAT2) is installed on the communication links between the central device and Branch Devices 2 and 3. It should be noted that the number and connection relationships of the branch devices and NAT devices in the DVPN network can be configured according to actual conditions, and this embodiment of the present invention does not limit this.

[0056] Please see Figure 2 This is a block diagram of an electronic device provided in an embodiment of the present invention. The structure of this electronic device can be used to implement the above-described... Figure 1 The central device, branch device, or NAT device in the system. Electronic device 100 includes a processor 110, a memory 120, and a communication module 130. The components are electrically connected directly or indirectly to each other to realize 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 perform corresponding functions. It can be a general-purpose processor, including CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be a DSP digital signal processor, ASIC application-specific integrated circuit, FPGA off-the-shelf programmable gate array or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

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

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

[0060] Understandable Figure 2 The structure shown is only a schematic diagram of the electronic device 100. The electronic device 100 may also include components that are larger than... Figure 2 The more or fewer components shown, or having the same Figure 2 The different configurations shown. Figure 2 The components shown can be implemented using hardware, software, or a combination thereof.

[0061] The following will be based on the above. Figure 1 As examples, the various steps in the methods provided by the embodiments of the present invention and their corresponding technical effects are introduced. Please refer to... Figure 3 This is a flowchart illustrating a method for traversing dynamic NAT using IPSEC, provided in an embodiment of the present invention.

[0062] In 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 being translated by the first NAT device, and records the address and port information of the second branch device before and after being translated by the second NAT device.

[0063] For ease of understanding, the embodiments of the present invention are described in... Figure 1 In the example where branch device 1 is the first branch device and branch device 2 is the second branch device, the following explanation will focus on a scenario where branch device 1 (the initiating end) requests communication with branch device 2 (the responding end). Before branch device 1 and branch device 2 can communicate, they each need to establish an IPsec tunnel with the central device.

[0064] Branch device 1 sends an IPsec tunnel establishment request to the central device through its corresponding NAT device, NAT device 1. The central device establishes an IPsec tunnel with branch device 1 based on this 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 branch device 1 in the internal network (called the pre-translation address and port information) into the post-translation address and port information of the external network. Therefore, the central device will record the pre-translation address and port information and the post-translation address and port information of branch device 1.

[0065] Similarly, branch device 2 sends an IPsec tunnel establishment request to the central device through its corresponding NAT device, NAT device 2. The central device establishes an IPsec tunnel with branch device 2 based on this request. Since the IPsec tunnel establishment request is sent to the central device through NAT device 2, NAT device 2 will convert the branch device 2's original address and port information in the internal network (called the pre-translation address and port information) into the post-translation address and port information of the external network. Therefore, the central device will record the pre-translation address and port information and the post-translation address and port information of branch device 2.

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

[0067] In step S204, when the central device receives a request from the first branch device to obtain 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 the translation 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 the translation by the first NAT device to the second branch device.

[0068] To facilitate understanding, the above example will be used for further explanation. After branch device 1 and branch device 2 establish IPsec tunnels with the central device, branch device 1 can 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-translation and post-translation address and port information of branch device 2, and sends it to branch device 1 so that branch device 1 can obtain the network information of branch device 2. It can be understood that although the request is sent from branch device 1 to the central device, to ensure communication between branch device 1 and branch device 2, the central device also generates a second address resolution response message based on the pre-translation and post-translation address and port information of branch device 1, and sends it to branch device 2 so that branch device 2 can obtain the network information of branch device 1.

[0070] Understandably, in existing implementations, the central device only sends the address and port information before the translation to the branch device. However, in this embodiment of the invention, the central device not only sends the address and port information before the translation to the branch device, but also sends the address and port information after the NAT device translation to the branch device. This allows the IPSEC tunnel between the first branch device and the second branch device to traverse dynamic NAT.

[0071] In 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] In 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 two branches.

[0073] Understandably, since the first branch device requests network information from the central device for the second branch device, an entry for the second branch device is created in the first NAT device. However, since the second NAT device does not yet have an entry for the first branch device, the communication link between the first and second branch devices is not yet established.

[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 and 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 an entry for the first branch device based on the UDP message, thus establishing a communication link between the first branch device and the second branch device.

[0075] To facilitate understanding, let's continue with the example above. After receiving the second address resolution response message from the central device, branch device 2 generates a UDP packet based on the translated address and port information of branch device 1. This UDP packet is then sent to NAT device 1 via NAT device 2, allowing NAT device 2 to create a NAT entry for branch device 1 based on the UDP packet. This establishes the communication link between branch device 1 and branch device 2. Furthermore, after receiving the first address resolution response message from the central device, branch device 1 negotiates with branch device 2 using IKE to establish an IPsec tunnel. Once the IPsec tunnel between branch device 1 and branch device 2 is successfully established, they can communicate through this tunnel.

[0076] As can be seen from the above steps, the first and second branch devices establish IPsec tunnels with the central device respectively. The central device records the address and port information of these two branch devices before and after NAT translation. When the central device receives a request from the first branch device to obtain the network information of the second branch device, it sends the address and port information of the second branch device before and after NAT translation to the first branch device, and the address and port information of the first branch device before and after NAT translation 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 an entry for the first branch device to connect the communication link between the first and second branch devices. The first branch device receives the second address resolution response message and negotiates Internet key exchange with the second branch device to establish its IPsec tunnel with the second branch device. This achieves traversal of dynamic NAT in the MGRE over IPsec scenario, ensuring successful negotiation between the initiating and responding ends.

[0077] Optionally, for step S202, this embodiment of the invention provides a possible implementation method, please refer to [link to relevant documentation]. Figure 4 .

[0078] Step S202-1: The first branch device generates an IKE negotiation message requesting the establishment of an IPSEC tunnel based on its own IP address and IKE negotiation port number, and sends it 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 translation on the IP address and IKE negotiation port number in the IKE negotiation message before sending it to the central device.

[0080] In step S202-3, the central device establishes an IPSEC tunnel with the first branch device based on the IKE negotiation message sent by the first NAT device, and records the first branch device's pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address and two post-conversion IKE negotiation port numbers obtained during the IKE negotiation process.

[0081] Step S202-4: The second branch device generates an IKE negotiation message requesting the establishment of an IPSEC tunnel based on its own IP address and IKE negotiation port number, and sends it 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 translation on the IP address and IKE negotiation port number in the IKE negotiation message before sending it to the central device.

[0083] In step S202-6, the central device establishes an IPSEC tunnel with the second branch device based on the IKE negotiation message sent by 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 during 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 for the two phases of IPSEC negotiation respectively.

[0085] For ease of understanding, let's continue with the example above. Assume that the address and port information of branch device 1 and branch device 2 before the translation are shown in Table 1 below.

[0086] Table 1

[0087]

[0088] Based on the content of Table 1, the following will describe 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, the following is the process: First, branch device 1 generates an IKE negotiation message requesting the establishment of an IPSEC tunnel based on its own IP address 1.0.0.1, the first IKE negotiation port number before the translation 500 and the second IKE negotiation port number before the translation 4500, as well as the central device's IP address 3.0.0.1 and two IKE negotiation port numbers 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-translation IP address of branch device 1 (1.0.0.1) in the IKE negotiation message to the post-translation IP address (3.0.0.2). It also converts the first pre-translation IKE negotiation port number (500) of branch device 1 to the corresponding post-translation IKE negotiation port number (10001), and the second pre-translation IKE negotiation port number (4500) of branch device 1 to the corresponding post-translation IKE negotiation port number (10002). Finally, it sends the converted IKE negotiation message to the central device. It should be noted that the two post-translation IKE negotiation ports 10001 and 10002 used in this embodiment are for illustrative purposes only and are not intended to impose specific limitations.

[0091] Finally, the central device receives the IKE negotiation message sent by NAT device 1 and establishes an IPsec tunnel with branch device 1. Simultaneously, the central device obtains the pre-translation address and port information of branch device 1 from the IKE negotiation message, namely the pre-translation IP address 1.0.0.1, the first pre-translation IKE negotiation port number 500, and the second pre-translation IKE negotiation port number 4500, as well as the post-translation address and port information of branch device 1, namely the post-translation IP address 3.0.0.2, the first post-translation IKE negotiation port number 10001, and the second post-translation IKE negotiation port number 10002. The central device then records both the pre-translation and post-translation address and port information of branch device 1.

[0092] For steps S202-4 to S202-6, 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 the establishment of an IPSEC tunnel based on its own 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, as well as the central device's IP address 3.0.0.1 and two IKE negotiation port numbers 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-translation IP address of branch device 2, i.e., 2.0.0.1, to the post-translation IP address, i.e., 4.0.0.2, converts the first pre-translation IKE negotiation port number, 500, of branch device 2 to the corresponding post-translation IKE negotiation port number, i.e., 10001, and converts the second pre-translation IKE negotiation port number, 4500, of branch device 2 to the corresponding post-translation IKE negotiation port number, i.e., 10002, before sending 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. Simultaneously, the central device obtains the pre-translation address and port information of branch device 2 from this IKE negotiation message, namely, 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, as well as the post-translation address and port information of branch device 2, namely, 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. The central device then records both the pre-translation and post-translation address and port information of branch device 2.

[0095] After the central device establishes IPSEC tunnels with branch device 1 and branch device 2 respectively, the converted address and 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] This can be understood as the central device recording the address and port information of the first and second branch devices before and after the conversion, so that when the two 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, this embodiment of the invention provides a possible implementation method, please refer to [link to relevant documentation]. 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 being translated by the second NAT device and the two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain the first address resolution response message and send it to the first branch device.

[0101] Understandably, in the existing implementation, 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 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 this embodiment, the second branch device receives packets through the second NAT device. Therefore, the first branch device also needs to obtain the translated address and port information of the second branch device to ensure that the packets it sends to the second branch device can be correctly forwarded to the second branch device through the second NAT device. Therefore, the central device in this embodiment utilizes the extended fields of the NHRP protocol message to add the IP address of the second branch device after translation by the second NAT device and two translated IKE negotiation port numbers to the packets sent to the first branch device, so that the first branch device can obtain the translated address and port information of the second branch device.

[0103] To facilitate understanding, the above example will continue. The central device generates a message based on the branch device 2's own IP address, 2.0.0.1, and adds the branch device 2's IP address (4.0.0.2 after NAT device 2 translation) and the two translated IKE negotiation port numbers (10001 and 10002) to the extended field of the NHRP protocol message, thus obtaining the first address resolution response message. The central device then sends the first address resolution response message to branch device 1, so that branch device 1 can obtain the translated address and port information of branch device 2, that is, obtain branch device 2's translated IP address 4.0.0.2 and the two translated IKE negotiation port numbers (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, this embodiment of the invention provides a possible implementation method, please refer to the following: Figure 5 .

[0105] In step S204-2, the central device generates an NHRP protocol message based on the IP address of the first branch device, and adds the IP address of the first branch device after being translated by the first NAT device and the two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain a second address resolution response message and send it to the second branch device.

[0106] It is understandable that, in addition to the first branch device acting as the initiating end needing to obtain the translated address and port information of the second branch device, the second branch device acting as the responding end also needs to obtain the translated address and port information of the first branch device so that the two branch devices 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 existing implementations, 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 this embodiment, the first branch device receives messages through the first NAT device. Therefore, the second branch device also needs to obtain the translated address and port information of the first branch device to ensure that the messages it sends to the first branch device can be correctly forwarded to the first branch device through the first NAT device. Therefore, in this embodiment, the central device uses the extended fields of the NHRP message protocol to add the IP address of the first branch device after translation by the first NAT device and two translated IKE negotiation port numbers to the message sent to the second branch device, so that the second branch device can obtain the translated address and port information of the first branch device.

[0108] To facilitate understanding, the above example will continue. The central device generates a message based on the branch device 1's own IP address, 1.0.0.1, and adds the branch device 1's IP address translated by NAT device 1 (3.0.0.2) and the two translated IKE negotiation port numbers (10001 and 10002) to the extended field of the NHRP protocol message, thus obtaining a second address resolution response message. The central device then sends the second address resolution response message to branch device 2, enabling branch device 2 to obtain the translated address and port information of branch device 1, i.e., the translated IP address of branch device 1 (3.0.0.2) and the two translated IKE negotiation port numbers (10001 and 10002).

[0109] Optionally, for step S206, this embodiment of the invention provides a possible implementation method, please refer to the following: Figure 5 .

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

[0111] In step S206-2, the second branch device generates a first UDP packet based on the IP address of the first branch device after being translated by the first NAT device and the first IKE negotiated port number after the first translation, and sends the first UDP packet to the first NAT device through the second NAT device.

[0112] In step S206-3, the second branch device generates a second UDP packet based on the IP address of the first branch device after being translated by the first NAT device and the port number negotiated by the second IKE after translation, and sends the second UDP packet to the first NAT device through the second NAT device.

[0113] To facilitate understanding, let's continue with the example above. Since branch device 1 requested network information from the central device for branch device 2, an entry for branch device 2 is created in NAT device 1. However, NAT device 2 does not yet have an entry for branch device 1, so the communication link between branch device 1 and branch device 2 is not yet established. Therefore, after receiving the second address resolution response message, branch device 2 will obtain the translated IP address of branch device 1 (3.0.0.2), the first translated IKE negotiation port number (10001), and the second translated IKE negotiation port number (10002).

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

[0115] Next, branch device 2 will generate a second UDP packet based on the translated IP address 3.0.0.2 of branch device 1 and the second translated IKE negotiation port number 10002, and send the second UDP packet to NAT device 1 through NAT device 2, so that NAT device 2 can create a second entry for branch device 1 based on the second UDP packet, that is, an entry with IP address 3.0.0.2 and port number 10002.

[0116] This can be understood as follows: after NAT device 2 creates an entry for branch device 1, NAT device 2 can process packets sent from branch device 1 to branch device 2 based on that entry. Similarly, if NAT device 1 has an entry for branch device 2, then NAT device 1 can process packets sent from branch device 2 to branch device 1 based on that entry. Thus, the communication link between branch device 1 and branch device 2 is established.

[0117] Optionally, for step S208, this embodiment of the invention provides a possible implementation method, please refer to the following: Figure 5 .

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

[0119] In step S208-2, the first branch device generates a phase one negotiation message based on the IP address of the second branch device after being translated by the second NAT device and the IKE negotiation port number after the third translation, 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 two-phase negotiation message based on the IP address of the second branch device after being translated by the second NAT device and the IKE negotiation port number after the fourth translation, and sends the two-phase negotiation message to the second branch device through the first NAT device to negotiate IPSEC SA with the second branch device.

[0121] To facilitate understanding, the above example will be used for illustration. First, after receiving the first address resolution response message, branch device 1 will obtain the translated IP address of branch device 2, which is 4.0.0.2, the third translated IKE negotiation port number, which is 10001, and the fourth translated IKE negotiation port number, which is 10002.

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

[0123] The IKE negotiation process between branch device 1 and branch device 2 can be understood as consisting of two phases: the first phase involves negotiating the IKE SA via port 500 and a phase one negotiation message, defining the key for communication between the two ends; the second phase involves negotiating the IPsec SA via port 4500 and a phase two negotiation message, defining the encryption policy for protecting data packets at the IP layer. After completing these two phases of negotiation, branch device 1 and branch device 2 successfully establish an IPsec tunnel.

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

[0125] In step S210, the first branch device periodically generates keep-alive packets and sends them to the second branch device through its IPSEC tunnel with the second branch device to keep alive the entries in the first NAT device and the second NAT device corresponding to the IKE negotiation port numbers used for the first phase negotiation.

[0126] Understandably, in a DVPN network, branch devices periodically send registration messages to the central device via port 4500, the IKE negotiation port used for the second phase of negotiation. Therefore, this registration message can serve as a keep-alive message for port 4500, ensuring that the entry corresponding to port 4500 in the NAT device does not age out. However, port 500, the IKE negotiation port used for the first phase of negotiation, is not used again for a long period after its initial use in the IKE negotiation process. Therefore, this embodiment of the invention also provides a keep-alive mechanism to keep port 500 active.

[0127] To facilitate understanding, let's continue with the example above. Branch device 1 periodically generates keep-alive packets for port number 500 and sends them to branch device 2 through its IPsec tunnel with branch device 2. Since the packets sent from branch device 1 to branch device 2 pass through NAT devices 1 and NAT devices 2, the periodic sending of keep-alive packets by branch device 1 ensures that the entry corresponding to port number 500 in NAT devices 1 and NAT devices 2 remains valid. This prevents the entry from aging, thus achieving the effect of keeping port number 500 alive.

[0128] Understandably, the keep-alive mechanism on port 500 is crucial for the IPsec renegotiation between the initiating and responding ends. To ensure the security of communication between the initiating and responding ends, they will renegotiate IKE after a period of time, and IKE negotiations are initiated by sending packets from port 500. Therefore, keeping port 500 alive ensures that the initiating and responding ends can successfully renegotiate, thereby increasing the success rate of the negotiation between the two ends and enabling MGRE over IPsec traversal of dynamic NAT.

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

[0130] Step S210-1: The first branch device periodically generates a packet according to the ISAKMP protocol, based on its own IP address and the IKE negotiation port number used for the first phase negotiation, the second branch device's own IP address and the IKE negotiation port number used for the first phase negotiation, and the tunnel identifier of its IPSEC tunnel with the second branch device. The packet is then encrypted using IKE SA to obtain a keep-alive packet and sent to the first NAT device.

[0131] Step S210-2: The first NAT device sends the IP address of the first branch device before it is translated by the first NAT device and the IKE negotiation port number used for the first phase negotiation in the keepalive message to the central device after address and port translation.

[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 being translated by the second NAT device and the IKE negotiation port number after the third translation in the keep-alive message into the original IP address 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 connect to multiple branch devices, and these branch devices have the same translated IP address, each IPsec tunnel has a tunnel identifier, i.e., a cookie value, to distinguish different IPsec tunnels. For example, in Figure 1 In the DVPN network shown, assuming that branch device 1 has established IPSEC tunnels with both branch device 2 and branch device 3, since branch device 2 and branch device 3 are both connected to NAT device 2, their IP addresses after translation are the same. Therefore, the IPSEC tunnels between branch device 1 and branch device 2 and between branch device 1 and branch device 3 can be distinguished by the cookie value.

[0135] To facilitate understanding, let's continue with the example above. First, branch device 1 periodically generates packets according to the ISAKMP (Internet Security Association and Key Management Protocol) protocol. This is 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 (cookie value) of its IPSEC tunnel with branch device 2. Then, it encrypts these packets using the key (IKE SA) from the first phase of the IKE negotiation between the two devices, thus obtaining a keep-alive packet and sending it to NAT device 1. It's understandable that encrypting the packets improves the security of the keep-alive packet transmission.

[0136] Then, NAT device 1 translates the pre-translation IP address 1.0.0.1 of branch device 1 in the keepalive message to the post-translation IP address 3.0.0.2, and translates the IKE negotiation port number 500 used by branch device 1 for the first phase negotiation to the first post-translation IKE negotiation port number 10001 before sending it to the central device. Next, the central device receives the keepalive message sent by NAT device 1 and forwards it to NAT device 2. Finally, NAT device 2 receives the keepalive message sent by the central device, translates the post-translation IP address 4.0.0.2 of branch device 2 to the pre-translation IP address 2.0.0.1, and translates the third post-translation IKE negotiation port number 10001 of branch device 2 to the IKE negotiation port number 500 used for the first phase negotiation before sending it to branch device 2, so that branch device 2 receives the keepalive message.

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

[0138] In step S212, after receiving the keep-alive message sent by the first NAT device, the central device obtains the first translated IKE negotiation port number of the first branch device recorded locally based on the tunnel identifier in the keep-alive message, and compares it with the first translated IKE negotiation port number of the first branch device in the keep-alive message. If the two are inconsistent, the central device updates the first translated IKE negotiation port number of the first branch device recorded locally.

[0139] It is understood that the keep-alive mechanism for port number 500 provided in this embodiment of the invention can also ensure that the central device can update the port number in a timely manner when the NAT device malfunctions.

[0140] To facilitate understanding, the above example will continue. After receiving the keep-alive message from NAT device 1, the central device retrieves the locally recorded first translated IKE negotiation port number of branch device 1 based on the tunnel identifier (cookie value) in the keep-alive message, and compares it with the first translated IKE negotiation port number of branch device 1 in the keep-alive message. If they do not match, the central device updates the locally recorded first translated IKE negotiation port number of branch device 1 to record the latest first translated IKE negotiation port number of branch device 1. In this way, when NAT device 1 malfunctions, the central device can promptly obtain the translated IKE negotiation port number corresponding to port number 500 reassigned to branch device 1 by NAT device 1, thereby improving the accuracy of the translated IKE negotiation port number recorded by the central device.

[0141] This invention also provides a DVPN network, including a central device and multiple branch devices. Each branch device has a NAT device configured on its communication link with the central device. The DVPN network is used to implement the IPSEC traversal dynamic NAT method disclosed in this invention.

[0142] In summary, NAT traversal is frequently required when deploying MGRE over IPSEC scenarios. Whether it's static or dynamic NAT, whether port translation is needed, and whether the port translation is static or dynamic are largely irrelevant to the user, and in most cases, users cannot change the NAT rules. However, the IPSEC traversal method for dynamic NAT provided in this invention eliminates the need for users to concern themselves with NAT rules. This method can be directly applied to full cone, restricted cone, and port restricted cone NAT scenarios, thereby significantly expanding the deployment scenarios and application scope of MGRE over IPSEC.

[0143] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

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

[0145] If the aforementioned functions are implemented as software functional 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 this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0146] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for traversing dynamic NAT using IPsec, characterized in that, The method is applied to a DVPN network, which includes a central device, a first branch device, and a second branch device. A first NAT device is configured on the communication link between the first branch device and the central device, and a second NAT device is configured on the 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 IPSEC tunnels with the central device. The central device records the address and port information of the first branch device before and after being translated by the first NAT device, and records the address and port information of the second branch device before and after being translated by the second NAT device. When the central device receives the address resolution request message for the second branch device sent by the first branch device, it sends a first address resolution response message carrying the address and port information of the second branch device before and after the translation 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 the translation 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 an entry for 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 negotiates Internet Key Exchange (IKE) with the second branch device to establish an IPsec tunnel between them.

2. The method according to claim 1, characterized in that, The first branch device and the second branch device respectively establish IPsec tunnels with the central device. The central device records the address and port information of the first branch device before and after translation by the first NAT device, and records the address and port information of the second branch device before and after translation by the second NAT device, including: The first branch device generates an IKE negotiation message requesting the establishment of an IPSEC tunnel based on its own IP address and IKE negotiation port number and sends it to the first NAT device; The first NAT device receives the IKE negotiation message sent by the first branch device, and then performs address and port translation on the IP address and IKE negotiation port number in the IKE negotiation message before sending it to the central device; The central device establishes an IPSEC tunnel with the first branch device based on the IKE negotiation message sent by the first NAT device, and records the first branch device's pre-conversion IP address, two pre-conversion IKE negotiation port numbers, and post-conversion IP address and two post-conversion IKE negotiation port numbers obtained during the IKE negotiation process. The second branch device generates an IKE negotiation message requesting the establishment of 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 then performs address and port translation on the IP address and IKE negotiation port number in the IKE negotiation message before sending it to the central device; The central device establishes an IPSEC tunnel with the second branch device based on the IKE negotiation message sent by 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 during 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 translation 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 being translated by the second NAT device and two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain the first address resolution response message and send 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 translation 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, and adds the IP address of the first branch device after being translated by the first NAT device and two translated IKE negotiation port numbers to the extended field of the NHRP protocol message to obtain the second address resolution response message and send 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 from it the IP address of the first branch device after being translated by the first NAT device, the first translated IKE negotiation port number, and the second translated IKE negotiation port number; The second branch device generates a first UDP packet based on the IP address of the first branch device after being translated by the first NAT device and the first IKE negotiation port number after the translation, and sends the first UDP packet to the first NAT device through the second NAT device; The second branch device generates a second UDP packet based on the IP address of the first branch device after being translated by the first NAT device and the IKE negotiated port number after the second translation, and sends the second UDP packet 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 from it the IP address of the second branch device after being translated by the second NAT device, the third translated IKE negotiation port number, and the fourth translated IKE negotiation port number; The first branch device generates a phase one negotiation message based on the IP address of the second branch device after being translated by the second NAT device and the IKE negotiation port number after being translated by the third NAT device, 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; The first branch device generates a two-phase negotiation message based on the IP address of the second branch device after being translated by the second NAT device and the IKE negotiation port number after the fourth translation, and sends the two-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 includes: The first branch device periodically generates keep-alive messages and sends the keep-alive messages to the second branch device through its IPSEC tunnel with the second branch device to keep alive the entries in the first NAT device and the second NAT device corresponding to the IKE negotiation port numbers used for the first phase negotiation.

8. The method according to claim 7, characterized in that, Each of the aforementioned IPSEC tunnels has a tunnel identifier; The first branch device periodically generates keep-alive messages and sends these messages to the second branch device through its IPsec tunnel with the second branch device, including: The first branch device periodically generates a packet according to the ISAKMP protocol, based on its own IP address and the IKE negotiation port number used for the first phase negotiation, the second branch device's own IP address and the IKE negotiation port number used for the first phase negotiation, and the tunnel identifier of its IPSEC tunnel with the second branch device, and encrypts the packet using the IKE SA to obtain the keep-alive packet and sends it to the first NAT device. The first NAT device performs address and port translation on the IP address of the first branch device before it is translated by the first NAT device and the IKE negotiation port number used for the first phase negotiation in the keep-alive message and then sends it 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 being translated by the second NAT device and the IKE negotiation port number after the third translation in the keep-alive message into the IP address before translation 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 includes: After receiving the keep-alive message sent by the first NAT device, the central device obtains the first translated IKE negotiation port number of the first branch device recorded locally based on the tunnel identifier in the keep-alive message, and compares it with the first translated IKE negotiation port number of the first branch device in the keep-alive message. If the two are inconsistent, the central device updates the first translated IKE negotiation port number of the first branch device recorded locally.

10. A DVPN network, characterized in that, It includes a central device and multiple branch devices, and each of the branch devices is equipped with a NAT device on its communication link with the central device. The DVPN network is used to implement the method of any one of claims 1 to 9.

Images