So my question for you is, did you identify what the problem is with the site-
to-site
route-based VPN between site 3 and site 4?
I hope you did.
And what I'd like to do right now is do a walkthrough by taking a look at the
live interface
and then together walking through and identifying what the problem is and then
also after implementing
a correction to verify that what we thought was wrong indeed was the problem.
So to start off, what I'd recommend and we do is let's do a quick check here at
the
red VM as we try to ping the IP address of this purple VM. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
red VM as we try to ping the IP address of this purple VM.
Another option is we could also try to ping the IP address of the tier 0
gateway interface
that connects to this segment.
So we could try to ping 10.44.0.1 and that way we wouldn't have to worry
specifically
about which IP address a client on the other side had.
So for testing purposes, let's go ahead and test what they ping to this IP
address as
a known given the 10.44.0.1 and let's try that from the VM over here at site 3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a known given the 10.44.0.1 and let's try that from the VM over here at site 3.
So here is the site 3 VM and let's do a ping over to 10.44.0.1 and sure enough
that is
not working and it's going to leave that ping attempting in the background over
and over
again and that way when it does start working, those ping should automatically
start working
as well.
And just to confirm what the active edge node is, we'll click on networking
network
topology here at site 3 and we'll go ahead and double click on the tier 0
gateway and
what we want to do is go to lab 3-1 and its management IP address is dot 36. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
what we want to do is go to lab 3-1 and its management IP address is dot 36.
So let's go to that edge node for a moment and just check basic connectivity
over to
24.1.2.40.
All right.
So here we are at edge 1.
We'll do a get gateways and then we'll go into VRF for VRF 1.
That's our services router and we'll do a ping over to 24.1.2.40 and sure
enough, so
that confirms that we have basic external connectivity on both gateways from
the gateway
0 at site 3 to the gateway 0 at site 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
0 at site 3 to the gateway 0 at site 4.
Also over here, let's do a get route and that'll show us our routing table and
there's the
default route and I don't see a route to the 10.44 subnets.
So that's very likely at least one of our problems, the site 3 does not have a
route
that's using the next top of 103434 dot 44 to reach the 1044 networks.
So back at the NSX manager under VPNs, if we look at our IP succession and
expand site
4, hmm, that says enable. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
4, hmm, that says enable.
Let's do a refresh and look at site 4.
It says there's no problem.
That's because the actual IPsec tunnel itself is happy, happy.
It's up and running between site 3 and site 4.
It's just isn't trying to use that path as it's forwarding traffic.
Also another really handy tool in troubleshooting is this option right here,
download config.
Let's imagine you have two sites and you want to check out all the details and
the endpoints,
everything else and the protocols being used between the two sites.
What you can do is download the config from both sites and then open it up in a
text editor
and go through them step by step. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and go through them step by step.
So sometimes it's super helpful to have these side by side.
Have one site in a document on the left hand side of your screen, have the
other site in
a document on the right hand side of the screen and just go through it step by
step.
So this is showing us the initial like tunnel information with the hashing and
the encryption
and so forth.
It's also showing us for the IPsec tunnel and there's the encryption that we
modified
at the tail end of our set of videos.
And so what we can do is just compare all these details with what's set up on
the other
site as well.
However, because the tunnel is up, we can go ahead and dismiss that because the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, because the tunnel is up, we can go ahead and dismiss that because the
actual
tunnel itself isn't having the problem, it's the route.
So let's go back to our tier 0 gateway.
We'll click on the three dots.
We'll click on edit, let's go down to our routing and we have two routes there.
Oh, we have one default route and we have a route for IPsec policy based tunnel
to an
external Cisco router, but we don't have the route to the 1044 subnet.
So let's add that by clicking on add static route, we'll call this subnets at
site four.
We'll specify the 10 dot 44 address space for the 16 bit mass. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We'll specify the 10 dot 44 address space for the 16 bit mass.
So 1044 anything and for the next hop, we'll click on set there and set the
next hop to
10 dot 34 dot 34 dot 44, which based on apology and how we set up these
sessions is the IP
address on the virtual tunnel interface that we're using over at site four.
And then for the scope, I'm also going to limit the scope to our IPsec session.
So I'll select that and then click on add and then click on apply.
And then before I click on save, let me just take a peek here at our client. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then before I click on save, let me just take a peek here at our client.
So here is our little client still trying to do his pings.
Let me do a control C.
Yeah, sure enough, 581 packets that were sent, none received.
So we'll start that ping again.
They'll go over here and we'll click on save and close.
And if that was the whole problem, those pings should now be working.
So let's bring back the client.
So here's our client and sure enough, those pings are now beginning to go
through.
So that was our issue at site three.
We had a missing route.
And as a result, our tier zero gateway was not trying to send the traffic that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And as a result, our tier zero gateway was not trying to send the traffic that
was destined
for 1044, anything, it wasn't trying to send that over the tunnel.
And that's what was causing our route based IPsec site, site tunnel between
site three
and site four to fail was that although it was a route based VPN, we didn't
have the
correct route in place.
And now that we do, if we go back to VPN and IPsec sessions and go back to our
IPsec session
to site four and we click on view statistics, we should now have packets that
are going
through and if that ping is still running, which it is, if we click on refresh WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
through and if that ping is still running, which it is, if we click on refresh
here,
those counters should be increasing, which they are fantastic.
So thanks for joining me in this set of videos and in the skill regarding
configuring and
verifying an IPsec route based VPN tunnel between two tier zero gateways in an
NSX environment.
And I look forward to seeing you my friend in another set of videos very, very
soon.
Until then, I hope this has been informative and I'd like to thank you for
viewing.