Virtual Private Networks (VPNs)

A virtual private network (VPN) uses encryption to send data securely over an untrusted network.
The high cost of dedicated WAN connections was one of the main reasons for VPNs to be used by
organizations.

A VPN takes advantage of an existing internet connection to communicate securely between

devices. Let's see how this is done.

VPNs provide a secure internet connection between locations by encrypting packets in transit.

Encapsulation

A VPN uses a protocol that tunnels, or encapsulates, each of those packets into a new packet.

Information in the packet header of these encrypted packets routes the information through the
internet. On the destination device, the outer wrapping of the packets is removed, and the packet is
decrypted—"the data is back in its original format.

If an attacker were to intercept packets sent via a VPN, they wouldn't be able to read any of the
contents. Only the device on the other end has the appropriate decryption key that allows them to
view the packet contents.

Now, there are multiple ways that you can configure a VPN through the internet.

Host-to-Host VPN

The first way is using a host-to-host VPN. This type of VPN allows an individual host connected to
the internet to establish a VPN connection to another host. With a host-to-host connection, both
devices need the ability to establish and understand the VPN protocol that's used. Both devices
must have the software for encrypting the packets and encapsulating the packets.

Site-to-Site VPN

Another way is using a site-to-site VPN. With a site-to-site VPN, you have a collection of computers
at each location. Each computer in any location is able to communicate securely with any other
computer at another location.
Rather than requiring VPN configuration on every single computer, you install a single device, which
acts as a gateway server. A VPN gateway is a dedicated VPN device that handles VPN connections,
as well as the encryption and decryption of packets sent over the internet.

The nice thing about using a VPN gateway is the protocols and encapsulation method only need to
be configured and maintained on a single device for the entire network, instead of on each individual
device. It also allows for all traffic between the two sites to be encrypted 100 percent of the time.

Remote Access VPN

The final method is a remote access VPN. In this case, individual hosts on the network can establish
a VPN connection to the remote site. In this configuration, the client computer must be able to
establish the VPN connection with a special device called a VPN concentrator that sits on the edge
of the private network.

VPN concentrators are hardware devices that are dedicated to establishing client connections, as
well as encrypting and decrypting VPN packets. Each client is configured with software that allows it
to encrypt packets. The VPN concentrator is configured to allow or reject connections from users. It
also removes the encryption before forwarding the information to the private network.

VPN Protocols

Now, VPNs can use a few different methods to establish connections and encrypt traffic. These
methods are known as VPN tunneling protocols. The two most commonly used VPN tunneling
protocols are IPsec and SSL.

IPsec encrypts contents sent through a tunnel created by another protocol.

IPsec

IPsec is probably one of the most common tunneling encryption mechanisms currently used, and
IPsec is actually made up of two different protocols.

The first one is the Authentication Header, or AH. The second one is the Encapsulating Security
Payload (ESP). AH is used to authentic the connection, while ESP is used to encrypt the data that's
being sent through the connection.
When you implement IPsec, you can use either of these protocols by themselves. For example, if
you chose to implement AH only, then your VPN will have authentication, but no encryption. In most
cases, you'll want to make sure that your VPN solution using IPsec includes ESP.

IPsec also has two different modes for sending packets through the tunnel. The first way is called
transport mode.

With transport mode, IPsec only encrypts each packet's internal data. Everything else—"the
destination IP address, the origination IP address—"is all in cleartext.

The second mode is called tunneling mode. In tunneling mode, the entire packet is encrypted. It is
then encapsulated in another non-encrypted packet—"complete with a new IP header—"and sent
over the internet. Tunnel mode is usually the default sending mode for IPsec.

SSL

Another protocol that can be used for a VPN connection is SSL. SSL's been around for a long time.
It's been used in combination with other protocols, mostly HTTP, in order to secure traffic between
two devices.

For example, if you were to go to an online store and purchase a product, more than likely, you're
going to use the secure version of HTTP—"HTTPS—"to protect the credit card information we're
sending to the web server.

Well, HTTPS leverages SSL to encrypt the traffic between those two devices. This makes SSL a
great option for encrypting other types of connections between devices, such as a VPN connection.
SSL requires certificates for identity proof, as well as for encryption.

One of the benefits of using SSL is the fact that it uses port 443. This is really important because
most network firewalls in most organizations are already configured to allow HTTPS traffic on this
port, so we don't have to make any major firewall changes if we want to deploy an SSL VPN.

Split Tunnel vs. Full Tunnel

There's one more VPN configuration option we need to discuss, and that is the different between
split tunnel and full tunnel VPN configurations.

With a split tunnel VPN, only certain types of traffic—"for example, traffic destined for a specific IP
address range—"are sent through the VPN connection. All other traffic goes through the internet as
normal. This configuration might be good for people who need to access private network resources
but still want to access the internet through their own internet, and not through the VPN. It also helps
reduce the amount of traffic sent through the VPN—"instead of sending all traffic through the VPN,
only necessary traffic is sent.

Split tunneling also has something called inverse split tunneling. This is where all traffic is sent
through the VPN except for a specific type of traffic, which is routed through the regular internet,
unencrypted. The split is inverted, as its name suggests.

The other way you can configure the VPN is to route all traffic through the VPN, regardless of the
type of traffic. This is usually the default VPN configuration method.

Summary

When you implement a VPN, be sure to select a protocol supported by all of the devices that need to
encrypt or encapsulate packets. When you use a VPN through a firewall, make sure you open the
necessary ports to allow the VPN traffic through the firewall. In addition, make sure you know which
type of VPN connection and configuration is best for your organization.

VPN in Detail

VPN Basics
A virtual private network (VPN) is a remote-access connection that uses encryption to
securely send data over an untrusted network. By using a VPN, you can take advantage
of an existing internet connection to securely communicate between devices. When
working with VPNs, consider the following:

● A VPN provides an alternative to:

○ WAN connections.
○ Connections that use telephone lines and a remote access server.
● VPNs work by using a Tunneling Protocol that encrypts packet contents and
encapsulates those packets.
○ The encapsulated packets are routed through the internet using the
information in the packet header.
 ○ When the packet reaches the destination device, the outer wrapping
encapsulating the packets and the encryption is removed.
○ Only the destination device is allowed to remove the wrapping and restore
the packet to its original form.
● The following are two styles of VPN tunnels commonly used:
○ Full tunnel, which routes all of a user's network traffic through the VPN
tunnel. This can sometimes send traffic that is not necessary.
○ Split tunnel, which routes only certain types of traffic, usually determined
by destination IP address, through the VPN tunnel. All other traffic is
passed through the normal internet connection.
● VPNs can be implemented in the following ways:
○ A host-to-host VPN allows an individual host connected to the internet to
establish a VPN connection to another host on the internet. Both devices
must be configured for a VPN connection and have the software to
encrypt and encapsulate the packets.
○ A site-to-site VPN uses routers on the edge of each site. The routers are
configured for a VPN connection and encrypt and decrypt the packets
being passed between the sites. With this configuration, individual hosts
are unaware of the VPN.
○ A remote-access VPN uses a server (called a VPN concentrator)
configured to accept VPN connections from individual hosts.
■ The VPN concentrator is located on the edge of a network.
■ The VPN concentrator establishes multiple connections with
multiple hosts.
■ The individual hosts must be able to establish a VPN connection.
■ The hosts can access resources on the VPN server or the private
network using the VPN connection.
○ An always-on VPN employs the concept that a user is always on the VPN,
whether physically within the LAN or remotely. There is no turning it on or
off. All traffic is basically fully tunneled.
 ● Tunnel endpoints are devices that can encrypt and decrypt packets. When you
create a VPN, you establish a security association between the two tunnel
endpoints. These endpoints create a secure virtual communication channel. Only
the destination tunnel endpoint can unwrap packets and decrypt the packet
contents.
● Routers use the decrypted packet headers to deliver the packet to the destination
device. Intermediate routers along the path cannot read the encrypted packet
contents.

When implementing a VPN, be sure to:

● Select a protocol that is supported by all devices that need to encrypt and
encapsulate packets.
● Open the appropriate ports to allow VPN traffic through the firewall.

VPN and Wireless Networks

VPNs can also be used to help secure connections made over open wireless networks.
Many establishments, such as airports, hotels, and restaurants, provide unsecured
public Wi-Fi access. Because encryption is not used to secure the wireless connection,
many users are hesitant to use these networks. In most cases, this hesitancy is
warranted. However, it is generally considered acceptable to use a VPN connection to
securely transfer data over an open Wi-Fi network. As long as strong tunneling ciphers
and protocols are used, the VPN provides sufficient encryption to secure the connection
even though the wireless network itself is not encrypted. It is recommended that you
use IPsec or SSL to secure the VPN because these protocols are relatively secure.
Avoid using PPTP with MS-CHAPv2 as this configuration setup is no longer considered
secure.

If you are using a VPN over an open wireless network and need to access a secure
website, be sure your browser's HTTPS requests go through the VPN connection. To
conserve VPN bandwidth and improve latency, many VPN solutions automatically
reroute web browsing traffic through the client's default network connection instead of
through the VPN tunnel. This behavior would result in HTTP/HTTPS traffic being
transmitted over the insecure open wireless network instead of through the secure VPN
tunnel.

This lesson covers the following topics:

● VPN Tunneling Protocol

● Transport Layer Security Tunneling
● Internet Protocol Security Tunneling
● Secure Communication and Access

VPN Tunneling Protocol

A VPN can use a Tunneling Protocol that encrypts packet contents and wraps them in
an unencrypted packet. The Tunneling Protocol (also referred to as the VPN Protocol)
identifies the methods that devices use to establish the VPN connection and encrypt the
data. The three types of protocols used by VPNs are:

● Carrier Protocol (such as IP).

● Tunneling Protocol (such as PPTP or L2TP).
● Passenger Protocol (for the data being transmitted).

Many networks make use of a piece of hardware called a VPN concentrator. VPN
concentrators are advanced routers that can create and maintain many secure
connections to the network through VPN tunnels.

Transport Layer Security Tunneling

A transport layer security (TLS) VPN means the client connects to the remote access
server using digital certificates. The server certificate identifies the VPN gateway to the
client. Optionally, the client can also be configured with its own certificate. This allows
for mutual authentication, where both server and client prove their identity to one
another. TLS creates an encrypted tunnel for the user to submit authentication
credentials. These would normally be processed by a RADIUS server. Once the user is
authenticated and the connection is fully established, the VPN gateway tunnels all
communications for the local network over the secure socket.
Configuring an OpenVPN server in the OPNsense security appliance. This configuration
creates a remote access VPN. Users are authenticated via a RADIUS server on the
local network. (Screenshot courtesy of OPNsense)
A TLS VPN can use either TCP or UDP. UDP might be chosen for marginally superior
performance, especially when tunneling latency-sensitive traffic such as voice or video.
TCP might be easier to use with a default firewall policy. TLS over UDP is also referred
to as Datagram TLS (DTLS).

It is important to use a secure version of TLS. The latest version at the time of writing is
TLS 1.3. TLS 1.2 is also still supported. Versions earlier than this are deprecated.

Internet Protocol Security Tunneling

Transport Layer Security is applied at the application level. Internet Protocol Security
(IPsec) operates at the network layer of the OSI model (layer 3). This means that it can
be implemented without having to configure specific application support and that it
incurs less packet overhead.

There are two core protocols in IPsec, which can be applied singly or together,
depending on the policy:

● Authentication Header (AH)—performs a cryptographic hash on the whole

packet, including the IP header, plus a shared secret key (known only to the
communicating hosts), and adds this value in its header as an Integrity Check
Value (ICV). The recipient performs the same function on the packet and key and
should derive the same value to confirm that the packet has not been modified.
The payload is not encrypted so this protocol does not provide confidentiality.
● Encapsulating Security Payload (ESP) can be used to encrypt the packet rather
than simply calculating an ICV. ESP attaches three fields to the packet: a header,
a trailer (providing padding for the cryptographic function), and an Integrity Check
Value. Unlike AH, ESP excludes the IP header when calculating the ICV.

IPsec can be used in two modes:

● Transport mode—is used to secure communications between hosts on a private

network. When ESP is applied in transport mode, the IP header for each packet
is not encrypted, just the payload data. If AH is used in transport mode, it can
provide integrity for the IP header.

● Tunnel mode—is used for communications between VPN sites across an

unsecure network. With ESP, the whole IP packet (header and payload) is
encrypted and encapsulated as a datagram with a new IP header. AH has no use
case in tunnel mode, as confidentiality is usually required.
IPsec datagram using ESP in tunnel mode.

Configuring a site-to-site VPN using IPsec tunneling with ESP encryption in the
OPNsense security appliance. (Screenshot courtesy of OPNsense)

Each host or router that uses IPsec must be assigned a policy. An IPsec policy sets the authentication
mechanism and also the use of AH/ESP and transport or tunnel mode for a connection between two peers.

IPsec's encryption and hashing functions depend on a shared secret. The secret must be communicated to
both peers, and the peers must perform mutual authentication to confirm one another's identity. The
Internet Key Exchange (IKE) protocol implements an authentication method, selects which cryptographic
ciphers are mutually supported by both peers, and performs key exchange. The set of properties is
referred to as a security association (SA).
IKE negotiations take place over two phases:

● Phase I establishes the identity of the two peers and performs key agreement
using the Diffie-Hellman algorithm to create a secure channel. Two methods of
authenticating peers are commonly used:
● Digital certificates —are issued to each peer by a mutually trusted certificate
authority to identify one another.
● Pre-shared key (group authentication) —is when the same passphrase is
configured on both peers.
● Phase II uses the secure channel created in Phase I to establish which ciphers
and key sizes will be used with AH and/or ESP in the IPsec session.
There are two versions of IKE. Version 1 was designed for site-to-site and host-to-host
topologies and requires a supporting protocol to implement remote access VPNs. IKEv2
has some additional features that have made the protocol popular for use as a
stand-alone remote access client-to-site VPN solution. The main changes are the
following:

● Supports EAP authentication methods, allowing, for example, user authentication

against a RADIUS server.
● Provides a simple setup mode that reduces bandwidth without compromising
security.
● Allows network address translation (NAT) traversal and MOBIKE multihoming.
NAT traversal makes it easier to configure a tunnel allowed by a home
router/firewall. Multihoming means that a smartphone client with Wi-Fi and
cellular interfaces can keep the IPsec connection alive when switching between
them.

Secure Communication and Access

A Software-Defined Wide Area Network (SD-WAN) enables organizations to connect
their various branch offices, datacenters, and cloud infrastructure over a wide area
network (WAN). One of the key advantages of SD-WAN is its ability to provide
enhanced security features and considerations. For example, SD-WAN uses encryption
to protect data as it travels across the network and can segment network traffic based
on priority ratings to ensure that critical data is fully protected.

Additionally, SD-WAN can intelligently route traffic based on the application and tightly
integrate with firewalls to provide additional protection against known threats. SD-WAN
centralizes the management of network security policies to simplify enforcing security
measures across an entire network.

Secure Access Service Edge (SASE) combines the protection of a secure access
platform with the agility of a cloud-delivered security architecture. SASE offers a
centralized approach to security and access, providing end-to-end protection and
streamlining the process of granting secure access to all users, regardless of location.
SASE is a network architecture that combines wide area networking (WAN)
technologies and cloud-based security services to provide secure access to
cloud-based applications and services.

SASE offers several security features to help organizations protect their networks and
data as SASE operates under a zero trust security model. SASE incorporates Identity
and Access Management (IAM) and assumes all users and devices are untrusted until
they are authenticated and authorized. SASE also provides a range of threat prevention
features, such as intrusion prevention, malware protection, and content filtering.

Configuring a VPN 00:00-00:13

In this demonstration, we're going to cover how to configure OpenVPN on a pfSense security
appliance. We're already logged into pfSense on the Dashboard page.

Install OpenVPN Client Export Package 00:13-00:49

The first thing I'm going to do is to go to System > Package Manager and select Available Packages.
I'm going to type in ‘openvpn' to search for the OpenVPN Client Export package. This will allow us to
export our configuration settings to make setting up our clients a lot easier. Click Install and Confirm.
This will take about a minute or so to install. Now let's confirm the installation. Success.

Configure OpenVPN Server Type 00:49-01:13

Now let's go over to VPN > OpenVPN. We'll select Wizard to get started. In the past, setting up a
VPN was a bit complicated, but the wizard makes setting up OpenVPN really quick and easy.

For the type of server, we're going to select Local User Access. We could also pick LDAP or
RADIUS if you have those set up, but we don't. Click Next to continue.

Configure OpenVPN Certificate 01:13-02:10

Now we need to create a certificate authority. pfSense adds this right in the wizard so you don't have
to do it manually somewhere else, which is nice.

For the Descriptive name, I'll just enter in "TestoutCA". I'll leave these next few fields at the default
values and go down to Country Code. Here, I'll enter ‘US'. For State or Province, I'll enter ‘UT' for
Utah. For City, I'm in the wonderful town of ‘Pleasant Grove'. For Organization, I'll put ‘TestOut'. Now
click on Add new CA to add the Certificate Authority to the server.

Now we must create a new server certificate. We just added the Certificate Authority. Next, we need
an actual certificate. For Descriptive name, I'll just put ‘Testout'. I'll leave everything with the default
values. Country Code, State, City, and Organization are all auto-populated with the correct answers,
so I'll just click on Create new certificate.

OpenVPN Setup 02:10-03:52

Now let's configure the server information. For our interface, we want to select our WAN. We also
have LAN and DMZ. Our WAN is where traffic will typically come from. Our Protocol will be UDP on
IPv4 only. You can see we have some other choices in case your setup is different from mine.

Our VPN uses the default port of 1194. We'll enter a description for our VPN and just call it
‘TestoutVPN'.

We'll leave all the cryptographic settings set to their defaults and skip down to Tunnel Settings.

The first thing we must do is enter some virtual network settings for our tunnel network. This will be a
virtual network that our clients and server will use to communicate on. I'm going to enter
'10.10.20.0/24'. All my VPN clients will get an IP address of 10.10.20.something with a subnet mask
of 255.255.255.0.

Next is our local network. This is the LAN network that your VPN clients will access. My local LAN
network is '10.10.10.0/24'.

For concurrent connections, I'll just put in 5. You can enter more or less than that. It just depends on
how many VPN users you'll have connecting at one time.

Now, once your users connect, they'll need a DNS server. You could put in a public DNS or local
DNS. I'll put in the DNS that my LAN uses, which is '10.10.10.1'. This is also the IP address of my
pfSense appliance.

Scroll down and click Next.

Firewall Rules 03:52-04:39

Now we need to set up two firewall rules. We need to allow traffic from our VPN clients to our VPN
server. We also need to allow traffic from our clients through the VPN to our network. Lucky for us,
we don't have to do this manually. OpenVPN understands what we need, and by checking these
boxes, OpenVPN will configure those rules for us. Configuring rules is not part of this lesson, but
they're certainly a skill you need to know. Click Next to continue. And on this page, click Finish.

Let's review what we've done. We have our interface set to WAN. Our protocol and port are set to
UDP on port 1194. Our tunnel network looks good. Our encryption is here. And our description is
TestoutVPN.

Add an OpenVPN User 04:39-05:07

Now let's head over to System > User Manager and click on Add. I really don't want my admin user
to be the same as one of my VPN users, so I'm going to add a different user here to keep them
separate. For the username, I'll enter ‘danafellows'. I'll enter my password and confirm it. I'll just put
Dana for the full name. Click Save.

Everything looks good, and that's all I need to do here.

Confirm Server Access Mode 05:07-05:31

I'll go back up to VPN > OpenVPN, come down here, and click on the edit icon. For some reason,
our server mode changes to Remote Access SSL plus TLS, but we're using Remote Access (User
Auth), so we need to confirm that and change it back if needed. It looks like we do, in fact, need to
change that. I'll scroll down to the bottom and click on Save.

Client Download 05:31-05:54

Now it's time to download the client configuration. We'll go to Client Export. On the next page, scroll
down to our list of OpenVPN client configuration options. I'll find the one for the Windows Installer
and click on it to download the configuration file.

Now I'll copy this over to a machine I have on a different network and install the OpenVPN client.

Install and Run OpenVPN Client 05:54-07:46

I'm now on a machine on my DMZ network. I copied the installation file over, and I'll install it now. I'll
click Yes to the User Access Control, click Install to continue, and click through all the rest of these to
complete the installation process. Click Finish, and finally, click Close.

Now let's double-click to start the OpenVPN client. I'll drag the installation files into the Recycle Bin.

I'll move the OpenVPN client, here on the taskbar, to a spot where we can see it better. Right-click
on it and choose Connect. My username is automatically populated, so I'll just enter in my password
and check the Save password box. Click OK to connect. I get a message that I'm connected, and my
Assigned IP is listed here.

Now, if you're like me, you might ask yourself, "How did the client know how to connect to my
OpenVPN server out there on the internet?" Let's take a second to look at the config file. I'll
right-click and select Edit Config to open it. It opens in a text file, and here are all the settings that
were configured for us. Down here is the IP address of the WAN interface. Now, you might say, "Hey,
that's a private IP address." Yes it is. This is a test network, so I'm actually using a private IP range
for my WAN. Let's take a look at that for a minute.

Here's a diagram of my test network. I accessed my pfSense and OpenVPN settings from this client,
over here. The configuration is actually here, on the pfSense. The client over on my DMZ network is
the one that initiated the connection to the VPN just a second ago. This client can be anywhere on
the internet, but for demo purposes, I placed it on my DMZ. Now let's just confirm a few final things
before we wrap up.

Confirm That OpenVPN is Connected 07:46-08:49

I'm still on my client on my DMZ. I'm going to open a command prompt to check my IP settings. I'll
do an ‘ipconfig /all' and press Enter. I'll scroll up a bit. Here's the IP address of this machine on the
DMZ, 172.16.1.101. That is my IP scheme for the DMZ. Now let's scroll down a bit. Remember, we
made our tunnel network 10.10.20.0, and right here is an address from that range that's assigned to
us. We saw that a few minutes ago, also right after we connected.

One final thing. I access the pfSense configuration through a web browser. I have it blocked from
being accessed externally. But since we're connected to the LAN through this VPN, let's see if we
can access it. I'll open my browser, and in the Address field, I'll enter the IP of the pfSense with the
LAN address of 10.10.10.1. When I do that, the Sign In page is displayed, confirming that I have
access to LAN resources.
Summary 08:49-09:07

That's it for this demo. We configured OpenVPN on pfSense. We installed the client configuration
package, set up our certificate, configured OpenVPN server settings, created a user, downloaded
and installed the OpenVPN client on a remote host, and confirmed our connection.

Configure Remote Access, non-VPN

00:00-00:33
Remote access is a method that allows you to connect to a computer remotely from another
computer. This could be useful if you're logging into your computer at home while you're away,
helping a family member, or just requiring access to a server. Some of you may be familiar with a
VPN, which stands for Virtual Private Network. This is another means of connecting to a remote
network when you're physically not there. These connections require more knowledge to set up, but
the non-VPN method we're showing you today doesn't.

Setting up the Connection 00:33-02:42

To get started, we'll open our web browser and type in remotedesktop.google.com. We'd like to
access my computer, so let's click on this option here. You'll be required to have a Google account.
We already have one, so we're just going to log in. First, we need to provide our email, and after
that, input our password. We're not worried about saving the password or this extra pop-up down
here, so we'll make these go away. On the left-hand side, we have three options: Remote Access,
Remote Support, and Set up via SSH. Remote Access is for accessing another PC, something you'd
set up. Remote Support would be for helping someone else, where they'd need to download a link
and provide you with a code. The third option is to set up an SSH connection to a Windows or Linux
Computer.

We're going to walk through the setup for remote access. First, we must ensure we're on the
computer requiring remote access and then download this link here. It will download an extension
that can be used by both Chrome and Edge, as they're built on the same platform. It may take a bit
for this to download, so we're going to fast-forward. Now, you can see the MSI file is downloaded. All
we have to do is click Accept & Install. This will start the installation process. The window should pop
up to show us where the MSI file was downloaded. Once executed, it will prompt to close some
applications before it can be installed. Our install is done, so we can close this window.
Now that we have Chrome Remote Desktop installed, we can name the PC we are setting up. By
default, it grabs the hostname of the computer. If your hostname wasn't set up previously, you may
see a mix of letters and numbers instead of Office-PC like this one. We're going to click Next. For
security purposes, you'll be required to set up a PIN. I'm going to set this and then confirm it for a
second time. After clicking Start, we should be able to accept one final UAC prompt, and then our
Office-PC should be ready to go. You'll notice it says Offline; however, when you refresh the web
browser, it's now Online. Now, let's try connecting to this PC from another PC.

Connecting to a Remote Computer 02:42-03:26

Okay, we're on our other PC where Chrome Remote Desktop isn't installed. Let's navigate to
remotedesktop.google.com and click Access my computer. Login with your previously set up
credentials. Once done, we'll see the main screen for our remote desktop menu. In the middle, you
can see the computer we just set up for remote access. Let's give it a go and select it. After that,
you'll be prompted for a PIN. You can choose to remember it on this device; however, if you're
focused on security, you can choose not to remember it.

Great, it looks like our remote connection worked. We have access to the desktop and can do
everything on it just like you'd be sitting at this desk, whether it's just surfing the internet or even
launching different applications, like system information.

Summary 03:26-03:35

That's it for this demo. In this demo, we showed you how you can leverage a way to connect to your
PC remotely without using a VPN.