At its core,
the Windows VPN server really is nothing more than a
networking device; it's a router fundamentally.
And so when you connect to the VPN server,
that traffic needs to be routed to the internal network,
and so forth.
So there are some important networking considerations that have to be made
when considering where and how to deploy our VPN server.
First is network placement.
Where are we going to put this VPN server?
Well, we can put the VPN server directly on the LAN,
put it on the internal network and call it a day,
but you may also want to put it in a perimeter or DMZ network,
and there are advantages and disadvantages to that,
either way, and we'll talk about that in more detail shortly.
Network interface configuration, again, you can do one network interface,
which is the standard for a Windows server,
but you can also support multi‑home with multiple network interfaces.
For VPN client addressing, when VPN clients connect,
they obviously need an IP address,
we need to consider whether or not to use DHCP or a static address pool.
And for VPN client IP subnet assignments,
we need to decide what those subnets look like,
what those prefixes looks like, and also make accommodations for routing.
And finally,
our edge firewall needs to be configured to allow traffic from
the public internet into the VPN server itself.
So let's talk a little bit about VPN server network placement.
The simplest way to do this is just to put this VPN server on your network,
join it to your domain,
and then translate that traffic in from the
internet from from your edge firewall, and and call it a day.
That's probably not the best deployment model,
and we'll talk a little bit more about that shortly.
But in this scenario, a LAN‑based,
domain‑joined, single‑network interface server is very simple,
very easy to deploy, and easy to manage.
You can also put the VPN server in a DMZ or a perimeter network,
and here you could join it to your domain if you wish.
That's optional in this scenario.
Always On VPN does support workgroup‑ joined machines; you
don't have to join it to the domain.
And arguably, if you're going to put it in a DMZ network,
you probably shouldn't join it to a domain anyway,
but that's a design decision you have to make.
But in that scenario, you can do this with a single network interface,
and it works quite well.
Another option available to you is to do multi‑home,
and there's a variety of different ways you can do this.
Some customers will put the server on the LAN with the
network interface in the internal network,
and then another network interface in the perimeter or DMZ network,
and in this scenario, it's usually domain‑joined.
Another scenario that works quite well for high‑security
environments is when the VPN server is in a perimeter or
DMZ network with two interfaces,
and the external interfaces in an external‑facing DMZ,
and the internal interface is in an internal‑facing DMZ.
This forces traffic leaving the firewall to cross a perimeter,
or internal firewall,
for traffic inspection and logging before it reaches the internal network.
Now, when our VPN clients connect to the VPN server,
they're going to need an IP address.
They get a virtual interface and establish a virtual
tunnel link from the client to the gateway.
And there are a couple of ways to perform client IP addressing.
The first is DHCP, and while it sounds like that might work well,
DHCP is not recommended for a couple of reasons.
First of all, you have very limited addressing options.
You can only assign addresses from the subnet for
which the VPN server belongs to.
And so, that subnet might not have enough IP addresses.
If you're going to support a couple of thousand
endpoints or connections per server,
you may not have the space available in that DHCP scope to support that.
Also, DHCP introduces another dependency,
and if DHCP is down or fails,
no clients will be able to connect or route or anything like that,
so it tends to be problematic.
Also, there's no real advantage to using it,
simply because the clients don't lease IP addresses from the DHCP server,
the VPN server does.
So there's no way to do any sort of of logging or tracing to find out,
well, who leased this specific IP address from the DHCP server?
If you go to the DHCP server,
you'll see that the VPN server leased a block of 25 or
50 or 100 IP addresses and that's it.
Also, the VPN server, by default, discards all of the options that are in DHCP,
so there's no real advantage there to using it.
So the recommendation is to use a static pool.
A static pool provides you the flexibility to deploy
as many IP addresses as you want,
and then you're not limited by the space available on the internal subnet.
You can also use a static address pool with a unique IP subnet,
and this is really recommended because it does allow you to
very easily determine where VPN client traffic is coming
from, it's easier to see in logs,
and identify in logs; it's also easier to just intuitively know that this
particular traffic is coming from a VPN client subnet.
That can be helpful for ACL and log searching and things like that.
My recommendation also is to over provision here.
You're carving out a unique subnet,
a unique IP subnet that is not in use in your network.
If you're expecting a few thousand connections,
try not to provision, you know, 2000 client IP addresses.
My suggestion is to over provision that.
Provision 3000 or 4000 even, for that matter.
Give yourself from some room for growth,
also give yourself some room to support spikes and things like that.
IPv6 is supported for Always On VPN; it is optional.
The only option here is to use a static IP address pool with a unique prefix.
It's also important to know that your internal network must be configured
to route VPN client IP subnets back to each individual VPN server, if you
have more than one VPN server. This is crucial.
Sometimes it's going to involve setting a static route on an internal
firewall, or if you're using routing protocols,
you may need to publish those routes internally.
In terms of the edge firewall,
it needs to be configured to allow inbound TCP port 443 to support the
SSTP protocol. It also needs to be configured to allow inbound UDP
ports 500 and 4500 for the IKEv2 protocol.
These are the only protocols and ports that are required to
be allowed inside from the edge firewall.
Also, when you're configuring that,
ensure that the public IP address translates to the private IP address
of the VPN server, and make sure when you're setting up this NAT rule
that you are translating only the destination address. Do not translate
the source address; this causes problems for VPN servers. It also makes
the logs rather meaningless because all the traffic appears to come from
the edge firewall, and again, it can also cause problems for IKEv2, and
it also causes serious problems when you're doing load balancing,
So avoid source NAT‑ing,
perform only destination NAT. Administrators also need to decide on a
tunneling model for their endpoints. The two options are split tunneling and
force tunneling. With split tunneling, only traffic bound for the internal
network is routed over the VPN, and this is the recommended model. It
provides the best user experience.
It also ensures best performance and also reduces the traffic burden on your
internal infrastructure. Force tunneling is used if you want to perform
traffic inspection and do those types of things for your internet traffic
for your remote or field‑based clients.
All traffic, including internet traffic, is routed
over the VPN tunnel in this scenario.
Again, you can use this to, you know,
provide visibility and control, to perform traffic inspection and content
filtering, and things like that for internet traffic.
It generally ends up resulting in a rather poor user experience,
mostly because you now have suboptimal network paths,
additional latency, and a variety of things that conspire
to make that a rather, again,
poor user experience. It does require many more resources on the back end.
You need better internet pipe,
you need more servers provisioned with more CPU and memory.
Generally speaking,
this is a model that we want to avoid, mostly because there are
better options or better alternatives to that.
There are more elegant ways to perform traffic inspection,
internet traffic inspection, and you know,
provide visibility and control for those endpoints when they're in their field,
rather than being heavy handed and tunneling all that traffic back over the VPN tunnel.