Por: João Victor (joao_victor_goncalves@hotmail.

com)

Configurando Juniper SRX para comunicação GRE e IPSEC:

No post a seguir, vamos simular um cenário onde é possível fecharmos um vpn site to site, e um túnel
GRE, isolando essa conectividade em uma tabela de roteamento customizada (inet.0).

A idéia aqui não é trafegar GRE por dentro de um IPSEC, mas sim implementar dois protocolos de
tunelamento independentes um do outro em um mesmo equipamento (no caso do SRX), usando uma
tabela de roteamento diferente da padrão (também SRX) e usando dois fabricantes distintos (Juniper
SRX e Router CISCO).

Abaixo, segue a topologia:

E vamos “viajar” em uma necessidade de usarmos o GRE, IPSEC e uma instancia de roteamento. A idéia
não é demonstrar um “desenho de rede incrível e máster blaster”, mas mostrar o funcionamento dos
dois protocolos de tunelamento + a customização de rotas em uma tabela de roteamento virtual;

 LAN 10 e LAN 20 devem se comunicar de forma bidirecional;

 LAN 10 e LAN 20 precisam de acesso a LAN-30;
 LAN 10 possui um link de internet;
 A rede da LAN-30, e a rede da LAN-20 não podem ser roteadas na tabela de roteamento padrão,
por qualquer motivo plausível que seja. Um motivo aceitável é um conflito de redes. Não
importa o motivo... vamos ver funcionar 😊;
 A LAN 30 não deve conectar em nenhuma máquina/ip da rede LAN-10 e LAN-20;
 A LAN 10 precisa acessar a LAN-20 e vice-versa;
 Então vamos configurar um tunnel GRE entre a LAN-20 e a LAN-10, mas lembre-se que a LAN-20 não
pode ser conhecida na tabela de roteamento padrão do firewall (inet.0). Você talvez pense, “mas não
poderia usar um NAT? ”, sim, poderia, mas, a ideia aqui é mostrar como configuramos as features.

A configuração que eu vou aplicar no RT-LAN-20 será a config abaixo:

!!!INTERFACE LOOPBACK QUE SERÁ USADA COMO SOURCE IP ADDRESS DOS PACOTES GRE´S!!!
interface Loopback20
ip address 2.2.2.1 255.255.255.255
!
interface Tunnel20
ip address 172.16.0.2 255.255.255.0
tunnel source Loopback20  LOOPBACK CONFIGURADA NO ROTEADOR
tunnel destination 1.1.1.1  LOOPBACK CONFIGURADA NO SRX
!
interface FastEthernet0/0  INTERFACE WAN
ip address 200.200.200.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet0/1.20 INTERFACE LAN
encapsulation dot1Q 20
ip address 10.20.20.1 255.255.255.0
!
ip route 1.1.1.1 255.255.255.255 200.200.200.1 ROTA PARA ALCANÇAR A LOOPBACK REMOTA. REPARE
QUE O NEXT-HOP É O “LINK WAN”###
ip route 10.10.10.0 255.255.255.0 172.16.0.1 ROTA PARA ALCANÇAR A LAN-10 REMOTA ATRAVÉS DO
TUNEL GRE. REPARE QUE O NEXT-HOP É O IP DA INTERFACE TUNEL REMOTO###
ip route 10.30.30.0 255.255.255.0 172.16.0.1 ROTA PARA ALCANÇAR A LAN-30 REMOTA ATRAVÉS DO
TUNEL GRE. REPARE QUE O NEXT-HOP É O IP DA INTERFACE TUNEL REMOTO ###

Abaixo a configuração que eu devo aplicar no SRX:

Primeiro eu vou configurar todas as interfaces:

###INTERFACE QUE CONECTA A WAN###

set interfaces ge-0/0/0 unit 0 family inet address 100.100.100.2/24

###INTERFACE GRE###
set interfaces gr-0/0/0 unit 10 tunnel source 1.1.1.1
set interfaces gr-0/0/0 unit 10 tunnel destination 2.2.2.1 ip DA LOOPBACK 20 DO ROUTER LAN-20
set interfaces gr-0/0/0 unit 10 family inet address 172.16.0.1/24

###INTERFACE QUE CONECTA A LAN 10###

set interfaces ge-0/0/1 vlan-tagging
set interfaces ge-0/0/1 unit 10 vlan-id 10
set interfaces ge-0/0/1 unit 10 family inet address 10.10.10.1/24

###INTERFACE QUE CONECTA A INTERNET

set interfaces ge-0/0/2 unit 0 family inet address 11.11.11.2/24

###INTERFACE LOOPBACK QUE SERÁ O SOURCE IP DO GRE###

set interfaces lo0 unit 10 family inet address 1.1.1.1/32
###INTERFACE TUNNEL QUE SERÁ USADA PELO IPSEC###
set interfaces st0 unit 10 family inet

###CONFIGURAÇÃO DE ZONAS###
set security zones security-zone Trust interfaces ge-0/0/1.10
set security zones security-zone Untrust host-inbound-traffic system-services ping
set security zones security-zone Untrust interfaces lo0.10 ###REPARE QUE A INTERFACE LOOPBACK
FICA VINCULADA A ZONA QUE CONECTA A WAN. NO NOSSO CASO É A ZONA UNTRUST###
set security zones security-zone Untrust interfaces ge-0/0/0.0
set security zones security-zone GRE-TO-RT-CISCO host-inbound-traffic system-services ping
set security zones security-zone GRE-TO-RT-CISCO interfaces gr-0/0/0.10
set security zones security-zone INTERNET host-inbound-traffic system-services ike
set security zones security-zone INTERNET host-inbound-traffic system-services ping
set security zones security-zone INTERNET interfaces ge-0/0/2.0
set security zones security-zone VPN-TO-LAN-30 interfaces st0.10

###ROTA ESTÁTICA PARA ALCANÇAR A LOOPBACK QUE ESTÁ CONFIGURADA NO RT-LAN-2###

set routing-options static route 2.2.2.1/32 next-hop 100.100.100.1

###ROTA DEFAULT PARA ACESSO A INTERNET###

set routing-options static route 0.0.0.0/0 next-hop 11.11.11.1

###CONFIGURAÇÃO DE INSTANCIA DE ROTEAMENTO. REPARE QUE O TUNEL GRE E A INTERFACE TUNEL USADA PELO
TUNEL IPSEC ESTÃO ASSOCIADAS A ESSA INSTANCIA DE ROTEAMENTO. A INTERFACE LOOPBACK E A INTERFACE
QUE É O PEER IPSEC VPN NÃO ESTÃO NESSA INSTANCIA DE ROTEAMENTO###
set routing-instances lab-1 instance-type virtual-router
set routing-instances lab-1 interface gr-0/0/0.10
set routing-instances lab-1 interface ge-0/0/1.10
set routing-instances lab-1 interface st0.10
set routing-instances lab-1 routing-options static route 10.20.20.0/24 next-hop gr-0/0/0.10
set routing-instances lab-1 routing-options static route 0.0.0.0/0 next-table inet.0

###CRIAÇÃO DE POLITICAS DE ROTEAMENTO ONDE NÓS DETERMINAMOS QUE APENAS O RANGE 10.10.10.0/24 QUE
ESTÁ NA INSTANCIA lab-1 DEVE SER ACEITA. LOGO ABAIXO VEREMOS PORQUE CRIAMOS ESSA POLITICA E QUAL
O EFEITO###
set policy-options policy-statement FROM-INSTANCE-LAB term 10 from instance lab-1
set policy-options policy-statement FROM-INSTANCE-LAB term 10 from route-filter 10.10.10.0/24
exact
set policy-options policy-statement FROM-INSTANCE-LAB term 10 then accept
set policy-options policy-statement FROM-INSTANCE-LAB term 20 then reject

###POLITICA DE ROTEAMENTO NEGANDO QUALQUER OUTRA ROTA DE QUALQUER OUTRA INSTANCIA DE ROTEAMENTO
CUSTOMIZADA###
set policy-options policy-statement REJECT term 10 then reject

###APLICAÇÃO DE FILTRO DE ROTAS PARA QUE A TABELA DE ROTEAMENTO PADRÃO CONHEÇA A REDE LAN-10. A
POLICY CRIADA ACIMA SERÁ USADA PARA COMPARTILHAR A ROTA DA REDE 10.10.10.0/24 COM A TABELA DE
ROTEAMENTO PADRÃO (inet.0)###
set routing-options instance-import FROM-INSTANCE-LAB
set routing-options instance-import REJECT

###PROPOSTA DE FASE I DO TUNEL IPSEC###

set security ike proposal IKE-AES-256-CBC-SHA1-DH2-PSK authentication-method pre-shared-keys
set security ike proposal IKE-AES-256-CBC-SHA1-DH2-PSK dh-group group2
set security ike proposal IKE-AES-256-CBC-SHA1-DH2-PSK authentication-algorithm sha1
set security ike proposal IKE-AES-256-CBC-SHA1-DH2-PSK encryption-algorithm aes-256-cbc

###POLITICA IKE###
set security ike policy IKE-POLICY-IBM mode main
set security ike policy IKE-POLICY-IBM proposals IKE-AES-256-CBC-SHA1-DH2-PSK
set security ike policy IKE-POLICY-IBM pre-shared-key ascii-text "$9$.mT36/t0OR5QF/AtIRNdVsoJDik"
###DEFINIÇÃO DE GATEWAY VPN ASSOCIANDO A INTERFACE DE INTERNET, QUE PERTENCE A TABELA DE
ROTEAMENTO inet.0, VEMOS TAMBÉM POLITICA DE FASE I, E ENDEREÇO IP DO PEER REMOTO###
set security ike gateway GW-LAB ike-policy IKE-POLICY-IBM
set security ike gateway GW-LAB address 22.22.22.2
set security ike gateway GW-LAB external-interface ge-0/0/2.0

###PROPOSTA DE FASE II###

set security ipsec proposal IPSEC-POL-AES-128-CBC-SHA1-96 protocol esp
set security ipsec proposal IPSEC-POL-AES-128-CBC-SHA1-96 authentication-algorithm hmac-sha1-96
set security ipsec proposal IPSEC-POL-AES-128-CBC-SHA1-96 encryption-algorithm aes-128-cbc

###POLITICA DE FASE II###

set security ipsec policy IPSEC-POL-AES-CBC-SHA1-96 perfect-forward-secrecy keys group2
set security ipsec policy IPSEC-POL-AES-CBC-SHA1-96 proposals IPSEC-POL-AES-128-CBC-SHA1-96

###ASSOCIANDO TODOS OS PARAMETROS DE VPN DESCRITOS ACIMA DENTRO DE UMA CONFIGURAÇÃO DE VPN###
set security ipsec vpn VPN-LAB bind-interface st0.10
set security ipsec vpn VPN-LAB ike gateway GW-LAB
set security ipsec vpn VPN-LAB ike ipsec-policy IPSEC-POL-AES-CBC-SHA1-96
set security ipsec vpn VPN-LAB traffic-selector LAB-1-10 local-ip 10.10.10.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-10 remote-ip 10.30.30.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-20 local-ip 10.20.20.0/24
set security ipsec vpn VPN-LAB traffic-selector LAB-1-20 remote-ip 10.30.30.0/24
set security ipsec vpn VPN-LAB establish-tunnels immediately

###DEFINIÇÃO DE OBJETOS QUE SERÃO REFERENCIADOS NAS POLICIES###

set security address-book global address H_1.1.1.1 1.1.1.1/32
set security address-book global address H_2.2.2.1 2.2.2.1/32
set security address-book global address N_10.20.20.0_24 10.20.20.0/24
set security address-book global address N_10.10.10.0_24 10.10.10.0/24
set security address-book global address N_10.30.30.0_24 10.30.30.0/24

###CONFIGURAÇÃO DE NAT PARA ACESSO A INTERNET###

set security nat source rule-set LAB
set security nat source rule-set LAB
set security nat source rule-set LAB
set security nat source rule-set LAB
set security nat source rule-set LAB
from zone Trust
to zone INTERNET
rule 10 match source-address 10.10.10.0/24
rule 10 match destination-address 0.0.0.0/0
rule 10 then source-nat interface

###CONFIGURAÇÃO DE REGRAS DE FIREWALL. AS REGRAS ESTÃO ANY POIS ESTAMOS EM UM AMBIENTE DE

LABORATÓRIO###
set security policies from-zone GRE-TO-RT-CISCO to-zone Trust policy FROM-RT-TO-LAN-10 match
source-address N_10.20.20.0_24
set security policies from-zone GRE-TO-RT-CISCO to-zone Trust policy FROM-RT-TO-LAN-10 match
destination-address N_10.10.10.0_24
set security policies from-zone GRE-TO-RT-CISCO to-zone Trust policy FROM-RT-TO-LAN-10 match
application any
set security policies from-zone GRE-TO-RT-CISCO to-zone Trust policy FROM-RT-TO-LAN-10 then
permit
set security policies from-zone GRE-TO-RT-CISCO to-zone Trust policy FROM-RT-TO-LAN-10 then log
session-close
set security policies from-zone Trust to-zone GRE-TO-RT-CISCO policy FROM-LAN-10-TO-LAN-20 match
source-address N_10.10.10.0_24
set security policies from-zone Trust to-zone GRE-TO-RT-CISCO policy FROM-LAN-10-TO-LAN-20 match
destination-address N_10.20.20.0_24
set security policies from-zone Trust to-zone GRE-TO-RT-CISCO policy FROM-LAN-10-TO-LAN-20 match
application any
set security policies from-zone Trust to-zone GRE-TO-RT-CISCO policy FROM-LAN-10-TO-LAN-20 then
permit
set security policies from-zone Trust to-zone GRE-TO-RT-CISCO policy FROM-LAN-10-TO-LAN-20 then
log session-close
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN match source-address
N_10.10.10.0_24
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN match source-address
N_10.20.20.0_24
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN match destination-address
N_10.30.30.0_24
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN match application any
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN then permit
set security policies from-zone Trust to-zone VPN-TO-LAN-30 policy VPN then log session-close
set security policies from-zone GRE-TO-RT-CISCO to-zone VPN-TO-LAN-30 policy VPN match source-
address N_10.20.20.0_24
set security policies from-zone GRE-TO-RT-CISCO to-zone VPN-TO-LAN-30 policy VPN match
destination-address N_10.30.30.0_24
set security policies from-zone GRE-TO-RT-CISCO to-zone VPN-TO-LAN-30 policy VPN match
application any
set security policies from-zone GRE-TO-RT-CISCO to-zone VPN-TO-LAN-30 policy VPN then permit
set security policies from-zone GRE-TO-RT-CISCO to-zone VPN-TO-LAN-30 policy VPN then log
session-close
set security policies from-zone Trust to-zone INTERNET policy INTERNET match source-address
N_10.10.10.0_24
set security policies from-zone Trust to-zone INTERNET policy INTERNET match destination-address
any
set security policies from-zone Trust to-zone INTERNET policy INTERNET match application any
set security policies from-zone Trust to-zone INTERNET policy INTERNET then permit
set security policies from-zone Trust to-zone INTERNET policy INTERNET then log session-close

Abaixo a configuração do router RT-LAN-30:

crypto isakmp policy 10
encr aes 256
authentication pre-share
group 2
crypto isakmp key lablab123 address 11.11.11.2 ip da interface de internet do SRX
!
crypto ipsec transform-set LAB esp-aes esp-sha-hmac
!
crypto map LAB 10 ipsec-isakmp
set peer 11.11.11.2
set transform-set LAB
match address 111
!
interface Loopback100
ip address 8.8.8.8 255.255.255.255 Vamos usar essa loopback para similar algum ip na
internet
!
interface FastEthernet0/0
ip address 22.22.22.2 255.255.255.0
duplex auto
speed auto
crypto map LAB Crypto map criada anteriormente é associada a interface de internet do router
!
interface FastEthernet0/1
ip address 10.30.30.1 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 22.22.22.1
!
#TRÁFEGO QUE DEVE SER TUNELADO#
access-list 111 permit ip 10.30.30.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 111 permit ip 10.30.30.0 0.0.0.255 10.20.20.0 0.0.0.255
Agora vamos aos testes. Vamos começar testando o tunel gre entre a VLAN20 e a VLAN10:

1- A partir do roteador RT-LAN-20, eu vou pingar a ponta remota do tunel GRE:

RT-LAN-20#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 92/106/132 ms

2- A partir do SRX eu vou pingar a ponta remota do tunel GRE:

root# run ping 172.16.0.2 routing-instance lab-1 rapid
PING 172.16.0.2 (172.16.0.2): 56 data bytes
!!!!!
--- 172.16.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 17.091/20.007/21.801/1.725 ms
Repare que eu precisei referenciar o parâmetro “routing-instance lab-1”, pois por padrão, se eu
apenas pingar o ip 172.16.0.2, ele vai usar a tabela de roteamento padrão (inet.0), mas o nosso
túnel GRE está na tabela de roteamento lab-1.

3- OK, validamos o túnel GRE, agora vamos validar a conectividade entre as duas vlans (vlan 20
 Vlan 10). No PC que está na vlan 10, ip 10.10.10.110, eu vou fazer um telnet na porta 3389
do ip 10.20.20.220:

Conexão estabelecida, conforme acima.

4- Agora vamos analisar o SRX, e a tabela de sessão que ele criou para essa sessão:
root# run show security flow session protocol tcp
Session ID: 184620, Policy name: FROM-LAN-10-TO-LAN-20/5, Timeout: 1794, Valid
In: 10.10.10.110/49163 --> 10.20.20.220/3389;tcp, If: ge-0/0/1.10, Pkts: 2, Bytes: 88
Out: 10.20.20.220/3389 --> 10.10.10.110/49163;tcp, If: gr-0/0/0.10, Pkts: 1, Bytes: 48
Total sessions: 1

Agora, vamos dissecar a saída acima:

Session ID: 184620, Policy name: FROM-LAN-10-TO-LAN-20/5, Timeout: 1794, Valid
Acima nós vemos o id da sessão que foi criada para a conexão tcp, a policy em
uso é a policy “FROM-LAN-10-TO-LAN-20”, que é uma “regra any”. Em um cenário
real, não recomendo o uso de “regra any”, mas para laboratórios, não vejo
problema. Considere a verificação de regras (Security-policies) em um cenário
real.

In: 10.10.10.110/49163 --> 10.20.20.220/3389;tcp, If: ge-0/0/1.10, Pkts: 2,

A linha acima, mostra a conexão de entrada para o ip 10.20.20.220 a partir do
ip 10.10.10.110. A interface de entrada é a ge-0/0/1.10 e dois pacotes foram
enviados para essa sessão, nesta direção.

Out: 10.20.20.220/3389 --> 10.10.10.110/49163;tcp, If: gr-0/0/0.10, Pkts: 1, Bytes: 48

A linha acima, mostra a conexão de retorno para do ip 10.20.20.220 para o ip
10.10.10.110. E a interface de entrada, para este fluxo de retorno é a
interface gr-0/0/0.10, ou seja, nosso tunnel GRE 😊.

5- Vamos agora, analisar o sentido contrário: from vlan 20 to vlan 10:

6- Vamos analisar a tabela de conexão do firewall:

root# run show security flow session protocol tcp
Session ID: 238328, Policy name: FROM-RT-TO-LAN-10/4, Timeout: 1742, Valid
In: 10.20.20.220/49161 --> 10.10.10.110/3389;tcp, If: gr-0/0/0.10, Pkts: 2, Bytes: 88
Out: 10.10.10.110/3389 --> 10.20.20.220/49161;tcp, If: ge-0/0/1.10, Pkts: 1, Bytes: 48
Total sessions: 1
Como já analisamos um log parecido nas etapas acima, vou ser mais breve neste aqui.

Conforme acima, podemos ver que o trafego de entrada chega pelo Tunel GRE interface gr-
0/0/0.10 e o trafego de retorno volta pela interface ge-0/0/1.10.
Ok, túnel GRE está validado. Evidencias estatísticas podem ser obtidas através da verificação de
contadores de interface.

O túnel gre é uma interface lógica, mas o JUNOS considera essa interface como qualquer outra, então,
vamos analisar o que os comandos de verificação de interface podem nos oferecer:

- show interface gr-0/0/0.10:

root> show interfaces gr-0/0/0.10
Logical interface gr-0/0/0.10 (Index 77) (SNMP ifIndex 518)
Flags: Point-To-Point SNMP-Traps 0x4000
IP-Header 2.2.2.1:1.1.1.1:47:df:64:0000000000000000 Encapsulation:
GRE-NULL
Gre keepalives configured: Off, Gre keepalives adjacency state:
down
Input packets : 30469
Output packets: 33622
Security: Zone: GRE-TO-RT-CISCO
Allowed host-inbound traffic : ping
Protocol inet, MTU: 1476
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 172.16.0/24, Local: 172.16.0.1, Broadcast:
172.16.0.255

Acima temos informações relevantes como:

 Cabeçalho do pacote gre, repare que ele possui o ip das loopbacks e protocol number 47. Ou
seja na rede WAN, o cabeçalho dos pacotes que irão trafegar possuem apenas os ips 1.1.1.1/32
e 2.2.2.1/32 como source/destination;
 Encapsulamento;
 Contadores de INPUT e OUTPUT;
 MTU.

Não que as outras informações sejam irrelevantes, na verdade o que “julga” a informação relevante ou
não, é a sua necessidade e o que você está verificando.

Outros comandos que trazem mais informações são:

Show int gr-0/0/0.10 extensive
Show int gr-0/0/0.10 detail
 show interfaces gr-0/0/0.10 terse

Divirta-se com eles. 😊

Agora, vamos verificar o túnel IPSEC e a comunicação que passa por ele:

1- Vamos começar verificando se a fase I foi estabelecida:

root> show security ike sa
Index State Initiator cookie Responder cookie Mode Remote Address
8006454 UP cda95f4f269b0c9d 680734d72e3a646d Main 22.22.22.2
De acordo com o log acima, a fase I está estabelecida.

Ou:

root> show security ike sa detail

IKE peer 22.22.22.2, Index 8006454, Gateway Name: GW-LAB
Role: Initiator, State: UP
Initiator cookie: cda95f4f269b0c9d, Responder cookie: 680734d72e3a646d
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 11.11.11.2:500, Remote: 22.22.22.2:500
Lifetime: Expires in 19633 seconds
Peer ike-id: 22.22.22.2
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes256-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-2
Traffic statistics:
Input bytes : 3140
Output bytes : 4080
Input packets: 11
Output packets: 27
Flags: IKE SA is created
IPSec security associations: 8 created, 0 deleted
Phase 2 negotiations in progress: 0

Negotiation type: Quick mode, Role: Initiator, Message ID: 0

Local: 11.11.11.2:500, Remote: 22.22.22.2:500
Local identity: 11.11.11.2
Remote identity: 22.22.22.2
Flags: IKE SA is created

No roteador Cisco:
Router#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
22.22.22.2 11.11.11.2 QM_IDLE 1018 0 ACTIVE

IPv6 Crypto ISAKMP AS

OU:
Router#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
 K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id Local Remote I-VRF Status Encr Hash Auth DH Lifetime Cap.

1018 22.22.22.2 11.11.11.2 ACTIVE aes sha psk 2 06:31:25

Engine-id:Conn-id = SW:18

IPv6 Crypto ISAKMP SA

Ok, fase I negociada com sucesso. 😊

2- Vamos verificar se a fase II foi estabelecida:

Existem inúmeras formas de ver isso, a mais rápida é verificando se os “endpoints” se falam
através do túnel. Por exemplo, o ip 10.20.20.220 consegue fazer telnet na porta 3389 do
10.30.30.3:

Funcionou!!! Se funcionou quer dizer que o túnel está 100% estabelecido. Mas, mesmo assim,
seguem abaixo comandos que comprovam isso:

root> show security ipsec sa detail

ID: 268173313 Virtual-system: root, VPN Name: VPN-LAB
Local Gateway: 11.11.11.2, Remote Gateway: 22.22.22.2
Traffic Selector Name: LAB-1-10
Local Identity: ipv4(10.10.10.0-10.10.10.255)
Remote Identity: ipv4(10.30.30.0-10.30.30.255)
Version: IKEv1
DF-bit: clear
Bind-interface: st0.10

Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29

Last Tunnel Down Reason: Lifetime expired
Direction: inbound, SPI: b0f7f642, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2786 seconds
Lifesize Remaining: 4608000 kilobytes
Soft lifetime: Expires in 2148 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64

Direction: outbound, SPI: 7ba4a1f4, AUX-SPI: 0

, VPN Monitoring: -
Hard lifetime: Expires in 2786 seconds
Lifesize Remaining: 4608000 kilobytes
Soft lifetime: Expires in 2148 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
 ID: 268173314 Virtual-system: root, VPN Name: VPN-LAB
Local Gateway: 11.11.11.2, Remote Gateway: 22.22.22.2
Traffic Selector Name: LAB-1-20
Local Identity: ipv4(10.20.20.0-10.20.20.255)
Remote Identity: ipv4(10.30.30.0-10.30.30.255)
Version: IKEv1
DF-bit: clear
Bind-interface: st0.10

Port: 500, Nego#: 0, Fail#: 0, Def-Del#: 0 Flag: 0x2c608b29

Last Tunnel Down Reason: Lifetime expired
Direction: inbound, SPI: 42392cd0, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2800 seconds
Lifesize Remaining: 4607999 kilobytes
Soft lifetime: Expires in 2171 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64

Direction: outbound, SPI: 199c67e1, AUX-SPI:

, VPN Monitoring: -
Hard lifetime: Expires in 2800 seconds
Lifesize Remaining: 4607999 kilobytes
Soft lifetime: Expires in 2171 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
Anti-replay service: counter-based enabled, Replay window size: 64

Observe que este comando traz como informação, peer local, remote peer, o nome da vpn,
traffic selector, ou seja, o trafego que precisa ser tunelado e foi definido na config de vpn e
muito mais informação.

Abaixo a mesma verificação no router Cisco:

Router#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: LAB, local addr 22.22.22.2

protected vrf: (none)

local ident (addr/mask/prot/port): (10.30.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.10.10.0/255.255.255.0/0/0)
current_peer 11.11.11.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0 Estes contadores estão zerados porque
a rede 10.10.10.0/24 não tinha ainda “conversado” com a rede VLAN30.
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 3, #recv errors 0

local crypto endpt.: 22.22.22.2, remote crypto endpt.: 11.11.11.2

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xB0F7F642(2969040450)

inbound esp sas:

 spi: 0x7BA4A1F4(2074386932)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 701, flow_id: SW:701, crypto map: LAB
sa timing: remaining key lifetime (k/sec): (4606674/2622)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xB0F7F642(2969040450)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 702, flow_id: SW:702, crypto map: LAB
sa timing: remaining key lifetime (k/sec): (4606674/2622)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

protected vrf: (none)

local ident (addr/mask/prot/port): (10.30.30.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.20.20.0/255.255.255.0/0/0)
current_peer 11.11.11.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 269, #pkts encrypt: 269, #pkts digest: 269 Como já tivemos comunicação bi-
direcional entre as duas redes, então, os contadores refente a esse fluxo, incrementou.
#pkts decaps: 317, #pkts decrypt: 317, #pkts verify: 317
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 22.22.22.2, remote crypto endpt.: 11.11.11.2

path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x42392CD0(1111043280)

inbound esp sas:

spi: 0x199C67E1(429680609)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 703, flow_id: SW:703, crypto map: LAB
sa timing: remaining key lifetime (k/sec): (4571389/2629)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0x42392CD0(1111043280)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 704, flow_id: SW:704, crypto map: LAB
 sa timing: remaining key lifetime (k/sec): (4571389/2629)
IV size: 16 bytes
replay detection support:
Status: ACTIVE

outbound ah sas:
outbound pcp sas:

Voltando ao SRX, para verificar se o túnel vpn está incrementando trafego bidirecional, use o
comando abaixo:
root> show interfaces st0.10
Logical interface st0.10 (Index 71) (SNMP ifIndex 512)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 269
Output packets: 317
Security: Zone: VPN-TO-LAN-30
Protocol inet, MTU: 9192
Flags: Sendbcast-pkt-to-re

Lembre-se que, a interface st0.10, também é uma interface como qualquer outra e o JUNOS
mostrará estatísticas de pacotes entrando e saindo dessa interface.

Já sabemos que está tudo funcionando no nosso laboratório, mas apenas para entendermos
como o JUNOS vai rotear o trafego, vamos analisar a tabela de roteamento customizada (lab-1)
que nós criamos:
root> show route table lab-1.inet.0

lab-1.inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 20:04:20 TRAFEGO DE INTERNET SERÁ ENVIADO PARA A TABELA

PADRÃO
to table inet.0
10.10.10.0/24 *[Direct/0] 6d 20:20:35
> via ge-0/0/1.10
10.10.10.1/32 *[Local/0] 6d 20:20:39
Local via ge-0/0/1.10
10.20.20.0/24 *[Static/5] 20:04:20 ROTA PARA ALCANÇAR A REDE VLAN 20 É INSTALADA
USANDO COMO INTERFACE DE SAIDA O TUNEL GRE
> via gr-0/0/0.10
10.30.30.0/24 *[Static/5] 6d 01:12:52
> via st0.10ROTA PARA ALCANÇAR A REDE VLAN 30 É INSTALADA NA TABELA DE
ROTEAMENTO USANDO A INTERFACE TUNEL ST0.10
100.10.10.0/24 *[Direct/0] 2d 02:02:18
> via ge-0/0/1.100
100.10.10.2/32 *[Local/0] 2d 02:02:18
Local via ge-0/0/1.100
172.16.0.0/24 *[Direct/0] 6d 20:20:35
> via gr-0/0/0.10
172.16.0.1/32 *[Local/0] 6d 20:20:38
Local via gr-0/0/0.10
192.168.0.0/24 *[Static/5] 20:04:20
> to 100.10.10.1 via ge-0/0/1.100
200.20.20.0/24 *[Direct/0] 2d 02:02:18
> via ge-0/0/1.200
200.20.20.2/32 *[Local/0] 2d 02:02:18
Local via ge-0/0/1.200
 Tabela de roteamento padrão (inet.0):

root> show route table inet.0

inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)

+ = Active Route, - = Last Active, * = Both

0.0.0.0/0 *[Static/5] 6d 20:25:53

> to 11.11.11.1 via ge-0/0/2.0
1.1.1.1/32 *[Direct/0] 6d 20:26:23 LOOPBACK LOCAL INSTALADA NA TABELA DE
ROTEAMENTO PADRÃO
> via lo0.10
2.2.2.1/32 *[Static/5] 6d 20:25:53 LOOPBACK REMOTA INSTALADA NA TABELA DE
ROTEAMENTO PADRÃO E USA INTERFACE WAN/IP WAN PARA ALCANÇAR.
> to 100.100.100.1 via ge-0/0/0.0

10.10.10.0/24 *[Direct/0] 6d 20:25:53 A REDE VLAN-10 SÓ APARECE NESSA TABELA, PORQUÊ

NÓS USAMOS O RECURSO DE POLITICA DE ROTEAMENTO. REPARE QUE A ROTA NÃO APARECE COMO UMA ROTA
DA TABELA lab-1, MAS É COMO SE A ROTA TIVESSE “VAZADO” PARA A TABELA PADRÃO, POR ISSO A
JUNIPER CHAMA ESTE RECURSO DE “ROUTE-LEAKS”.
> via ge-0/0/1.10
11.11.11.0/24 *[Direct/0] 6d 20:25:53
> via ge-0/0/2.0
11.11.11.2/32 *[Local/0] 6d 20:25:57
Local via ge-0/0/2.0
100.100.100.0/24 *[Direct/0] 6d 20:25:53
> via ge-0/0/0.0
100.100.100.2/32 *[Local/0] 6d 20:25:58
Local via ge-0/0/0.0

Vamos testar o acesso da vlan-10 á “internet”, lembre-se que o RT-LAN-30 possui uma loopback
com ip 8.8.8.8. Então, vamos fechar um telnet nesse ip, na porta 80, e ver como a sessão é
criada no firewall:

Segue a tabela de sessão do SRX:

root> show security flow session protocol tcp
Session ID: 87120, Policy name: INTERNET/8, Timeout: 206, Valid
In: 10.10.10.110/49165 --> 8.8.8.8/80;tcp, If: ge-0/0/1.10, Pkts: 10, Bytes: 432
Out: 8.8.8.8/80 --> 11.11.11.2/18094;tcp, If: ge-0/0/2.0, Pkts: 5, Bytes: 204
Total sessions: 1

Analisando o log acima vemos que:

- A security policy internet é usada para liberar esse trafego;
- interface de entrada é a ge-0/0/1.10;
- interface de retorno do trafego é a ge-0/0/2.0;
- O ip 8.8.8.8 está respondendo para o ip nat 11.11.11.2;
 Vamos ter certeza de que a vlan-30 não conecta em nenhum ip da vlan-10 e vlan-20. Para isso
eu vou criar um filtro:
set security flow traceoptions file PKT-FILTER
set security flow traceoptions file size 2m
set security flow traceoptions file files 5
set security flow traceoptions file world-readable
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter lab-1-filter source-prefix 10.30.30.0/24
set security flow traceoptions packet-filter lab-1-filter destination-prefix 10.10.10.0/24

E abaixo, segue o log negando o ping da rede 10.30.30.0/24 para o ip 10.10.10.110 e

10.20.20.220 (eu mudei a ultima linha do script acima para “destination-prefix
10.20.20.0/24”:
Dec 28 17:24:43 17:24:43.704659:CID-0:RT: 10.30.30.1/2048 -> 10.10.10.110/49140 proto 1
Dec 28 17:24:43 17:24:43.704664:CID-0:RT: packet dropped, denied by policy
Dec 28 17:24:43 17:24:43.704665:CID-0:RT: denied by policy default-policy-00(2), dropping pkt
Dec 28 17:24:43 17:24:43.704666:CID-0:RT: packet dropped, policy deny.

Dec 28 17:36:02 17:36:01.892889:CID-0:RT: 10.30.30.1/2048 -> 10.20.20.220/26284 proto 1

Dec 28 17:36:02 17:36:01.892892:CID-0:RT: packet dropped, denied by policy
Dec 28 17:36:02 17:36:01.892894:CID-0:RT: denied by policy default-policy-00(2), dropping pkt
Dec 28 17:36:02 17:36:01.892895:CID-0:RT: packet dropped, policy deny.
Tudo funcionando conforme esperado 😊.

No próximo post vou usar basicamente o mesmo cenário, mas irei exemplificar o uso de
roteamento de origem em tabelas de roteamento customizada, para alcançar um determinado
ip.

Até mais,
João Victor