I'm trying to catch all traffic using the 0.0.0.0/1 and 128.0.0.0/1 trick, and I've noticed that even though the tproxy rules appear, only the 128.0.0.0/1 network appears on the loopback, I suppose its because possibly 0.0.0.0/1 is seen as invalid and can't be applied to an interface?
The result is that traffic isnt intercepted for 0-128 routes?
Is this expected behaviour, and if so is there a way I can funnel all traffic equivalent of 0.0.0.0/0 down the intercept (this is for SSH in this case).
Thanks!
Jon.
33149","time":"2025-05-23T19:39:17.418Z"}
ziti-router-1 | {"file":"github.com/openziti/ziti/tunnel/intercept/tproxy/tproxy_linux.go:555","func":"github.com/openziti/ziti/tunnel/intercept/tproxy.(*tProxy).addInterceptAddr","level":"info","msg":"Adding rule iptables -t mangle -A NF-INTERCEPT [-m comment --comment ssh-service -d 0.0.0.0/1 -p tcp --dport 22:22 -j TPROXY --tproxy-mark 0x1/0x1 --on-ip=127.0.0.1 --on-port=33149]","time":"2025-05-23T19:39:17.418Z"}
ziti-router-1 | {"file":"github.com/openziti/ziti/tunnel/intercept/tproxy/tproxy_linux.go:555","func":"github.com/openziti/ziti/tunnel/intercept/tproxy.(*tProxy).addInterceptAddr","level":"info","msg":"Adding rule iptables -t mangle -A NF-INTERCEPT [-m comment --comment ssh-service -d 128.0.0.0/1 -p tcp --dport 22:22 -j TPROXY --tproxy-mark 0x1/0x1 --on-ip=127.0.0.1 --on-port=33149]","time":"2025-05-23T19:39:17.419Z"}
ziti-router-1 | {"ctrlId":"NetFoundry Inc. Client LIboJaJ32","file":"github.com/openziti/ziti/router/state/manager.go:258","func":"github.com/openziti/ziti/router/state.(*ManagerImpl).ch
see below, the 0.0.0.0/1 is missing 
419d4ba1e2c4:~# ip -br a
lo UNKNOWN 127.0.0.1/8 100.64.0.1/10 128.0.0.0/1 ::1/128
eth0@if142 UP 172.21.0.2/16
Actually how would this even work, because if I add a 10.0.0.0/8 the router goes down because it now has a locally connected route on Lo which overrides the routes to the other routers? Wondering if there is a way around this?
I've read plenty of earlier threads where people are mentioning using 0.0.0.0/1 and 128.0.0.0/1 to divert all traffic down the ziti tunnel?
I have a feeling I may have to work around this by using bunches of specific routes or even dns wildcards, but it would have been nice to use the big subnets. I found another thread similar to this and the consensus was to do policy based routing which is what I'm already attempting with Wireguard and FRR routing + firewall marks which does actually work but its a heath robinson cobbled together approach and Ziti is so much more slick to be able to use.
I've seen people be successful with two cidr ranges. I've never tested it personally but i believe it works.
The routers and tunnelers know to add exclusions to the ips for the overlay itself, so those shouldn't be an issue.
I'm not exactly sure if you have a question or are just sharing your journey now (which is cool!)? You seem to have a good grip on the concepts, did i miss any question you had?
1 Like
Ah okay, so you are saying it knows to add the exclusions, this is the part that I was worried was not happening because when I add 10.0.0.0/8 as an intercept and bind it to a tunnel via the service policy, I see in the logs the tunneller actually goes down because it can't connect to any controller anymore, so not sure if this is because I'm applying said policy in the wrong place?
It could be more of I'm trying to do things in slightly the wrong order or binding to the wrong router/tuneller.
That's my recollection yeah. Do you have one controller or did you setup more than one? do you see any logs indicating the exclusions?
"Excluding $ip from tunneler" (ziti-tunnel-sdk-c/lib/ziti-tunnel/ziti_tunnel.c at d6c0a5db8bde64ce97f972672d46b9c33a1952d6 · openziti/ziti-tunnel-sdk-c · GitHub)
I have one controller, I will check the logs to see if any exclustions.
does debug logging need enabling on the controller as there is much info in the logs
ziti-controller-1 | {"_context":"ch{cNQjMb5Kc}-\u003eu{classic}-\u003ei{cNQjMb5Kc/aNba}","file":"github.com/openziti/ziti/controller/handler_ctrl/remove_terminators.go:92","func":"github.com/openziti/ziti/controller/handler_ctrl.(*removeTerminatorsHandler).handleRemoveTerminators","level":"info","msg":"removed terminators","routerId":"cNQjMb5Kc","terminatorIds":["6GJS3dlod4KY9GyizYY6Qz"],"time":"2025-05-25T13:23:47.154Z"}
ziti-controller-1 | {"file":"github.com/openziti/ziti/controller/handler_edge_ctrl/create_tunnel_terminator_v2.go:157","func":"github.com/openziti/ziti/controller/handler_edge_ctrl.(*createTunnelTerminatorV2Handler).CreateTerminator","level":"info","msg":"created terminator","routerId":"cNQjMb5Kc","service":"ssh-service","serviceId":"4VNjVPeiJ6Ew6AN9IuJYVy","terminatorId":"3h3MUSG1vw8IYGW5R7MMHn","time":"2025-05-25T13:23:47.158Z"}
ziti-controller-1 | {"elapsedTime":6540106,"file":"github.com/openziti/ziti/controller/handler_edge_ctrl/create_tunnel_terminator_v2.go:179","func":"github.com/openziti/ziti/controller/handler_edge_ctrl.(*createTunnelTerminatorV2Handler).CreateTerminator","level":"info","msg":"completed create tunnel terminator operation","routerId":"cNQjMb5Kc","service":"ssh-service","serviceId":"4VNjVPeiJ6Ew6AN9IuJYVy","terminatorId":"3h3MUSG1vw8IYGW5R7MMHn","time":"2025-05-25T13:23:47.158Z"}
Currently this workaround is functioning but its messy / heath robinson affair!
{
"name": "ssh-intercept",
"configTypeId": "g7cIWbcGg",
"data": {
"addresses": [
"10.0.0.0/11",
"10.64.0.0/10",
"10.128.0.0/9",
"10.32.0.0/12",
"10.48.0.0/13",
"10.56.0.0/14",
"10.61.0.0/16",
"10.62.0.0/16",
"10.63.0.0/16"
],
"portRanges": [
{
"high": 22,
"low": 22
}
],
"protocols": [
"tcp"
]
}
}
That intercepts all 10.0.0.0/8 but I specifically avoids stamping on my zerotier overlay which is how the tunnels and controller communicate on 10.60.0.0/16
Thanks to Gemini 2.5 for the quick list, but no thanks to ChatGPT 4o which is terrible at subnetting!
No, you would enable debug logging on the client tunneler to see this particular log message. It's something you'll see on the client.
1 Like