Today I would like to test an integration of DMVPN and GET VPN
technologies. DMVPN can be used over the public network like Internet
and GET VPN only over private like MPLS (because of IP preservation).
As you remember from my previous posts about DMVPN the best option is the phase 3. With thousands of spokes your hub has to keep the same number of SAs (security association).
As you remember, for the phase 3, the first packet was sent to the hub and then was redirected (NHRP) to the destination. Next packets were sent directly to the spoke:
Let’s test how it works with GET VPN:
1) First I added a new spoke 3 which will be a Key Server for GET VPN.
2) Next I have to remove a tunnel protection on the hub and all spokes:
Once we remove the protection, I see on my firewall the new GRE connections (not ESP as before):
I need to change the ACL for the new spoke:
3) Once I have unprotected GRE tunnels between all routers, I can start implementing GET VPN
a) key server:
b) group members:
On the ASA I can see:
Let’s fix it:
Ok, let’s check how to works:
DMVPN:
a) hub
b) spoke - R2
On the Key Server (R4) I see 3 registered GMs:
As the GET VPN is tunnel less on R2 we can see:
I check now how the traffic from Lan2 is sent to Lan3:
As you see the first attempt is sent using spoke-to-spoke connection.
Let’s check if we can intercept traffic (inside IPs) as with the native GET VPN:
so, I can assume it works as expected. We can’t see inside IP addresses. We don’t have many SAs as with native DMVPN and traffic between spokes is sent directly, even the first packet.
As you remember from my previous posts about DMVPN the best option is the phase 3. With thousands of spokes your hub has to keep the same number of SAs (security association).
As you remember, for the phase 3, the first packet was sent to the hub and then was redirected (NHRP) to the destination. Next packets were sent directly to the spoke:
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.1 40 msec 56 msec 76 msec
2 10.10.10.3 104 msec 88 msec 140 msec
R2#
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.3 104 msec 104 msec 72 msec
R2#Let’s test how it works with GET VPN:
1) First I added a new spoke 3 which will be a Key Server for GET VPN.
interface Tunnel0
no tunnel protection ipsec profile IPSEC-PRFOnce we remove the protection, I see on my firewall the new GRE connections (not ESP as before):
GRE spoke3 8.8.8.1:0 hub 5.5.5.1:0, idle 0:00:04, bytes 1088, flags E
GRE spoke2 7.7.7.1:0 hub 5.5.5.1:0, idle 0:00:04, bytes 1088, flags E
GRE spoke1 6.6.6.1:0 hub 5.5.5.1:0, idle 0:00:04, bytes 1088, flags E
GRE spoke2 7.7.7.1:0 hub 5.5.5.1:0, idle 0:00:00, bytes 1156, flags E
GRE spoke1 6.6.6.1:0 hub 5.5.5.1:0, idle 0:00:00, bytes 1156, flags EI need to change the ACL for the new spoke:
asa1(config)# %ASA-4-106023: Deny protocol 47 src spoke3:8.8.8.1 dst hub:5.5.5.1 by access-group "SPOKE3" [0x0, 0x0]access-list SPOKE3 ext permit gre host 8.8.8.1 host 5.5.5.13) Once I have unprotected GRE tunnels between all routers, I can start implementing GET VPN
a) key server:
crypto key generate rsa general-keys modulus 1024 label GETVPN-KEY
access-list 100 deny udp any eq 848 any eq 848
access-list 100 permit gre any any
!
crypto gdoi group GETVPN-GROUP
identity number 1
server local
rekey retransmit 10 number 2
rekey authentication mypubkey rsa GETVPN-KEY
rekey transport unicast
sa ipsec 1
profile IPSEC-PRF
match address ipv4 100
replay counter window-size 64
address ipv4 8.8.8.1
!b) group members:
crypto gdoi group GETVPN-GROUP
identity number 1
server address ipv4 8.8.8.1
!
crypto map MAPA 1 gdoi
set group GETVPN-GROUP
!
interface FastEthernet0/0
crypto map MAPA
!On the ASA I can see:
%ASA-4-106023: Deny udp src spoke3:8.8.8.1/848 dst hub:5.5.5.1/848 by access-group "SPOKE3" [0x0, 0x0]
%ASA-4-106023: Deny udp src spoke2:7.7.7.1/848 dst spoke3:8.8.8.1/848 by access-group "SPOKE2" [0x0, 0x0]
%ASA-4-106023: Deny udp src spoke1:6.6.6.1/848 dst spoke3:8.8.8.1/848 by access-group "SPOKE1" [0x0, 0x0]Let’s fix it:
access-list SPOKE1 ext permit udp host 6.6.6.1 host 8.8.8.1 eq 848
access-list SPOKE2 ext permit udp host 7.7.7.1 host 8.8.8.1 eq 848
access-list SPOKE3 ext permit udp host 8.8.8.1 host 5.5.5.1 eq 848
Ok, let’s check how to works:
DMVPN:
a) hub
R1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Hub, NHRP Peers:3,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 6.6.6.1 10.10.10.2 UP 01:08:22 D
2 7.7.7.1 10.10.10.3 UP 01:08:22 D
1 8.8.8.1 10.10.10.4 UP 01:08:12 D
R1#b) spoke - R2
R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 5.5.5.1 10.10.10.1 UP 01:14:39 S
1 7.7.7.1 10.10.10.3 UP 01:01:10 D
R2#sh ip nh
R2#sh ip nhrp
10.10.10.1/32 via 10.10.10.1, Tunnel0 created 01:15:00, never expire
Type: static, Flags: nat used
NBMA address: 5.5.5.1
100.33.33.0/24 via 10.10.10.3, Tunnel0 created 01:01:17, expire 00:58:42
Type: dynamic, Flags: router nat
NBMA address: 7.7.7.1
R2#On the Key Server (R4) I see 3 registered GMs:
R4#sh crypto gdoi
Group Information
Group Name : GETVPN-GROUP
Group Identity : 1
Group Members : 3
IPSec SA Direction : Both
Active Group Server : Local
Group Rekey Lifetime : 86400 secs
Group Rekey
Remaining Lifetime : 84047 secs
Rekey Retransmit Period : 10 secs
Rekey Retransmit Attempts: 2
Group Retransmit
Remaining Lifetime : 0 secs
IPSec SA Number : 1
IPSec SA Rekey Lifetime: 3600 secs
Profile Name : IPSEC-PRF
Replay method : Count Based
Replay Window Size : 64
ACL Configured : access-list 100
Group Server list : Local
R4#As the GET VPN is tunnel less on R2 we can see:
R2#sh crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: MAPA, local addr 6.6.6.1
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
current_peer port 848
PERMIT, flags={origin_is_acl,}
#pkts encaps: 12, #pkts encrypt: 12, #pkts digest: 12
#pkts decaps: 7, #pkts decrypt: 7, #pkts verify: 7
#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 1
local crypto endpt.: 6.6.6.1, remote crypto endpt.:
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x714D2F06(1900883718)
inbound esp sas:
spi: 0x714D2F06(1900883718)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 53, flow_id: SW:53, crypto map: MAPA
sa timing: remaining key lifetime (k/sec): (4458211/1083)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x714D2F06(1900883718)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 54, flow_id: SW:54, crypto map: MAPA
sa timing: remaining key lifetime (k/sec): (4458211/1080)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
R2#I check now how the traffic from Lan2 is sent to Lan3:
R2#traceroute 100.33.33.33 source 100.22.22.22
Type escape sequence to abort.
Tracing the route to 100.33.33.33
1 10.10.10.3 104 msec 80 msec 72 msec
R2#As you see the first attempt is sent using spoke-to-spoke connection.
Let’s check if we can intercept traffic (inside IPs) as with the native GET VPN:
so, I can assume it works as expected. We can’t see inside IP addresses. We don’t have many SAs as with native DMVPN and traffic between spokes is sent directly, even the first packet.
Comments
Post a Comment