Skip to main content

DMVPN - IPv6 - VRF

In my today lab I will try to implement DMVPN with some additional features like VRF and IPv6. As you see in the below picture, routers can establish secure connection over ASA.

dmvpn-4-2.jpg

My basic ip/ipv6 configuration:

hub:
 
hostname R1
!
vrf definition GREEN
 !
 address-family ipv6
 exit-address-family
!
ip vrf RED
!
ipv6 unicast-routing
!
interface Loopback100
 vrf forwarding GREEN
 no ip address
 ipv6 address 2001:100::1/64
!
interface FastEthernet0/0
 ip vrf forwarding RED
 ip address 5.5.5.1 255.255.255.0
 speed auto
 duplex auto
!
ip route vrf RED 0.0.0.0 0.0.0.0 5.5.5.2

next the spoke1:
 
hostname R2
!
vrf definition GREEN
 !
 address-family ipv6
 exit-address-family
!
ip vrf RED
!
ipv6 unicast-routing
!
interface Loopback100
 vrf forwarding GREEN
 no ip address
 ipv6 address 2001:200::2/64
!
interface FastEthernet0/0
 ip vrf forwarding RED
 ip address 6.6.6.1 255.255.255.0
 duplex auto
 speed auto
!
ip route vrf RED 0.0.0.0 0.0.0.0 6.6.6.2

and the spoke2:
 
hostname R3
!
vrf definition GREEN
 !
 address-family ipv6
 exit-address-family
!
ip vrf RED
!
ipv6 unicast-routing
!
interface Loopback100
 vrf forwarding GREEN
 no ip address
 ipv6 address 2001:300::3/64
 ipv6 enable
!
interface FastEthernet0/0
 ip vrf forwarding RED
 ip address 7.7.7.1 255.255.255.0
 duplex auto
 speed auto
!
ip route vrf RED 0.0.0.0 0.0.0.0 7.7.7.2

Let’s test the basic connectivity:
 
R1#ping vrf RED 6.6.6.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 60/64/68 ms
R1#
R1#ping vrf RED 7.7.7.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 7.7.7.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/68/108 ms
R1#

ASA configuration:
 
!
interface GigabitEthernet0
 nameif spoke1
 security-level 0
 ip address 6.6.6.2 255.255.255.0
!
interface GigabitEthernet1
 nameif spoke2
 security-level 0
 ip address 7.7.7.2 255.255.255.0
!
interface GigabitEthernet2
 nameif inside
 security-level 100
 ip address 5.5.5.2 255.255.255.0
!

Let’s start DMVPN part:

Hub:
 
!
interface Tunnel0
 vrf forwarding GREEN
 no ip address
 no ip redirects
 ipv6 address FE80::2001 link-local
 ipv6 address 2001:DB8:1:1::1/64
 ipv6 nhrp authentication cisco123
 ipv6 nhrp map multicast dynamic
 ipv6 nhrp network-id 100
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf RED

!

spoke1:
 
!
interface Tunnel0
 vrf forwarding GREEN
 no ip address
 no ip redirects
 ipv6 address FE80::2002 link-local
 ipv6 address 2001:DB8:1:1::2/64
 ipv6 nhrp authentication cisco123
 ipv6 nhrp map multicast 5.5.5.1
 ipv6 nhrp map 2001:DB8:1:1::1/64 5.5.5.1
 ipv6 nhrp network-id 100
 ipv6 nhrp nhs 2001:DB8:1:1::1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf RED
!

spoke2:
 
!
interface Tunnel0
 vrf forwarding GREEN
 no ip address
 no ip redirects
 ipv6 address FE80::2003 link-local
 ipv6 address 2001:DB8:1:1::3/64
 ipv6 nhrp authentication cisco123
 ipv6 nhrp map multicast 5.5.5.1
 ipv6 nhrp map 2001:DB8:1:1::1/64 5.5.5.1
 ipv6 nhrp network-id 100
 ipv6 nhrp nhs 2001:DB8:1:1::1
 tunnel source FastEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf RED
!

On ASA I see following messages:
 
%ASA-3-106010: Deny inbound protocol 47 src spoke1:6.6.6.1 dst inside:5.5.5.1
%ASA-3-106010: Deny inbound protocol 47 src spoke2:7.7.7.1 dst inside:5.5.5.1

Let’s fix it:
 
access-list SPOKE1 ext permit gre host 6.6.6.1 host 5.5.5.1
access-group SPOKE1 in inter spoke1

access-list SPOKE2 ext permit gre host 7.7.7.1 host 5.5.5.1
access-group SPOKE2 in inter spoke2

It works fine:
 
asa1(config)# sh conn
4 in use, 4 most used
GRE spoke2 7.7.7.1:0 inside 5.5.5.1:0, idle 0:00:54, bytes 168, flags E
GRE spoke1 6.6.6.1:0 inside 5.5.5.1:0, idle 0:01:22, bytes 168, flags E
GRE spoke2 7.7.7.1:0 inside 5.5.5.1:0, idle 0:00:54, bytes 232, flags E
GRE spoke1 6.6.6.1:0 inside 5.5.5.1:0, idle 0:01:22, bytes 232, flags E
asa1(config)#

I check now DMVPN (unprotected yet) status on all peers:

1) hub
 
R1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv6 NHRP Details
Type:Hub, Total NBMA Peers (v4/v6): 2
    1.Peer NBMA Address: 6.6.6.1
        Tunnel IPv6 Address: 2001:DB8:1:1::2
        IPv6 Target Network: 2001:DB8:1:1::2/128
        # Ent: 1, Status: UP, UpDn Time: 00:00:20, Cache Attrib: D
    2.Peer NBMA Address: 7.7.7.1
        Tunnel IPv6 Address: 2001:DB8:1:1::3
        IPv6 Target Network: 2001:DB8:1:1::3/128
        # Ent: 1, Status: UP, UpDn Time: 00:02:47, Cache Attrib: D

R1#
R1#sh dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 2001:DB8:1:1::1, VRF "GREEN"
   Tunnel Src./Dest. addr: 5.5.5.1/MGRE, Tunnel VRF "RED"
   Protocol/Transport: "multi-GRE/IP", Protect ""
   Interface State Control: Disabled
   nhrp event-publisher : Disabled
Type:Hub, Total NBMA Peers (v4/v6): 2
    1.Peer NBMA Address: 6.6.6.1
        Tunnel IPv6 Address: 2001:DB8:1:1::2
        IPv6 Target Network: 2001:DB8:1:1::2/128
        # Ent: 2, Status: UP, UpDn Time: 00:05:06, Cache Attrib: D
    2.Peer NBMA Address: 6.6.6.1
        Tunnel IPv6 Address: 2001:DB8:1:1::2
        IPv6 Target Network: FE80::2002/128
        # Ent: 0, Status: UP, UpDn Time: 00:05:06, Cache Attrib: D
    3.Peer NBMA Address: 7.7.7.1
        Tunnel IPv6 Address: 2001:DB8:1:1::3
        IPv6 Target Network: 2001:DB8:1:1::3/128
        # Ent: 2, Status: UP, UpDn Time: 00:07:33, Cache Attrib: D
    4.Peer NBMA Address: 7.7.7.1
        Tunnel IPv6 Address: 2001:DB8:1:1::3
        IPv6 Target Network: FE80::2003/128
        # Ent: 0, Status: UP, UpDn Time: 00:07:33, Cache Attrib: D


Crypto Session Details:
--------------------------------------------------------------------------------

Pending DMVPN Sessions:

R1#

2) spoke1
 
R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv6 NHRP Details
Type:Spoke, Total NBMA Peers (v4/v6): 1
    1.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: 2001:DB8:1:1::1
        IPv6 Target Network: 2001:DB8:1:1::/64
        # Ent: 1, Status: UP, UpDn Time: 00:02:59, Cache Attrib: S

R2#
R2#sh dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 2001:DB8:1:1::2, VRF "GREEN"
   Tunnel Src./Dest. addr: 6.6.6.1/MGRE, Tunnel VRF "RED"
   Protocol/Transport: "multi-GRE/IP", Protect ""
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv6 NHS:
2001:DB8:1:1::1  RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1
    1.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: 2001:DB8:1:1::1
        IPv6 Target Network: 2001:DB8:1:1::/64
        # Ent: 2, Status: UP, UpDn Time: 00:04:37, Cache Attrib: S
    2.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: FE80::2001
        IPv6 Target Network: FE80::2001/128
        # Ent: 0, Status: NHRP, UpDn Time: never, Cache Attrib: S


Crypto Session Details:
--------------------------------------------------------------------------------

Pending DMVPN Sessions:

R2#

3) spoke2
 
R3#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface: Tunnel0, IPv6 NHRP Details
Type:Spoke, Total NBMA Peers (v4/v6): 1
    1.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: 2001:DB8:1:1::1
        IPv6 Target Network: 2001:DB8:1:1::/64
        # Ent: 1, Status: UP, UpDn Time: 00:05:44, Cache Attrib: S

R3#
R3#sh dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================

Interface Tunnel0 is up/up, Addr. is 2001:DB8:1:1::3, VRF "GREEN"
   Tunnel Src./Dest. addr: 7.7.7.1/MGRE, Tunnel VRF "RED"
   Protocol/Transport: "multi-GRE/IP", Protect ""
   Interface State Control: Disabled
   nhrp event-publisher : Disabled

IPv6 NHS:
2001:DB8:1:1::1  RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1
    1.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: 2001:DB8:1:1::1
        IPv6 Target Network: 2001:DB8:1:1::/64
        # Ent: 2, Status: UP, UpDn Time: 00:06:16, Cache Attrib: S
    2.Peer NBMA Address: 5.5.5.1
        Tunnel IPv6 Address: FE80::2001
        IPv6 Target Network: FE80::2001/128
        # Ent: 0, Status: NHRP, UpDn Time: never, Cache Attrib: S


Crypto Session Details:
--------------------------------------------------------------------------------

Pending DMVPN Sessions:

R3#

I check now the NHRP status and as you see below the NHRP mappings is done for link-local address too:

1) hub
 
R1#sh ipv6 nhrp
2001:DB8:1:1::2/128 via 2001:DB8:1:1::2
   Tunnel0 created 00:10:16, expire 01:50:19
   Type: dynamic, Flags: unique registered used
   NBMA address: 6.6.6.1
2001:DB8:1:1::3/128 via 2001:DB8:1:1::3
   Tunnel0 created 00:12:08, expire 01:47:51
   Type: dynamic, Flags: unique registered used
   NBMA address: 7.7.7.1
FE80::2002/128 via 2001:DB8:1:1::2
   Tunnel0 created 00:09:41, expire 01:50:19
   Type: dynamic, Flags: unique registered
   NBMA address: 6.6.6.1
FE80::2003/128 via 2001:DB8:1:1::3
   Tunnel0 created 00:12:08, expire 01:47:51
   Type: dynamic, Flags: unique registered
   NBMA address: 7.7.7.1
R1#
R1#sh ipv6 nhrp multicast
  I/F     NBMA address
Tunnel0    7.7.7.1         Flags: dynamic
Tunnel0    6.6.6.1         Flags: dynamic
R1#

2) spoke1
 
R2#sh ipv6 nhrp
2001:DB8:1:1::/64 via 2001:DB8:1:1::1
   Tunnel0 created 00:11:48, never expire
   Type: static, Flags: used
   NBMA address: 5.5.5.1
FE80::2001/128 via FE80::2001
   Tunnel0 created 00:11:47, never expire
   Type: static, Flags:
   NBMA address: 5.5.5.1
R2#
R2#sh ipv6 nhrp multicast
  I/F     NBMA address
Tunnel0    5.5.5.1         Flags: static
R2#

3) spoke2
 
R3#sh ipv6 nhrp
2001:DB8:1:1::/64 via 2001:DB8:1:1::1
   Tunnel0 created 00:33:06, never expire
   Type: static, Flags: used
   NBMA address: 5.5.5.1
FE80::2001/128 via FE80::2001
   Tunnel0 created 00:14:56, never expire
   Type: static, Flags:
   NBMA address: 5.5.5.1
R3#
R3#sh ipv6 nhrp multicast
  I/F     NBMA address
Tunnel0    5.5.5.1         Flags: static
R3#

Let’s test ipv6 connectivity:
 
R1#ping vrf GREEN ipv6 2001:DB8:1:1::2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1:1::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 152/157/168 ms
R1#
R1#ping vrf GREEN ipv6 2001:DB8:1:1::3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1:1::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 124/146/160 ms
R1#

Now my peers need to learn about their LAN’s. I will static routes:

R1:
 
ipv6 route vrf GREEN 2001:200::/64 Tunnel0 2001:DB8:1:1::2
ipv6 route vrf GREEN 2001:300::/64 Tunnel0 2001:DB8:1:1::3

R2:
 
ipv6 route vrf GREEN 2001:100::/64 Tunnel0 2001:DB8:1:1::1
ipv6 route vrf GREEN 2001:300::/64 Tunnel0 2001:DB8:1:1::3

R3:
 
ipv6 route vrf GREEN 2001:100::/64 Tunnel0 2001:DB8:1:1::1
ipv6 route vrf GREEN 2001:200::/64 Tunnel0 2001:DB8:1:1::2

As you see the IPv6 routing works fine:
 
R1#ping vrf GREEN ipv6 2001:200::2 source loop100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:200::2, timeout is 2 seconds:
Packet sent with a source address of 2001:100::1%GREEN
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 136/148/152 ms
R1#
R1#
R1#ping vrf GREEN ipv6 2001:300::3 source loop100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:300::3, timeout is 2 seconds:
Packet sent with a source address of 2001:100::1%GREEN
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 140/169/224 ms
R1#

As you see the DMVPN works in the phase 1:
 
R2#traceroute vrf GREEN ipv6 2001:300::3
Type escape sequence to abort.
Tracing the route to 2001:300::3

  1 2001:DB8:1:1::1 128 msec 124 msec 136 msec
  2 2001:DB8:1:1::3 252 msec 172 msec 236 msec
R2#

The last step is adding the IPsec. Because we have two VRFs here I need to start with a keyring:
 
crypto keyring KEYRING vrf RED
  pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123

then VRF-aware ISAKMP profile:
 
crypto isakmp profile ISAKMP-PROFILE
   keyring KEYRING
   match identity address 0.0.0.0 RED

basic isakmp and ipsec policy:
 
crypto isakmp policy 10
 encr 3des
 authentication pre-share
 group 2
!
crypto ipsec transform-set TS esp-3des esp-sha-hmac

and then IPsec profile:
 
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS
 set isakmp-profile ISAKMP-PROFILE

and next I apply the profile on the tunnel interface:
 
interface tunnel0
tunnel protection ipsec profile IPSEC-PROFILE

I enable debug to see what is going on:
 
R1#debug crypto isakmp
Crypto ISAKMP debugging is on
R1#
*Jan  6 01:05:03.353: ISAKMP (1002): received packet from 6.6.6.1 dport 500 sport 500 RED (R) QM_IDLE
*Jan  6 01:05:03.357: ISAKMP:(1002):deleting node 1192631245 error FALSE reason "QM done (await)"
*Jan  6 01:05:03.357: ISAKMP:(1002):Node 1192631245, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
*Jan  6 01:05:03.361: ISAKMP:(1002):Old State = IKE_QM_R_QM2  New State = IKE_QM_PHASE2_COMPLETE
*Jan  6 01:05:04.025: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
*Jan  6 01:05:04.025: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: retransmit phase 1
*Jan  6 01:05:04.029: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
R1#
*Jan  6 01:05:04.029: ISAKMP:(0): sending packet to 7.7.7.1 my_port 500 peer_port 500 (I) MM_NO_STATE
*Jan  6 01:05:04.033: ISAKMP:(0):Sending an IKE IPv4 Packet.
R1#

Hm, I think I have to check my ASA:
 
%ASA-4-106023: Deny udp src spoke1:6.6.6.1/500 dst inside:5.5.5.1/500 by access-group "SPOKE1" [0x0, 0x0]
%ASA-4-106023: Deny icmp src spoke2:7.7.7.1 dst inside:5.5.5.1 (type 3, code 3) by access-group "SPOKE2" [0x0, 0x0]
%ASA-4-106023: Deny protocol 50 src spoke1:6.6.6.1 dst inside:5.5.5.1 by access-group "SPOKE1" [0x0, 0x0]
%ASA-4-106023: Deny protocol 50 src spoke1:6.6.6.1 dst inside:5.5.5.1 by access-group "SPOKE1" [0x0, 0x0]
%ASA-4-106023: Deny protocol 50 src spoke1:6.6.6.1 dst inside:5.5.5.1 by access-group "SPOKE1" [0x0, 0x0]
%ASA-4-106023: Deny protocol 50 src spoke1:6.6.6.1 dst inside:5.5.5.1 by access-group "SPOKE1" [0x0, 0x0]
%ASA-4-106023: Deny icmp src spoke2:7.7.7.1 dst inside:5.5.5.1 (type 3, code 3) by access-group "SPOKE2" [0x0, 0x0]

At the moment only GRE is allowed and I have to add UDP/500 and ESP:
 
access-list SPOKE1 ext permit udp host 6.6.6.1 host 5.5.5.1 eq 500
access-list SPOKE1 ext permit esp host 6.6.6.1 host 5.5.5.1

access-list SPOKE2 ext permit udp host 7.7.7.1 host 5.5.5.1 eq 500
access-list SPOKE2 ext permit esp host 7.7.7.1 host 5.5.5.1

I found one mistake in my config -> missing IVRF:
 
R2#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel0
Profile: ISAKMP-PROFILE
Uptime: 00:01:00
Session status: UP-ACTIVE
Peer: 5.5.5.1 port 500 fvrf: RED ivrf: (none)
      Phase1_id: 5.5.5.1
      Desc: (none)
  IKEv1 SA: local 6.6.6.1/500 remote 5.5.5.1/500 Active
          Capabilities:(none) connid:1003 lifetime:23:58:58
  IPSEC FLOW: permit 47 host 6.6.6.1 host 5.5.5.1
        Active SAs: 4, origin: crypto map
        Inbound:  #pkts dec'ed 1 drop 0 life (KB/Sec) 4342102/3540
        Outbound: #pkts enc'ed 2 drop 0 life (KB/Sec) 4342102/3540

R2#

but when I tried to add the GREEN VRF under ISAKMP profile I found I can’t:
 
R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#crypto isakmp profile ISAKMP-PROFILE
R1(conf-isa-prof)#
R1(conf-isa-prof)#vrf GREEN
% vrf GREEN not configured


R1(conf-isa-prof)#do sh run | i vrf
vrf definition GREEN
ip vrf RED
...
R1(conf-isa-prof)#
R1(conf-isa-prof)#exit

I used the new command because it has to work with IPv6 but ISAKMP profile isn’t compatible with
the command.

From Cisco doc:

If the IKEv2 profile is used for tunnel protection, the Inside VRF (IVRF) for the tunnel interface should be configured on the tunnel interface.

I try do the same on ISAKMP (no IVRF on ISAKMP profile).

As you see there is connectivity between Loop100 (vrf GREEN):
 
R2#ping vrf GREEN ipv6 2001:100::1 source loop100
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:100::1, timeout is 2 seconds:
Packet sent with a source address of 2001:200::2%GREEN
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 120/129/140 ms
R2#
 
but you can’t see the IVRF here:
 
R1#sh crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation

Interface: Tunnel0
Session status: DOWN
Peer: 7.7.7.1 port 500 fvrf: RED ivrf: (none)
      Desc: (none)
      Phase1_id: (none)
  IPSEC FLOW: permit 47 host 5.5.5.1 host 7.7.7.1
        Active SAs: 0, origin: crypto map
        Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

Interface: Tunnel0
Profile: ISAKMP-PROFILE
Uptime: 00:08:33
Session status: UP-ACTIVE
Peer: 6.6.6.1 port 500 fvrf: RED ivrf: (none)
      Phase1_id: 6.6.6.1
      Desc: (none)
  IKEv1 SA: local 5.5.5.1/500 remote 6.6.6.1/500 Active
          Capabilities:(none) connid:1001 lifetime:23:51:16
  IPSEC FLOW: permit 47 host 5.5.5.1 host 6.6.6.1
        Active SAs: 2, origin: crypto map
        Inbound:  #pkts dec'ed 17 drop 3 life (KB/Sec) 4292794/3086
        Outbound: #pkts enc'ed 17 drop 0 life (KB/Sec) 4292795/3086

R1#

Be aware the line is incorrect:
 
Peer: 6.6.6.1 port 500 fvrf: RED ivrf: (none)

and to check the real VRF you need to check configuration or:
 
R1#sh vrf
  Name                             Default RD          Protocols   Interfaces
  GREEN                            <not set>           ipv6        Lo100
                                                                   Tu0
  RED                              <not set>           ipv4        Fa0/0
R1#
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more