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

[2HgRyz13]

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

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

[Patrick M. Hausen]

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.

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:

Code Select Expand

[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:



And this is the corresponding peer - it has the peer's interface address in AllowedIPs, necessarily so:



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.

[2HgRyz13]

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.

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.

[2HgRyz13]

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.

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:

Code Select Expand

[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:



And this is the corresponding peer - it has the peer's interface address in AllowedIPs, necessarily so:



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.

[Patrick M. Hausen]

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.

[2HgRyz13]

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.

[Patrick M. Hausen]

Oh sh*t - my private key is visible via mouse over. Going to change that now.

[2HgRyz13]

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.

[2HgRyz13]

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.

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?

[2HgRyz13]

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.

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.

[Patrick M. Hausen]

When 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.

[2HgRyz13]

When 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!

[2HgRyz13]

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.

[Monviech (Cedrik)]

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.

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.

[Patrick M. Hausen]

I 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