It's a pretty tough go to use a technology that you've never
heard of before, so in this video,
I'd like to introduce you to a pretty cool technology
called GET VPN.
And for this discussion, let's imagine
that this network right here is from our service provider,
and that our service provider, maybe
they're using layer 3 VPNs with MPLS.
They know about all of our routes
and how to reach everything in our network.
So maybe you want to protect the traffic from 10.3 to 10.1,
so traffic going this way, and maybe from 10.1 to 10.4
this way, and 10.4 to 10.2 this way, and from 10.2 to 10.3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this way, and 10.4 to 10.2 this way, and from 10.2 to 10.3.
And then we don't want to forget across the middle
and across up.
So we could implement VPNs.
That's a whole bunch.
I think that's like six VPNs that we
would have to implement to go ahead and have
that protection across our service provider network.
But another option that we could use instead
of having to manually build all those tunnels
is called GET VPN.
And GET isn't like a commercial.
"Get VPN!
You need VPN now!"
GET VPN refers to Group Encrypted Transport. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
GET VPN refers to Group Encrypted Transport.
Here's the idea.
So let's imagine we have an IPsec controller.
Now, the IPsec controller, his job
is to be in charge of all of the IPsec security associations
and make sure everyone knows about what to do.
So we could have this controller communicate
with each of these devices.
And we could have the controller say, you know what?
Here's the SAs, the Security Associations, for IPsec
I want you to use.
And included with that, here are the keys you should use.
And if I ever need to change that, or update,
or rotate the key, I will communicate with you,
and let you know.
And in addition, here's the interesting traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And in addition, here's the interesting traffic.
And so on the controller, we could specify traffic
from 10.1 to 10.3, or we could just
say 10 anything to 10 anything.
That would cover it.
And in that interesting traffic list,
the controller could push down that full config as far as
what to do to all the routers.
Then the routers, all they would have to do
is say, oh, I've got traffic that's
about to leave this interface.
Is it coming from 10 and going to 10
based on the interesting traffic?
And if so, it can just encrypt it
using the keys that were provided by the controller,
and then just send it.
So the original packet, if it was from 10.1.0.50 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the original packet, if it was from 10.1.0.50
going 10.2.0.50, here's the original packet.
So we have the payload here, whatever
was being sent from PC1 to PC2.
The original IP header at this point would be PC1,
and the destination would be PC2.
What the router would do, once it's
about to route it out this interface
where we've applied our policy, the router would say,
I'm going to go ahead encrypt all of that.
I'm going to put a new header on it.
And with IPsec, it'd be protocol 50 for ESP,
because Encapsulating Security Payload is protocol 50.
AH is protocol 51. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
AH is protocol 51.
But AH does a great job with data integrity,
but it doesn't do anything for encryption.
So AH by itself is rarely ever used.
We're going to use ESP, Encapsulating Security Payload,
because that does the encryption and the data integrity of HMAC
all built into IPsec.
We don't need to use AH.
So it'd be an ESP protocol 50 header.
And then check this out.
It preserves or replaces the original IP addresses.
So it'd still show up as coming from PC1 going to PC2. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then it would send it.
So over the service provider network,
it would still look like it's going
from 10.1.0.50 to 10.2.0.50.
So that's why it's important the service provider
network knows how to route to those networks for us.
And then it went on to receive that packet.
It would go ahead and decrypt it,
and then forward the naked unencrypted packet
onto its destination.
So unlike traditional tunneled IPsec traffic,
these devices are not replacing and putting in new IP addresses
based on their source and destination.
They're preserving what was in the original IP header
as they forward that encrypted traffic. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as they forward that encrypted traffic.
So thanks for joining me.
In this video, we're getting a high level overview of GET VPN.
I'll see you in the next video.
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.