In this video, I'd like to share with you some troubleshooting
methodologies that we can apply when we're
troubleshooting IPsec VPNs.
And the first thing I'd like to chat with you about regarding
troubleshooting why a VPN may not be working
is one word, and that's routing.
In most cases, with our VPNs, we have some type of policy that's
associated with an interface.
If there are legacy crypto maps, the crypto map
would be applied to an interface.
If it's a VTI, a Virtual Tunnel Interface,
we'd have an IPsec profile associated with that interface.
And either way, the key is, when traffic crosses over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And either way, the key is, when traffic crosses over
that interface, it's at that moment
that the router decides, oh, should I encrypt this or not?
And if the answer is yes, the router's then going to say,
do I have an IKE phase 1 if we're using IKE version 1?
Do I have an IKE phase 1 tunnel between myself and the peer?
And if not, they negotiate it and build it.
And then after that's built, they
would then negotiate and build the IKE phase 2 tunnel.
Again, that's if we're using IKE version 1.
But it was all triggered by having traffic that
was routed over that interface.
So the key takeaway is that if this router receives a packet,
and it doesn't believe for whatever reason WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it doesn't believe for whatever reason
that that traffic needs to be routed over this interface,
the whole initial IPsec policy won't be triggered or brought
up due to a lack of routing.
So my coaching would be, the very first thing
we'd want to look at is routing, is the router believing
that it should forward the traffic over the interface
where our crypto policy, in whatever flavor we're using,
is applied.
And so here, if our entering traffic
was supposed to be from 10.1.0 going to 10.2.0 from R1's
perspective, we could go ahead and do a show IP route
and say, OK, dear Mr. R1, if you've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and say, OK, dear Mr. R1, if you've
got a packet from 10.1.0 going to 10.2.0,
what would you do with it?
And maybe there is a default route that's
forcing it out this interface.
Or maybe there's a static route.
But if there's no route, or if the route goes out
a different interface, and the policy is applied here,
again, that'd be a miss, and it wouldn't trigger
the whole IPsec process.
So from a routing perspective, let's
take a look at R1 and its routing table and ask ourselves
the question, if traffic is coming
from 10.1.0 going to 10.2.0, what will it do with it?
So here on R1, if we did a show IP route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So here on R1, if we did a show IP route
and looked at its routing table, and then we
asked ourselves the question, traffic
from 10.1.0 going to 10.2.0--
there's no explicit match for 10.2 anything,
so it would use the default route.
And that default route has the next hop of 15.1.1.5.
And hopefully, to reach 15.1.1.5,
we have the interface where the actual cryptography is applied
which would trigger the IPsec.
So if our IPsec tunnel was between R1 and R2,
and it was matching on 10.1.0 to 10.2.0,
when R1 receives that packet, it would make a routing decision. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
when R1 receives that packet, it would make a routing decision.
And if this is the interface that leads off
to 15.1.1.5, which it is, that would
trigger the IPsec, at which case,
if the tunnels weren't already up,
it would negotiate the tunnels.
They'd build the tunnels.
And then that traffic could be encrypted and shipped
through the tunnel from R1 to R2.
So the internet would see the IP addresses of 15.1.1.1
going to 25.2.2.2.
And the original payload, including the original IP
header that was sourced, for example, from 10.1.0.50--
that would all be encapsulated and encrypted
and part of the payload.
So it'd be protected from the eyes of the internet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it'd be protected from the eyes of the internet
or this public network.
So that's step number 1, make sure we have routing
enabled correctly so that the router wants
to forward through the interface where the cryptography is
applied.
Second is, if we're going to peer from R1 to R2,
we'd want to make darn sure that we
have reachability between R1 and R2 on the transport network.
So let's verify that as well.
So if the peers are supposed to be 15.1.1.1 and 25.2.2.2,
we'd want to look at the routing table
and verify that we have reachability between those two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and verify that we have reachability between those two
endpoints.
And by default, with IPsec, they're
going to negotiate the [INAUDIBLE]
again for the IKE phase 1 tunnel with UDP port 500.
And for the actual IPsec tunnel, unless we're
using NAT traversal, it'll be using
ESP, which is protocol number 50 at layer 4.
So if there's something preventing those protocols
between the two endpoints, the two endpoints of the VPN
tunnel, again, that would cause a problem.
So routing-- make sure it's working,
and then make sure we have reachability
between the endpoints of the VPN tunnel. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
between the endpoints of the VPN tunnel.
So after we've verified routing and also reachability
between the peers, we'd also want
to verify that we have the correct policy implemented.
And it depends on, are we using version 1 or version 2?
And do we have compatible IKE phase
1 policies for version 1 and compatible IPsec policies?
And do we have the correct passwords or authentication
in place so they can both negotiate, authenticate,
and build all the tunnels that they need to?
And a lot of that configuration is
going to depend on how we've implemented IPsec.
So we have other sets of videos on implementing
site-to-site tunnels with crypto maps, with tunnel interfaces. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
site-to-site tunnels with crypto maps, with tunnel interfaces.
We also have some videos on GETVPN and DMVPN.
So in the next video, here's what I propose we do.
In the next video, let's take a look at the same topology.
And I'll bring it up here once again
so we can get a preview of it.
And let's start off with the troubleshooting exercise
where we're going to troubleshoot IKE version
1 and IKE phase 1 and identify, first
of all, why it's not working between R1 and R2.
And then we'll implement a solution.
And all that's coming up in the very next video.
So I'll see you there in just a moment.
Meanwhile, I hope this has been informative for you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, I hope this has been informative for you.
And I'd like to thank you for viewing.