Túnel GRE + IPSec entre Cisco IOS e Huawei NE40
Neste post iremos discutir um cenário muito comum (e pouco documentado), que é utilizar um túnel GRE protegido com IPSec entre um roteador Cisco IOS ASR1002 e um Roteador Huawei NE40. A topologia deste exemplo é descrita abaixo. Ela foi mantida simples para que possamos discutir os detalhes do GRE+IPSEC, sem entrar nos demais pontos da rede. Nela temos o roteador Cisco com endereço IP público 198.51.100.2 e o roteador Huawei NE40 com o IP público 203.0.113.66. Ambos estão conectados a Internet, e com conectividade entre si. Precisamos estabelecer um túnel GRE entre os roteadores e protegê-lo através do IPSec no modo tunnel. O endereçamento do túnel é 172.31.31.0/30. Informações importantes sobre licença/módulos Veja com o fabricante dos seus equipamentos se não é necessário algum tipo de placa de serviços, ou licença. No caso dos equipamentos deste laboratório, o roteador NE40-M2K não precisou de módulo físico adicional, apenas a licença de IPSec. No roteador Cisco também não foi necessário licença, pois o IOS dele já estava no ADVIPSERVICES-K9 (que contém toda a base para o Ipsec). *informação útil*: se quiser rodar IKEv1, no roteador Huawei você precisa de um módulo de software para IKEv1 (que você consegue com o fornecedor Huawei). Configurações do Cisco IOS XE Vamos lá então configurar o roteador Cisco para estabelecer a VPN. Não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas. Configurações de fase 1, de acordo com a tabela acima: Tudo o que estiver acima é relativo a Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂. Agora, configurando a fase 2: Simples demais no Cisco! Vamos agora combinar as duas fases em um profile: Criando o túnel GRE e adicionando a proteção IPSec: Configurações do Huawei Vamos lá então configurar o roteador Huawei para estabelecer a VPN. Assim como do Cisco, não vou entrar em detalhes das interfaces físicas, somente da VPN. No final do artigo tem um bloco com a conf pertinente delas. A configuração no roteador Huawei é um pouco mais complexa, pois ele cria um túnel para o protocolo GRE, e um túnel para o IPSec. Além disso, queremos usar o mesmo IP para ambos os túneis, sendo necessária uma VRF. 😮 Criando o service instance para uso da VPN (aplicavel somente no NE40): Subindo a nova VRF (vpn-instance): Criando as duas interfaces Loopback com o mesmo IP (magias da VRF). A looback com o túnel IPSec ficará na tabela de roteamento pública, enquanto que a com o túnel GRE ficará na tabela VPNA. Agora sim chegamos ao IPSec. A ACL de tráfego interessante define o tráfego que será protegido pelo IPSec. No caso então, teremos o tráfego GRE entre os IPs do site A e site B. Perceba que só faço a comunicação em um sentido – o sentido do roteador protegendo o tráfego dele). A ACL acima pode ser lida assim: “Proteja os dados do protocolo GRE, vindo da VRF vpna entre a origem 203.0.113.66 e o destino 198.51.100.2” Partimos agora criar a fase 1 (lembra que no cisco já até começa com ela, muito mais simples). No meio dela tem algumas configurações de binding de VPN-Instance, por conta da VRF criada. Tudo o que estiver acima é relativo a Fase 1. Então quando estiver diagnosticando problemas, e ele for desta fase, já sabe onde mudar 🙂. Seguimos para a fase 2: Vamos agora combinar as duas fases em um profile: Criando os túneis GRE e IPSEC. Vamos lá para não confundir: Tunnel 900 – é um túnel GRE, operando por dentro da vpna. Tunnel 10 – é um túnel IPSec, operando na tabela global A ideia na Huawei é de que exista um túnel IPSec rodando por fora, e um segundo túnel GRE por dentro, um encapsulado no outro. Mas o engraçado é que o túnel GRE roda fora da VRF, e o ipsec dentro. Baguncinha ne? Então o tunnel900 que é o GRE (e que recebe os IPs do /30) usa um destino que vai por dentro da VPNA. E dentro da VPNA o destino é alcançado pelo túnel IPSec. Também observe que a policy de IPsec foi associada ao tunnel 10, utilizando o profile que foi criado. Por fim, e não menos importante, uma rota que tem uma certa complexidade em si mesma: dentro da instancia VPNA, eu digo que para chegar ao peer remoto, eu utilizo a interface de IPSec recem criada, com o next-hop o próprio peer. E assim configuramos o roteador Huawei. Vamos ver se subiu agora. Validação do funcionamento No processo de validação do túnel, devemos sempre lembrar que cada fase e etapa depende do estabelecimento completo da outra, logo, não adianta querer ter conectividade se a fase 1 ainda não estabeleceu a comunicação. Em ambos os roteadores, vamos validar em sequência: Vamos lá para os testes. Checagem Cisco Validando a conectividade via ICMP ping Checando se o IKEv2 estabeleceu na Fase 1: Quando não aparecer nada na saída, ou ele não estiver em ready, quer dizer que alguns dos parâmetros da Fase 1 não casaram. Confira em ambos os lados se eles estão de acordo. Continuamos a validação na Fase 2: Na saída acima, vemos que os roteadores trocaram o contrato de “tráfego interessante”. Cada lado se comprometeu a proteger um sentido da comunicação GRE. Em sequência ainda na Fase 2, existem alguns contadores muito importantes que se referem a pacotes enviados/recebidos/encapsulados/encryptados/verificados. Ele fica na saída do comando “show crypto ipsec sa”. Vamos ver eles. Quando estes contadores não estão incrementando, ou ainda incrementando falhas, é porque alguma configuração da Fase 2 não está casando. Um bom exemplo seria somente o contador de encaps/encrypt ser incrementado, e enquanto o decaps/decrypt ficando zerado. Isto vai ser um problema da ACL de tráfego interessante que está divergindo em ambos os lados. Ou bloqueio da comunicação na rede de transporte ou ainda outros fatores que não vamos tratar aqui. Se
GRE + IPSec tunnel between Cisco IOS and Huawei NE40
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 GRE+IPSEC without getting into the rest of the network. 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. Important License/Module Information Check with the manufacturer of your equipment to see if some kind of service card, or license is not required. 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). *Helpful information*: if you want to run IKEv1, on the Huawei router you need a software module for IKEv1 (which you get from the Huawei vendor). Cisco IOS XE Configurations 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. Phase 1 settings, according to the table above: 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 🙂 . Now setting up phase 2: Too simple on Cisco! We will now combine the two phases into one profile: Creating the GRE tunnel and adding IPSec protection: Huawei Settings 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. 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. 😮 Creating the service instance to use the VPN (only applicable on NE40): Upgrading the new VRF (vpn-instance): 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. Now we come to IPSec. 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). The above ACL can be read like this: “Protect GRE protocol data coming from VRF vpna between source 203.0.113.66 and destination 198.51.100.2” 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. 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 🙂 . We move on to phase 2: We will now combine the two phases into one profile: Creating GRE and IPSEC tunnels. Let’s not get confused: Tunnel 900 – is a GRE tunnel, operating inside the vpna. Tunnel 10 – is an IPSec tunnel, operating on the global table 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? 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. 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. And so we set up the Huawei router. Let’s see if it has gone up now. Operation Validation 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. On both routers, we will validate in sequence: Let’s go to the tests. Cisco Check Validating connectivity via ICMP ping Checking that IKEv2 has established in Phase 1: 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. We continue validation in Phase 2: 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. 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. When these counters are not incrementing, or still incrementing failures, it is because some Phase 2 configuration is not matching. A good example would be that only the encaps/encrypt counter is incremented, while the decaps/decrypt is reset
Túnel GRE + IPSec entre Cisco IOS y Huawei NE40
En este post vamos a discutir un escenario muy común (y poco documentado), que consiste en utilizar un túnel GRE protegido con IPSec entre un router Cisco IOS ASR1002 y un router Huawei NE40. La topología de este ejemplo se describe a continuación. Se ha mantenido simple para que podamos discutir los detalles de GRE+IPSEC, sin entrar en los otros puntos de la red. En ella tenemos el router Cisco con dirección IP pública 198.51.100.2 y el router Huawei NE40 con IP pública 203.0.113.66. Ambos están conectados a Internet, y con conectividad entre ellos. Necesitamos establecer un túnel GRE entre los routers y protegerlo mediante IPSec en modo túnel. La dirección del túnel es 172.31.31.0/30. Información importante sobre la licencia y los módulos Consulte con el fabricante de su equipo para ver si no se requiere algún tipo de tarjeta de servicio, o licencia. En el caso del equipo de este laboratorio, el router NE40-M2K no necesitaba ningún módulo físico adicional, sólo la licencia IPSec. En el router Cisco tampoco fue necesaria ninguna licencia, ya que su IOS ya estaba en ADVIPSERVICES-K9 (que contiene toda la base para Ipsec). *Información útil*: si desea ejecutar IKEv1, en el router Huawei necesita un módulo de software para IKEv1 (que se obtiene del proveedor de Huawei). Configuraciones de Cisco IOS XE Así que vamos a configurar el router Cisco para establecer la VPN. No entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf. Configuraciones de la fase 1 según la tabla anterior: Todo lo anterior se refiere a la Fase 1. Así que cuando estés diagnosticando problemas, y él sea de esta etapa, ya sabes dónde cambiar 🙂 . Ahora preparando la fase 2: ¡Demasiado simple en Cisco! Ahora combinaremos las dos fases en un solo perfil: Creación del túnel GRE y adición de la protección IPSec: Configuraciones Huawei A continuación, vamos a configurar el router Huawei para establecer la VPN. Como en el caso de Cisco, no entraré en detalles sobre las interfaces físicas, sólo sobre la VPN. Al final del artículo hay un bloque con su correspondiente conf. La configuración en el router Huawei es un poco más compleja, ya que crea un túnel para el protocolo GRE, y un túnel para IPSec. Además, queremos utilizar la misma IP para ambos túneles, por lo que se necesita un VRF. 😮 Creación de una instancia de servicio para utilizar la VPN (sólo aplicable en NE40): Actualización del nuevo VRF (vpn-instance): Creación de las dos interfaces Loopback con la misma IP (magia VRF). El looback con el túnel IPSec estará en la tabla de enrutamiento público, mientras que el del túnel GRE estará en la tabla VPNA. Ahora llegamos a IPSec. La ACL de tráfico interesante define el tráfico que será protegido por IPSec. En el caso entonces, tendremos el tráfico GRE entre las IPs del sitio A y el sitio B. Tenga en cuenta que sólo hago la comunicación en una dirección – la dirección del router proteger su tráfico). El ACL anterior puede leerse así: “Proteger los datos del protocolo GRE procedentes del VRF vpna entre el origen 203.0.113.66 y el destino 198.51.100.2” Ahora crearemos la fase 1 (recuerda que en cisco incluso se empieza por ella, mucho más sencillo). En el medio tiene algunos ajustes de enlace VPN-Instance, debido a la VRF creada. Todo lo anterior se refiere a la Fase 1. Así que cuando estés diagnosticando problemas, y él sea de esta etapa, ya sabes dónde cambiar 🙂 . Pasamos a la fase 2: Ahora combinaremos las dos fases en un solo perfil: Creación de túneles GRE e IPSEC. Vamos allá para no confundir: Túnel 900 – es un túnel GRE, que opera dentro de la vpna. Túnel 10 – es un túnel IPSec, que funciona en la tabla global La idea en Huawei es que hay un túnel IPSec funcionando en el exterior, y un segundo túnel GRE en el interior, uno encapsulado en el otro. Pero lo curioso es que el túnel GRE va por fuera de la VRF, y el ipsec por dentro. ¿Baguncinha ne? Así que tunnel900 que es el GRE (y que recibe las IPs de /30) usa un destino que va dentro de la VPNA. Y dentro de la VPNA se llega al destino por túnel IPSec. Observe también que la política IPsec se asoció con el túnel 10, utilizando el perfil que se creó. Por último, una ruta que tiene cierta complejidad en sí misma: dentro de la instancia VPNA, digo que para llegar al peer remoto, uso la interfaz IPSec recién creada, siendo el next-hop el propio peer. Y así configuramos el router Huawei. A ver si ahora ha subido. Validación del funcionamiento En el proceso de validación del túnel, debemos recordar siempre que cada fase y etapa depende del establecimiento completo de la otra, por lo que no tiene sentido querer tener conectividad si la fase 1 aún no ha establecido la comunicación. En ambos routers, validaremos en secuencia: Pasemos a las pruebas. Comprobación Cisco Validación de la conectividad mediante ping ICMP Comprobación de que IKEv2 se ha establecido en Fase 1: Cuando no aparece nada en la salida, o no está lista, significa que alguno de los parámetros de la Fase 1 no coincidía. Comprueba en ambos lados si están de acuerdo. Continuamos la validación en la fase 2: En la salida anterior, vemos que los routers han conmutado el contrato de “tráfico interesante”. Cada parte se ha comprometido a proteger una dirección de la comunicación GRE. En secuencia todavía en Fase 2, hay algunos contadores muy importantes que se refieren a paquetes enviados/recibidos/encapsulados/encriptados/verificados. Se encuentra en la salida del comando “show crypto ipsec sa”. Veámoslos. Cuando estos contadores no se incrementan, o siguen incrementando fallos, es porque alguna configuración de Fase 2 no se está casando. Un buen ejemplo sería que sólo se incrementara el contador de encaps/encrypt, y que el de decaps/decrypt se
Lançamento Made4Flow v2
É com muito orgulho que anunciamos o lançamento da versão 2 do Made4Flow e Anti-DDoS. Trazendo diversas melhorias, essa versão traz novas funcionalidades e otimizações. Com um visual bem mais atrativo e opção de customização interativa das Dashboards, o Made4Flow v2 se destaca com sua interface muito mais polida e refinada, e também muito mais rápida e dinâmica comparado ao seu antecessor.
Launch Made4Flow v2
We are very proud to announce the release of version 2 of Made4Flow and Anti-DDoS. Bringing several improvements, this version brings new features and optimizations. With a much more attractive look and interactive dashboard customization option, Made4Flow v2 stands out with its much more polished and refined interface, and also much faster and dynamic compared to its predecessor.
Iniciar Made4Flow v2
Estamos muy orgullosos de anunciar el lanzamiento de la versión 2 de Made4Flow y Anti-DDoS. Con varias mejoras, esta versión aporta nuevas funciones y optimizaciones. Con un aspecto mucho más atractivo y la opción de personalización de los cuadros de mando interactivos, Made4Flow v2 destaca por su interfaz mucho más pulida y refinada, y también mucho más rápida y dinámica en comparación con su predecesora.
O que é TR-069 e como ele pode ajudar os provedores
TR-069 é um protocolo de gestão de dispositivos de rede. Ele permite que provedores de serviços de internet gerenciem e configurem dispositivos de rede, como roteadores e modems, remotamente.
Com TR-069, os provedores podem automatizar tarefas de configuração, monitoramento e manutenção dos dispositivos de rede, o que ajuda a garantir que os serviços de internet funcionem de maneira consistente e eficiente. Além disso, TR-069 também permite aos provedores coletar dados de desempenho dos dispositivos, o que os ajuda a identificar e resolver problemas de maneira rápida e eficiente.
Em resumo, TR-069 é uma ferramenta valiosa para provedores de serviços de internet, pois permite automatizar e gerenciar dispositivos de rede de forma remota, coletar dados de desempenho para identificar e resolver problemas rapidamente, automatizar atualizações de software e firmware e oferecer soluções de gerenciamento de rede para seus clientes, o que pode ajudar a reduzir custos, aumentar a eficiência operacional e aumentar a satisfação e a fidelidade dos clientes.
What is TR-069 and how it can help providers
TR-069 is a network device management protocol. It allows ISPs to remotely manage and configure network devices such as routers and modems.
With TR-069, ISPs can automate configuration, monitoring, and maintenance tasks for network devices, which helps ensure that Internet services run consistently and efficiently. In addition, TR-069 also allows providers to collect device performance data, which helps them identify and resolve issues quickly and efficiently.
In summary, TR-069 is a valuable tool for Internet Service Providers as it allows you to automate and manage network devices remotely, collect performance data to quickly identify and resolve problems, automate software and firmware upgrades, and offer network management for your customers, which can help reduce costs, increase operational efficiency, and increase customer satisfaction and loyalty.
Qué es TR-069 y cómo puede ayudar a los proveedores
TR-069 es un protocolo de gestión de dispositivos de red. Permite a los ISP administrar y configurar de forma remota dispositivos de red como enrutadores y módems.
Con TR-069, los proveedores pueden automatizar las tareas de configuración, supervisión y mantenimiento de los dispositivos de red, lo que contribuye a garantizar que los servicios de Internet funcionen de forma coherente y eficiente. Además, TR-069 también permite a los proveedores recopilar datos de rendimiento del dispositivo, lo que les ayuda a identificar y resolver problemas de manera rápida y eficiente.
En resumen, TR-069 es una herramienta valiosa para los proveedores de servicios de Internet, ya que le permite automatizar y administrar dispositivos de red de forma remota, recopilar datos de rendimiento para identificar y resolver problemas rápidamente, automatizar actualizaciones de software y firmware y ofrecer administración de red para sus clientes. lo que puede ayudar a reducir costos, aumentar la eficiencia operativa y aumentar la satisfacción y lealtad del cliente.
Atualização Made4graph
O Made4graph é um software de gerenciamento do cliente PPPoE e gerencia via TR-069 que conta com diversas funcionalidades que ajudam o provedor a visualizar e tomar ações na rede de seu cliente final.
Estamos em constante construção e desenvolvimento de novas funções dentro do software, acompanhando a evolução do mercado, trazendo novidades e também atendendo as necessidades dos clientes
