So let's move on to the demonstration.
Let's configure some zero trust network access policies.
Once again, back in the Endpoint Manager admin center,
I'm going to demonstrate traffic filters on our user tunnel.
So I'm going to click on this profile,
but I want you to be clear that traffic filters and everything that I'm
demonstrating here can be applied to the device tunnel as well,
but I'm just going to demonstrate it on the user tunnel.
So here we are in our user tunnel,
we're going to scroll down and click Edit next to our Configuration settings,
and now we're going to go to our Apps and Traffic Rules.
And here you'll see Network traffic rules for this VPN connection.
So we'll click Add, and we'll provide a name here.
So in this case, I'm going to, for demonstration purposes,
I'm going to create a traffic filter that restricts access
to the internal network over RDP only.
So the only port I'm going to open up is 3389, so we'll take a look at that.
So I'm going to give this a name.
The Rule type here, I'm going to select Split tunnel.
And then for the Protocol, of course, you notice that's not a drop‑down list,
unfortunately.
It would be nice if it was.
But fundamentally, it's asking for the protocol number.
So in this case, I'm just going to do TCP, which is Protocol number 6.
Now this is interesting here.
This is a rather odd behavior of the UI is that you do not
have to define the local port ranges.
If you leave this out, it defaults to basically any local port.
The UI wants to complain about this though.
It says it must not be empty.
I can assure you you can leave this empty and it will work.
So I'm going to ignore this, and I'm going to go to the remote port ranges here,
and I'm going to specify my remote port,
which in this case is the RDP port of 3389.
And I've defined that for both the upper and lower
port because it's just a single port.
If you had an application that used a port range, you can do it that way.
If you want multiple ports to apply to this rule,
you can just simply add those here.
Once again,
the local address range I really don't care about because it's on my endpoint.
One, I'm not going to know what that IP address is.
Two, I could define a range, but I find that of limited usefulness.
I really don't care what the what the local address is
on the endpoint or on the client.
I'm really concerned with how it's accessing my internal network.
So in this case, I'm going to add my remote address range.
And sadly, the UI does not accept a CIDR notation here.
It does in XML, which makes your life a little easier,
but here you'll actually have to specify a valid address range.
And so for simplicity sake, I'm just going to specify 172.16.0.0/24.
And again, those have to be valid addresses.
No network IDs, no broadcast IDs.
So we'll click Save, and that table row has been added.
So I'm going to click Review + save and then save once again.
And now I've updated our Always On VPN device
configuration profile to support a traffic filter.
So let's jump over to the client and see what that looks like in action.
So here we are back on our Windows client.
This client has already synchronized its configuration with Intune,
and it should have the policy in place.
Now, it's important to understand that we've implemented these traffic filters,
but they don't show up in any sort of visible way on the endpoint.
You can't see it.
If you look at the VPN properties, you can't see it in the Windows Firewall.
The traffic filters are implemented essentially in WFP,
in the Windows Filtering Platform,
so they're implemented in the OS at a very low level.
But we can see them in action,
and that's what I kind of want to demonstrate here.
So recall that we defined our traffic filter to restrict access
to the internal network on RDP port 3389,
and we defined the entire 172.16.0.0/24 subnet.
So, what does that look like in action?
Let's take a quick look.
And so I'm going to open up the PowerShell,
and the first thing I want to do is just demonstrate some behavior here.
So I'm going to try to ping a server on the internal network,
and the first thing you'll notice here is that the
name resolves to an IP address, but then I get a general failure message,
and this should happen if I try to ping any other internal resource.
So you can see ICMP traffic is not being allowed over this tunnel.
Now I'm going to run the Test‑NetConnection command,
I'm going to specify the port of 445, which is the SMB port,
and I'm going to specify the application server here,
what internal resource.
And you'll see that our TcpTestSucceeded report says False,
so we do not have access to that particular port.
However, if I change this port to 3389,
so you'll see now that the TcpTestSucceeded value is True,
so I do have access on this port.
That means if I open up the RDP application,
I should be able to RDP into the server.
And sure enough, I do.
Not real exciting here because this is a Windows Server Core server,
but I have access to this particular server.
So I'm going to bail out on that, and again,
if I was trying to open an Explorer window,
you would see that I would not have that access,
as I demonstrated previously.
So there you go.
No access to port 445, so I can't get to any SMB shares on the server.
I can't even ping it, but I can RGB to it.
So that is our traffic filter in action.
If you plan to implement this traffic filter using XML,
you'll use the code that you see here on your screen.
This traffic filter, again, identifies the protocol as Protocol 6,
which is TCP, the remote port range being 3389.
And if this was a multi‑value, you could,
if you had multiple ports, you could do 3389,
4000, what have you.
And then if it's a range, it would just be 3389 to 3392 or something like that,
right?
The RemoteAddressRanges here, as you see,
I've defined this in CIDR notation,
which makes it a little easier to configure in XML,
but you can do address ranges or you could do multiple addresses as well,
and those are comma separated.
Again, the VPNv2 CSP reference is your friend here.
It will tell you everything you need to know about the accepted
parameters in this particular traffic filter.
And looking at the traffic filter XML in practice,
let's take a quick peek at that,
what you'll see here is that I've implemented it here in this block,
which is what I just showed you just a minute ago.
This is our traffic filter, Protocol 6, 3389 to the internal subnet. So that's how it's implemented in the Sfile itself