{"id":11668,"date":"2023-02-22T11:21:41","date_gmt":"2023-02-22T14:21:41","guid":{"rendered":"https:\/\/made4it.com.br\/tunnel-gre-ipsec-between-cisco-ios-and-huawei-ne40\/"},"modified":"2023-03-08T10:40:22","modified_gmt":"2023-03-08T13:40:22","slug":"tunnel-gre-ipsec-between-cisco-ios-and-huawei-ne40","status":"publish","type":"post","link":"https:\/\/made4it.com.br\/en\/tunnel-gre-ipsec-between-cisco-ios-and-huawei-ne40\/","title":{"rendered":"GRE + IPSec tunnel between Cisco IOS and Huawei NE40"},"content":{"rendered":"\n \n\n

In this post we will discuss a very common (and little documented) scenario, which is to use a GRE tunnel secured with IPSec between a Cisco IOS ASR1002 router and a Huawei NE40 router.<\/p>\n \n\n

The topology for this example is described below. It has been kept simple so that we can discuss the details of GRE+IPSEC without getting into the rest of the network.<\/p>\n \n\n

In it we have the Cisco router with public IP address 198.51.100.2 and the Huawei NE40 router with public IP 203.0.113.66. Both are connected to the Internet, and with connectivity to each other. We need to establish a GRE tunnel between the routers and secure it through IPSec in tunnel mode. The tunnel addressing is 172.31.31.0\/30.<\/p>\n \n\n \n\n

\"\"<\/a><\/figure>\n\n

<\/p>\n\n \n\n

In the next lines below we will talk about GRE and IPSec. The objective is not to completely detail these protocols, but to give an overview and, mainly, a basis for the rest of the article. Don’t be hasty, there is very relevant information in there.<\/p>\n \n\n

\n GRE<\/strong>\n <\/p>\n \n\n

Generic Routing Encapsulation (GRE) is a tunneling protocol that can encapsulate a variety of network protocols (eg ATM, IPX, IPv6 and even IPv4) within IPv4 packets. These packets can then be transmitted over common IPv4 networks (eg Internet).<\/p>\n \n\n

Some GRE use cases:
interconnect disconnected internal networks
interconnect isolated IPv6 networks via IPv4 networks
establishing Head Office x Branch Office communication via the Internet
mitigation links
with VPNs when routing protocols are required<\/p>\n \n\n

\n
\n IPSEC<\/strong>\n <\/p>\n \n\n

IPSec is a security framework developed by the IETF that seeks to solve security problems that the IPv4 protocol failed to address, such as encryption, data integrity, source validation, and anti-replay.
IPSec is actually not a single protocol, but a combination of protocols and algorithms. The main ones are IKEv1, IKEv2, ESP and AH.<\/p>\n \n\n

IPSec is widely used in VPNs, both remote-access and site-to-site.<\/p>\n \n\n

In the life cycle of a tunnel, we have 5 well-defined stages:<\/p>\n \n\n

    \n \n\n
  1. Definition of Interesting Traffic<\/strong>
    The interesting traffic is the trigger that causes the tunnel to be established. The router or firewall, upon noticing interesting traffic, initiates the next steps of IPSec negotiation.
    Interesting traffic is usually configured in the form of ACLs, or traffic policies.

    <\/li>\n \n\n
  2. IKE phase 1<\/strong>
    In phase 1 the protocol establishes a secure communication channel with the remote peer. Once this secure channel is established, the phase 2 message exchanges are allowed.
    It is in phase 1 that peers are protected, authenticated, and ISAKMP policies are compared (and need to match). There are two modes, main and aggressive.

    Terms you will see about phase 1: ike, isakmp, DH group, pre-shared-key, integrity, isakmp policy

    <\/li>\n \n\n
  3. IKE phase 2<\/strong>
    In this phase, with the secure tunnel already established in phase 1, we can negotiate what we call IPSec SAs, which are nothing more than dynamically negotiated “contracts” for the type of traffic that will be protected by the IPSec tunnel. An example might be “I will protect traffic from the network 192.168.1.0\/24 when the destination is 192.168.2.0\/24 using encryption algorithm X and authentication algorithm Y”, and the remote peer makes the rule in the opposite direction.

    Another function of phase 2 is to maintain SAs, as well as expire keys and sessions if some parameter is reached (e.g. expire SAs and trade new ones every x hours, or every N kilobytes).

    Terms we will see about phase 2: ipsec, ipsec sa, crypto acl, transform set, mode tunnel, authentication, encryption, ipsec policy

    <\/li>\n \n\n
  4. Data Transfer<\/strong>
    At this stage is the data transfer itself. Once the interesting traffic arrives at the router, and phases 1 and 2 are complete, the packets are sent according to the contracts established in IPSec SA, and are transmitted to the remote peer.

    <\/li>\n \n\n
  5. Tunnel Closure<\/strong>
    Tunnel closure happens by manual process, or when some IPSec parameter expires or reaches its limit. In this case, all keys are dropped, contracts are broken, and if traffic needs to be forwarded, a new IPSec tunnel needs to be established.<\/li>\n \n\n <\/ol>\n \n\n

    For more details on GRE and IPSEC, please refer to the references cited at the end of the article.<\/p>\n \n\n

    \n \n <\/p>\n \n\n

    \n The GRE and IPSEC configurations agreed upon by the parties<\/strong>\n <\/p>\n \n\n

    The example below is how VPN information is agreed upon. These are usually forms that are filled out with information about the tunnel.<\/p>\n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n \n \n\n
    \n \n\n

    \n VPN Device<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Site A VPN Device<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Site B VPN Device<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n\n

    \n VPN Peer IP Address *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 198.51.100.2<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 203.0.113.66<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n\n

    \n Device *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Cisco ASR 1004<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Huawei NE40-M2K<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n\n

    \n Version *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n V3.0.6<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n <COOL_VERSEO><\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n \n \n <\/td>\n \n\n <\/tr>\n \n\n
    \n \n\n

    \n Tunnel Properties<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Site A VPN Device<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Site B VPN Device<\/b>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Phase 1<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Authentication Method<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n <Pre-Shared Key><\/span>\n <\/p>\n \n\n

    \n APasswordWellS3gur@<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n <Pre-Shared Key><\/span>\n <\/p>\n \n\n

    \n APasswordWellS3gur@<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n IKE version<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n IKEv2<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n IKEv2<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Diffie-Hellman Group<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n group 14<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n group 14<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Encryption Algorithm *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n AES 256<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n AES 256<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Hashing Algorithm *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n SHA-1<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n SHA-1<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Main or Aggressive Mode *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Main mode<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Main mode<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n SA Lifetime * (for renegotiation) with no kbytes rekeying<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 86400 seconds<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 86400 seconds<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Phase 2<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Encapsulation * (ESP or AH)<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n ESP<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n ESP<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Encryption Algorithm *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n AES 256<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n AES 256<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Authentication Algorithm *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n SHA-1<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n SHA-1<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Perfect Forward Secrecy for rekeying *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Disabled<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Disabled<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Diffie-Hellman Group *<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n group 14<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n group 14<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n SA Lifetime * (for renegotiation) ) with no kbytes rekeying<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 3600 seconds<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 3600 seconds<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n GRE<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Addressing<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 172.31.31.1\/30<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 172.31.31.2\/30<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Keepalives<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Disabled<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n Disabled<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n MTU<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 1400<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 1400<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n

    \n \n\n

    \n Adjust MSS<\/b>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 1360<\/span>\n <\/p>\n \n\n <\/td>\n \n\n

    		\n \n\n

    \n 1360<\/span>\n <\/p>\n \n\n <\/td>\n \n\n <\/tr>\n \n\n <\/tbody>\n \n\n <\/table>\n \n\n \n\n

    Important License\/Module Information<\/h2>\n\n

    Check with the manufacturer of your equipment to see if some kind of service card, or license is not required.<\/p>\n\n

    In the case of the equipment in this lab, the NE40-M2K router did not need an additional physical module, just the IPSec license. On the Cisco router no license was needed either, because its IOS was already in ADVIPSERVICES-K9 (which contains the entire basis for Ipsec).<\/p>\n\n

    *Helpful information*<\/strong>: if you want to run IKEv1, on the Huawei router you need a software module for IKEv1 (which you get from the Huawei vendor).<\/p>\n\n

    Cisco IOS XE Configurations<\/h2>\n\n

    So let’s configure the Cisco router to establish the VPN. I won’t go into detail about the physical interfaces, only about the VPN. At the end of the article there is a block with the relevant conf of them.<\/p>\n\n

    Phase 1 settings, according to the table above:<\/p>\n\n

    <\/p>\n\n

    # PROPOSAL PARA fase 1\ncrypto ikev2 proposal ikev2proposal\n encryption aes-cbc-256\n integrity sha1\n group 14\n\n# policy de fase 1\ncrypto ikev2 policy ikev2policy\n match fvrf any\n proposal ikev2proposal\n\n\n# chaveiro com as PSK\ncrypto ikev2 keyring keys\n peer site_b\n  address 203.0.113.66\n  pre-shared-key UmaSenhaBemS3gur@\n !\n\n# profile com o PEER\ncrypto ikev2 profile ikev2profile\n match identity remote address 203.0.113.66 255.255.255.255\n authentication remote pre-share\n authentication local pre-share\n keyring local keys\n<\/code><\/pre>\n\n
    Everything above is relative to Phase 1. Then when you are diagnosing problems, and he is of this stage, you already know where to change \ud83d\ude42 .<\/p>\n\n
    Now setting up phase 2:<\/p>\n\n
    # confs da fase 2\ncrypto ipsec transform-set TS esp-aes 256 esp-sha-hmac\n mode tunnel<\/code><\/pre>\n\n
    Too simple on Cisco! We will now combine the two phases into one profile:<\/p>\n\n
    # Profile a ser usado na VPN (combina as confs de fase1 e fase2)\ncrypto ipsec profile VPN-IKEv2-IPsec-Profile\n set transform-set TS\n set ikev2-profile ikev2profile<\/code><\/pre>\n\n
    Creating the GRE tunnel and adding IPSec protection:<\/p>\n\n
    # cria o tunnel GRE e aplica a protecao\ninterface Tunnel299\n description Tunnel Test Rafael\n bandwidth 10000\n ip address 172.31.31.1 255.255.255.252\n ip mtu 1400\n ip tcp adjust-mss 1360\n tunnel source Port-channel1.536\n tunnel destination 203.0.113.66\n tunnel protection ipsec profile VPN-IKEv2-IPsec-Profile\nend<\/code><\/pre>\n\n
    Huawei Settings<\/h2>\n\n
    So let’s configure the Huawei router to establish the VPN. As with Cisco, I won’t go into detail about the physical interfaces, only the VPN. At the end of the article there is a block with the relevant conf of them.<\/p>\n\n
    The configuration on the Huawei router is a bit more complex, as it creates one tunnel for the GRE protocol, and one tunnel for IPSec. Also, we want to use the same IP for both tunnels, so a VRF is needed. \ud83d\ude2e<\/p>\n\n
    Creating the service instance to use the VPN (only applicable on NE40):<\/p>\n\n
    # Cria o service-instance-group (somente NE40)\nservice-location 1\n location slot 1\n commit\n\nservice-instance-group group1\n service-location 1<\/code><\/pre>\n\n
    Upgrading the new VRF (vpn-instance):<\/p>\n\n
    ip vpn-instance vpna\n ipv4-family\n  route-distinguisher 100:1\n  apply-label per-instance\n  vpn-target 111:1 export-extcommunity\n  vpn-target 111:1 import-extcommunity<\/code><\/pre>\n\n
    Creating the two Loopback interfaces with the same IP (VRF magic). The looback with the IPSec tunnel will be in the public routing table, while the one with the GRE tunnel will be in the VPNA table.<\/p>\n\n
    # Lo da tabela global, para uso do IPSec\ninterface LoopBack1\nip address 203.0.113.66 255.255.255.255\nbinding tunnel ipsec\n\n# Lo atrelada a vrf, para uso no GRE do mesmo IP.\ninterface LoopBack10\n ip binding vpn-instance vpna\n ip address 203.0.113.66 255.255.255.255\n binding tunnel gre<\/code><\/pre>\n\n
    Now we come to IPSec.  <\/p>\n\n
    The interesting traffic ACL defines the traffic that will be protected by IPSec. In this case then, we will have GRE traffic between the IPs of site A and site B. Note that I only communicate in one direction – the direction of the router protecting its traffic).  <\/p>\n\n
    # ACL de tr\u00e1fego interessante\nacl number 3000\n rule 0 permit gre vpn-instance vpna source 203.0.113.66 0\n destination 198.51.100.2 0<\/code><\/pre>\n\n
    The above ACL can be read like this:<\/p>\n\n
    \n          “Protect GRE protocol data coming from VRF vpna between source 203.0.113.66 and destination 198.51.100.2”<\/em>\n        <\/p>\n\n
    We will now create phase 1 (remember that in cisco it even starts with it, much simpler). In the middle of it you have some VPN-Instance binding settings, because of the VRF created.<\/p>\n\n
    # PROPOSAL PARA fase 1\nike proposal 1\n encryption-algorithm aes-cbc 256\n dh group14\n authentication-algorithm sha1\n integrity-algorithm hmac-sha1-96\n\n# chaveiro com as PSK e peer\nike peer teste\n pre-shared-key UmaSenhaBemS3gur@adriano\n ike-proposal 1\n remote-address 198.51.100.2\n sa binding vpn-instance vpna<\/code><\/pre>\n\n
    Everything above is relative to Phase 1. Then when you are diagnosing problems, and he is of this stage, you already know where to change \ud83d\ude42 .<\/p>\n\n
    We move on to phase 2:<\/p>\n\n
    # confs da fase 2\nipsec proposal comfone\n encapsulation-mode tunnel\n transform esp\n esp authentication-algorithm sha1\n esp encryption-algorithm aes 256<\/code><\/pre>\n\n
    We will now combine the two phases into one profile:<\/p>\n\n
    # policy combinando ambas as fases\nipsec policy teste 1 isakmp\n ipsec df-bit clear\n security acl 3000\n ike-peer teste\n proposal comfone\n log enable<\/code><\/pre>\n\n
    Creating GRE and IPSEC tunnels. Let’s not get confused:<\/p>\n\n
    Tunnel 900 – is a GRE tunnel, operating inside the vpna.<\/p>\n\n
    Tunnel 10 – is an IPSec tunnel, operating on the global table<\/p>\n\n
    The idea at Huawei is that there is one IPSec tunnel running on the outside, and a second GRE tunnel on the inside, one encapsulated in the other. But the funny thing is that the GRE tunnel runs outside the VRF, and the ipsec inside. Baguncinha ne?<\/p>\n\n
    # Tunel GRE (dentro da VRF)\ninterface Tunnel900\n bandwidth 10000\n mtu 1400\n ip address 172.31.31.2 255.255.255.252\n clear ip df\n tunnel-protocol gre\n source LoopBack10\n destination vpn-instance vpna 198.51.100.2\n\n# Tunel IPsec\ninterface Tunnel10\n ip address unnumbered interface LoopBack1\n tunnel-protocol ipsec\n ipsec policy teste service-instance-group group1<\/code><\/pre>\n\n
    Then tunnel900 which is the GRE (and which receives the IPs from \/30) uses a destination that goes inside the VPNA. And inside the VPNA the destination is reached by the IPSec tunnel. Also note that the IPsec policy has been associated with tunnel 10, using the profile that was created.<\/p>\n\n
    Last but not least, a route that has a certain complexity in itself: within the VPNA instance, I say that to reach the remote peer, I use the newly created IPSec interface, with the next-hop the peer itself.<\/p>\n\n
    # Rota para o peer na VPN-Instance para usar o Tunnel\nip route-static vpn-instance vpna 198.51.100.2 255.255.255.255\n Tunnel10 198.51.100.2<\/code><\/pre>\n\n
    And so we set up the Huawei router. Let’s see if it has gone up now.<\/p>\n\n
    Operation Validation<\/h2>\n\n
    In the tunnel validation process, we must always remember that each phase and stage depends on the complete establishment of the other, so there is no point in wanting to have connectivity if phase 1 has not yet established communication.<\/p>\n\n
    On both routers, we will validate in sequence:<\/p>\n\n
      \n
    • connectivity<\/li>\n\n\n\n
    • phase1<\/li>\n\n\n\n
    • phase2<\/li>\n\n\n\n
    • GRE connectivity<\/li>\n\n\n\n
    • interface status<\/li>\n<\/ul>\n\n
      Let’s go to the tests.<\/p>\n\n
      Cisco Check<\/h2>\n\n
      Validating connectivity via ICMP ping<\/p>\n\n
      RT-CISCO-ASR1004#ping 203.0.113.66\nType escape sequence to abort.\nSending 5, 100-byte ICMP Echos to 203.0.113.66, timeout is 2 seconds:\n!!!!!\nSuccess rate is 100 percent (5\/5), round-trip min\/avg\/max = 22\/24\/27 ms\nRT-CISCO-ASR1004#<\/code><\/pre>\n\n
      Checking that IKEv2 has established in Phase 1:<\/p>\n\n
      <\/p>\n\n
      RT-CISCO-ASR1004#show crypto ikev2 sa\n IPv4 Crypto IKEv2  SA\n\nTunnel-id Local                 Remote                fvrf\/ivrf            Status\n1         198.51.100.2\/500    203.0.113.66\/500    none\/none            READY\n      Encr: AES-CBC, keysize: 256, PRF: SHA1, Hash: SHA96, DH Grp:14, Auth sign:\n PSK, Auth verify: PSK\n      Life\/Active Time: 86400\/17 sec<\/code><\/pre>\n\n
      When nothing appears in the output, or it is not ready, it means that some of the parameters in Phase 1 did not match. Check on both sides if they agree.<\/p>\n\n
      We continue validation in Phase 2:<\/p>\n\n
      RT-CISCO-ASR1004#show crypto ipsec sa\n\ninterface: Tunnel299\n    Crypto map tag: Tunnel299-head-0, local addr 198.51.100.2\n   protected vrf: (none)\n   local  ident (addr\/mask\/prot\/port): (198.51.100.2\/255.255.255.255\/47\/0)\n   remote ident (addr\/mask\/prot\/port): (203.0.113.66\/255.255.255.255\/47\/0)\n   current_peer 203.0.113.66 port 500\n     PERMIT, flags={origin_is_acl,}\n    #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2\n    #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2 \n    #pkts compressed: 0, #pkts decompressed: 0\n    #pkts not compressed: 0, #pkts compr. failed: 0\n    #pkts not decompressed: 0, #pkts decompress failed: 0\n    #send errors 0, #recv errors 0\n\n     local crypto endpt.: 198.51.100.2, remote crypto endpt.: 203.0.113.66\n     plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb Port-channel1.535\n     current outbound spi: 0x2E41D7D5(776067029)\n     PFS (Y\/N): N, DH group: none\n\n     inbound esp sas:\n      spi: 0x27487883(659060867)\n        transform: esp-256-aes esp-sha-hmac ,\n        in use settings ={Tunnel, }\n        conn id: 2010, flow_id: HW:10, sibling_flags FFFFFFFF80000048, crypto map: Tunnel299-head-0\n        sa timing: remaining key lifetime (k\/sec): (4607999\/3508)\n        IV size: 16 bytes\n        replay detection support: Y\n        Status: ACTIVE(ACTIVE)\n\n     inbound ah sas:\n\n     inbound pcp sas:\n\n     outbound esp sas:\n      spi: 0x2E41D7D5(776067029)\n        transform: esp-256-aes esp-sha-hmac ,\n        in use settings ={Tunnel, }\n        conn id: 2009, flow_id: HW:9, sibling_flags FFFFFFFF80000048, crypto map: Tunnel299-head-0\n        sa timing: remaining key lifetime (k\/sec): (4607999\/3508)\n        IV size: 16 bytes\n        replay detection support: Y\n        Status: ACTIVE(ACTIVE)\n\n     outbound ah sas:\n\n     outbound pcp sas:<\/code><\/pre>\n\n
      In the output above, we see that the routers have switched the “interesting traffic” contract. Each side has committed to protecting one direction of GRE communication.<\/p>\n\n
      Following on still in Phase 2, there are some very important counters that refer to packets sent\/received\/encrypted\/verified. It is in the output of the “show crypto ipsec sa” command. Let’s take a look at them.<\/p>\n\n
      RT-CISCO-ASR1004#show crypto ipsec sa  | inc pkts\n    #pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2\n    #pkts decaps: 2, #pkts decrypt: 2, #pkts verify: 2\n    #pkts compressed: 0, #pkts decompressed: 0\n    #pkts not compressed: 0, #pkts compr. failed: 0\n    #pkts not decompressed: 0, #pkts decompress failed: 0\nRT-CISCO-ASR1004#ping 172.31.31.2 repeat 2\nType escape sequence to abort.\nSending 2, 100-byte ICMP Echos to 172.31.31.2, timeout is 2 seconds:\n!!\nSuccess rate is 100 percent (2\/2), round-trip min\/avg\/max = 22\/22\/22 ms\nRT-CISCO-ASR1004#show crypto ipsec sa  | inc pkts\n    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4\n    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4\n    #pkts compressed: 0, #pkts decompressed: 0\n    #pkts not compressed: 0, #pkts compr. failed: 0\n    #pkts not decompressed: 0, #pkts decompress failed: 0<\/code><\/pre>\n\n
      When these counters are not incrementing, or still incrementing failures, it is because some Phase 2 configuration is not matching.  <\/p>\n\n
      A good example would be that only the encaps\/encrypt counter is incremented, while the decaps\/decrypt is reset to zero. This is going to be an interesting traffic ACL problem that is diverging on both sides. Or a communication blockage in the transport network, or other factors that we won’t go into here. If you need help, be sure to contact us.<\/p>\n\n
      Finally, let’s validate the connectivity itself! But now inside the tunnel already protected!<\/p>\n\n
      RT-CISCO-ASR1004#ping 172.31.31.2 repeat 100\nType escape sequence to abort.\nSending 100, 100-byte ICMP Echos to 172.31.31.2, timeout is 2 seconds:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!\nSuccess rate is 100 percent (100\/100), round-trip min\/avg\/max = 21\/21\/23 ms\nRT-CISCO-ASR1004#<\/code><\/pre>\n\n
      And the tunnel interface is up, and functional:<\/p>\n\n
      # interface UP\nRT-CISCO-ASR1004#sh int tun299\nTunnel299 is up, line protocol is up\n  Hardware is Tunnel\n  Description: Tunnel Test Rafael\n  Internet address is 172.31.31.1\/30\n  MTU 9914 bytes, BW 10000 Kbit\/sec, DLY 50000 usec,\n     reliability 255\/255, txload 1\/255, rxload 1\/255\n  Encapsulation TUNNEL, loopback not set\n  Keepalive not set\n  Tunnel linestate evaluation up\n  Tunnel source 198.51.100.2 (Port-channel1.536), destination 203.0.113.66\n   Tunnel Subblocks:\n      src-track:\n         Tunnel299 source tracking subblock associated with Port-channel1.536\n          Set of tunnels with source Port-channel1.536, 1 member (includes iterators), on interface <OK>\n  Tunnel protocol\/transport GRE\/IP\n    Key disabled, sequencing disabled\n    Checksumming of packets disabled\n  Tunnel TTL 255, Fast tunneling enabled\n  Tunnel transport MTU 1414 bytes\n  Tunnel transmit bandwidth 8000 (kbps)\n  Tunnel receive bandwidth 8000 (kbps)\n  Tunnel protection via IPSec (profile \"VPN-IKEv2-IPsec-Profile\")\n  Last input never, output never, output hang never\n  Last clearing of \"show interface\" counters 19:14:47\n  Input queue: 0\/375\/0\/0 (size\/max\/drops\/flushes); Total output drops: 0\n  Queueing strategy: fifo\n  Output queue: 0\/0 (size\/max)\n  5 minute input rate 1000 bits\/sec, 1 packets\/sec\n  5 minute output rate 1000 bits\/sec, 1 packets\/sec\n     253 packets input, 22764 bytes, 0 no buffer\n     Received 0 broadcasts (0 IP multicasts)\n     0 runts, 0 giants, 0 throttles\n     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort\n     13497 packets output, 659844 bytes, 0 underruns\n     0 output errors, 0 collisions, 0 interface resets\n     0 unknown protocol drops\n     0 output buffer failures, 0 output buffers swapped out<\/code><\/pre>\n\n
      Huawei Check<\/h2>\n\n
      To validate operation on the Huawei NE40 router, the approach is the same as for the Cisco.  <\/p>\n\n
      Validating connectivity via ICMP ping (remember to use loopback source)<\/p>\n\n
      <~RT-HUAWEI-NE40> ping -a 203.0.113.66 198.51.100.2\n  PING 198.51.100.2: 56  data bytes, press CTRL_C to break\n    Reply from 198.51.100.2: bytes=56 Sequence=1 ttl=62 time=1 ms\n    Reply from 198.51.100.2: bytes=56 Sequence=2 ttl=62 time=1 ms\n    Reply from 198.51.100.2: bytes=56 Sequence=3 ttl=62 time=1 ms\n    Reply from 198.51.100.2: bytes=56 Sequence=4 ttl=62 time=1 ms\n    Reply from 198.51.100.2: bytes=56 Sequence=5 ttl=62 time=2 ms\n\n  --- 198.51.100.2 ping statistics ---\n    5 packet(s) transmitted\n    5 packet(s) received\n    0.00% packet loss\n    round-trip min\/avg\/max = 1\/1\/2 ms<\/code><\/pre>\n\n
      Checking that IKEv2 has established in Phase 1:<\/p>\n\n
      [~RT-HUAWEI-NE40]dis ike sa\nSlot 3, IKE SA Information:\nCurrent IKE SA number: 2\n-----------------------------------------------------------------------------\nconn-id    peer                    flag                phase   ext    vpn\n-----------------------------------------------------------------------------\n1212       198.51.100.2          RD                  v2:2    -      vpna\n1211       198.51.100.2          RD                  v2:1    -      vpna\n\n[~RT-HUAWEI-NE40]dis ike sa verbose remote 198.51.100.2\nSlot 3, IKE SA Verbose Information:\n  ----------------------------\n  Establish Time : 2022-12-03 09:49:43\n  PortCfg Name   : Tunnel10\n  IKE Peer Name  : teste\n  Connection Id  : 1211\n  Version        : v2\n  Flow VPN       : vpna\n  Peer VPN       : -\n  Instance ID    : 0\n  -----------------------------------------------\n    Initiator Cookie        : 0xefaf822684f391e7\n    Responder Cookie        : 0xdac01cc355e9c8ad\n    Local Address           : 203.0.113.66\n    Remote Address          : 198.51.100.2\n    Peer Identity           : ip, 198.51.100.2\n    Authentication Method   : PRE_SHARED\n    Diffie-Hellman Group    : MODP_2048\n    Encryption Algorithm    : AES256_CBC\n    Authentication Algorithm: SHA1\n    Integrity Algorithm     : SHA1_96\n    Send\/Receive Message_id : 0\/2\n    Remaining Duration      : 85680\n    Reference Counter       : 2\n    Flags                   : RD\n    Is Backuped             : 0\n    InBound SpeedLimit      : -\n    OutBound SpeedLimit     : -\n  -----------------------------------------------\n<\/code><\/pre>\n\n
      When nothing appears in the output, or it is not in ready (RD), it means that some of the Phase 1 parameters did not match. Check on both sides if they agree.<\/p>\n\n
      We continue validation in Phase 2:<\/p>\n\n
      [~RT-HUAWEI-NE40]  dis ipsec sa\n\nIKE IP Security Association :\n==================================\nIPsec SA Information for Slot : 3\n==================================\n\n===============================\nInterface: Tunnel10\n===============================\n\n  -----------------------------\n  IPsec policy name: \"teste\"\n  sequence number: 1\n  instance id: 0\n  mode: isakmp\n  vpn: vpna\n  ext: -\n  -----------------------------\n    connection id: 1212\n    rule number: 0\n    encapsulation mode: tunnel\n    tunnel local: 203.0.113.66    tunnel remote: 198.51.100.2\n    flow      source: 203.0.113.66\/255.255.255.255 0-65535 47 0xFF\n    flow destination: 198.51.100.2\/255.255.255.255 0-65535 47 0xFF\n    input\/output security packets: 104\/104\n    input\/output security kilobytes: 18\/18\n    input\/output bandwidth limit drop packets: 0\/0\n    input\/output bandwidth limit drop kilobytes: 0\/0\n\n    [inbound ESP SAs]\n      establish: 2022-12-03 09:49:43\n      spi: 776067029 (0x2e41d7d5)\n      vpn: vpna said: 53\n      proposal: ESP-ENCRYPT-256-AES ESP-AUTH-SHA1\n      sa remaining key duration (kilobytes\/sec): 1843182\/2862\n      max received sequence-number: 104\n      udp encapsulation used for nat traversal: N\n\n    [outbound ESP SAs]\n      establish: 2022-12-03 09:49:43\n      spi: 659060867 (0x27487883)\n      vpn: vpna said: 54\n      proposal: ESP-ENCRYPT-256-AES ESP-AUTH-SHA1\n      sa remaining key duration (kilobytes\/sec): 1843182\/2862\n      max sent sequence-number: 104\n      udp encapsulation used for nat traversal: N\n<\/code><\/pre>\n\n
      Finally, let’s validate the connectivity itself by checking the traffic counters! But now inside the tunnel already protected!<\/p>\n\n
      [~RT-HUAWEI-NE40]dis inter Tunnel 900 | i packets\nInfo: It will take a long time if the content you search is too much or the string you input is too long, you can press CTRL_C to break.\nChecksumming of packets disabled\n    300 seconds input rate 64 bits\/sec, 1 packets\/sec\n    300 seconds output rate 0 bits\/sec, 0 packets\/sec\n    0 seconds input rate 0 bits\/sec, 0 packets\/sec\n    0 seconds output rate 0 bits\/sec, 0 packets\/sec\n    223 packets input,  22712 bytes\n    227 packets output,  29534 bytes\n      Unicast: 223 packets, Multicast: 0 packets\n      Unicast: 227 packets, Multicast: 0 packets\n[~RT-HUAWEI-NE40]ping -a 172.31.31.2 172.31.31.1\n  PING 172.31.31.1: 56  data bytes, press CTRL_C to break\n    Reply from 172.31.31.1: bytes=56 Sequence=1 ttl=255 time=22 ms\n    Reply from 172.31.31.1: bytes=56 Sequence=2 ttl=255 time=22 ms\n    Reply from 172.31.31.1: bytes=56 Sequence=3 ttl=255 time=22 ms\n    Reply from 172.31.31.1: bytes=56 Sequence=4 ttl=255 time=22 ms\n    Reply from 172.31.31.1: bytes=56 Sequence=5 ttl=255 time=21 ms\n\n  --- 172.31.31.1 ping statistics ---\n    5 packet(s) transmitted\n    5 packet(s) received\n    0.00% packet loss\n    round-trip min\/avg\/max = 21\/21\/22 ms\n\n[~RT-HUAWEI-NE40]dis inter Tunnel 900 | i packets\nInfo: It will take a long time if the content you search is too much or the string you input is too long, you can press CTRL_C to break.\nChecksumming of packets disabled\n    300 seconds input rate 64 bits\/sec, 1 packets\/sec\n    300 seconds output rate 0 bits\/sec, 0 packets\/sec\n    0 seconds input rate 0 bits\/sec, 0 packets\/sec\n    0 seconds output rate 0 bits\/sec, 0 packets\/sec\n    228 packets input,  23152 bytes\n    232 packets output,  30074 bytes\n      Unicast: 228 packets, Multicast: 0 packets\n      Unicast: 232 packets, Multicast: 0 packets\n[~RT-HUAWEI-NE40]\n<\/code><\/pre>\n\n
      And the tunnel interface is up, and functional:<\/p>\n\n
      [~RT-HUAWEI-NE40]dis inter Tunnel 900 extensive\nTunnel900 current state : UP (ifindex: 112)\nLine protocol current state : UP\nLast line protocol up time : 2022-12-03 09:39:38\nDescription:\nRoute Port,The Maximum Transmit Unit is 1400\nInternet Address is 172.31.31.2\/30\nEncapsulation is TUNNEL, loopback not set\nTunnel source 203.0.113.66 (LoopBack10), destination vrf vpna 198.51.100.2\nTunnel protocol\/transport GRE\/IP, key disabled\nkeepalive disabled\nChecksumming of packets disabled\nCurrent system time: 2022-12-03 10:03:48\n    300 seconds input rate 64 bits\/sec, 1 packets\/sec\n    300 seconds output rate 0 bits\/sec, 0 packets\/sec\n    0 seconds input rate 0 bits\/sec, 0 packets\/sec\n    0 seconds output rate 0 bits\/sec, 0 packets\/sec\n    228 packets input,  23152 bytes\n    0 input error\n    232 packets output,  30074 bytes\n    0 output error\n    Input:\n      Unicast: 228 packets, Multicast: 0 packets\n    Output:\n      Unicast: 232 packets, Multicast: 0 packets\n    Input bandwidth utilization  :    0%\n    Output bandwidth utilization :    0%\n<\/code><\/pre>\n\n
      With this we arrive at the established and functioning tunnel between the Cisco IOS XE router and the Huawei NE40!  <\/p>\n\n
      Complete Cisco Configuration<\/h2>\n\n
      # interface WAN\ninterface Port-channel1.536\n description WAN-If\n encapsulation dot1Q 536\n ip address 198.51.100.2 255.255.255.252\n no shutdown\n\n# PROPOSAL PARA fase 1\ncrypto ikev2 proposal ikev2proposal\n encryption aes-cbc-256\n integrity sha1\n group 14\n\n# policy de fase 1\ncrypto ikev2 policy ikev2policy\n match fvrf any\n proposal ikev2proposal\n\n\n# chaveiro com as PSK\ncrypto ikev2 keyring keys\n peer site_b\n  address 203.0.113.66\n  pre-shared-key UmaSenhaBemS3gur@\n !\n\n# profile com o PEER\ncrypto ikev2 profile ikev2profile\n match identity remote address 203.0.113.66 255.255.255.255\n authentication remote pre-share\n authentication local pre-share\n keyring local keys\n\n# confs da fase 2\ncrypto ipsec transform-set TS esp-aes 256 esp-sha-hmac\n mode tunnel\n\n# Profile a ser usado na VPN (combina as confs de fase1 e fase2)\ncrypto ipsec profile VPN-IKEv2-IPsec-Profile\n set transform-set TS\n set ikev2-profile ikev2profile\n\n\n# cria o tunnel GRE e aplica a protecao\ninterface Tunnel299\n description Tunnel Test Rafael\n bandwidth 10000\n ip address 172.31.31.1 255.255.255.252\n ip mtu 1400\n ip tcp adjust-mss 1360\n tunnel source Port-channel1.536\n tunnel destination 203.0.113.66\n tunnel protection ipsec profile VPN-IKEv2-IPsec-Profile\nend\n<\/code><\/pre>\n\n
      Huawei Complete Configuration<\/h2>\n\n
      # Cria o service-instance-group (somente NE40)\nservice-location 1\n location slot 1\n commit\n\nservice-instance-group group1\n service-location 1\n\n# PROPOSAL PARA fase 1\nike proposal 1\n encryption-algorithm aes-cbc 256\n dh group14\n authentication-algorithm sha1\n integrity-algorithm hmac-sha1-96\n\n# ACL de tr\u00e1fego interessante\nacl number 3000\n rule 0 permit gre vpn-instance vpna source 203.0.113.66 0 destination 198.51.100.2 0\n\n\n# policy de fase 1\nipsec policy teste 1 isakmp\n ipsec df-bit clear\n security acl 3000\n ike-peer teste\n proposal comfone\n log enable\n\n\n# chaveiro com as PSK e peer\nike peer teste\n pre-shared-key <senha>\n ike-proposal 1\n remote-address 198.51.100.2\n sa binding vpn-instance vpna\n\n\n# confs da fase 2\nipsec proposal comfone\n encapsulation-mode tunnel\n transform esp\n esp authentication-algorithm sha1\n esp encryption-algorithm aes 256\n\n\n# Para uso de Gre over IPSEC com o local address sendo compartilhado, para n\u00e3o haver conflito, ser\u00e1 necessario criar uma vrf.\nip vpn-instance vpna\n ipv4-family\n  route-distinguisher 100:1\n  apply-label per-instance\n  vpn-target 111:1 export-extcommunity\n  vpn-target 111:1 import-extcommunity\n\n# Neste cenario o IP de saida ser\u00e1 uma lo (atentar que a config bindando o tunel ipsec, ser\u00e1 feita quando atrelar o tunel a esta interface)\n\ninterface LoopBack1\n ip address 203.0.113.66 255.255.255.255\n binding tunnel ipsec\n\n# Lo atrelada a vrf, para uso no GRE do mesmo IP.\ninterface LoopBack10\n ip binding vpn-instance vpna\n ip address 203.0.113.66 255.255.255.255\n binding tunnel gre\n \n # Tunel GRE do Teste\ninterface Tunnel900\n bandwidth 10000\n mtu 1400\n ip address 172.31.31.2 255.255.255.252\n clear ip df\n tunnel-protocol gre\n source LoopBack10\n destination vpn-instance vpna 198.51.100.2\n\n\n# Tunel IPsec do teste\ninterface Tunnel10\nip address unnumbered interface LoopBack1\ntunnel-protocol ipsec\nipsec policy teste service-instance-group group1\n\n# Rota para o peer na VPN-Instance para usar o Tunnel\nip route-static vpn-instance vpna 198.51.100.2 255.255.255.255 Tunnel10 198.51.100.2\n<\/code><\/pre>\n\n
      \n          Authors<\/strong>\n        <\/p>\n\n
      Rafael Ganascim<\/p>\n\n
      Julian Eble<\/p>\n\n
      \n          References<\/strong>\n        <\/p>\n\n
      [1] Overview of GRE. NE40E-M2 Huawei. https:\/\/support.huawei.com\/hedex\/hdx.do?docid=EDOC1100277532&id=EN-US_CONCEPT_0172355906&ui=1<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
      In this post we will discuss a very common (and little documented) scenario, which is to use a GRE tunnel secured with IPSec between a Cisco IOS ASR1002 router and a Huawei NE40 router. The topology for this example is described below. It has been kept simple so that we can discuss the details of […]<\/p>\n","protected":false},"author":13,"featured_media":10386,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"postBodyCss":"","postBodyMargin":[],"postBodyPadding":[],"postBodyBackground":{"backgroundType":"classic","gradient":""},"footnotes":""},"categories":[1],"tags":[],"class_list":["post-11668","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nao-categorizado"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/posts\/11668","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/comments?post=11668"}],"version-history":[{"count":0,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/posts\/11668\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/media\/10386"}],"wp:attachment":[{"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/media?parent=11668"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/categories?post=11668"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/made4it.com.br\/en\/wp-json\/wp\/v2\/tags?post=11668"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}