How to Access Your Local LAN While Connected to FortiClient VPN

**Published by TangleTecs · Managed IT & Networking**

You connect to your company VPN using FortiClient and suddenly your local network goes dark. Your NAS drive disappears. Your printer stops working. You cannot reach your router admin page. Your local file shares are gone.

This is one of the most common frustrations IT teams and remote workers run into and it has a specific cause: **full-tunnel VPN routing**.

By default, FortiClient routes all your internet traffic through the VPN tunnel. This means your machine stops talking directly to local devices and instead sends everything, including local network requests, through the corporate network first. The result: your LAN becomes unreachable.

This guide explains exactly why this happens and three ways to fix it.

Why This Happens: Full Tunnel vs Split Tunnel

When FortiClient connects, it pushes a default route (`0.0.0.0/0`) through the VPN tunnel. This is called **full tunneling**: every packet, regardless of destination, gets sent over the VPN.

**Split tunneling** is the alternative. Instead of routing everything through the VPN, only traffic destined for the corporate network goes through the tunnel. Everything else, including local LAN traffic, takes the normal direct path.

Full tunnel:  Your PC -> VPN -> Corporate Network -> Internet/LAN (broken)
Split tunnel: Your PC -> VPN -> Corporate Network (work traffic only)
              Your PC -> Router -> LAN devices (local traffic works)

There are two ways to solve this: configure split tunneling on the FortiGate (the right long-term fix), or apply a local workaround on your machine (useful when you do not control the VPN server).

Method 1: Enable Split Tunneling on the FortiGate (Recommended)

If you manage the FortiGate firewall, this is the cleanest solution. You configure the VPN tunnel to only route traffic destined for your corporate subnets, leaving everything else on the local path.

Go to **VPN -> SSL-VPN Portals** and select your portal

Under **Tunnel Mode**, find the **Split Tunneling** option

Set it to **Enabled Based on Policy Destination**

Define your routing address (your corporate subnet, e.g. `10.0.0.0/8` or `192.168.10.0/24`)

Once applied, FortiClient will only tunnel traffic destined for those defined subnets. All other traffic, including your local LAN, routes normally.

Method 2: Add a Static Route Manually (Windows)

If you do not have access to the FortiGate, or you need a quick fix while waiting for your IT team to configure split tunneling, you can add a static route manually on your Windows machine after the VPN connects.

Before the VPN connects (or disconnect temporarily), open Command Prompt and run:

Once the VPN is connected, open Command Prompt as Administrator and run:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1

To make the route persist across reboots:

route add -p 192.168.1.0 mask 255.255.255.0 192.168.1.1

Method 3: Add a Static Route on macOS / Linux

netstat -rn | grep default
sudo route -n add -net 192.168.1.0/24 192.168.1.1

ip route show default
sudo ip route add 192.168.1.0/24 via 192.168.1.1

The cleanest long-term solution is to configure split tunneling on the FortiGate itself. If you manage VPN infrastructure and want help designing a secure split-tunnel policy, contact TangleTecs.

Use our free [Port Checker](https://www.tangletecs.com/tools/networking#port-checker) and [Ping tool](https://www.tangletecs.com/tools/networking#ping) to diagnose connectivity issues on your local network or through the VPN.

Secure RDP: Best Practices for Remote Access

RDP is one of the most targeted remote access protocols because exposed endpoints are easy to scan and brute-force. A secure deployment requires layered controls, not one single setting.

1) Never expose RDP directly to the internet

Put RDP behind VPN, ZTNA, or a remote access gateway

Restrict inbound access by source IP where possible

Remove all unnecessary public NAT rules for port 3389

Use conditional access and device posture checks

Disable local admin sign-in for normal user accounts

Keep OS and endpoint software fully patched

Disable clipboard/drive redirection where not needed

Apply account lockout thresholds and idle timeouts

Alert on unusual geolocation or sign-in times

Forward logs to centralized monitoring for review

Run tabletop drills for account compromise, ransomware containment, and service restoration so your team can act quickly under pressure.

Top 5 Best Practices for Optimizing Firewall Deployment Architecture

A robust firewall architecture balances security, performance, and maintainability.

Define clear trust boundaries (users, servers, DMZ, management, third-party) and allow only documented flows between zones.

Use object groups, naming conventions, and reusable templates so rules are readable, auditable, and easy to maintain at scale.

Start with deny-all, then allow only required apps, ports, and destinations. Time-bound any temporary exceptions.

Test policy updates in staging, peer review all high-impact changes, and maintain rollback plans for each deployment window.

Audit for shadowed, stale, and unused rules, then recertify periodically with system owners to reduce risk and improve performance.

Top 5 Best Practices for Optimizing Your Firewall Deployment Architecture

VLANs: Why They Matter for Your Organization

VLANs are one of the simplest and most effective ways to improve both network security and performance.

Reduce broadcast traffic and unnecessary network noise

Separate sensitive systems from general user traffic

Limit lateral movement during security incidents

Create separate VLANs for users, servers, voice, printers, IoT, and management traffic.

VLANs alone are not security. Enforce ACLs and firewall rules between VLANs so only required communication is allowed.

Use a predictable IP schema and document gateways, DHCP scopes, and trunk ports for faster troubleshooting.

As your environment changes, review VLAN design quarterly to remove legacy segments and align with current business workflows.

Monitoring only helps when alerts are actionable. The goal is not more alerts, but better signal quality.

Saturation (CPU, memory, interface utilization)

Map each signal to clear thresholds and owner teams.

Define severity levels, on-call ownership, and escalation timelines so incidents are routed quickly and consistently.

Combine synthetic and real traffic visibility

Use synthetic checks for critical paths and flow telemetry for real-world behavior. Together they catch both hard failures and performance degradation.

After every major incident, document root cause, corrective actions, and monitoring updates so the same failure is less likely to repeat.

Latest Insights

How to Access Your Local LAN While Connected to FortiClient VPN

Secure RDP: Best Practices for Remote Access

Top 5 Best Practices for Optimizing Your Firewall Deployment Architecture

VLANs: Why They Matter for Your Organization

Your Network Monitoring Playbook