Now that you're well‑armed against TCP issues that arise,
it's time to look at the equally important issues that arise within UDP.
There are two main issues that arise within UDP.
The first issue that you'll encounter when dealing with UDP
is incorrectly configured firewall issues.
The second issue you'll encounter is incorrectly configured services.
Just as with TCP,
UDP operations can be drastically hindered by a firewall
that's been incorrectly configured.
Let's take a look at some of the common firewall issues associated with UDP.
While UDP firewall issues can manifest themselves in
the same way as TCP issues do,
UDP also has special caveats due to its implementation.
The most common issue system engineers will encounter is DHCP‑related issues.
DHCP issues arise due to the implementation of their ports.
System engineers will unknowingly block port 67 or 68,
which we know from our prior modules is essential for the
correct operation of DHCP as blocking either one of these ports
will stop DHCP from leasing addresses.
There is another issue associated with DHCP and firewalls though.
Some vendors implement DHCP through raw sockets,
which essentially means it sits above the network stack,
which in turn means that DHCP cannot be blocked even if you want it to.
For example, if I were to block DHCP on my edge router,
the traffic would still pass through since the edge
router is running a Linux OS Debian.
There is very limited reasons that you would actually want to
restrict DHCP while running it on the same device,
but I just want to make you aware of this odd situation.
It should also be noted that Windows does not have this
issue as blocking either port will instantly killed DHCP
traffic in a Windows network.
In this diagram,
we have a PC with a MAC address of A0:AF:BD:7B:42:A1
broadcasting for a DHCP address, utilizing the hard‑coded DHCP source port of 68.
The DHCP server of B4:FB:E4:2C:6D:C9 receives the request
and attempts to answer the request,
but is unable to due to port 67 being denied on the firewall due to a untested,
newly implemented firewall rule.
At this point,
the requesting PC will continue to broadcast unsuccessfully
until it decides to utilize an APIPA address.
Let's drop to a video where we can troubleshoot a DHCP
lease issue from a Windows Server.
In this video, Jason, the network administrator of Wired Brain Coffee,
has recently implemented a new Windows Server 2016 with DHCP.
But for some reason, his computer is unable to retrieve an address.
If we examine his traffic through Wireshark,
we can see his computer is broadcasting for an address without an answer.
Let's examine our Windows Server firewall rules to see if anything is amiss.
Looking into the inbound rules and sorting by the action,
everything appears to be allowed as nothing is blocked.
Let's look into our outbound rules to see if anything looks amiss there.
I think we may have found it.
It looks like someone has blocked the destination traffic to UDP port 68.
Let's disable this role and watch Wireshark to see if it's made a difference.
Wow, that was a quick response.
It appears the server of 192.168.56.4 has sent a lease to the
requesting PC, and the address given was 192.168.56.202. As previously
stated, when troubleshooting DHCP issues, make sure you investigate as
to whether or not the vendor is implementing DHCP over raw sockets
because until you know for sure,
you may be spending a lot of unnecessary time looking in the wrong location.
The second most common issue pertaining to UDP is DNS. DNS
operates over port 53, but DNS is a dual protocol,
meaning it operates over both UDP and TCP.
Trouble arises within DNS for engineers that block TCP,
thinking that they only need UDP.
That being said,
DNS, more often than not, uses UDP for its traffic as
everything 512 bytes and under runs through UDP, while
anything 512 bytes over runs over TCP.
The issue arises for engineers when troubleshooting this issue,
thinking it's a problem with UDP.
But in actuality, it's a TCP issue.
Unfortunately,
the engineer will have torn most of his hair out by the time
he discovers what the actual issue is. Let's look at a
diagram to help cement this idea.
In this scenario,
the computer of 192.168.1.1 attempts to browse the web site of www.train.org.
The DNS server of 192.168.1.2 reaches out to its DNS forwarder over port 53 and
retrieves the public response for www.train.org,
which resolves to 216.69.207.102. The computer is now
successfully able to access the requested site.
Next,
the server of 192.168. 1.2 attempts to perform a zone
transfer to the DNS server of 172.25.1.1.
When the server of 192.168.1.2 attempts a connection,
it's immediately dropped by the router as TCP is not on
the allowed protocol list over port 53.
That's why this turns into a UDP issue. Even though the root cause is a TCP
issue, engineers are convinced something is wrong with UDP. But in reality, it's as simple as correcting a firewall rule.