Weird random traceroute like packets

I’m debugging an issue, so doing packet captures on a local ethernet link from one of my Peplink Routers (B One), and I’m seeing what looks like something trying a traceroute I’m not expecting.

There are packets which appear to originate at the router to Google’s DNS (8.8.8.8 port 443), but with TTL values of 2 and 3. (Only 2 and 3.) Which then get ICMP time expired responses.

This is over the VLAN WAN to another unit (a B20X).

12:47:15.397152 d4:xx:xx:xx:xx:60 > 10:xx:xx:xx:xx:e0, ethertype 802.1Q (0x8100), length 78: vlan 7, p 0, ethertype IPv4 (0x0800), (tos 0x0, ttl 3, id 48276, offset 0, flags [none], proto TCP (6), length 60)
10.xx.xx.252.3111 > 8.8.8.8.443: Flags [S], cksum 0x6e7a (correct), seq 2020789940, win 5840, options [mss 1460,sackOK,TS val 2528426472 ecr 0,nop,wscale 2], length 0

12:47:15.467053 10:xx:xx:xx:xx:e0 > d4:xx:xx:xx:xx:60, ethertype 802.1Q (0x8100), length 74: vlan 7, p 0, ethertype IPv4 (0x0800), (tos 0x30, ttl 253, id 48276, offset 0, flags [none], proto ICMP (1), length 56)
10.5.102.254 > 10.xx.xx.252: ICMP time exceeded in-transit, length 36
(tos 0x30, ttl 1, id 48276, offset 0, flags [none], proto TCP (6), length 60)
10.xx.xx.252.3111 > 8.8.8.8.443: [|tcp]

The address 10.5.102.254 is not one I use on my network.

Any ideas?

Looks like a wan healthcheck mechanism to me. Are you using Smartcheck?
Peplink devices often use TCP-based health checks and advanced path probing to assess WAN availability and quality. These can resemble traceroute but:

  • Don’t necessarily use TTL=1 (to reduce noise or avoid detection).
  • Might use TCP SYN packets (not UDP or ICMP).
  • Can perform probing via different TTL values to intermediate hops to monitor path behavior or troubleshoot.
  • Will often choose 8.8.8.8:443 as a target for being a reliable endpoint.

This TTL behavior—SYN packets to a real destination with TTL=2, TTL=3, then checking the ICMP time exceeded replies—is consistent with a proprietary probing mechanism.

Perhaps @TK_Liew might knwo for sure.

1 Like

The traceroute is expected and it is used for WAN Quality Report.

2 Likes

The WAN quality sounds reasonable.

Though the packets don’t go away when I turn off WAN quality monitoring on that WAN.

Also 10.5.102.254 is T-Mobile, I get that address when I try a traceroute over the cellular connection from the other end of the link.

@Barry_Twycross1250 ,

Can you please check the default outbound policy as well ? If you use Auto, lowest latency algorithm will be applied. This will generate the similar traffics.

Please set it default outbound policy using algorithm and recheck.

The default rule is auto, but I did have a rule which did fastest response including this link.

I turned that off, and still seeing the packets.

(Not that it really matters, it’s just a curiosity.)

@Barry_Twycross1250, Have you changed the Default Rule from Auto to Custom with Enforced (for example) algorithm?