Решено. Смотрите внизу сообщения: Обновил свою UXG-Lite до текущей Release Candidate (4.1.10), и с тех пор весь трафик, который приходит с узла, отличного от родной VLAN в моей сети, считается «недействительным». ((Неважно, идёт ли он в интернет или к другой VLAN))

Когда я откатываюсь обратно к 4.1.8 (которую он никогда не вызывал), проблема остается. Поэтому я не думаю, что это напрямую связано с текущей RC, но я не знаю, как это устранить.

Я также использую Network Application 9.0.114.

(Три хоста в приведенных ниже примерах – это один и тот же узел с тремя IP-адресами:)

root@UniFiNext-GenGatewayLite:~# tcpdump -i any icmp and host 192.168.25.121 -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
19:18:12.503158 eth0 In IP14 (invalid)
19:18:12.503158 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 5, length 64
19:18:12.508729 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 5, length 64
19:18:13.504567 eth0 In IP14 (invalid)
19:18:13.504567 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 6, length 64
19:18:13.509740 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 6, length 64
19:18:14.505934 eth0 In IP14 (invalid)
19:18:14.505934 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 7, length 64
19:18:14.510568 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 7, length 64
19:18:15.507785 eth0 In IP14 (invalid)
19:18:15.507785 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 8, length 64
19:18:15.513668 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 8, length 64

root@UniFiNext-GenGatewayLite:~# tcpdump -i any icmp and host 192.168.60.6 -nn
tcpdump: data link type LINUX_SLL2
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
19:33:17.917939 eth0 In IP14 (invalid)
19:33:17.917939 eth0.600 In IP 192.168.60.6 > 18.239.36.55: ICMP echo request, id 12, seq 1, length 64
19:33:17.922757 eth0.600 Out IP 18.239.36.55 > 192.168.60.6: ICMP echo reply, id 12, seq 1, length 64
19:33:13.504567 eth0 In IP14 (invalid)
19:33:13.504567 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 6, length 64
19:33:13.509740 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 6, length 64
19:33:14.505934 eth0 In IP14 (invalid)
19:33:14.505934 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 7, length 64
19:33:14.510568 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 7, length 64
19:33:15.507785 eth0 In IP14 (invalid)
19:33:15.507785 eth0.25 In IP 192.168.25.121 > 18.239.36.55: ICMP echo request, id 7, seq 8, length 64
19:33:15.513668 eth0.25 Out IP 18.239.36.55 > 192.168.25.121: ICMP echo reply, id 7, seq 8, length 64

Моя родная сеть: 192.168.1.0/24, мои VLAN (в примере): 192.168.25.0/24 и 192.168.60.0/29.

На практике, любой трафик, который считается недействительным (между моими VLAN), теперь блокируется брандмауэром.

Весь трафик начинается с неверной версии IP. (В примерах я вижу IPv14, но я также видел, как проходили другие версии IP. Контекст в том, что это IPv4. Мне пришлось поместить его в WireShark, чтобы я мог его интерпретировать. WireShark называет это недействительной версией IPv4) ((скриншот не из вышеуказанных пингов, а только для справки))

Редактировать: Для полноты: Я сбросил до заводских настроек (и снова добавил его в сеть) UXG-Lite и перезагрузил свои коммутаторы.

Редактировать2: После сброса до заводских настроек и повторного предоставления, проблема решена.