If your on a zero trust network adapter like zscaler or netskope, you will see that traceroute doesn’t work as expected. The article below shows how to install mtr (my trace route) using brew:
## Install xcode
xcode-select --install
## Install mtr
brew install mtr
Next we need to change the owner of the MTR package and it’s permissions (otherwise you will need to run it as root every time):
sudo chown root /opt/homebrew/Cellar/mtr/0.95/sbin/mtr-packet
sudo chmod 4755 /opt/homebrew/Cellar/mtr/0.95/sbin/mtr-packet
## Symlink to the new mtr package instead of the default MAC version
ln -s /opt/homebrew/Cellar/mtr/0.95/sbin/mtr /opt/homebrew/bin/
ln -s /opt/homebrew/Cellar/mtr/0.95/sbin/mtr-packet /opt/homebrew/bin/
To run a rolling traceroute with ICMP echo’s use the following:
mtr andrewbaker.ninja
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
The issue is that Zscaler will attempt to tunnel this traffic. This can be observed by viewing your current routes:
netstat -rn
Internet:
Destination Gateway Flags Netif Expire
default 192.168.0.1 UGScg en0
1 100.64.0.1 UGSc utun6
2/7 100.64.0.1 UGSc utun6
4/6 100.64.0.1 UGSc utun6
8/5 100.64.0.1 UGSc utun6
10/12 100.64.0.1 UGSc utun6
10.1.30.3 100.64.0.1 UGHS utun6
10.1.30.15 100.64.0.1 UGHS utun6
10.1.31/24 100.64.0.1 UGSc utun6
10.1.31.3 100.64.0.1 UGHS utun6
10.1.31.41 100.64.0.1 UGHS utun6
10.1.31.101 100.64.0.1 UGHS utun6
10.1.31.103 100.64.0.1 UGHS utun6
10.10.0.11 100.64.0.1 UGHS utun6
10.10.0.12 100.64.0.1 UGHS utun6
10.10.160.86 100.64.0.1 UGHS utun6As you can see from the above, it lists the routes that are being sent to the Zscaler tunnel interface “utun6” (this is unique to your machine but will look similar). To get around this you can specify the source interface the MTR should run from with the “-I” flag. Below we instruct mtr to use en0 (the lan cable):
mtr andrewbaker.ninja -I en0
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. unfisecuregateway 1.8% 56 2.0 2.2 1.5 4.5 0.6
2. 41.71.48.65 0.0% 56 4.2 8.1 3.1 28.3 6.0
3. 41.74.176.249 0.0% 56 4.2 4.5 3.4 8.2 0.9
4. 196.10.140.105 0.0% 55 3.0 4.0 2.6 18.8 2.4
5. 52.93.57.88 0.0% 55 5.1 6.3 3.7 12.4 2.0
6. 52.93.57.103 0.0% 55 4.9 4.1 2.6 12.5 1.5
7. (waiting for reply)
8. 150.222.94.230 0.0% 55 4.0 4.8 3.1 13.8 1.8
9. 150.222.94.243 0.0% 55 4.3 5.3 2.9 37.6 5.2
10. 150.222.94.242 0.0% 55 15.2 4.9 2.9 15.2 2.2
11. 150.222.94.237 0.0% 55 3.4 5.7 3.1 18.9 2.9
12. 150.222.93.218 0.0% 55 4.6 5.5 3.8 11.4 1.3
13. (waiting for reply)MTR supports TCP, UDP and SCTP based traceroutes. This is useful when testing path latency and packet loss in external or internal networks where QoS is applied to different protocols and ports. Multiple flags are available (man mtr), but for a TCP based MTR use -T (indicates TCP should be used) and -P (port to trace to):
mtr andrewbaker.ninja -T -P 443 -I en0Ping specifying source interface
Ping supports specifying the source interface you would like to initiate the ping from. The “-S” flag indicates that the following IP is the source IP address the ping should be done from. This is useful if you want to ping using an internal resource bypassing a route manipulator tool such as Zscaler.
ping outlook.office.com -S 10.220.64.37