Analysis of Dynamic Multi-Point VPN

Source: Internet
Author: User
Tags hmac

A Brief Analysis of Dynamic Multi-Point VPN using IPSec tunnel for secure data transmission over the Internet is the main solution for communication between Headquarters and branches of the company. Its commercial value will not be mentioned here, and it will take a long time to find a document. The IPSec network topology can be a star structure (hub-and-spoke) or a mesh structure (full mesh ). In practical applications, data traffic is mainly distributed between branches and centers, and the traffic distribution between branches is small. Therefore, the star structure (hub −and −spoke) is usually the most commonly used, and it is more economical. Because the hub-and-spoke structure uses fewer point-to-point links than the full mesh structure, the line cost can be reduced. In a star topology, no additional communication fee is required for the connectivity between branches and branches (spoke −to −spoke. However, in a star structure, branch-to-branch communication must span the center, which consumes resources in the center and introduces latency. Especially when using IPSec Encryption, the center needs to decrypt the data transmission branch tunnel and re-encrypt the received data in the branch tunnel. Another case is that the two branches of communication are in the same city and the center is in another city, which introduces unnecessary latency. When the scale of the star IPSec network (hub-and-spoke) continues to expand, the configuration of the Traditional VPN becomes more complex and is not easy to maintain and troubleshoot. Therefore, dynamic routing of IP data packets makes sense. However, there is a basic problem between the IPSec tunnel and the dynamic routing protocol. The Dynamic Routing Protocol relies on multicast or broadcast packets for route update. the IPSec tunnel does not support multicast or broadcast packet encryption. The concept of dynamic multi-point VPN (DMVPN) is introduced here. Two protocols are introduced: GRE and nhrp gre: Universal Routing Encapsulation. Defined by IETF in RFC 2784. It is a protocol that encapsulates any other network layer protocol on any network layer protocol. GRE encapsulates the payload in a GRE package, and then encapsulates the GRE package for forwarding based on the actual transfer protocol. (I think GRE is similar to the Trojan shell. Ipv_^) IPSec does not support broadcast and Multicast Transmission. However, GRE can effectively carry broadcast and multicast packets to the peer end, and GRE tunnel packets are unicast. This means that the GRE tunnel data packets can be encrypted by IPSec, that is, GRE Over IPSec. The GRE tunnel and IPSec Encryption are used to update the route table on the routers at both ends of the encrypted tunnel using dynamic routing protocol. The subnet learned from the tunnel peer will contain the IP address of the Peer tunnel in the route table entry as the next hop address to reach the peer network. In this way, the network at any end of the tunnel changes, and the other end dynamically learns this change, and maintains network connectivity without changing the configuration of the router. IPSec uses the access control list (ACL) to match the data streams of interest. When a data packet matches the defined ACL, the IPSec encrypted tunnel is created. When GRE Over IPSec is used, the GRE tunnel configuration includes the GRE tunnel peer address, which is also the peer address of the IPSec tunnel. Therefore, there is no need to define a matching ACL for IPSec separately. By binding the GRE tunnel to the IPSec, once the GRE tunnel is established, the IPSec Encryption is immediately triggered. When using IPSec to encrypt the GRE packet, you can configure IPSec as the transmission mode, because GRE has encapsulated the original packet as a unicast IP packet, and there is no need for IPSec to encapsulate another packet header. The GRE feature allows IPSec to run dynamic protocols in a fashionable manner. So far, the history of IPSec does not support dynamic routing has changed, and the "multi-point" in DMVPN is flattened. Next, let's take a look at how "dynamic" features are introduced? GRE establishes a tunnel, and IPSec completes the encrypted part of the VPN network. To create a GRE tunnel, one end of the tunnel must know the IP address of the other end and must be able to route on the Internet. This requires that the center and all branch routers have static public IP addresses. However, it is very expensive to apply for a static IP address from the ISP. Generally, to save address resources and improve the effective utilization, the ISP provides dynamic IP addresses through the DHCP service for both ADSL and Direct cable access. (Note: address shortage caused by IPv4 bottlenecks. IPv6 does not have this problem. It claims that each grain of sand on the earth can be divided into IP addresses. In a strong tone, it is clear that GRE + IPSec needs to clearly know the IP addresses at both ends of the tunnel, the IP address of the branch router's Internet interface is dynamically allocated by its local ISP, And the IP address of each incoming network is different. The GRE tunnel cannot be established, so the VPN still cannot work. In this way, when NHRP caught everyone's appetite, it made a debut in the eyes of the market and gave it some applause. It's just like ....... NHRP: Next Hop Resolution Protocol. Defined by IETF in RFC 2332. It is used to solve the problem of how the source node (host or router) on the non-broadcast Multi-Channel Access (NBMA) network obtains the "Next Hop" Internet network layer address and the NBMA subnet address to reach the target node. Next let's take a look at how NHRP solves the static IP address problem, and let the VPN "dynamic": 1. Branch to center (Spoke −to −hub) the central Router does not have any GRE or IPSec configuration information about the branch in the DMVPN network created through the dynamic tunnel, on the branch router, the GRE tunnel must be configured based on the public IP address of the central router and the NHRP protocol. When the branch router is powered on, the ISP obtains the IP address through DHCP and automatically establishes an IPSec-encrypted GRE tunnel, register your own Internet port IP address (which seems to have rebounded) with the central router through NHRP ). There are three reasons for this: 1. Because the IP address of the outer port of the branch router is automatically obtained, the IP address may be different each time it goes online, therefore, the central router cannot be configured based on the address information. 2. The central Router does not have to configure GRE or IPSec information for all branches, which greatly simplifies the configuration of the central router. All relevant information can be automatically obtained through NHRP. (That is, the branches report their respective features to the center) 3. When the DMVPN network is expanded, you do not need to change the configurations of the center router and other branch routers. Through the dynamic routing protocol, the new branch router is automatically registered to the central router. In this way, all other branch routers can learn the new route, and the new branch routers can also learn the route information to all other routers until convergence. (The central router is like the ospf dr) 2. The dynamic tunnel from the branch to the branch (Spoke −to Spoke) is established in the DMVPN network, and the branch to the center (Spoke −to −hub) once the tunnel is established, the continuous tunnel does not need to be configured between the branches. When a branch needs to transmit data packets to another branch, it uses NHRP to dynamically obtain the IP address of the target branch. In this process, the central router acts as the NHRP server, responds to the NHRP request, and provides the public network address of the target branch to the source branch. Therefore, the two branches dynamically establish an IPSec tunnel through the mGRE port for data transmission. The tunnel will be automatically removed after the predefined period. In a DMVPN network, the Spoke-to-Hub tunnel continues to exist once it is established, and there is no continuous tunnel between branches. In this way, after the router is initialized, the central router will advertise the accessible routes of the subnets of other branches to the branch router through a continuous tunnel. At this point, it seems that the problem of "multiple points" and "dynamic" has been solved, and DMVPN can work normally, right ?! None! Currently, the "Next Hop" address in the route table of the branch router to the subnet of another branch is still the tunnel port address of the central router, rather than the tunnel port address of the other branch router. In this way, the data transmission between the Branch and the branch still passes through the central router. To solve this problem, the next hop address must be the tunnel port address of the branch router, rather than the address of the central router. In the same distance vector routing protocol (RIP) or OSPF, the horizontal split (split horizon) function is usually implemented to prevent route information from being sent back to its source port, to avoid the generation of routing loops on neighboring routers. If you are running the RIP or OSPF protocol on a DMVPN network, you must disable the Horizontal split (split horizon) function. Otherwise, the branch router cannot learn the route to the subnet of another branch. For RIP, no split horizon is a success, because when RIP sends the route to the routing information source port, its "Next Hop" address is not changed, it is still the original address (that is, the target address ). But when it sends the route information to the source port of the route information, the next hop address is changed to the port address. Therefore, you must disable this feature. (VPN is a private protocol of CISCO. the IOS command for disabling this feature is no ip next − hop − self VPN ). OSPF is a link-State routing protocol, which does not have the Horizontal split (split horizon) problem. However, when configuring the OSPF network type, you should configure it as a broadcast type instead of a point-to-multiple-point type. Otherwise, the above problems will still occur. In addition, you must configure the central router (Hub) of the DMVPN as the specified router (DR) of OSPF) higher OSPF priority. Finally, the overall solution of DMVPN is summarized through the combination of Multi-Point GRE (mGRE) and Next Hop Resolution Protocol (NHRP) and IPSec. In the DMVPN solution, IPSec is used to implement encryption, GRE or multi-point GRE (mGRE) is used to establish a tunnel, and NHRP is used to solve the dynamic address problem of the branch node. DMVPN only requires the central node to apply for a static public IP address. (If DNS is used, can the central node be dynamic ?) The GRE tunnel supports the transmission of multicast or broadcast (multicast/broadcast) IP packets within the tunnel. Therefore, DMVPN supports running Dynamic Routing Protocols over IPSec and mGRE tunnels. It should be noted that NHRP must be configured as dynamic multicast ing. In this way, when the branch router registers the unicast ing address on the NHRP server (Central router, NHRP creates a multicast/broadcast (multicast/broadcast) ing for this branch router at the same time. Cisco dmvpn configuration instance: Configure r1 # sh ruhostname r1 on the HUB router! Crypto isakmp policy 10 encr 3 desauthentication pre-sharegroup 2 crypto isakmp key cisco1234 address 0.0.0.0 0.0.0.0! Crypto ipsec transform-set ccie esp-3des esp-sha-hmac mode transport! Crypto ipsec profile ciscoset transform-set ccie! Interface Tunnel0ip address 192.168.1.1 255.255.255.0no ip redirectsno ip next-hop-self VPN 100ip nhrp authentication ciscoip nhrp map multicast dynamicip nhrp network-id duplicate no ip split-horizon VPN 100 tunnel source Serial0/0 tunnel mode gre multipointtunnel key 10000 tunnel protection ipsec profile cisco! Interface Loopback0ip address 10.1.1.1 255.255.255.0! Interface Serial0/0ip address 173.16.1.1 255.255.255.0! Router VPN 100 network 10.0.0.0network 192.168.1.0no auto-summaryip route 0.0.0.0 0.0.0.0 173.16.1.2 configure the Spoke router r2 # sh runhostname r2! Crypto isakmp policy 10 encr 3 desauthentication pre-sharegroup 2 crypto isakmp key cisco1234 address 0.0.0.0 0.0.0.0! Crypto ipsec transform-set ccie esp-3des esp-sha-hmac mode transport! Crypto ipsec profile ciscoset transform-set ccie! Interface Tunnel0ip address 192.168.1.2 Protocol ip redirectsip nhrp authentication ciscoip nhrp map multicast protocol nhrp map 192.168.1.1 protocol nhrp network-id protocol ip nhrp ISP protocol source Serial0/0 tunnel mode gre multipointtunnel key 10000 tunnel protection ipsec profile cisco! Interface Loopback0ip address 10.2.2.1 255.255.255.0! Interface Serial0/0ip address 173.16.2.1 255.255.255.0! Router VPN 100 network 10.0.0.0network 192.168.1.0no auto-summaryip route 0.0.0.0 0.0.0.0 173.16.2.2 configure the Spoke router r3 # sh runhostname r3! Crypto isakmp policy 10 encr 3 desauthentication pre-sharegroup 2 crypto isakmp key cisco1234 address 0.0.0.0 0.0.0.0! Crypto ipsec transform-set ccie esp-3des esp-sha-hmac mode transport! Crypto ipsec profile ciscoset transform-set ccie! Interface Tunnel0ip address 192.168.1.3 Protocol ip redirectsip nhrp authentication ciscoip nhrp map multicast protocol nhrp map 192.168.1.1 protocol nhrp network-id protocol ip nhrp healthcare protocol source FastEthernet0/0 tunnel mode gre multipointtunnel key 10000 tunnel proteipsec profile cisco! Interface Loopback0ip address 10.3.3.1 255.255.255.0! Interface FastEthernet0/0ip address 173.16.3.1 255.255.255.0duplex autospeed auto! Router VPN 100 network 10.0.0.0network 192.168.1.0no auto-summary! Ip route 0.0.0.0 0.0.0.0 173.16.3.2

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.