Default Route Issue OSX Monterey M1

Community Support macOS
,
#1

Hi all,

Firstly love this product having a ball messing with it, beats setting up L2TP everywhere! :slight_smile:

I have an issue on my MAC. It’s an M1 Air and I just pumped it to the latest version 12.3.1 Monterey. I’m also running ZT One 1.8.8.

I have a basic network with the following routes. 10.244.0.254 is my Mikrotik CPE where all the magic happens. I’ve added in RFC1918 to allow ‘lazy split tunnelling’ while I get this issue resolved.

image
image946×248 6.82 KB

So on my Android I can tick the route via Zerotier and I get the full-tunnel with default route and everything is happy. On my Mac however if I enable Default Route override I lose access to everything.

So my route table with the split-tunnel config looks like this:

10 10.244.0.254 UGSc feth203
10.244/16 link#26 UC feth203 !
10.244.0.254 5a:9b:1b:2b:13:64 UHLWIir feth203 1190
10.244.255.255 ff:ff:ff:ff:ff:ff UHLWbI feth203 !
172.16/12 10.244.0.254 UGSc feth203
192.168.0/16 10.244.0.254 UGSc feth203

When I turn on default route it goes to this:

0/1 10.244.0.254 UGScg feth203
10 10.244.0.254 UGSc feth203
10.244/16 link#26 UC feth203 !
10.244.0.254 5a:9b:1b:2b:13:64 UHLWIir feth203 1174
10.244.255.255 ff:ff:ff:ff:ff:ff UHLWbI feth203 !
128.0/1 10.244.0.254 UGSc feth203
172.16/12 10.244.0.254 UGSc feth203
192.168.0/16 10.244.0.254 UGSc feth203

(Sorry for the layout issues above I’m only allowed to embed 1 image …)

Now from what I can tell this is expected behaviour and testing with a mate with ‘non-M1’ Macbook Pro his works fine. However, when I enable this on mine I lose access to everything, ICMP response is simply No route to host for everything I try.

Hope this is enough information I’m not really sure where to go from here so any help would be appreciated.

Cheers

#2

I can confirm the same issue on my M1 Max Monterey.
Really frustrating as we use Zerotier with default routing for business critical stuff.

#3

Sorry we missed this. Is the routing table different on an intel mac? It looks normal from here.

Will try to reproduce soon. But this is the only report like this as far as I know.

#4

I don’t see how it would be. More likely it’s a compatibility issue with the ARM architecture.

#5

is anyone else getting doubled 0/1 and 128.0/1 routes?

default            192.168.82.1       UGScg            en11       
0/1                10.147.20.1        UGScg         feth570       
0/1                192.168.82.1       UGScIg           en11     
128.0/1            10.147.20.1        UGSc          feth570       
128.0/1            192.168.82.1       UGScI            en11
#6

Yea, double routes here (once connected) but I think this is expected

image
image1242×876 92.5 KB

For clarity, I often loose internet access if I disconnect (by reboot, disconnect or exit - not figured out how to repro yet). Once disconnected, the routes to the feth* still exist which is obviously an issue :slight_smile: meaning that the tun hasn’t been destroyed properly I guess?

Running ZT 1.8.4 on Monterey 12.0.1

This also occurred on my OLD intel mac on Catalina, same issue

#7

Ok, can repro, sort of :slight_smile: (seems like this repro allows internet rather than blocking!)

I connected and everything came up as expected (routes etc.), then I just exited the app (with “Quit ZeroTier UI”). The routes remained, and the feth208 actually remained active!! Meaning I had access to ZT without the app running…

image
image1228×864 180 KB

#8

This is to be expected. Quitting the UI app does not stop ZeroTier from running. ZeroTier is a system service that’s run in the background by launchd on macOS. The UI app communicates with the system service via a REST API (in the same manner that zerotier-cli communicates with the system service).

#9

Ok, didn’t know that! It makes sense with the references to “Exiting the UI”… doh.

However I do have the disconnect repro:

  1. Connect to a ZT network
  2. Disconnect WiFi
  3. Reconnect wifi
  4. No internet

This is the routing table at step 4

image
image2054×590 173 KB 

# route -n get 1.1.1.1
   route to: 1.1.1.1
destination: default
       mask: default
    gateway: 10.0.4.1
  interface: en0
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING,GLOBAL>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0
#10

Are you saying that the default route is broken after you turn the wifi back on?

#11

No, it’s not just the default route, as you can see the routing looks fine (in my last post). It’s something else stopping the traffic

#12

I’m trying to figure out what you’re saying in that post, hence my question. From what I can tell, you’re saying something along the lines of, “I turned off my WiFi, and now my internet doesn’t work.” Which is to be expected because you turned off your internet connection. I’m sure you can see why i’m sitting here scratching my head right now.

#13

Jeeze sorry… I wrote that post while trying to debug, got disconnected while trying to post it :zipper_mouth_face:

It’s corrected now, so yea, internet connectivity is required :sweat_smile:

It seems like if you are connected to ZT then disconnect (via reboot, WiFi dropoff etc. I.e. no manual disconnect via ZT UI) then it’s left in a state where there is no connectivity. Even if you go into the UI and try to reconnect, disconnect, exit etc. it doesn’t want to reset whatever is the blocker

#14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.