So let's move onto the next demonstration, configuring our first VPN server.
And so here we are on our VPN server.
The virtual machine has already been provisioned, joined to the domain.
But before we move along too far, I want to talk a little bit about networking.
If you will recall from some of our previous modules,
we talked about the networking model supported for the RRAS server.
You could have a single network interface or you could have multi‑homed server,
which is pretty common where you have an interface in a perimeter
DMZ network and the other internal interfaces either on the LAN or
on an inside perimeter facing the LAN.
And so in that scenario,
there's some special attention you have to take to make sure the
configuration of the network interfaces is functional.
So on this server and in this lab I'm using a
multi‑homed server for demonstration.
Just to reiterate,
a single network interface is perfectly acceptable
in a lot of different scenarios, so don't feel bad if you just have one.
That's okay.
That's acceptable.
And in that scenario, it's very easy.
You just configure it as you would any other server,
but you have to pay careful attention when you have multiple network interfaces.
So I'm going to open the network control panel,
and I like to use the classic one and get right where I'm going.
So I'm just going to type in the search field ncpa.cpa,
and that takes me right to this classic network control panel.
You'll see I have two interfaces,
and the first thing that I want you to notice is that I've renamed them.
They are not Ethernet0 and Ethernet1 and so forth
because those aren't very descriptive,
and you'll find that having clearly labeled network
interfaces is going to be really helpful later on.
So in this case,
I have renamed them LAN and DMZ to kind of illuminate what it
is exactly that their assignments are for.
This is the LAN interface, it's on my domain network,
and the DMZ interface is in a DMZ or perimeter network.
Now, I would encourage you to use whatever naming convention you like.
If you want this one to be VLAN, you know,
2012 and VLAN 52, really doesn't matter as long as they make sense to you.
What I would avoid is using the name Internal for any internal
interfaces because RRAS actually uses Internal for the name of the
virtual interface that it uses for VPN clients,
so we want to avoid using the name internal to avoid
any confusion there in the future, so I've renamed mine LAN and DMZ.
So let's take a look at the DMZ interface properties.
I'm going to right‑click, choose Properties here,
and you'll see that I have an IPv4 and IPv6 enabled,
and that's it.
Since this is a DMZ interface, I have no reason to provide any services in
that network other than IP, so I've disabled everything else.
So this reduces my attack surface in that public‑facing or perimeter‑facing DMZ.
I've just configured IPv4 and in this case IPv6. Also, when you're configuring
IPv4, ensure that you configure an IP address subnet mask and default gateway,
but do not configure DNS servers here.
Those are configured on the internal interface.
So let's go take a look at my internal interface. Choose Properties. And here,
since this is on my domain network, or on my LAN,
I've left a couple of the other services open because I
need Client for Microsoft Network and those types of
things, so for management and whatnot.
But here, when I look at my IPv4 properties,
you'll see that I have an IP address and subnet mask,
but no default gateway.
Again, a server with two network interfaces or more than one network interface,
multi‑homed, can have only a single default gateway. It
should be on the external‑facing network.
The internal network, of course, needs some additional work.
So, and by the way, I have a DNS server defined here as well.
So you would define your DNS servers only on the internal interface.
Now, in the absence of a default gateway, the only network that would be
reachable here would be this 172.16.1.0/24 network.
If I need to reach any remote internal subnets, and in this example here, my
domain services are on 172.16.0, so how does that work?
How I'm able to get to that?
Well, I have to create a static route.
And so the best way to do this is by creating a static route
using PowerShell. So let's open up a PowerShell window.
Needs to be elevated, of course.
And in this case, I've already created this route because I
had to join this server to the domain.
So in this case, you'll see that my IP address is on the 172.16 network, but
I can still ping my domain controller at 172.16.0.200.
And the reason for that is because, again,
I've created the static route previously. And we can take a look at the
routing table. You can use the classic route print,
but again, I prefer to use PowerShell Get‑NetRoute.
So we're going to look at the IPv4 routing table specifically, and here is the
route that you see that I created previously. I define a route, a static route
as 172.16.0.0/16, so I basically summarize the entire 172.16 /16 network, at
least those first two octets, and my next hop is my gateway on this particular
subnet, which is 172.16.1.254.
So to demonstrate what this might look like if we needed to add an
additional route, so let's say I wanted to add,
for example, 172.17.0.0/16, well,
we will use the New‑NetRoute command. The address family is IPv4. The
DestinationPrefix in this case is 172.17.0.0/16.
The NextHop is again the gateway on this network.
Where is the egress point on this network?
And in this case, it is 172.16.1.254. And then we need to provide the interface.
So in other words,
which interface does this traffic egress on. And in this case, it
will accept two values, or one of two values, and that is the
InterfaceAlias or the InterfaceIndex.
I will use the InterfaceAlias because I know what it is because
I renamed it earlier, and that is the LAN interface. And now
you'll see I have my second route, 172.17.0.0. 172.16.0.0 was
the one I added previously.
So I would be able to reach either of these remote internal subnets through the
internal interface without having a default gateway there.
Now, if I needed to reach additional remote internal networks,
let's say I had something in, you know,
10.21.12.0 or something else, maybe I wanted to route the entire 10 network,
I would add additional routes accordingly, and you would
do it here at the command line. I would encourage you to
summarize as much as possible.
So if you have a dozen 10.0.something routes,
you may just want to bring the old, you know,
whole 10.0.0.0/8 network or maybe even just do a /16.
You want to keep it as simple as possible just to,
you know, keep your sanity, but at the end of the day,
as long as the server can reach any of these internal subnets,
then its clients will be able to reach them as well.
And again,
and this is only really required when you have two network interfaces, sSo just keep that in mind.