How to setup OpenZiti and Wireguard/OpenVPN protocol together?

Support General Questions
1

Currently we use OpenVPN/Wireguard Full Tunnel encryption behind a DNS server for connecting to our clients devices. (We have over 6000+.) We have OpenZiti used within our company connecting to our internal services which works great. However, our Firmware developers want to be able to have both OpenVPN/Wireguard and Openziti enabled. From my testing, I have noticed that if we have OpenVPN/Wireguard Full Tunnel encryption and Openziti enabled, Openziti fails. If we utilize Split Tunnel encryption, it works with OpenZiti.

Wondering what would be the best way of managing this so our Firmware developers can work with connecting to devices as well as staying connected to our internal services?

2

Hi @MacFee,

It would seem to me that if you are using full-tunnel mode for OpenVPN/Wireguard, and if that traffic is intercepted first it's possibly breaking OpenZiti's mTLS? That or perhaps it's swallowing DNS requests as well and thus not making it to the OpenZiti IP address. You'd probably have to look at the tunneler / sdk logs or do a wirecapture to know for sure which is happening.

I assume you/the firmware devs are running ziti-edge-tunnel and not embedding OpenZiti's SDK directly into their code? I would think if you embed the OpenZiti SDK into your application itself the transport encryption from a full tunnel wouldn't affect the OpenZiti SDK traffic but truthfully this isn't a configuration I've ever personally tested so I am only hypothesizing here.

If you're using ziti-edge-tunnel though I would think you'd be able to configure the tunneler with a different IP range and exclude that IP range from the full tunnel (if it supports that sort of thing)?

The obvious and easy answer here is "use split tunnel" though, since we know that configuration works... :slight_smile:

If you'd indulge me, I am interested in this topology. Having OpenVPN, Wireguard AND OpenZiti seems -- I dunno, maybe a bit redundant? Is that just because of legacy? I'm just wondering if OpenVPN/Wireguard are preferable for some other reason?

3

It would seem to me that if you are using full-tunnel mode for OpenVPN/Wireguard, and if that traffic is intercepted first it's possibly breaking OpenZiti's mTLS?

Exactly this. This is what is happening.

The packet tunnel logs are the following:

[2026-07-23T14:27:52:177Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:425 logNetworkPath() Network Path Update:Status:satisfied, Expensive:false, Cellular:false, DNS:trueInterfaces:14: name:en0, type:wifi14: name:en0, type:wifi26: name:utun8, type:other
[2026-07-23T14:27:52:204Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:371 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1
[2026-07-23T14:27:52:205Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:410 startNetworkMonitor() Setting fallback DNS to 192.168.1.1(85441)[2026-07-23T14:27:52.204Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53(85441)[2026-07-23T14:27:55.837Z]    INFO tunnel-cbs:ziti_dns.c:567 format_resp() found record[100.64.0.26] for query[1:bull-board.dev.foo.com]
[2026-07-23T14:27:55:844Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:425 logNetworkPath() Network Path Update:Status:satisfied, Expensive:false, Cellular:false, DNS:trueInterfaces:14: name:en0, type:wifi14: name:en0, type:wifi26: name:utun8, type:other
[2026-07-23T14:27:55:862Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:371 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1[2026-07-23T14:27:55:862Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:410 startNetworkMonitor() Setting fallback DNS to 192.168.1.1(85441)
[2026-07-23T14:27:55.862Z]    INFO tunnel-cbs:ziti_dns.c:273 
ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53(85441)[
2026-07-23T14:27:56.135Z]    INFO tunnel-cbs:ziti_dns.c:567 format_resp() found record[100.64.0.7] for query[1:bull-board.us.foo.com][2026-07-23T14:27:56:304Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:425 logNetworkPath() Network Path Update:Status:satisfied, Expensive:false, Cellular:false, DNS:trueInterfaces:14: name:en0, type:wifi14: name:en0, type:wifi26: name:utun8, type:other
[2026-07-23T14:27:56:339Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:371 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 192.168.1.1[2026-07-23T14:27:56:340Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:410 startNetworkMonitor() Setting fallback DNS to 192.168.1.1(85441)
[2026-07-23T14:27:56.339Z]    INFO tunnel-cbs:ziti_dns.c:273 ziti_dns_set_upstream() DNS upstream[1] is set to 192.168.1.1:53(85441)[2026-07-23T14:27:59.849Z]    INFO tunnel-cbs:ziti_dns.c:567 format_resp() found record[100.64.0.12] for query[1:grafana.dev.foo.com](85441)[2026-07-23T14:28:06.839Z]   ERROR ziti-sdk:channel.c:1125 on_tls_connect() ch[0] failed to connect to ER[dev-router0] [-3008/unknown node or service](85441)
[2026-07-23T14:28:06.839Z] INFO ziti-sdk:channel.c:981 reconnect_channel() ch[0] reconnecting in 68058ms (attempt = 218)(85441)[2026-07-23T14:28:09.006Z]   
ERROR tunnel-sdk:tunnel_tcp.c:191 on_tcp_client_err() client=tcp:100.64.0.1:64365 err=-14, terminating connection(85441)
[2026-07-23T14:28:13.897Z]    INFO tunnel-cbs:ziti_dns.c:567 format_resp() found record[100.64.0.11] for query[1:gitlab.foo.com]
[2026-07-23T14:28:17:677Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:425 logNetworkPath() Network Path Update:Status:unsatisfied, Expensive:false, Cellular:false, DNS:trueInterfaces:14: name:en0, type:wifi14: name:en0, type:wifi26: name:utun8, type:other[2026-07-23T14:28:18:042Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:425 logNetworkPath() Network Path Update:Status:unsatisfied, Expensive:false, Cellular:false, DNS:trueInterfaces:14: name:en0, type:wifi14: name:en0, type:wifi

I assume you/the firmware devs are running ziti-edge-tunnel and not embedding OpenZiti's SDK directly into their code?

Correct. We don't use the sdk since our devices are a mix of OpenVPN and Wireguard connections.

If you're using ziti-edge-tunnel though I would think you'd be able to configure the tunneler with a different IP range and exclude that IP range from the full tunnel (if it supports that sort of thing)?

That will be a tough action to do. I don't really know how to get that to work.

Having OpenVPN, Wireguard AND OpenZiti seems -- I dunno, maybe a bit redundant? Is that just because of legacy? I'm just wondering if OpenVPN/Wireguard are preferable for some other reason?

It is but we have setup fault-tolerance and high availability setup where we can scale with OpenVPN/Wireguard where it doesn't cost us an arm-and-leg for other services out there. We have thought on using OpenZiti as a full replacement but it's complicated for us at the moment in setting up faul-tolerance and high availability atm.

4

Running multiple overlays with any in a 'full tunnel mode' simultaneously has always been a problem since they are always competing/conflicting. I don't know if there's any great answers if you're running in a full-tunnel. Sometimes the start order can matter. Unfortunately, I'm not sure this is a "supported configuration" and it's certainly not something we generally test. If something breaks OpenZiti's mTLS (like DPI and other endpoint protection type software) that fundamentally breaks OpenZiti too. OpenZiti has always been designed with a split-tunnel design. I'm not sure how much more I can offer you on this one, I'm afraid.