Traceroute problem in one LAN

RouterOS General
1

Traceroute problem in one LAN

PC1 has IP 192.168.20.1/17 (in LAN1)
PC2 has IP 192.168.129.3/24 (in LAN2)
Ie. each PC is in a different LAN.
Currently we use just basic static IP routing; no VLAN, no tunneling protocols, no OSPF etc.
.

Network topology (simplified):

      WAN
       |
    Router1
     |    |
Router2  Router3/AP
   |        |  
L3switch   LAN2 
   |
 LAN1

Router1 and Router2 are from other vendors (AVM and Ubiquiti), Router3 (hAP ac^2) and the L3switch (CRS326) are MiktoTik.

>

Symptoms:
PC1 can not traceroute PC2, but ping is ok.
PC2 can traceroute as well ping PC1, though traceroute seems incomplete, see below.

Question:
What might be the cause for traceroute not working from PC1 in LAN1 ?
It seems to be a firewall issue, but what exactly to look for?
How to fix this problem?
.

> ```text
PC1 to PC2:
-----------
$ traceroute 192.168.129.3
traceroute to 192.168.129.3 (192.168.129.3), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  *^C

$ ping 192.168.129.3
PING 192.168.129.3 (192.168.129.3) 56(84) bytes of data.
64 bytes from 192.168.129.3: icmp_seq=1 ttl=61 time=2.33 ms
64 bytes from 192.168.129.3: icmp_seq=2 ttl=61 time=0.705 ms
64 bytes from 192.168.129.3: icmp_seq=3 ttl=61 time=0.721 ms
^C
--- 192.168.129.3 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2017ms
rtt min/avg/max/mdev = 0.705/1.252/2.331/0.763 ms

.

PC2 to PC1:

$ traceroute 192.168.20.1
traceroute to 192.168.20.1 (192.168.20.1), 30 hops max, 60 byte packets
1 192.168.129.254 (192.168.129.254) 0.470 ms 0.448 ms 0.428 ms
2 fritz.box (192.168.254.254) 15.445 ms 15.427 ms 15.407 ms
3 192.168.254.253 (192.168.254.253) 15.386 ms 15.370 ms 15.341 ms
4 192.168.254.253 (192.168.254.253) 15.319 ms 5.435 ms *

$ ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 56(84) bytes of data.
64 bytes from 192.168.20.1: icmp_seq=1 ttl=61 time=2.24 ms
64 bytes from 192.168.20.1: icmp_seq=2 ttl=61 time=0.965 ms
64 bytes from 192.168.20.1: icmp_seq=3 ttl=61 time=0.801 ms
^C
— 192.168.20.1 ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 0.801/1.337/2.246/0.646 ms

>
2

traceroute on Linux sends UDP packets in the forward direction (unless you explicitly ask it to use another protocol), only the “TTL expired” backward notifications are ICMP. Mikrotik’s /tool traceroute uses ICMP packets also in the forward direction by default.

3

SOLVED!

The cause of the problem was that on the L3switch in ACL all UDP traffic was blocked.
Ie. there was such a rule under “/interface/ethernet/switch/rule” :

add switch=switch1 ports=$myPorts mac-protocol=ip protocol=udp comment=“L3+4 UDP” disabled=yes

And the last rule is:

add switch=switch1 ports=$myPorts new-dst-ports=“” comment=“block all other”

Changing the “disabled=yes” to “disabled=no” solved the problem.

4

Hi, yes, indeed UDP was the cause. Solved now. Thx.

My motivation was to eliminate outgoing UDP traffic completely as we don’t use such services in our LAN. But of course traceroute diagnosis is an exception.
I must admit, I never would have expected that traceroute uses UDP, I rather was thinking it uses an L2 protocol (hmm. of course L2 protocol works only in LAN, so let’s forget that remark :slight_smile:)
Nevertheless I’ll change that rule so that only admins can use UDP, but not the normal users. This should be possible with station IPs.

Update: found even a much better solution. “man traceroute” says:

lft , the Layer Four Traceroute, performs a TCP traceroute, like traceroute -T , but attempts to provide compatibility with the original such implementation, also called
“lft”.

That “lft” seems to work with TCP instead of UDP, so then I can block the UDP again.
The MikroTik traceroute tool is good too, but of course it can work only on the router/switch device. We need a more flexible method, ie. from any PC station (all Linux here). The above said Linux tool “lft” is ok. Already reverted back and tested with lft: works like a charm.