Network Troubleshooting Basics

Cybrary is a well established and free IT training platform with several intuitive labs to explore

A paid subscription with more advanced labs is available as well outside the scope of this platform

Head to https://www.cybrary.it to create a free account for learning available on their platform

Head to Network Troubleshooting Basics to complete it yourself or you can perform on homelab below

Requirements:

 • Windows PC w/ Internet Connection

 • 2 USB Flash Drives w/ at least 64GB Capacity

 • Unused PC w/ at least 4GB of Memory

1. Network Troubleshooting Methodology

Being methodical is a great help when troubleshooting network issues. Users often just tell us it's broken

The first goal in resolving any IT related problem is to narrow down the total scope of the investigation

Begin by thoroughly understanding the reported problem and gathering as much user information as possible

Monitor systems to pinpoint the issue's symptoms, and determine what devices or systems are being affected

Determine if the issue is localized or systemic, and affecting a specific segment, or the entire network

As you work to find the cause of the problem, examine the network device configurations to ensure correct

Check for misconfigured IP Addresses, subnets, VLANs, or access control lists (ACLs) to find the root cause

Use the ping and traceroute tools to test basic network connectivity and identify potential routing issues

Start with local tests and gradually move outward. Use nsloookup or dig to verify DNS resolution process

If necessary, capture network packets using tools like Wireshark or TCPDump and analyze captured traffic

This will help identify anomalies, errors, or excessive traffic that may be causing the overall problems

Ensure that DNS servers are reachable and correctly configured. A simplified troubleshooting checklist:

1. Define the Problem

2. Identify Affected Systems

3. Isolate the Problem

4. Check Physical Connectivity

5. Review Configuration

6. Ping and Trace Route

7. Check DNS and Name Resolution

8. Examine Network Traffic

Effective network troubleshooting can be performed by using simple tools. Some common examples include:

The ping command is a basic tool that uses the ICMP protocol to check the reachability of a network host

The tool is designed to work on an Internet Protocol (IP) network and measure thr packets round-trip time

Traceroute (on Unix-based systems) and tracert (on Windows) are used to trace the path that packets take

The tools can identify each node from origin to destination and helps identify where failures are occuring

Netstat is a command-line tool that displays network connections, routing tables, and interface statistics

This tool is extremely useful for diagnosing network issues related to the connections and TCP / UDP ports

Wireshark is a powerful network protocol analyzing, allowing you to capture and inspect packets real-time

This is an invaluable tool for identifying network traffic issues and diagnosing protocol-level problems

Nslookup (on Windows) and dig (on Unix-based systems) are used to query DNS (Domain Name System) servers

This is the process which resolves hostnames to IP addresses and vice versa. They help diagnose DNS issues

Ipconfig (on Windows) and ifconfig/ip a (on Unix-based systems) display network interface configurations

They are incredibly useful for verifying and modifying the network settings on any given local machine

Similar to Wireshark, TCPDump is a packet analyzer for Unix-like systems, performing captures of packets

It captures and displays network packets, but unlike Wireshark, this is often used entirely from the CLI

Physical network issues like faulty cables or connectors can quite often cause network problems as well

Cable testers are tools which help identify and diagnose these hardware-related and physical layer issues

Many tools are available to perform network troubleshooting. It is important to know when to utilize each

2. Troubleshooting Layer by Layer

Network connectivity is broken into three primary layers, these are covered in the OSI and TCP/IP models:

 • Layer 1: Physical

 • Layer 2: Data Link

 • Layer 3: Network

If there is a failure level issue at the physical layer, all layers above it will also fail as a result

At the physical layer, we look for issues with the network card, the network cables, and the switch ports

We can check the operating systems logs to look for signs of a hardward falure on the network card (NIC)

We can replace the NIC card if we have a spare, or we can install a USB NIC card just for testing purposes

If the NIC card is fine, there may be an issue with the UTP cables that connect the NIC card to the switch

An easy test is simply replacing the UTP cable from host to wall jack and from patch panel to switch port

If the cable connections are functioning, we then check the switch port for issues or intentional blocks

For example, Cisco switches can be configured to allow one MAC address on a given port and block others

If we suspect a port issues, we can try moving the host to another switch port on that same Virtual LAN

Another UTP cable in the wall goes from the jack to the patch panel in the server room / network cabinet

It's rare, but these cables sometimes develop issues, and when they occur most folks overlook the signs

If you do not have a cable tester handy, try moving the host to another nearby jack to test the current

At the data link layer, we are concerned with the local LAN communication, aka, host to switch to host

First, test if the host can reach other hosts on the local subnet or on the local network segment / VLAN

If there is an issue, one should check the ARP cache on the local host and remote host for a bad mapping

On the switch, the MAC address table (CAM Table) keeps a mapping of the MAC address to the switch port

Sometimes, this information needs to be updated. Bad MAC table entries must be cleared if needing updated

We should also check the switch configuration to ensure that the port is in the correct Virtual LAN (VLAN)

At the network layer, we are concerned with the movement of IP packets from network to network or router

This layer had additional levels of complexity compared to layers 1 and 2, common things to check here:

 • Is the IP Address on the host correct?

 • Is the subnet mask on the host correct?

 • Is the default gateway on the host correct?

 • Can the host reach the gateway?

 • Can the gateway reach the host?

A hosts's IP Address can be configured manually or automatically using Dynamic Host Configuration Protocol

With Dynamic Host Configuration Protocol (DHCP), clients lease IPs from a set pool of available addresses

When a clients DHCP lease expires, the client must make a new request for an IP address to the DHCP server

A DHCP server can provide an IP Address, network mask, deafult gateway, and other important config items

like a DNS server for name resolution and domain name so that the client only needs hostname instead of IP

Simply releasing and renewing the DHCP lease can often help resolve connectivity issues with DHCP clients

If clients can reach a remote server by IP Address but not by name, there is an issue with name resolution

Name resolution is the bane of many network administrators, often complex problems boil down to just this

Always check to see if the client has a DNS server entry configured, kept in the /etc/resolv.conf on Linux

If a nameserver entry points to the correct name server, then pivot your focus on that DNS server itself

For example, an A record may be misconfigured in the local zone file, or the DNS service needs restarting

When troubleshooting an issues, it is always best to take a layer by layer approach, starting from Layer 1

In the next lesson, you will build a virtual network where you will troubleshoot and resolve common issues

3. Install Arch Linux

Arch Linux is a lightweight, flexible, and minimalist Linux distribution designed to offer full control

Its philosophy centers on simplicity, not in the sense of being beginner-friendy, but in the sense of

keeping the system free of unnecessary layers so users can build exactly the system they want from scratch

According to the official website, Arch Linux is a "simple, lightweight and flexible Linux distribution"

In this lab we will use the Arch Linux Distribution to emulate an enterprise network for troubleshooting

Arch Linux is unique in that you must install the operating system piece by piece through the command line

Download Arch Linux Image: Arch Linux Download Mirrors

Download Rufus Disk Imaging Software: Rufus Official Download

Insert USB Flash Drive, run rufus.exe, select target drive, select the Arch Linux Image, then hit start:

Remove the USB Flash Drive and Insert into unused PC. Start PC and press the hotboot key at the startup:

Select the option to boot from your USB Flash Drive, then select the Arch Linux install medium from below:

Once the operating system loads you will be presented with a root command prompt to install the OS from:

Previously it was required to build this operating system line by line with a command for each portion

Now there are several installer scripts which come bundled with arch which make the install much easier

For the sake of having a deep understanding of the OS, in this lab we will be installing the classic way

We will be customizing each aspect of the OS, start by running the command to list the keyboard layouts:

The list is large so don't get decision paralysis, run the following command to set to the default us:

Run the following command from the Arch Installation Terminal to set the operating systems font package:

Now run the following command from the Arch Installation Terminal to verify the systems boot mode:

If the system returns 64 or 32 you are in UEFI 64-bit or 32-bit mode, if no results you're in BIOS mode

Plug in your ethernet cable and run the following commands to check for an active internet connection:

Next run the following command from the Arch Installation Terminal to update the systems clock and time:

Next run the following command from the Arch Installation Terminal to lisk the avilable disks to install:

The drives will be listed and you should tell your target based on the size, remove the +- from the name

Run the following command from the Arch Installation Terminal to begin partitioning with the fdisk tool:

The fdisk tool can be used to create a disk partitioning format that our operating system will follow:

 • Press n to create a new partition

 • Enter 1 as the partition number

 • Press Enter to accept the default first sector

 • Set the last sector to +1G for a 1GB partition

 • Enter y to remove the vfat signature

 • Change to EFI System type by pressing t and selecting parition 1 and option 1

 • Press n to create another partition

 • Enter 2 as the partition number

 • Press Enter to accept the default first sector

 • Set the last sector to +4G for a 4GB partition

 • Change to Linux Swap type by pressing t and selecting partition 2 and option 19

 • Press n to create another partition

 • Enter 3 as the partition number

 • Press Enter to accept the default first sector

 • Press Enter to accept the default last sector

 • Change to Linux x86-64 Root type by pressing t and selecting parition 3 and option 23

 • Press p and confirm you see all three paritions

 • Press w to write changes to disk and exit fdisk

Run the following commands from the Arch Installer Terminal to format and initialize our new paritions:

Run the following command from the Arch Installer Terminal to mount the paritions and enable the swap:

Run the following command to install basic linux utilities to be carried over to our installed system:

Run the following command from the Arch Installation Terminal to generate the fstab file and UUID labels:

Run the following command from the Arch Installation Terminal to change the root into the new systems root:

You will notice that the terminals prompt has changed to [root@archiso /]#, indicating we are on system

Run the following commands from the Arch Installation Terminal to set the timezone, in this case EST time:

Run the following commands from the Arch Installation Terminal to set the localization and keyboard layout:

Run the following command from the Arch Installation Terminal to set our machines network hostname:

Run the following commands from the Arch Installation Terminal to set a root password for the arch system:

Run the following commands from the Arch Installation Terminal to install the Grub bootloader and scripts:

Run the following commands from the Arch Installation Terminal to reboot into our newly created system:

After the reboot our system will load into the GRUB bootloader and present us with a command line after:

Hit enter to select the first option and you will be presented with the command line for your new system

Before moving on to the next section for our lab we need to login, username root and the password you set

4. Install Lab Tools

Though we now have our base operating system, we will be using more tools in this toubleshooting lesson

Let's go and install these tools including a desktop environment, GNS3, Docker, and the VM dependancies

Run the following command from the Arch Linux Terminal to create our initial network configuration file:

From the nano text editor, type out the few lines listed below, then CTRL+O to save and CTRL+X to exit:

Run the following commands from the Arch Linux Terminal to enable and start the network and DNS services:

Run the following commands from the Arch Linux Terminal to syncronize our packages and reboot the system:

Run the following commands from the Arch Linux Terminal to install XORG and the GNOME desktop environment:

Now that we have the garphic environment installed, our OS will boot to a login screen, then the desktop:

Now we are in business. Many programs however don't supporting running as root so we create another user

To reach the Terminal from within GNOME, click the 9 dots at the bottom and click the Console application:

Run the following commands from the Arch Linux Terminal to create a local user account and add sudo to it:

Now find the line below and remove the hashtag and space to allow members of the wheel group to use sudo:

Log out or reboot the operating system and log back in with our new account, we see that the tour works:

GNS3 is an application which allows you to deploy virtual network topologies with official device images

In this lab we will be using the GNS3 application as our network emulator to build the enterprise network

Run the following commands from the Arch Linux Terminal to install all the GNS3 dependency programs:

Run the following commands from the Arch Linux Terminal to install GNS3 and the full GNS3 utility suite:

We will be using Docker later in this lab to build container appliances for our virtual network topology

Run the following commands from the Arch Linux Terminal to enable and start docker and modify permissions:

Unfortunately GNS3 still calls Version 1.24 of the Docker API which is older than the minimum required

Run the following command from the Arch Linux Terminal to edit the docker applications service config:

Navigate to the first empty line in the configuration file and type the following, CTRL+O & CTRL+X to save

Run the following commands from the Arch Linux Terminal to apply these changes to the docker service:

Run the following command from the Arch Linux Terminal to install additional Docker application plugins:

Run the following command from the Arch Linux Terminal to install TigerVNC for our virtual vnc consoles:

Unfortunately there is a bug in the working version of python-pyqt5 5.15.11-3 which breaks the GNS3 tool

Run the following command from the Arch Linux Terminal to downgrade this package and fix your GNS3 install:

Our application should be ready to go now. In the future this step may not be necessary but here we are

Run the following command from the Arch Linux Terminal to launch the GNS3 application in the background:

Resulting Output:

Once GNS3 opens you will be directed to the setup wizard. Select 'Start and connect to a local controller'

On the Local Controller Configuration page, ensure /usr/bin/gns3server is the path and the port is 3080:

Once the application connects to the local server, you will be greeted with a success page, click finish:

We now have our platform running on which we will construct our network topology for the troubleshooting

5. Install VyOS Appliance

Our virtual network will include an IPsec VPN tunnel to connect two remote network sites as a logical LAN

Before we can build the VPN connections we must create the environment they will be making tunnels within

VyOS is an open source command line driven firewall program with site-to-site VPN capabilities and tools

Our IPsec tunnel will be managed by two VyOS firewall appliances, let's walk through installing them both

Head to GNS3 Marketplace to download the VyOS .gns3a file

Head to VyOS Stream Releases to download the latest VyOS version

From the GNS3 GUI window click on File > New Blank Project > title your project as Project4 and hit ok:

We must import appliances in order to simulate them on our virtual network, head to File > New Template:

From here head over to Import and Appliance File > vyos.gns3a > Install the appliance on the main server:

From the GNS3 Install VyOS appliance menu, click Create a new version and enter 1.5 + your iso filename:

Your image filename will likely be different, it is critical to ensure that you enter the exact filename:

Select the VyOS Nightly version and click Next > OK > Finish to install the new GNS3 Appliance Template:

We can now use this appliance to later initiate the VPN connections that are built into VyOS, click OK

6. Build Docker Containers with Alpine

Docker is a container deployment tool which we will use in this lab to create virtual containers as hosts

Alpine Linux is a lightweight distribution of Linux which is small and resource efficient as a container

Rather than importing our Servers and the Hosts as appliances, we will create each of them from scratch

This moves us away from the black box of vendor provided appliances to understand the fundamental kernel

This will give you a deep understanding of routing protocols and underlying software enabling connectivity

We have 4 seperate appliances to make: a File Server, a DNS Server, two Linux Hosts, and two Web Browsers

Run the following command from the Arch Linux Terminal to create the Dockerfile for our File Server node:

Being the File Server, this node will be responsible for listening on TCP 21 and performing authentication

Our File Server will run Alpine Linux as the OS and Samba as the file server, type out below and save:

Next we will create a Dockerfile for our DNS Server, which will be responsible for domain name resolution

Run the following command from the Arch Linux Terminal to create the Dockerfile for our DNS Server node:

Our DNS Server will run Alpine Linux as the OS and Technitium as the actual DNS Server, type it out below:

Next we will create a Dockerfile for some standard linux hosts, we strip out the heavy routing protocols

We will however add in some useful tools to allow us to test connectivity and perform basic host commands

Run the following command from the Arch Linux Terminal to create the Dockerfile for our Linux Host devices:

Our Host devices will also run Alpine Linux as the OS and include networking testing tools, type out below:

Lastly we will create a Dockerfile for an out of band web browser to manage the pfSense firewall appliance

Run the following command from the Arch Linux Terminal to create the Dockerfile for our OOB Web Browser:

Our Browser devices will also run Alpine Linux and must include web-fonts for the display, type out below:

Run the following commands from the Arch Linux Terminal to build the Docker images from our Dockerfiles:

From the GNS3 GUI window, click File > New Template > Manually Create a New Template > Docker Containers:

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: file:latest

 • Name: FILESERVER

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment: Leave Blank

Click Finish then head to FILESERVER > Edit and change these general and advanced settings, then hit ok:

 • Symbol: :/symbols/affinity/square/blue/server.svg

 • Maximum Memory: 256 MB

 • Extra Volumes: /home/ftpuser

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: dns:latest

 • Name: DNS

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment: Leave Blank

Click Finish then head to DNS > then Edit and change these general and advanced settings, then click ok:

 • Symbol: :/symbols/affinity/square/green/server.svg

 • Maximum Memory: 256 MB

 • Extra Volumes: /etc/bind

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: host:latest

 • Name: LINUX-A

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment:

Click Finish then head to DNS > then Edit and change these general and advanced settings, then click ok:

 • Symbol: :/symbols/affinity/square/blue/client_vm.svg

 • Maximum Memory: 256 MB

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: browser:latest

 • Name: BROWSER-A

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment:

Click Finish then head to DNS > then Edit and change these general and advanced settings, then click ok:

 • Symbol: :/symbols/affinity/square/blue/globe.svg

 • Maximum Memory: 1024 MB

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: host:latest

 • Name: LINUX-B

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment: Leave Blank

Click Finish then head to DNS > then Edit and change these general and advanced settings, then click ok:

 • Symbol: :/symbols/affinity/square/red/client_vm.svg

 • Maximum Memory: 256 MB

From the Preferences Windows, under docker containers, click New > Existing Image > and use these options:

 • Image list: browser:latest

 • Name: BROWSER-B

 • Adapters: 1

 • Start command: Leave Blank

 • Console type: vnc

 • Environment:

Click Finish then head to DNS > then Edit and change these general and advanced settings, then click ok:

 • Symbol: :/symbols/affinity/square/red/globe.svg

 • Maximum Memory: 1024 MB

Now click on Apply and then OK. Our Docker containers will be available to deploy as appliances in GNS3

7. Deploy and Configure Virtual Network Topology

With our appliances available, we are ready to construct the environment which will run our lab exercise

From the GNS3 applications topology view, click on the 'Browse all devices' bottom at the bottom left menu

Drag an instance of each of the appliances and two cloud appliances to match the topology given below:

Now click on the ethernet cable icon to add links within our internal networks, use eth1 on the VyOS hosts

Now connect each of the VyOS firewalls to their cloud, make sure to use the interface eth0 on those VyOS:

Now that our nodes are physically connected, right click each node and change the hostname to remove the 1

Let's also add some topology elipses and text to make things a bit prettier, why not, standard housekeeping

The VyOS routers only need 512MB to run but are configured to use 2GB by default, right-click to change

Now let's assume the role of the network administrators and provision each VyOS Firewall Appliance fully

We need to first establish connectivity by configuring the interfaces, both public and private with IPs

Right click each of the VyOS Firewalls and click Start to turn them on, then for appliance A hit console:

Login to the routers console with username vyos and password vyos, now let's go configure our interfaces

Run the following commands from the VyOS Router Console to configure both the network interfaces and NAT:

Run the following command from the VyOS Router Console to verify proper IP Addresses for our interfaces:

Resulting Output:

We can see that each of our interfaces now has an IP address assigned, let's switch to VyOS-FIREWALL-B

Run the following commands from the VyOS Router Console to configure both the network interfaces and NAT:

Run the following command from the VyOS Router Console to verify proper IP Addresses for our interfaces:

Resulting Output:

Each Firewall appliance has now been properly configured our each individual networks need, close consoles

8. Troubleshoot SMB Share Connectivity

This topology shows two networks (192.168.1.0/24 and 10.10.10.0/24) that are connected by an IPSec VPN

Each network site has a VyOS Firewall which acts as the network edge router and connection to the internet

Our first issue is with Linux-A in the 192.168.1.0/24 network. The user is reporting a networking error

The user was told to install a Samba client and then attach it to an SMB share on the FILESERVER host

The user states that they are not able to install a Samba client. They are reporting the following error:

We are using Alpine Linux distribution in this lab. The apk command performs the same as apt or yum would

The message transient error indicates a network problem, which is our responsibililty as the administrator

While this may initially seem a bit cryptic, we will use basic network troubleshooting to resolve the issue

Run the following commands from the GNS3 LINUX-A Console Terminal to view the IP Address + Default Gateway:

Resulting Outside:

We can see from the output above that we have the correct IP Address and Gateway configured for this host

Run the following commands from the GNS3 LINUX-A Console Terminal to ping the Gateway and the Internet:

Resulting Output:

It appears IP connectivity from LINUX-A to its default gateway and to the outside internet is working fine

Run the following command from the GNS3 LINUX-A Console Terminal to ping Google and test name resolution:

Resulting Output:

Here we have discovered that domain dame resolution is not functioning properly, take note of the output

Run the following commands from the GNS3 LINUX-A Console Terminal to view the network and DNS config files:

Resulting Output:

We can see that resolv.conf is empty, also a line in /etc/network/interfaces to set DNS is commented out

At this point, you decide to speak with the local systems administrator for the 192.168.1.0/24 network

They tell you they no longer use the firewall for DNS and have stead set up an internal DNS Server for DNS

This will allow local servers, like FILESERVER, to be resolved by name from other hosts on the network

Run the following commands from the GNS3 LINUX-A Console Terminal to set the nameserver and view changes:

Resulting Output:

The results should confirm that name resolution is now working! Next install a Samba client for the user

Run the following commands from the GNS3 LINUX-A Console Terminal to install the Samba client and verify:

Resulting Output:

Using basic network troubleshoting techniques, you took a complex problem and found a simple resolution!

9. Troubleshoot Internet Connectivity

Next, you are told that the user on LINUX-B in the 10.10.10.0/24 network cannot connect to the internet

According to the local systems administrator, they just switched all the clients to DHCP for this network

Run the following command from the GNS3 LINUX-B Console Terminal to check the IP Address and the Gateway:

Resulting Output:

This output indicates that LINUX-B could not get an IP configuration from a DHCP server and has no set IP

Run the following command from the GNS3 LINUX-B Console Terminal to retry contacting the local DHCP server:

Resulting Output:

No luck. In speaking with the local system administrator, you learn the firewall should be the DHCP Server

Right click the VyOS-FIREWALL-B appliance and select console to restore the firewall appliances terminal

Run the following commands from the VyOS-FIREWALL-B Router Console to view the DHCP Server configuration:

Resulting Output:

The output from the commands we ran above shows us that the DHCP Server was never configured on our device

Unlike with many vendor firewall appliances or pfSense firewall appliances, VyOS won't use DHCP out the box

Run the following commands from the VyOS-FIREWALL-B Router Console to enable and configure the DHCP Server:

With DHCP configured, you decide to also check out the DNS resolver service since the firewall provides DNS

Because there is no DNS server in 10.10.10.0/24, we expect the firewall to act as the DNS resolver device

Run the following commands from the VyOS-FIREWALL-B Router Console to view the DNS Resolver configuration:

Resulting Output:

The output from the commands we ran above shows us that the DNS Resolver was never configured on our device

Unlike with many vendor firewall appliances or pfSense firewall appliances, VyOS won't use DNS out the box

Run the following commands from the VyOS-FIREWALL-B Router Console to enable and configure the DNS Resolver:

A DNS Resolver acts like a DNS Server. However, unlike a DNS Server, a Resolver does not host any DNS zones

The purpose of the DNS Resolver is to make name resolution requests to a name server on behalf of clients

Run the following command from the GNS3 LINUX-B Console Terminal to retry contacting the local DHCP server:

Resulting Output:

Run the following command from the GNS3 LINUX-B Console Terminal to check the IP Address and the Gateway:

Resulting Output:

We can see that after configuring the Firewall our device has now pulled a proper network configuration

Run the following commands from the GNS3 LINUX-B Console Terminal to test internet connection and the DNS:

Resulting Output:

Success! We have restored internet connectivity to this host and ensured that name reolution is working

10. Troubleshoot SMB Share Connectivity Round II

With another network troublshooting victory under your belt, you get called by the admin for 192.168.1.0/24

The user on LINUX-A cannot connect to FILESERVER using the Samba client you just had installed for them

It seems no good deed goes unpunished. Then again, we should have thested that before declaring victory:

You know from speaking with the system administrator that the 192.168.1.5 DNS server should resolve names

This should include local hostnames like FILESERVER. So you decide to check the zone file for 192.168.1.5

In the topology window, right-click the BROWSER-A host and select Console to open a Browser on the network:

You will use the web browser to connect to the local DNS server's web configuration tool type this URL in:

Resulting Output:

Set a new admin password, then head to the Zones tab and select itlab.center to view our dns zone file:

You can see in the itlab.center.zone file that only a NS and a SOA record exist, we are missing A records

For DNS to resolve local names, there needs to be an A record for every host you want clients to resolve

Let's add an A record for FILESERVER, click Add Record, then enter the following details and click save:

 • Name: FILESERVER

 • Type: A

 • TTL: 3600

 • IPv4 Address: 192.168.1.20

 • Add reverse (PTR) record: yes

 • Create reverse zone for PTR record: yes

 • Overwrite existing records: no

 • Comments: Local Samba Server

Run the following commands from the GNS3 LINUX-A Console Terminal to test the DNS servers name resolution:

Resulting Output:

We are much closer now, but the user does not want to have to enter the entire Fully Qualified Domain Name

Who has time for that? We must tell our local DNS client on LINUX-A to assume the itlab.center domain ext

Run the following commands from the GNS3 LINUX-A Console Terminal to add a DNS search and test our ping:

Resulting Output:

Run the following commands from the GNS3 LINUX-A Console Terminal to list the available smb shares again:

Resulting Output:

The Samba server may be a little slow to respond. Be patient. Once it does, take note of the files we find

11. Troubleshoot VPN Connectivity

It's time for some well-earned cup of coffee, or so you think. The admin for 10.10.10.10 has a new issue

The user for Linux-B user can't reach the FILESERVER either. The networks should be connected by a VPN

You know that 192.168.1.0/24 and 10.10.10.0/24 are connected by the two firewalls by using an IPsec VPN

Run the following command from the GNS3 LINUX-B Console Terminal to test connectivity to the FILESERVER:

Resulting Output:

And here we are, you've got another bad address error. Will there be no end to the name resolution issues?

You could configure hosts on 10.10.10.0/24 to use the DNS server on 192.168.1.0/24 but that is not ideal

That would push a lot of unnecessary traffic over the VPN, you decide to setup name resolution on client

Run the following commands from the GNS3 LINUX-B Console Terminal to add a local DNS Cache name record:

Resulting Output:

Run the following command from the GNS3 LINUX-B Console Terminal to test connectivity to the FILESERVER:

Resulting Output:

From the output above it looks like we have won on name resolution, but we still can't reach 192.168.1.20

It's time to check the dreaded IPsec VPN tunnel. This should be configure on each of our VyOS Firewalls

Right click the VyOS-FIREWALL-A appliance and select console to restore the firewall appliances terminal

Run the following commands from the VyOS-FIREWALL-A Router Console to view the IPsec VPN configuration:

Resulting Output:

The output from the commands we ran above shows us that the IPsec VPN was never configured on our device

You look this up online and discover that IPsec comprises two tunnels: IKE Phase 1 (IKE) and Phase 2 (ESP)

You read that these phases create a Security Association between two endpoints, in this case our firewalls

We are now ready to configure the site-to-site vpn, this consisting of both IKE phase 1 and ESP phase 2

Run the following commands from BOTH of the VyOS Router Consoles to define the cyptography for both phases:

Run the following commands from the VyOS-FIREWALL-A Router Console to define the peer and VTI bridge setup:

Run the following commands from the VyOS-FIREWALL-A Router Console to set the VTI interface and routing:

Run the following commands from the VyOS-FIREWALL-B Router Console to define the peer and VTI bridge setup:

Run the following commands from the VyOS-FIREWALL-B Router Console to set the VTI interface and routing:

Run the following commands from the VyOS-FIREWALL-A Router Console to display our VPN tunnel and test it:

Resulting Output:

The output from the above command shows us that the tunnel was created and we can send packets through it

Run the following command from the GNS3 LINUX-B Console Terminal to test connectivity to the FILESERVER:

Resulting Output:

Congratulations! You used simple network troubleshooting techniques to fix realistic networking issues

You've gained hands on experience with common network troubleshooting tools like ping, ip a, and netstat

You've also gains invaluable experience working with services like VyOS, Technitium, and Samba shares