So for this challenge where this client right here can't access that IP address
108010 which should be protected based on the IP sectonal setup whenever
possible troubleshooting is a great idea to verify the symptoms that the
customer is claiming.
So let's take a moment and go to this VM.
Let's do a quick ping over to 108010 to verify whether or not we have
connectivity.
So let's make sure the client is up and running and connected to the right
segments. This is red one. That's the VM. There's a site.
Pdres 10330151. This also indicates it's connected to the red segment 33 and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Pdres 10330151. This also indicates it's connected to the red segment 33 and
just to confirm red.
So 33 is our NSX based segment. So let's bring over our client. In fact, let's
go ahead and open up a web console.
That way it'll be a little bit bigger. So here's the web console for red one as
shown up here in the top left hand corner.
And if we do an IF config for ethernet zero being confirm it's IP address with
a pin route space dash and that confirms the routing tables.
We have a default route of 103301. So let's try to pin our default gateway 10. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We have a default route of 103301. So let's try to pin our default gateway 10.
33.0.1. And that works.
I think in the topology I might have had dot 60 there as an address that we
could use, but it appears the dot one gateway is working.
And let's also confirm that indeed is our address. So back in the NSX manager,
we'll go to networking and we'll go to segments.
There's our red, say 33 and sure enough 103301. So we can ping that address.
Let's go ahead and also try to see if we can ping over to 10, 8, 0, 10.
So we'll do a ping over to 10 dot 8 dot 0 dot 10 and survey says. Yep, that is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll do a ping over to 10 dot 8 dot 0 dot 10 and survey says. Yep, that is
not flying. So we'll do a control C and we had five out of five that failed.
So from the client's perspective, it could go ahead and reach his default
gateway, but it can't ping over here.
So let's go ahead and take a look at the details for the IP sec tunnel going
between gateway zero and the router.
So back at the NSX manager with networking selected, we'll click on VPN and let
's go to IP sec sessions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And sure enough that says down right there if we open up the details here
showing the local end point 780060.
And that's the virtual IP address for the tier zero gateway and that external
segment.
And the other end of the tunnel is 708010. And that all looks good based on our
configuration.
Let's go take a look at the router and verify its IP address is really 708010.
So at the router, if we do a commands, we can see what the actual IP addresses
are. Here's one of those show IP interface brief.
And here's the interfacing question 870010 that looks close. That's not the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here's the interfacing question 870010 that looks close. That's not the
right IP address.
Let's take a look at our configuration in the NSX manager.
So here in the NSX manager, we are supposed to be appearing with 708010.
And if those two devices are on the same segment, the same VLAN, which they are
, they need to have a common network address space.
So it appears the Cisco routers off by a couple of digits there.
It should be 708010 and not 870010.
So back at the router, let's go ahead and fix that. So I'll go back into the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So back at the router, let's go ahead and fix that. So I'll go back into the
interface for gigabit ethernet 0/0.78.
And then an interface configuration mode will put in the right address of 78.0.
0.10 with a 24-bit mask.
Instead of the erroneous 87, then we'll go ahead and do a shutdown and give
that a moment and a no shutdown.
And let's go ahead and verify with a quick ping that we can reach 78.0.0.60,
which is the virtual IP address over at Gateway 0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if that works, which it does, at least now we have the right IP address, let
's see if there's any other problems.
So back at the NSX manager, let me go ahead and do a refresh here. And that is
now up.
So that appears to have been the problem. Let's go back to our client and just
verify that we can ping.
So that ping test is going to go from this VM here over to an IP address over
in a 1080 network.
And we use .10. That's a loopback address I have set up on the external router.
So let's bring in our client. And last time we tried to ping, it did not work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's bring in our client. And last time we tried to ping, it did not work.
Let's go ahead and try it again, 108010 and survey says that looks a lot better
.
So now it's working and let's go verify the hit counts in the NSX interface.
So back at the NSX manager under the VPN section here with IPsec sessions tab
selected, let's click right here on view statistics.
And sure enough, not only is the tunnel up, but we also are showing packets
going across.
So that's another confirmation that the tunnel is up. Now another really cool
feature is this option right here under IPsec sessions. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Go to the session you want to look at. There's an option for download config
and check this out.
This is a great way for troubleshooting to get a one stop shop look at how the
VPN is configured in the NSX manager.
So if you click here on download config and then yes, it just downloaded that
to my downloads folder on my management computer.
And here it is. So here is the session name IPsec session to Cisco.
If we scroll down, it's showing us the details for the control tunnel, the Ike
version one tunnel that we set up,
including the method for authentication, the pre shared key we're using, the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
including the method for authentication, the pre shared key we're using, the
hashing, the encryption and the lifetime and the Diffie elm and group.
And if we scroll down, it has details regarding the profile we use for the IP
sec tunnel as well.
So we're using ESP, which is protocol 50. We're using shot to 56. There's our
lifetime.
There's the encryption algorithm and we're not using PFS.
And then we have a dead peer detection we took by default, which was checking
every 60 seconds.
And here it has the local and remote peer ID. So the local side is 70, 8060 and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And here it has the local and remote peer ID. So the local side is 70, 8060 and
the remote side is 78, 0010, which on the router a few moments ago, it had been
misconfigured.
And that's why we couldn't build the tunnel. And as far as protected networks
for our policy based IPsec tunnel, here are the two network and rest spaces
that we're protecting.
So from the perspective of the tier zero gateway is traffic from the 10, eight
zero network that's going to the 10, 33, zero network.
And the flip side of that is any traffic coming in from the other side, it's
expecting that traffic to be encrypted.
So it'll go through the process of decrypting the traffic that's coming in over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it'll go through the process of decrypting the traffic that's coming in over
the tunnel from the external router.
So thanks for joining me in this set of videos and the skill regarding IPsec
site site tunnels in the world of NSX.
And I look forward to seeing you my friend in another skill very, very soon.
Until then, I hope this has been informative and I'd like to thank you for
viewing.