Thereās a common troubleshooting ritual in offices everywhere:
1ļøā£ User encounters a problem with an appāitās slow, failing to load, or behaving strangely.
2ļøā£ User tethers their phone to bypass the office network.
3ļøā£ App suddenly works.
4ļøā£ User declares: āThe LAN is broken!ā
At first glance, this seems logicalāif switching to a mobile hotspot fixes the issue, then the LAN must be the problem, right?
šØ Not so fast. šØ
The hotspot test is not definitive proof of a LAN issue. In fact, many app issues have nothing to do with the LAN at all. They stem from MTU mismatches, upstream firewalls, geoblocking, DNS behavior, or CDN optimizationsāthings that affect LANs differently than mobile networks.
Blaming the LAN without a deeper investigation often leads to wasted troubleshooting time, incorrect conclusions, and the false assumption that mobile networks are inherently more reliable than wired networks.
Letās explore why the hotspot test can be misleadingāand how to correctly troubleshoot app issues.
Why Do Apps Sometimes Work on a Hotspot but Not on a LAN?
There are several technical differences between mobile networks and enterprise LANs that impact application behavior. Just because an app works on a mobile hotspot doesnāt mean the LAN is at fault.
1ļøā£ MTU Issues | Mobile Networks Are More Forgiving
One of the biggest hidden culprits is MTU (Maximum Transmission Unit) size.
š„ LANs typically use a 1500-byte MTU.
š± Mobile networks often have a smaller MTU (around 1350ā1400 bytes).
This means that some applications fail on the LAN because packets are too large and fragmentation is not properly handledābut they work fine on mobile because the smaller MTU avoids the issue altogether.
š“ Common problem: Firewalls or upstream routers blocking ICMP āFragmentation Neededā messages, preventing correct MTU negotiation.
ā
Why the hotspot test works: Mobile networks use a lower MTU by default, sidestepping the issue.
š Proper fix: Investigate MTU issues on the WAN path and ensure ICMP is not being blocked upstream.
2ļøā£ Geoblocking & IP-Based Restrictions
Some applications block entire IP ranges based on geography or network type.
š¢ LAN networks (especially corporate or ISP-provided ones) often have static, registered IP blocks.
š” Mobile networks use dynamic IP pools that frequently change and appear āgeneric.ā
If a service country-blocks or ISP-blocks certain IP ranges, your LAN might be affected while mobile hotspots slip through unnoticed.
š“ Common problem: Cloud services or streaming platforms enforcing IP-based access controls.
ā
Why the hotspot test works: Mobile IPs arenāt blocked, but your LANās ISP might be.
š Proper fix: Use a VPN or test with a different LAN-based IP before blaming the network itself. A useful service to test with is Cloudflareās WARP.
3ļøā£ LAN vs. Mobile DNS Behavior
Many applications rely on Content Delivery Networks (CDNs) to serve content. These CDNs use ECS (EDNS Client Subnet) to determine the best server for your location.
However, mobile networks often override DNS settings, leading to different resolution paths:
š LAN: Uses local ISP or corporate DNS resolvers, which may return a suboptimal CDN location.
š¶ Mobile: Often resolves to a generic DNS resolver that directs traffic differently.
š“ Common problem: Users on LANs get routed to CDN endpoints that are congested or far away, while mobile users hit closer, better-performing servers.
ā
Why the hotspot test works: Different DNS resolution on mobile leads to a better-performing path.
š Proper fix: Check DNS resolution paths using dig, nslookup, or traceroute to compare LAN and mobile results.
Why the Hotspot Test is a Bad Troubleshooting Method
While itās useful as an initial step, the hotspot test is not a definitive diagnosis.
ā It oversimplifies network complexity.
Modern networking is a multi-layered system involving routing, security, MTU handling, geolocation, and application behavior. Jumping to conclusions based on a single test ignores these variables.
ā It leads to misdiagnosis.
Blaming the LAN when the real issue is MTU, geoblocking, DNS, or app behavior sends troubleshooting teams on wild goose chases.
ā It creates the illusion that LANs are unreliable.
If we followed the logic that āif it works on a hotspot, the LAN is the problem,ā then why have LANs at all? Everyone should just tether off their phones 24/7!
Clearly, thatās not a practical solution. The reality is that LANs provide stability, reliability, and security that mobile hotspots cannot match.
How to Troubleshoot Properly
Instead of blindly blaming the LAN, use a structured troubleshooting approach:
Step 1: Compare Connectivity Paths
Run traceroute from both the LAN and the mobile hotspot to see if the paths differ.
š If the hotspot takes a different route (e.g., different CDN servers), the issue may not be the LAN.
Step 2: Check for MTU Issues
Run:
ping -f -l 1472 fusionsdwan.co.za
ā
If packets donāt fragment, MTU is fine.
ā If they fragment, your WAN might be dropping ICMP messages, causing application issues.
Step 3: Investigate DNS Resolution Differences
Compare:
nslookup fusionsdwan.co.za
Run this from LAN vs. Mobile Hotspot to check if they resolve to different IPs.
If mobile resolves to a better-performing CDN server, then the issue is DNS-based, not LAN-based.
Step 4: Test with a VPN
Connect the LAN through a VPN (e.g. Cloudflareās WARP) and retest the app.
š If the app starts working, the issue is likely geoblocking or ISP-based restrictions.
Step 5: Monitor Firewall Logs
Check if outgoing traffic from the LAN is being blocked by corporate or ISP firewalls.
š If certain ports or protocols are blocked, the issue is upstream, not the LAN itself.
Wrapping UP | Stop Jumping to Conclusions
Yes, sometimes the LAN is the problem. But the hotspot test alone is not proof.
Blindly assuming that āif it works on a hotspot, the LAN is brokenā leads to:
šØ Wasted troubleshooting time
šØ Frustrated IT teams
šØ A false perception that LANs are unreliable
Next time you see someone running a hotspot test and blaming the LAN, remind them:
š¹ Mobile networks handle MTU differently.
š¹ Apps may block LAN IPs but allow mobile ones.
š¹ CDNs and DNS behave differently on LAN vs. mobile.
š¹ Proper troubleshooting beats guesswork.
LANs arenāt dead. We just need smarter troubleshootingānot hotspot-induced paranoia. š
How Fusionās SD-WAN Solves the Last-Mile MTU Problem
One of the trickiest issues in troubleshooting application failures is the MTU mismatch problemāespecially in last-mile networks where ISPs have varying configurations. Many traditional networks leave MTU settings static, meaning problems go unnoticed until something breaks.
Fusionās SD-WAN takes a proactive approach to this by running an hourly MTU test between the data centre aggregation point and the SD-WAN edge.
Why Does This Matter?
While MTU issues across the greater internet (e.g., firewalls blocking ICMP fragmentation messages) still require intervention, last-mile MTU mismatches are a frequent cause of:
š¹ Inconsistent application performance
š¹ Unexplained slowdowns
š¹ Packet fragmentation or silent drops
Most ISPs donāt actively monitor or adjust for MTU mismatches in the last mile, leaving businesses to deal with random performance issues.
How Fusionās SD-WAN Fixes This
Fusionās SD-WAN automatically:
ā
Runs an hourly MTU test between the data centre and the SD-WAN edge
ā
Adjusts the MTU dynamically based on real-time results
ā
Logs MTU changes for visibility and proactive troubleshooting
By aligning the last-mile MTU with what the ISP actually supports, Fusion SD-WAN ensures that:
š¹ Packet fragmentation is minimised
š¹ ICMP filtering doesnāt cause unpredictable failures
š¹ The network automatically adapts to ISP changes
This means fewer false alarms when troubleshooting app issuesāeliminating last-mile MTU mismatches as a variable before jumping to conclusions.
So, when the next āhotspot testā makes someone blame the LAN, Fusionās SD-WAN users can confidently rule out last-mile MTU mismatchesāand focus on whatās really wrong. š
