Excessive ICMP Ping Flood

KVM
1

I unbind my GLKVM cloud access and disable cloud remote access, and disabled Tailscale, but I am seeing ICMP ping floods. Looks mostly to DNS servers.

Doesn't seem like the GLKVM is being a good citizen by flooding DNS servers with pings.

Is gl.inet going to fix this?

I temporarily added a FW rule to block ICMP requests from the GLKVM.

15:32:21.037665 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16056, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1285, seq 1, length 64
15:32:21.043988 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 32318, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1285, seq 1, length 64
15:32:21.056535 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 40559, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1287, seq 1, length 64
15:32:21.061990 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1287, seq 1, length 64
15:32:21.074029 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 4038, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1289, seq 1, length 64
15:32:21.080540 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5252, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1289, seq 1, length 64
15:32:22.097616 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16100, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1291, seq 1, length 64
15:32:22.103976 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 10640, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1291, seq 1, length 64
15:32:22.115354 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 40810, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1293, seq 1, length 64
15:32:22.121298 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1293, seq 1, length 64
15:32:22.137824 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 4310, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1295, seq 1, length 64
15:32:22.144277 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5380, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1295, seq 1, length 64
15:32:23.155054 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16205, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1299, seq 1, length 64
15:32:23.161281 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 34863, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1299, seq 1, length 64
15:32:23.175245 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 40871, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1301, seq 1, length 64
15:32:23.180784 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1301, seq 1, length 64
15:32:23.195173 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 4486, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1303, seq 1, length 64
15:32:23.201764 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5471, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1303, seq 1, length 64
15:32:24.214081 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16331, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1305, seq 1, length 64
15:32:24.220563 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 29467, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1305, seq 1, length 64
15:32:24.233142 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 41080, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1307, seq 1, length 64
15:32:24.238545 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1307, seq 1, length 64
15:32:24.252086 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 4721, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1309, seq 1, length 64
15:32:24.258599 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5613, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1309, seq 1, length 64
15:32:25.273808 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16616, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1311, seq 1, length 64
15:32:25.279996 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 39514, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1311, seq 1, length 64
15:32:25.294210 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 41238, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1313, seq 1, length 64
15:32:25.299531 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1313, seq 1, length 64
15:32:25.311596 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 4980, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1315, seq 1, length 64
15:32:25.318003 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5638, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1315, seq 1, length 64
15:32:26.332170 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16683, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1317, seq 1, length 64
15:32:26.338522 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 3082, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1317, seq 1, length 64
15:32:26.350292 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 41536, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1319, seq 1, length 64
15:32:26.355759 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1319, seq 1, length 64
15:32:26.369682 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5194, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1321, seq 1, length 64
15:32:26.376338 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5741, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1321, seq 1, length 64
15:32:27.391385 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16720, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1323, seq 1, length 64
15:32:27.397597 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 22863, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1323, seq 1, length 64
15:32:27.408695 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 41772, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1325, seq 1, length 64
15:32:27.414433 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1325, seq 1, length 64
15:32:27.428384 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5301, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1327, seq 1, length 64
15:32:27.435084 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 5850, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1327, seq 1, length 64
15:32:28.449213 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 16960, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1329, seq 1, length 64
15:32:28.456028 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 37227, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1329, seq 1, length 64
15:32:28.468722 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 41978, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1331, seq 1, length 64
15:32:28.474330 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1331, seq 1, length 64
15:32:28.485502 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5499, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1333, seq 1, length 64
15:32:28.492013 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6037, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1333, seq 1, length 64
15:32:29.510019 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17166, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1335, seq 1, length 64
15:32:29.516513 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 33558, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1335, seq 1, length 64
15:32:29.531892 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42055, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1337, seq 1, length 64
15:32:29.537674 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1337, seq 1, length 64
15:32:29.551788 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5523, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1339, seq 1, length 64
15:32:29.558684 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6133, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1339, seq 1, length 64
15:32:29.613057 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 41545, offset 0, flags [DF], proto UDP (17), length 48)
    192.168.69.60.58402 > 74.125.250.129.19302: [udp sum ok] UDP, length 20
15:32:29.632603 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 43, id 0, offset 0, flags [none], proto UDP (17), length 60)
    74.125.250.129.19302 > 192.168.69.60.58402: [udp sum ok] UDP, length 32
15:32:29.636730 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 70: (tos 0x0, ttl 64, id 41551, offset 0, flags [DF], proto UDP (17), length 56)
    192.168.69.60.58402 > 74.125.250.129.19302: [udp sum ok] UDP, length 28
15:32:29.656547 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 43, id 0, offset 0, flags [none], proto UDP (17), length 60)
    74.125.250.129.19302 > 192.168.69.60.58402: [udp sum ok] UDP, length 32
15:32:30.572443 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17451, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1341, seq 1, length 64
15:32:30.578774 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 18979, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1341, seq 1, length 64
15:32:30.592996 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42068, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1343, seq 1, length 64
15:32:30.598594 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1343, seq 1, length 64
15:32:30.612068 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5742, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1345, seq 1, length 64
15:32:30.618612 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6216, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1345, seq 1, length 64
15:32:31.634463 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17765, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1347, seq 1, length 64
15:32:31.640864 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 43446, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1347, seq 1, length 64
15:32:31.653102 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42191, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1349, seq 1, length 64
15:32:31.658595 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1349, seq 1, length 64
15:32:31.669806 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 5945, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1351, seq 1, length 64
15:32:31.676411 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6224, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1351, seq 1, length 64
15:32:32.689825 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 17785, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1353, seq 1, length 64
15:32:32.696472 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 35233, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1353, seq 1, length 64
15:32:32.707618 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42336, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1355, seq 1, length 64
15:32:32.713485 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1355, seq 1, length 64
15:32:32.727133 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 6062, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1357, seq 1, length 64
15:32:32.733938 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6250, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1357, seq 1, length 64
15:32:33.750175 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18030, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1359, seq 1, length 64
15:32:33.757022 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 36416, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1359, seq 1, length 64
15:32:33.771809 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42437, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1361, seq 1, length 64
15:32:33.777647 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1361, seq 1, length 64
15:32:33.792337 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 6268, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1363, seq 1, length 64
15:32:33.799560 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6321, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1363, seq 1, length 64
15:32:34.812496 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18044, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1365, seq 1, length 64
15:32:34.818791 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 8547, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1365, seq 1, length 64
15:32:34.830134 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42752, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1367, seq 1, length 64
15:32:34.836103 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1367, seq 1, length 64
15:32:34.851798 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 6451, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1369, seq 1, length 64
15:32:34.858361 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6541, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1369, seq 1, length 64
15:32:35.870646 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18180, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 1.1.1.1: ICMP echo request, id 1371, seq 1, length 64
15:32:35.877068 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 57, id 54945, offset 0, flags [none], proto ICMP (1), length 84)
    1.1.1.1 > 192.168.69.60: ICMP echo reply, id 1371, seq 1, length 64
15:32:35.889857 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 42974, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 8.8.8.8: ICMP echo request, id 1373, seq 1, length 64
15:32:35.895693 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 117, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 192.168.69.60: ICMP echo reply, id 1373, seq 1, length 64
15:32:35.909544 94:83:c4:bb:17:1f > 64:62:66:21:c8:40, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 6750, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.69.60 > 208.67.222.222: ICMP echo request, id 1375, seq 1, length 64
15:32:35.916390 64:62:66:21:c8:40 > 94:83:c4:bb:17:1f, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 6563, offset 0, flags [none], proto ICMP (1), length 84)
    208.67.222.222 > 192.168.69.60: ICMP echo reply, id 1375, seq 1, length 64
1 Like
2

I'm more than happy if they would add a toggle for that, not everyone wants to use goodcloud or online availability checking.

I know that pinging looks like very innocent but when I was a teenager I was able to extremely slow down a site, because you also have latency creating amplification, this is cloudflare however... but if cloudflare decides it is malicious you will experience also alot of blocking like on alot of vpns.

From java developement I always made time outs for atleast a few minutes to ping again, I don't see the point to always want to ping real time :slight_smile:, their routers had this issue also when multi wan was added.

3

Unless you can convince our product manager not to display the network status (LED), there needs to be a consistent method to detect network connectivity, which in this product is achieved through PING.

4

@minmie

No need to be condescending.

Every other embedded device I have on my network does not need to use ICMP ping floods to determine network connectivity and certainly not by flooding public DNS servers with ICMP requests.

Seems like there are significantly better methods to make a determination an Ethernet cable is connected and network is active, all of which will provide an indication a physical Ethernet cable is connected to the device.

cat /sys/class/net/eth0/operstate
up

cat /sys/class/net/eth0/carrier
1

ifconfig eth0
ip addr show eth0

ethtool eth0

Settings for eth0:
	Supported ports: [ TP AUI BNC MII FIBRE ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supported pause frame use: Symmetric Receive-only
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised pause frame use: No
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	                                     1000baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 1000Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 1
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: ug
	Wake-on: d
	Current message level: 0x0000003f (63)
			       drv probe link timer ifdown ifup
	Link detected: yes
1 Like
5

Many things require checking whether the network is accessible, not just whether a network cable is plugged in. For example, the PIKVM program needs to repeatedly check your public IP to ensure that NAT traversal doesn't fail due to router re-dialing. I'm not talking down to you—I'm just telling you this isn't my decision. I also find it inelegant, but the problem is, I'm not the decision-maker.

6

Or perhaps you actually want me to shut up, which is also fine.

7

@minmie

Thanks for the explanation.

Seems like if I disable cloud access, the GLKVM no longer needs to ICMP ping flood public DNS servers, and any other periodic checks. I can access the GLKVM via Tailscale, even without the Tailscale client running on the GLKVM since I have Tailscale running on my firewall and advertising sub-net routes.

The only thing the GLKVM possibly may need to do is check for firmware updates, but even that can be action driven, i.e. when the user clicks on firmware button.

The GLKVM is a great device for a homelab, but with the questionable traffic it would never be allowed in a business or corporate setting as it would be considered a security risk. Perhaps the product manager and designers might take that into consideration when making design/implementation decisions.

For now, I will have to create a firewall rule to block all outbound traffic from the GLKVM and manually disable the rule to periodically check for firmware updates, or download the firmware and perform a local upgrade.

Screenshot 2025-10-21 at 6.07.03 AM
Screenshot 2025-10-21 at 6.07.03 AM2286Ă—118 15.7 KB

8

Not at all. Just trying to help make things better.

I found the GitHub repo. I can submit issues there if you think it will help.

9

BACKGROUND

Bug report

Even with cloud server access disabled, GLKVM continuously sends ICMP PING requests to public DNS servers, and at an excessively high rate.

Screenshot 2025-10-26 at 8.58.50 AM
Screenshot 2025-10-26 at 8.58.50 AM1102Ă—494 18.3 KB

WHY IS THIS IMPORTANT?

  1. The default behavior is bombarding public DNS servers with ICMP requests.
  2. Even if you have a rule to redirect outbound DNS requests to an internal DNS server, the outbound ICMP requests will sill bombard public DNS servers, which may result in your IP getting blocked
  3. The default behavior results in unnecessary additional network traffic.

HOW TO MITIGATE THE PROBLEM

Unfortunately, the version of IPTABLES included in GLKVM does not support rate limiting.

  1. Create a S10block_icmp.sh file with the following IPTABLES rule to block ICMP requests in the /etc/kvmd/user/scripts folder
#! /bin/sh

iptables -A OUTPUT -p icmp --icmp-type echo-request -j DROP
  1. Make sure the file has execute permissions

chmod a+x S10block_icmp.sh

  1. reboot

reboot

END RESULT

The end result is GLKVM will no longer bombard public DNS servers with ICMP requests.

OBJECTIVE EVIDENCE

You can see the IPTABLES rule is blocking all outbound ICMP requests. This does not affect ICMP ping requests sent to GLKVM

iptables -L -v

Chain INPUT (policy ACCEPT 23109 packets, 9430K bytes)pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 16257 packets, 15M bytes)pkts bytes target     prot opt in     out     source               destination5141  432K DROP       icmp --  any    any     anywhere             anywhere             icmp echo-request
10

As my colleague mentioned earlier, this ping request is used to check whether the network assigned to the KVM device is available. If you need to disable it, the status of the LED light will no longer be associated with the device's network status. The method to disable it is as follows:

 /etc/init.d/S23led stop
11

@_zhang

Do you really need to bombard public DNS servers 10’s of times per second to make a determination what color to make the LED?

12

The reason for such frequent detection is to respond to the device network status more quickly. If the detection cycle is extended, users will report that our LED light status is not accurate enough. There have been such examples on the router side. We are also very embarrassed about this issue.

13

@_zhang

Let’s assume for the moment you need to send pings 10’s of time a second for the LED status to be accurate.

Does it have to be public DNS servers? Why can’t it be the configured gateway?

Screenshot 2025-10-28 at 3.03.17 AM
Screenshot 2025-10-28 at 3.03.17 AM888Ă—980 40.9 KB

I have several embedded devices (cameras mostly) on my network which have cloud access, which only ping the LAN side gateway for connectivity status.

05:41:28.111739 IP 192.168.69.75 > 192.168.69.5: ICMP echo request, id 0, seq 0, length 64
05:41:28.111819 IP 192.168.69.5 > 192.168.69.75: ICMP echo reply, id 0, seq 0, length 64
05:41:30.535155 IP 192.168.69.76 > 192.168.69.5: ICMP echo request, id 0, seq 0, length 64
05:41:30.535227 IP 192.168.69.5 > 192.168.69.76: ICMP echo reply, id 0, seq 0, length 64

Most enterprise class firewalls ping the WAN side gateway for network monitoring, which is 1 hop. Sending pings to public DNS servers is multiple hops over the internet, which is polluting the internet with unnecessary traffic.

05:38:32.869925 IP 69.111.XXX.XX > 69.111.180.1: ICMP echo request, id 29799, seq 14651, length 9
05:38:32.871164 IP 69.111.180.1 > 69.111.XXX.XX: ICMP echo reply, id 29799, seq 14651, length 9
05:38:37.871387 IP 69.111.XXX.XX > 69.111.180.1: ICMP echo request, id 29799, seq 14652, length 9
05:38:37.872602 IP 69.111.180.1 > 69.111.XXX.XX: ICMP echo reply, id 29799, seq 14652, length 9
05:38:42.871663 IP 69.111.XXX.XX > 69.111.180.1: ICMP echo request, id 29799, seq 14653, length 9
05:38:42.872845 IP 69.111.180.1 > 69.111.XXX.XX: ICMP echo reply, id 29799, seq 14653, length 9
05:38:47.875247 IP 69.111.XXX.XX > 69.111.180.1: ICMP echo request, id 29799, seq 14654, length 9
05:38:47.876373 IP 69.111.180.1 > 69.111.XXX.XX: ICMP echo reply, id 29799, seq 14654, length 9

Continuously sending pings over the internet—especially at high frequency or volume—can be problematic for several reasons:

:globe_with_meridians: 1. Network Congestion and Bandwidth Waste

  • Each ping sends a small packet of data, but when done repeatedly, it can add up and consume unnecessary bandwidth.

  • On shared or limited networks, this can degrade performance for other users or applications How-To Geek.

:brain: 2. Increased Latency and Ping Spikes

  • Ironically, excessive pinging can cause the very issue it's meant to diagnose: higher latency.

  • It can overload routers or network interfaces, leading to inconsistent response times or dropped packets conscioushacker.io Tech News Today.

:locked_with_key: 3. Security and Abuse Concerns

  • Continuous pinging can resemble a Denial of Service (DoS) attack, especially if directed at a single server or IP.

  • Some firewalls or intrusion detection systems may flag or block such behavior as malicious.

:battery: 4. Device and Power Drain

  • On mobile or battery-powered devices, constant network activity can drain power faster.

  • It also keeps network interfaces active, which may reduce device lifespan over time.

:hammer_and_wrench: 5. Misleading Diagnostics

  • Overuse of ping can mask real issues. For example, if you're flooding the network with pings, you might create artificial congestion that skews your test results.

In short, while ping is a useful diagnostic tool, it should be used sparingly and responsibly. If you're trying to monitor connectivity, consider using smarter tools like traceroute, pathping, or dedicated network monitoring software that samples more efficiently.