# How to troubleshoot a recalcitrant tunneler

**URL:** <https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457>\
**Category:** Uncategorized\
**Created:** [August 8, 2023, 7:32pm UTC](https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457 "2023-08-08T19:32:26Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jptechnical](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/jptechnical/32/1089_2.png) [@jptechnical](https://openziti.discourse.group/u/jptechnical)\
**Post date:** [August 8, 2023, 7:32pm UTC](https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457/1 "2023-08-08T19:32:26Z")

</div>

I keep peeling back the layers and finding something new I can break. Now I have a bunch of identities I have created, downloaded the jwts and they have at least handshakes enough with the controller to get an identity json. But, the tunneler device won’t start.

Here is my error.

```bash
root@linux:~# ziti-edge-tunnel run -i /opt/openziti/etc/identities/linux.jptech.ziti.json
(536)[0.000] INFO ziti-sdk:utils.c:188 ziti_log_set_level() set log level: root=3/INFO
(536)[0.000] ERROR ziti-edge-tunnel:ziti-edge-tunnel.c:1542 run_tunnel() failed to open network interface: open /dev/net/tun failed
About to run tunnel service... ziti-edge-tunnelroot@linux:~#

```

I am running these in LXC containers, debian12.

My creation script contains the following identities. The falkor one is a dest machine with MacOS, so I am using the ziti desktop app and it has enrolled fine and I can ping `100.64.0.2`.

```bash
ziti edge create identity device linux.jptech.ziti --role-attributes jptech.ssh.server,jptech.admin -o linux.jptech.ziti.jwt
ziti edge create identity device mac1.jptech.ziti --role-attributes jptech.admin -o mac1.jptech.ziti.jwt
ziti edge create identity device mac2.jptech.ziti --role-attributes jptech.ssh.server -o mac2.jptech.ziti.jwt
ziti edge create identity device win.jptech.ziti --role-attributes jptech.ssh.server -o win.jptech.ziti.jwt
ziti edge create identity device falkor.jptech.ziti --role-attributes jptech.ssh.server,jptech.admin -o falkor.jptech.ziti.jwt
ziti edge create identity device macbian.jptech.ziti --role-attributes jptech.ssh.server,jptech.admin -o macbian.jptech.ziti.jwt

```

---

<div class="post-metadata">

**Author:** ![jptechnical](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/jptechnical/32/1089_2.png) [@jptechnical](https://openziti.discourse.group/u/jptechnical)\
**Post date:** [August 8, 2023, 7:52pm UTC](https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457/2 "2023-08-08T19:52:09Z")

</div>

If anyone finds this, it was an LXC problem, specifically in proxmox. Here is the article that addresses it since it will be directly affected in OpenZiti: [OpenVPN in LXC - Proxmox VE](https://pve.proxmox.com/wiki/OpenVPN_in_LXC)

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [August 8, 2023, 9:14pm UTC](https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457/3 "2023-08-08T21:14:51Z")

</div>

Oh, good to know. I don’t think I had to do that before running `ziti-edge-tunnel` in lxd on my Ubuntu workstation. It might be something that’s always needed for the original lxc but not Canonical’s lxc/lxd flavored containers.

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [August 8, 2023, 9:43pm UTC](https://openziti.discourse.group/t/how-to-troubleshoot-a-recalcitrant-tunneler/1457/4 "2023-08-08T21:43:34Z")

</div>

Linux Tunnel Troubleshooting tips:

1. Is Ziti’s tun interface UP?

```bash
❯ ip link sh up tun0
19: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state 
UNKNOWN mode DEFAULT group default qlen 500
    link/none 

```

2. What is Ziti’s nameserver IP?

```bash
❯ resolvectl --interface=tun0 dns   
Link 19 (tun0): 100.64.0.2

```

3. Is my Ziti service working?

```bash
❯ dig +noall +answer ssh.ziti.service.example.com @100.64.0.2
my.ziti.service.example.com. 60 IN A 100.64.0.3

❯ ncat 100.64.0.3 22 </dev/null 
SSH-2.0-OpenSSH_7.4

```

Be careful with ping when testing Ziti services because the transports are TCP or UDP, not ICMP. It’s still useful, as you found, for probing the local tun interface address.

I’ve proposed adding these to [Troubleshooting | OpenZiti](https://openziti.io/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting) in [this pull request](https://github.com/openziti/ziti-doc/pull/633) ([preview](https://ziti-doc-git-qrkourier-patch-1-openziti.vercel.app/docs/reference/tunnelers/linux/linux-tunnel-troubleshooting#intercepting-or-hosting-not-working)).