GET VPN or Group Encrypted Transport is the one and only VPN solution that is tunnel-less. When I initially started learning this, tunnel-less, was the hardest part to wrap my head around. Considering all of the other VPN technologies rely on a "tunnel" to encrypt the traffic. However, after mulling over this for a while, like a long time, it hit me, literally, that not all of the VPN solutions actually tunnel at all.
Your standard variety crypto map based VPN doesn't "tunnel" anything, per-se. Rather it encapsulates "interesting" data inside of an "encrypted" header. There is a connection going out and a connection coming in. So technically there are 2 SAs, each being unidirectional. Inter site communication that goes out the interface a crypto map is applied to and the source/destination/payload matches the ACL called by the crypto map, get encrypted.
Only VPN solutions tied to GRE/VTI/DVTI/DMVPN and FlexVPN are actually tunneled. Once I decoupled this logic, it made it far easier to understand what was really going on. Which is centralized IPsec VPNs rather than distributed IPsec VPN.
Distributed IPsec VPN is where all nodes terminating a VPN must locally configure and maintain ISAKMP Phase 1 and IPsec Phase 2 logic that will match with other nodes that may form a VPN tunnel with each other. A centralized model, GET VPN, decouples Phase 1 and Phase 2, which are in fact two different operations entirely. The Key Server or Policy server creates/maintains a Phase 1 and Phase 2 policy. It also maintains a filter or ACL that will determine what traffic is sent as encrypted and what traffic is not.
The Group members are the nodes that are only configured with a Phase 1 policy and authentication method, PSK or certificate. The group members are configured to register with the key server which then pushes the Phase 2 policy down to the group members. The way that the KS communicates with the GM is through the GDOI mechanism.
The GDOI mechanism is the Group Domain of Interpretation, yeah really straightforward, I know ;). Basically from my testing, it's just a communication channel using UDP port 848 between the KS and GM to exchange Phase 2 information. After the GM is configured to register with the KS, the Phase 2 policy is pushed and installed as a dynamic ACL. Each GM and the KS belong to the same "Group" or SA and sequence number. This is what allows the GMs to determine if they can exchange data with each other.
One drawback I saw and I don't see a good reason as to why it's in place are the "rekey" operations that happen. There are two, the TEK and KEK. The KEK is used between the KS and GM for control plane operations. The TEK is used for data plane operations. The rekey interval is rather aggressive, every couple hours. An authentication mechanism more than anything else from what I can tell.
GETVPN is NOT officially supported over the internet as it doesn't support NAT. It "can" be ran over DMVPN, FlexVPN, LISP or other overlay you choose. It was originally intended to encrypt any to any communication over MPLS, we all know how nosy ISPs can be.
GETVPN also offers scale where the other VPN solutions really don't. It's one SA used to communicate with all the other GMs instead of potentially thousands.
CSR8#show crypto ipsec sa | in pkts|inbound|outbound
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#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
current outbound spi: 0x682ED99B(1747900827)
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
SW21#ping 10.19.22.22
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.19.22.22, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 26/30/36 ms
SW21#ping 10.20.23.23
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.23.23, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/20/29 ms
CSR8#show crypto ipsec sa | in pkts|inbound|outbound
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
current outbound spi: 0x682ED99B(1747900827)
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
Pings from a GM or a route behind it that match the proxy ACL are allowed to be sent encrypted to the destination, which is reachable via MPLS. From the outputs above, the 10 pings show up in the P2 output.
We'll take a look at how this all works in following posts, happy labbing!
Your standard variety crypto map based VPN doesn't "tunnel" anything, per-se. Rather it encapsulates "interesting" data inside of an "encrypted" header. There is a connection going out and a connection coming in. So technically there are 2 SAs, each being unidirectional. Inter site communication that goes out the interface a crypto map is applied to and the source/destination/payload matches the ACL called by the crypto map, get encrypted.
Only VPN solutions tied to GRE/VTI/DVTI/DMVPN and FlexVPN are actually tunneled. Once I decoupled this logic, it made it far easier to understand what was really going on. Which is centralized IPsec VPNs rather than distributed IPsec VPN.
Distributed IPsec VPN is where all nodes terminating a VPN must locally configure and maintain ISAKMP Phase 1 and IPsec Phase 2 logic that will match with other nodes that may form a VPN tunnel with each other. A centralized model, GET VPN, decouples Phase 1 and Phase 2, which are in fact two different operations entirely. The Key Server or Policy server creates/maintains a Phase 1 and Phase 2 policy. It also maintains a filter or ACL that will determine what traffic is sent as encrypted and what traffic is not.
The Group members are the nodes that are only configured with a Phase 1 policy and authentication method, PSK or certificate. The group members are configured to register with the key server which then pushes the Phase 2 policy down to the group members. The way that the KS communicates with the GM is through the GDOI mechanism.
The GDOI mechanism is the Group Domain of Interpretation, yeah really straightforward, I know ;). Basically from my testing, it's just a communication channel using UDP port 848 between the KS and GM to exchange Phase 2 information. After the GM is configured to register with the KS, the Phase 2 policy is pushed and installed as a dynamic ACL. Each GM and the KS belong to the same "Group" or SA and sequence number. This is what allows the GMs to determine if they can exchange data with each other.
One drawback I saw and I don't see a good reason as to why it's in place are the "rekey" operations that happen. There are two, the TEK and KEK. The KEK is used between the KS and GM for control plane operations. The TEK is used for data plane operations. The rekey interval is rather aggressive, every couple hours. An authentication mechanism more than anything else from what I can tell.
GETVPN is NOT officially supported over the internet as it doesn't support NAT. It "can" be ran over DMVPN, FlexVPN, LISP or other overlay you choose. It was originally intended to encrypt any to any communication over MPLS, we all know how nosy ISPs can be.
GETVPN also offers scale where the other VPN solutions really don't. It's one SA used to communicate with all the other GMs instead of potentially thousands.
CSR8#show crypto ipsec sa | in pkts|inbound|outbound
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#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
current outbound spi: 0x682ED99B(1747900827)
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
SW21#ping 10.19.22.22
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.19.22.22, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 26/30/36 ms
SW21#ping 10.20.23.23
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.23.23, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/20/29 ms
CSR8#show crypto ipsec sa | in pkts|inbound|outbound
#pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
#pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
current outbound spi: 0x682ED99B(1747900827)
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
Pings from a GM or a route behind it that match the proxy ACL are allowed to be sent encrypted to the destination, which is reachable via MPLS. From the outputs above, the 10 pings show up in the P2 output.
We'll take a look at how this all works in following posts, happy labbing!
