v25.1.11 in DEC 850.
Wireguard macOS peer client app.
I have two working WireGuard VPN instances running ok, each with its own interface assignment and no peers with split tunnels:
• one for LAN only over vpn
(its peer can access the file server on the LAN ok but can't browse the internet because of a related LAN-only firewall rule)
• one for internet only over vpn
(its peers can browse the web and whatismyipaddress shows their public IP address is OpnSense's instead of their ISP's and they can't access the LAN)
SPLIT TUNNEL
Today, I spent hours trying to create a split tunnel in several test peers so they can connect to the LAN but browse the internet over their own ISP instead of the vpn's.
The documentation seems simple, but I'm missing something.
For new peer tests with the LAN_only instance, I replaced Allowed IPs 0.0.0.0/0, :::/0
with the LAN network 10.1.10.0/24
Though the peer then browsed the internet over its ISP instead of the vpn, it couldn't access the LAN's file server anymore (10.1.10.99).
Huh???
Yet I can ping it -- 10.1.10.99.
But macOS won't connect to smb://10.1.10.99 as does fine with the default Allowed IPs in the peer.
By design I can't reach, including ping, other nodes on 10.1.10.0.
Then I changed Allowed IPs to 10.1.10.0/24, 10.25.25.0/24 (the latter is the vpn peer range) but the same thing happened.
How did specifying the LAN net(s) break the peer's access to the same LAN?
When I created a test peer with the default Allowed IPs 0.0.0.0/0, :::/0, the peer could again connect to the LAN's file server (smb://10.1.10.99) but by design couldn't browse anything on the internet because of its related LAN-only firewall rule.
I feel like it's gaslighting me. I'm sleep deprived and probably missed something obvious.
Can anyone tell me if split tunnels in WireGuard VPN peers works properly in the Business edition?
If so, what edition(s)?
I'll switch to Business if it works there.
Split Tunnel in Wireguard is only decided by the allowed IPs in the client, which is installing routes to force traffic into the tunnel.
This means it depends on MacOS, Windows, Linux etc if the routing works correctly.
Im also using MacOS but I use OpenVPN there because it works reliably with split tunnel and split dns. I use Viscosity as client software.
I also have wireguard on it but I use it as full tunnel.
Reading the first post something is definitely wrong. Selective routing through WireGuard while maintaining the default Internet connection does work. I have dozens of tunnels and networks like that.
No time to day to aid in detailled debugging. "Patchday" for our entire data centre - sorry.
I found this bug report for OpnSense 24.7.6 on October 11th, 2024. Maybe there's another bug now.
Also, if you have working Wireguard split tunnels, did you create the Peers with the Peer Generator in 25.1.11 or were they already created and working before 25.1.11?
https://github.com/opnsense/core/issues/7965
Steps to reproduce the behavior:
Upgrade to OPNsense 24.7.6
WireGuard split tunnel is no longer functional.
Expected behavior
Wireguard split tunnels should connect without issue and not show a "peer disconnected" error.
Describe alternatives you considered
Restore a snapshot / backup to OPNsense 24.7.4_1. Solves issue immediately.
Quote from: 2HgRyz13 on July 22, 2025, 10:36:19 AMAlso, if you have working Wireguard split tunnels, did you create the Peers with the Peer Generator in 25.1.11 or were they already created and working before 25.1.11?
Created before 25.1. But then I never use the peer generator. It's just 5 or so lines of config for a peer, copy public keys, done. Trivial.
Mac OS, IOS, other OPNsense systems.
I tried it manually, too.
The peer generator is also trivial and makes it easy to scan a QR code. No typing anything except the name and Allowed IPs and just click to add a pre-shared key.
I appreciate your time on this. I doubt you'll have time to try the following, but if you do, could you try creating a new peer with a split tunnel in 25.1.11? With and without the Peer Generator, since both are trivial?
I've read a few bug reports about OpnSense breaking WireGuard split tunnel. I already spent about 20+ hours on this and would hate to spend more if the problem is a bug and therefore outside of my control.
I'm also using macOS Wireguard client 10.0.16 (27). It works fine with LAN-only connections.
With split-tunnel connections, its log files show no errors. Web browsing works through the client ISP as expected, just no LAN access except for ping.
However, when the non-split tunnel client connects, the client status window shows the Data Recieved & Sent fields right away with data, even before I mount the file server, and the value increase steadily as expected.
But when connecting with the split-tunnel peer, the Data Received & Sent fields are missing until I ping the file server. Then the fields are present and show increasing values until I stop pinging, then never progress. That makes sense given the problem.
It seems like the split-tunnel peer I create isn't passing enough protocols and/or ports, maybe just icmp though I haven't tried others except for the attempt to mount with smb://.
The firewall rule that allows LAN access works fine with non-split-tunnel peers. The only thing different with a split-tunnel peer is the Allowed IPs field, which doesn't reference protocols or ports.
I see a notice that 25.1.12 is released but my OpnSense doesn't find it yet.
Thanks again for your time.
Try setting mtu 1280 at the peer.
Quote from: Monviech (Cedrik) on July 22, 2025, 08:12:30 AMSplit Tunnel in Wireguard is only decided by the allowed IPs in the client, which is installing routes to force traffic into the tunnel.
This means it depends on MacOS, Windows, Linux etc if the routing works correctly.
Im also using MacOS but I use OpenVPN there because it works reliably with split tunnel and split dns. I use Viscosity as client software.
I also have wireguard on it but I use it as full tunnel.
Quote from: Monviech (Cedrik) on July 22, 2025, 08:12:30 AMSplit Tunnel in Wireguard is only decided by the allowed IPs in the client, which is installing routes to force traffic into the tunnel.
This means it depends on MacOS, Windows, Linux etc if the routing works correctly.
Im also using MacOS but I use OpenVPN there because it works reliably with split tunnel and split dns. I use Viscosity as client software.
I also have wireguard on it but I use it as full tunnel.
Thanks, I'll consider that. I used OpenVPN years ago. I'm switching one site from a SonicWall using SSLVPN, which is now considered hopelessly insecure (Norway banned SSLVPN and US & UK don't recommend it anymore). Wireguard is fast and more secure. I tried IPSec VPN on the SonicWall, but even though the Windows client worked fine, there's no good macOS IPSec client except for a general purpose VPN client at $108 USD / year per user. I guess OpenVPN is a form of SSLVPN, but maybe OpenVPN is safer.
I'm migrating a site from SonicWall in order to increase their VPN security and speed. I had to emergency patch SSLVPN in the TZ SonicWall a few times in the last 12 months. Anyway Wireguard security is supposed to be better and its faster and some consider it less buggy (cough cough) because its code base is much smaller.
SonicWall offers Wireguard in its dedicated VPN devices but not in is TZ appliances.
I may have to delay the deployment until I get the split tunnels worked out, either fixing my own config mistake or downgrading OpnSense or switching to the Business edition or try another macOS Wireguard client if available.
Quote from: Patrick M. Hausen on July 22, 2025, 12:00:44 PMTry setting mtu 1280 at the peer.
Thanks for the idea. I just tried it but it didn't help.
Here we go...
[Interface]
PrivateKey = redactedxxxxxxx
Address = 10.25.25.4/32
[Peer]
PublicKey = redactedxxxxxxx
PresharedKey = redactedxxxxxxx
AllowedIPs = 10.1.10.0/24
Endpoint = redactedxxxxxxx.redactedxxxxxxx.com:51222
The file server is on the LAN at 10.1.10.99.
Non-split tunnel clients successfully access the file server through a firewall rule that only allows access to 10.1.10.99 on the LAN, but the access only works with a client using Allowed IPs: 0.0.0.0/0, ::/0 (not split tunneled)
I also tried MTU = 1280 (didn't help)
And I tried Allowed IPs:
10.1.10.99/32
then 10.1.10.0/24, 10.1.10.99/32
then 10.1.10.0/24, 10.1.10.99/32, 10.25.25.0/24
None helped. Split Tunnels sure look easy to set up, with just the Allowed IP = the LAN net x.x.x.0/24.
DNS shouldn't matter since we access the fileserver by IP address, not by name, but I tried the following anyway in the config (none helped)
DNS = 1.1.1.1
then DNS = 10.1.10.1
then DNS = 10.1.10.1, 10.25.25.1
then DNS = 10.1.10.1, 10.25.25.1, 1.1.1.1
Disabling Unbound DNS didn't help (as expected)
Disabling Outbound NAT & Normalization didn't help (as expected)
I suspect a bug in...
• OpnSense 25.1.11
• or my macOS WireGuard client 1.0.16 (27)
• or macOS Sequoia 15.5
What macOS Wireguard client do you use successfully with split tunnels?
I just read a notice that 25.1.12 is released, but my DEC 850 doesn't find it yet. Maybe in hours.
What's the AllowedIPs setting for the peer on the OPNsense side?
Quote from: Patrick M. Hausen on July 22, 2025, 01:09:20 PMWhat's the AllowedIPs setting for the peer on the OPNsense side?
Not sure what you mean.
I thought the Allowed IP setting is only on the client side, though I used the OpnSense firewall's built-in Wireguard Peer Generator to create the peer with Allowed IP= 10.1.10.0/24. Then I continued trying Allowed IP values with manual changes to the config file on the client Mac.
OpnSense Wireguard Instances don't have an Allowed IP setting, just the tunnel address setting, e.g., 10.25.25.1/24.
The file server is at 10.1.10.99, which is reachable through non-split-tunnel connections (Allowed IPs: 0.0.0.0/0, ::/0).
Dang, I just read this in a Brave AI search result about Wireguard clients for MacOS.
There are several WireGuard clients available for macOS, including the official WireGuard client and third-party alternatives. The official WireGuard client is available on the Mac App Store and provides basic functionality for managing and using WireGuard tunnels. However, it lacks advanced features such as split tunneling and more access to configuration options.
But it doesn't show a source for that, just for sentences preceding it.
Still, this would explain it.
I'm going to try at least one other macOS Wireguard client.
Until I do, I don't recommend trying to help me with this until I report back, except please tell me with macOS Wireguard client you like.
Apart from https://github.com/opnsense/core/issues/8974 when using default routes from wireguard (or other VPNs) consider using 0.0.0.0/1,128.0.0.0/1 as a default policy to avoid clobbering your system's default route 0.0.0.0/0.
Cheers,
Franco
Quote from: franco on July 22, 2025, 01:28:53 PMApart from https://github.com/opnsense/core/issues/8974 when using default routes from wireguard (or other VPNs) consider using 0.0.0.0/1,128.0.0.0/1 as a default policy to avoid clobbering your system's default route 0.0.0.0/0.
Cheers,
Franco
I don't plan on using 0.0.0.0/0 except for testing. My goal is to use a split tunnel 10.1.10.0/24
Quote from: 2HgRyz13 on July 22, 2025, 01:28:04 PMThere are several WireGuard clients available for macOS, including the official WireGuard client and third-party alternatives. The official WireGuard client is available on the Mac App Store and provides basic functionality for managing and using WireGuard tunnels. However, it lacks advanced features such as split tunneling and more access to configuration options.
That's plain wrong. The official Mac client takes a text based configuration with all options you can place in that text field.
My client with split tunnel looks like this:
[Interface]
PrivateKey = ****
Address = 192.168.255.2/32, 2003:a:d59:38ff::2/128
DNS = 192.168.255.1, ettlingen.hausen.com, hausen.com
MTU = 1280
[Peer]
PublicKey = ****
PresharedKey = ****
AllowedIPs = 192.168.0.0/16, 2003:a:d59:3800::/56, 2003:a:d7f:d938::/64
Endpoint = ****:51820
PersistentKeepalive = 25
On the OPNsense side this is the instance - you can ignore IPv6 if you do not use it:
(https://forum.opnsense.org/index.php?action=dlattach;attach=46331;image)
And this is the corresponding peer - it has the peer's interface address in AllowedIPs, necessarily so:
(https://forum.opnsense.org/index.php?action=dlattach;attach=46333;image)
HTH,
Patrick
P.S. DNS search domains does not work, currently, but that is the only limitation of the Mac client I am aware of.
Quote from: 2HgRyz13 on July 22, 2025, 01:28:04 PMDang, I just read this in a Brave AI search result about Wireguard clients for MacOS.
There are several WireGuard clients available for macOS, including the official WireGuard client and third-party alternatives. The official WireGuard client is available on the Mac App Store and provides basic functionality for managing and using WireGuard tunnels. However, it lacks advanced features such as split tunneling and more access to configuration options.
But it doesn't show a source for that, just for sentences preceding it.
Still, this would explain it.
I'm going to try at least one other macOS Wireguard client.
Until I do, I don't recommend trying to help me with this until I report back, except please tell me with macOS Wireguard client you like.
I just tried Passepartout app from the app store. Highly rated. Same problem, though.
Wireguard 1.0.16 (27) - experiences the issue
Passepartout 3.5.4 (3880) - experiences the issue
Because both experience issues, I think the problem is with OpnSense 25.1.11, macOS 15.5 or me.
I also doubt Brave AI's comment that Wireguard's own macOS app doesn't handle split tunnels. It has the Allowed IPs field and it's a basic feature. Unless someone knows otherwise.
Quote from: Patrick M. Hausen on July 22, 2025, 01:54:55 PMQuote from: 2HgRyz13 on July 22, 2025, 01:28:04 PMThere are several WireGuard clients available for macOS, including the official WireGuard client and third-party alternatives. The official WireGuard client is available on the Mac App Store and provides basic functionality for managing and using WireGuard tunnels. However, it lacks advanced features such as split tunneling and more access to configuration options.
That's plain wrong. The official Mac client takes a text based configuration with all options you can place in that text field.
My client with split tunnel looks like this:
[Interface]
PrivateKey = ****
Address = 192.168.255.2/32, 2003:a:d59:38ff::2/128
DNS = 192.168.255.1, ettlingen.hausen.com, hausen.com
MTU = 1280
[Peer]
PublicKey = ****
PresharedKey = ****
AllowedIPs = 192.168.0.0/16, 2003:a:d59:3800::/56, 2003:a:d7f:d938::/64
Endpoint = ****:51820
PersistentKeepalive = 25
On the OPNsense side this is the instance - you can ignore IPv6 if you do not use it:
(https://forum.opnsense.org/index.php?action=dlattach;attach=46331;image)
And this is the corresponding peer - it has the peer's interface address in AllowedIPs, necessarily so:
(https://forum.opnsense.org/index.php?action=dlattach;attach=46333;image)
HTH,
Patrick
I'm confused.
Your config files shows
AllowedIPs = 192.168.0.0/16,...
Yet your screenshots of the Peer client don't that, just 192.168.255.2/32 (...) which is the first ip address of the IP address the instance gives out from its tunnel address def of 192.168.255.1/24.
Your screenshot examples are radically different from all other documentation I've found. But what the heck. I'll try it.
On the peer (Mac) I have AllowedIPs = 192.168.0.0/16 - which means that traffic to this entire network goes into the tunnel from the Mac to the OPNsense.
On the OPNsense side I have AllowedIPs = 192.168.255.2/32 which means that the OPNsense sends traffic to this single address into the tunnel.
Really in WireGuard there are no clients and servers, just peers. AllowedIPs tells WireGuard what is supposed to be at the other side of the tunnel.
That's why you put 0.0.0.0/0 on your "client" into AllowedIPs when you want to tunnel everything, and only select networks when you want split tunnel. I put "client" into quotation marks because it's really just an administrative distinction - the always on system waiting for incoming connections (OPNsense) vs. the road warrior initiating a connection (Mac). For WireGuard there is no difference.
Repeating myself: AllowedIPs is what is at the other end.
Ok, thanks.
I see what you mean now.
What confused me, among other things, is that the Peer Generator created both the edit-view peer you showed in your OpnSense plus it created the peer settings for the client (for me via the QR code).
So the client's config is what I've been working with, its Allowed IPs: setting, which in my case in my LAN net expressed as 10.1.10.0/24 (in your client config its 192.168.0.0/16).
When I went into the edit view of the instance, I see the equivalent of what you showed on yours, a tunnel address of 10.25.25.1/24.
And the edit view of the already-created peer (as opposed to just the Peer Generator view during peer creation), also shows the equivalent of yours, 10.25.25.4/32.
All without the IPv6 addresses in my case.
The Peer Generator created the peer properly according to your screenshots.
And the Peer Generator created a QR code I used for the client, after which I manually viewed and edited that config file on the client: Allowed IPs: 10.1.10.0/24 (but I also tried 10.1.10.99/32 and that with the first separated by a comma). The file server is at 10.1.10.99 btw.
So unless I'm misunderstanding, my instance, the created peer listed in OpnSense and peer config in my Mac client seem correct.
Thanks for pointing out that a created peer in edit view in OpnSense only reveals its Allowed IPs: of the the client's IP, whereas the client config on the client computer is the only place listing the actual LAN network range in its Allowed IPs field.
Whew.
I'm going to add something wild in the next post instead of at the bottom of this one.
Oh sh*t - my private key is visible via mouse over. Going to change that now.
So here's the insane thing that happened while I investigated the Allowed IPs in the created peer in OpnSense.
When I went into the edit view in OpnSense of an existing peer to view its Allowed IPs, I saw just the IP address that the vpn client would get when it connected 10.25.25.4/32.
For the heck of it, because nothing else worked so far, I clicked in the field next to that address and typed in the Allowed IP range that should only be in the client's config, 10.1.10.0/24. Now there were two IPs in that field.
I clicked Save.
When I clicked "Apply" all hell broke loose. The peer page in the GUI became unresponsive, then the list of my numerous peers disappeared!! then reloading the page in the browser didn't work, then I couldn't reach OpnSense, and the internet was down. I power cycled the DEC 850 OpnSense and waited. Didn't help, still couldn't reach it in a browser. I tried changing my computer's IP address to match the default in a new DEC 850, 192.168.1.1, but still couldn't reach. I switch the computer back to its regular IP address but still couldn't reach the OpnSense.
I used my Mac to connect to its console (ls /dev/ then screen /dev/ttyusbblahblah... , then my root password in my password manager didn't work nor my admin credentials, so booted the DEC 850 again (power cycle) in the OpnSense menu and choose Single User mode, then reset the root password, then restarted again and restored the config from the menu by choosing a backup from about 6 hours ago.
Wildddd bug.
I'll report it later.
DON'T TRY IT UNLESS YOU'RE READY FOR DISASTER.
Fortunately, it was the middle of the night here and users won't know. I've been up all night wrestling with split tunnels and that was just the cheery on top. HA HA. Hold my calls. I'll go to bed soon.
Quote from: Patrick M. Hausen on July 22, 2025, 02:17:18 PMOn the peer (Mac) I have AllowedIPs = 192.168.0.0/16 - which means that traffic to this entire network goes into the tunnel from the Mac to the OPNsense.
On the OPNsense side I have AllowedIPs = 192.168.255.2/32 which means that the OPNsense sends traffic to this single address into the tunnel.
Really in WireGuard there are no clients and servers, just peers. AllowedIPs tells WireGuard what is supposed to be at the other side of the tunnel.
That's why you put 0.0.0.0/0 on your "client" into AllowedIPs when you want to tunnel everything, and only select networks when you want split tunnel. I put "client" into quotation marks because it's really just an administrative distinction - the always on system waiting for incoming connections (OPNsense) vs. the road warrior initiating a connection (Mac). For WireGuard there is no difference.
Repeating myself: AllowedIPs is what is at the other end.
Thanks again. I think I have a better understanding of the terminology now but will think about it more later.
Do my settings seem ok to you?
Quote from: 2HgRyz13 on July 22, 2025, 04:13:23 PMQuote from: Patrick M. Hausen on July 22, 2025, 02:17:18 PMOn the peer (Mac) I have AllowedIPs = 192.168.0.0/16 - which means that traffic to this entire network goes into the tunnel from the Mac to the OPNsense.
On the OPNsense side I have AllowedIPs = 192.168.255.2/32 which means that the OPNsense sends traffic to this single address into the tunnel.
Really in WireGuard there are no clients and servers, just peers. AllowedIPs tells WireGuard what is supposed to be at the other side of the tunnel.
That's why you put 0.0.0.0/0 on your "client" into AllowedIPs when you want to tunnel everything, and only select networks when you want split tunnel. I put "client" into quotation marks because it's really just an administrative distinction - the always on system waiting for incoming connections (OPNsense) vs. the road warrior initiating a connection (Mac). For WireGuard there is no difference.
Repeating myself: AllowedIPs is what is at the other end.
Thanks again. I think I have a better understanding of the terminology now but will think about it more later.
Do my settings seem ok to you?
Yes, the Allowed IPs are what is at the other end. The Peer Generator did it correctly before I understood it from your explanation. The AllowedIP in the OpnSense peer edit-view shows that it allows that one IP address used by the client computer's Wireguard VPN, and the client computer's config's Allowed IP shows the network range on the other end (my LAN) that's allowed, 10.1.10.0/24.
I think I'm getting it.
Quote from: 2HgRyz13 on July 22, 2025, 04:10:38 PMWhen I clicked "Apply" all hell broke loose. The peer page in the GUI became unresponsive, then the list of my numerous peers disappeared!!
[...]
Wildddd bug.
Nope. Not a bug. You explicitly told OPNsense to route 10.1.10.0/24 into the WireGuard tunnel instead of your LAN thereby losing connection to your LAN. Don't do that ;-)
BTW: your settings look ok now. If it still does not work, check firewall rules and as a last resort use tcpdump to trace packets as they (hopefully) travel through the tunnel.
BTW2: you cannot test from inside LAN with your Mac. You need an external Internet connection. Same reason as your almost desaster above - the Mac cannot be connected to 10.1.10.0/24 via it's local network and via the WG tunnel at the same time.
Quote from: Patrick M. Hausen on July 22, 2025, 04:23:03 PMQuote from: 2HgRyz13 on July 22, 2025, 04:10:38 PMWhen I clicked "Apply" all hell broke loose. The peer page in the GUI became unresponsive, then the list of my numerous peers disappeared!!
[...]
Wildddd bug.
Nope. Not a bug. You explicitly told OPNsense to route 10.1.10.0/24 into the WireGuard tunnel instead of your LAN thereby losing connection to your LAN. Don't do that ;-)
BTW: your settings look ok now. If it still does not work, check firewall rules and as a last resort use tcpdump to trace packets as they (hopefully) travel through the tunnel.
BTW2: you cannot test from inside LAN with your Mac. You need an external Internet connection. Same reason as your almost desaster above - the Mac cannot be connected to 10.1.10.0/24 via it's local network and via the WG tunnel at the same time.
Yes, I know, I've been testing the Wireguard connection through a Personal Hotspot. I verify I'm on an external network by visiting whatismyipaddress on the client computer. It shows the IP is my cellular provider's instead of the gigabit fiber into the DEC 850.
I frequently retest the client with Allowed IP 0.0.0.0/0 just to make sure I can reach the file server ok. It always works.
Then I went back to trying different Allowed IP setting in the client conf file: 10.1.10.0/24 and 10.1.10.99/32.
I need to stop for now because I haven't slept for a long time and we all know that can be dangerous.
Thank you very much for your detailed explanations and confirming my settings look ok!
UPDATE
This OpnSense configuration was correct all along.
And the peer config file was correct, too.
I dug up a Windows 11 pc, installed wireguard and imported the exact same conf file I'd been beating to death in macOS Sequoia 15.5 (Allowed IPs: 192.168.4.0/24 ).
The Windows PC WireGuard connected right away, let me connect to the file server right away, and browse the internet over the personal hotspot from my phone (as verified with whatismyipaddress).
The problem is 100% on the Mac.
M4 MBA, Sequoia 15.5
Wireguard at utun4
WireShark sees smb2 packets and more flowing on utun4 when WireGuard peer connects sans split tunnel, i.e, Allowed IPs: 0.0.0.0/0 . But with Allowed IPs: 192.168.4.0/24, WireShark shows zero packets of any type flowing on utun4 until I ping the file server.
On the M4 MBP Sequoia, I tried...
... wireguard gui client (same problem)
... passepartout macos wireguard client (same problem)
... defguard client (free) (same problem)
... homebrew version of wireguard and tested it in CLI (same problem)
On a stripped down old Intel macOS Sonoma 14.76 tried ...
... wireguard gui client (same problem)
I found other users complaining about the same or similar problem with split tunnels on macOS:
"MacOS Client does not create valid Routes" by a network engineer
https://github.com/DefGuard/client/issues/281
Though that's post is about DefGuard/WireGuard, it seems like macOS routes aren't correct.
Again, the exact same WireGuard conf file worked in Windows 11 WireGuard client.
After connecting macOS Wireguard GUI client, running
netstat -rn -f inet (-f inet for ip4 only) shows the macos routes
ifconfig shows the utun4 after Wireguard starts.
Ok, so for now, I'm taken my troubleshooting to the Wireguard support IRC since the problem is definitely NOT an OpnSense problem.
If I figure it out with Wireguard support, I post the solution here.
Oh, and I upgraded OpnSense to 25.7 before I realized the problem is 100% on the Mac.
Quote from: Monviech (Cedrik) on July 22, 2025, 08:12:30 AMSplit Tunnel in Wireguard is only decided by the allowed IPs in the client, which is installing routes to force traffic into the tunnel.
This means it depends on MacOS, Windows, Linux etc if the routing works correctly.
Im also using MacOS but I use OpenVPN there because it works reliably with split tunnel and split dns. I use Viscosity as client software.
I also have wireguard on it but I use it as full tunnel.
Maybe I should have been more explicit here, it would have prevented all this grief. xD
I should have stated explicitely that wireguard and MacOS only works correctly with full tunnels, I kind of only implied it.
So, use OpenVPN with Viscosity for MAC, no issues with split tunnels, or even OpenVPN inside OpenVPN or other stuff.
Quote from: Monviech (Cedrik) on July 24, 2025, 04:10:46 PMI should have stated explicitely that wireguard and MacOS only works correctly with full tunnels, I kind of only implied it.
Weird - works here for me. And has been for years. E.g. the IPMI interfaces in our data centre are in a private network - 10.0.0.0/16 with the 3rd octet denoting the rack number and the fourth one the rack unit. We use WG to connect to that management network with the Mac app store WG client and that worked flawlessly since we built the new DC.
Kind regards,
Patrick
Maybe it depends on factors out of our control if it works or not. On my iphone the split tunnel works. xD
Mysteries.
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.
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)