Packet Logged by every vm

Tinyblargon

Active Member
Jun 28, 2018
4
0
41
28
Over the last couple of weeks i've seen weird behaviour where the virtual switch inside proxmox acts like a hub. For a few packets it acts like a hub, sending the packet to every vm/container.

Network settings of 192.168.178.120
virtio=FE:B1:5F:22:B2:07,bridge=vmbr0,firewall=1

Firewall log
Code:
110 4 tap110i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr110i0 OUT=fwbr110i0 PHYSIN=fwln110i0 PHYSOUT=tap110i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
112 4 tap112i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr112i0 OUT=fwbr112i0 PHYSIN=fwln112i0 PHYSOUT=tap112i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
140 4 veth140i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr140i0 OUT=fwbr140i0 PHYSIN=fwln140i0 PHYSOUT=veth140i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
131 4 tap131i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr131i0 OUT=fwbr131i0 PHYSIN=fwln131i0 PHYSOUT=tap131i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
130 4 tap130i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr130i0 OUT=fwbr130i0 PHYSIN=fwln130i0 PHYSOUT=tap130i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
119 4 tap119i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr119i0 OUT=fwbr119i0 PHYSIN=fwln119i0 PHYSOUT=tap119i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
118 4 tap118i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr118i0 OUT=fwbr118i0 PHYSIN=fwln118i0 PHYSOUT=tap118i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
109 4 veth109i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr109i0 OUT=fwbr109i0 PHYSIN=fwln109i0 PHYSOUT=veth109i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
108 4 veth108i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr108i0 OUT=fwbr108i0 PHYSIN=fwln108i0 PHYSOUT=veth108i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
105 4 tap105i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr105i0 OUT=fwbr105i0 PHYSIN=fwln105i0 PHYSOUT=tap105i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
103 4 tap103i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr103i0 OUT=fwbr103i0 PHYSIN=fwln103i0 PHYSOUT=tap103i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
102 4 tap102i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr102i0 OUT=fwbr102i0 PHYSIN=fwln102i0 PHYSOUT=tap102i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
111 4 tap111i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr111i0 OUT=fwbr111i0 PHYSIN=fwln111i0 PHYSOUT=tap111i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
107 4 tap107i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr107i0 OUT=fwbr107i0 PHYSIN=fwln107i0 PHYSOUT=tap107i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN
101 4 tap101i0-IN 24/Apr/2019:21:06:44 +0200 DROP: IN=fwbr101i0 OUT=fwbr101i0 PHYSIN=fwln101i0 PHYSOUT=tap101i0 MAC=fe:b1:5f:22:b2:07:38:d5:47:e2:bd:50:08:00 SRC=217.21.193.20 DST=192.168.178.120 LEN=44 TOS=0x00 PREC=0x00 TTL=33 ID=10665 PROTO=TCP SPT=39835 DPT=443 SEQ=4106500480 ACK=0 WINDOW=1024 SYN

Any tips on how to further investigate this odd situation?
 
Last edited:
virtual switch can only works as an hub, it the mac address is not listened yet by the switch. (unicast, bum flood). (Note that it's the same with a real switch too).

Generally, you have first the arp request from a client, then when arp reponse come from the server, the switch listen the mac address of the server.

Or in the reverse way, if a server try to contact is gateway, the switch listen the mac address source of the server, when the server is sending is arp request.


Do you see this few packets flood sequence only once for a specific destination mac address ?
 
The Packet flooding happens for every VM that is public facing, port forwarded through the router.
but weirdly enough i'm not able to reproduce it. but it seems like it is happening more and more.
 
The Packet flooding happens for every VM that is public facing, port forwarded through the router.
but weirdly enough i'm not able to reproduce it. but it seems like it is happening more and more.

also this is strange than you have a public ip src, try to join a private destination ip.

SRC=217.21.193.20 DST=192.168.178.120

do you have a network schema with your router, proxmox nodes, vms with ips (private/public) and routing tables.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!