Can't get split tunnel to work in WireGuard peer in OpnSense 25.1.11

[Monviech (Cedrik)]

Maybe it depends on factors out of our control if it works or not. On my iphone the split tunnel works. xD

Mysteries.

[2HgRyz13]

It works on my iPhone, too.

I can access the file server from iOS 18.5 with its WireGuard client using the same config file over 5G cellular (wifi off). Of all the crazy things. So just isn't working on macOS (yet).

Someone on Stack Overflow has good advice I had already tried (A,B,D not C but tried C and it didn't work). Here it is for future reference:

https://serverfault.com/questions/1189523/wireguard-vpn-split-tunnels-config-fails-from-macs-but-works-from-windows-11

Suggested Fixes

A. Add Manual Routes on macOS After WireGuard connects, manually add a route to ensure 10.1.10.0/24 goes over the tunnel:

bash Copy Edit sudo route -n add -net 10.1.10.0/24 -interface utun4 Or persist it with a post-up script (e.g., if using CLI WireGuard).

You can confirm the route is missing or misrouted by checking netstat -rn or route get 10.1.10.99


B. Use AllowedIPs = 10.1.10.0/24, 10.1.10.99/32 Some versions of macOS need very explicit IPs to enforce route handling. Add the file server's IP directly in addition to the subnet:

nginx Copy Edit AllowedIPs = 10.1.10.0/24, 10.1.10.99/32


C. Use a DNS Name for File Server (Workaround) Sometimes SMB/Finder behaves differently with DNS names than raw IPs. Try accessing:

smb://fileserver.domain.local instead of smb://10.1.10.99

This sometimes forces different resolution paths.


D. Use Full Tunnel Temporarily but Block Internet via Firewall Rule If split-tunnel is the issue, temporarily use 0.0.0.0/0 and add an outbound block rule on OpnSense for the tunnel subnet to prevent internet access.

This is a compromise until macOS routing is sorted.

[2HgRyz13]

FYI -- I filed a bug report with Apple and suggested they have their macOS networking team consult their iOS networking team.

For amusement and contemplation, here are 4 routing tables (first 3 with same Wireguard config file that includes Allowed IP 10.1.10.0/24). The file server is always 10.1.10.99.

(1) WORKS: iPhone iOS 18.5 (wifi off) successful Wireguard split tunnels and file server access

Network Tools iOS app by Hurricane Electric (HE network tools):
routing table / Routes by Interface

Wireguard: utun7
Destination        Gateway      Flags
default            link#49      UCSI
10.25.25.4         10.15.25.4   UH
10.1.10            link#49      UCS
224.0.0/4          link#49      UmCSI
255.255.255.255/32 link#49      UCSI

(2) FAILS: macOS M4 Apple Silicon Sequoia 15.5, M4 Apple Silicon Tahoe Public Beta 1, Intel Sonoma 14.7.6 (no file server access; no packet flow in WireSHARK until pinging file server, which works)

netstat -rn -f inet

Wireguard: utun5
(excluding other interfaces)
Destination        Gateway      Flags
default            link#20      UCSIg (small "g" only difference with iOS's routing table)               
10.25.25.4         10.25.25.4   UH                     
10.1.10            link#20      UCS                       
224.0.0/4          link#20      UmCSI               
255.255.255.255/32 link#20      UCSI               

(3) WORKS: Windows 11 PC laptop, Windows 11 in Parallels VM in macOS Tahoe Public Beta 1 (all accessed the file server)

C:> route print

Wireguard: 10.25.25.4
(excluding other interfaces)
Active Routes:
Destination     Netmask            Interface
10.25.25.4      255.255.255.255    10.25.25.4
10.1.10.0       255.255.255.0      10.25.25.4 
10.1.10.255     255.255.255.255    10.25.25.4

Windows Wireguard uses broadcast instead of multicast. Broadcast (last octet .255 in 10.1.10.255) spews traffic to all devices in a local segment. Multicast (224.0.0/4) sends traffic to interested devices only.
   

(4) WORKS without split tunnels (Allowed IPs: 0.0.0.0/0) on all platforms tested (all accessed the file server)

Routing table from 3 macOS versions (Sonoma, Sequoia, Tahoe Public Beta 4):

Wireguard: utun5
(excluding other interfaces)
Destination        Gateway      Flags       
default            link#20      UCSg  (missing capital "I" in split tunnel routes above)       
hiding public IP   link#20      UHWIig         
224.0.0/4          link#20      UmCS  (missing capital "I" in split tunnel routes above)   
255.255.255.255/32 link#20      UCS   (missing capital "I" in split tunnel routes above)