Weird random traceroute like packets

Everything Else
1

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?

2

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
3

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

2 Likes
4

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.

5

@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.

image
image986×222 13.7 KB

Please set it default outbound policy using algorithm and recheck.

6

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.)

7

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