Unexpected container traffic / What is this odd MAC address?

I

ichihaifu

New Member
Jul 27, 2020
7
0
1
32
I noticed this some time ago in PVE firewall logs, but could not find out why this is happening:

Code: 
110 6 veth110i0-IN 27/Jul/2020:13:30:15 +0300 policy DROP: IN=fwbr110i0 OUT=fwbr110i0 PHYSIN=fwln110i0 PHYSOUT=veth110i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=198 TOS=0x00 PREC=0x00 TTL=64 ID=18081 PROTO=UDP SPT=514 DPT=1514 LEN=178
112 6 veth112i0-IN 27/Jul/2020:13:30:15 +0300 policy DROP: IN=fwbr112i0 OUT=fwbr112i0 PHYSIN=fwln112i0 PHYSOUT=veth112i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=198 TOS=0x00 PREC=0x00 TTL=64 ID=18081 PROTO=UDP SPT=514 DPT=1514 LEN=178
110 6 veth110i0-IN 27/Jul/2020:13:30:16 +0300 policy DROP: IN=fwbr110i0 OUT=fwbr110i0 PHYSIN=fwln110i0 PHYSOUT=veth110i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=216 TOS=0x00 PREC=0x00 TTL=64 ID=36706 PROTO=UDP SPT=514 DPT=1514 LEN=196
112 6 veth112i0-IN 27/Jul/2020:13:30:16 +0300 policy DROP: IN=fwbr112i0 OUT=fwbr112i0 PHYSIN=fwln112i0 PHYSOUT=veth112i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=216 TOS=0x00 PREC=0x00 TTL=64 ID=36706 PROTO=UDP SPT=514 DPT=1514 LEN=196
110 6 veth110i0-IN 27/Jul/2020:13:30:17 +0300 policy DROP: IN=fwbr110i0 OUT=fwbr110i0 PHYSIN=fwln110i0 PHYSOUT=veth110i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=213 TOS=0x00 PREC=0x00 TTL=64 ID=61936 PROTO=UDP SPT=514 DPT=1514 LEN=193
112 6 veth112i0-IN 27/Jul/2020:13:30:17 +0300 policy DROP: IN=fwbr112i0 OUT=fwbr112i0 PHYSIN=fwln112i0 PHYSOUT=veth112i0 MAC=b6:1b:a4:22:f6:40:52:76:8a:96:1c:be:08:00 SRC=xxx.xxx.xxx.xxx DST=yyy.yyy.yyy.yyy LEN=213 TOS=0x00 PREC=0x00 TTL=64 ID=61936 PROTO=UDP SPT=514 DPT=1514 LEN=193

It is rsyslog traffic that I had set up to be sent to a particular container (#113), but it looks like containers 110 and 112 are also logging the said traffic (I assume others would too, if they had logging configured). What strikes me even more odd is the length of MAC address in the log, and I could not find that anywhere in the standard ip configurations or ip tables.

Is this normal?
 
Bump .. anyone?

Some details to maybe paint better image:
Snippet from /etc/network/interfaces
Bash: 
cat /etc/network/interfaces
# network interface settings; autogenerated

...

auto vmbr0
iface vmbr0 inet static
        address  <..>
        netmask  255.255.255.0
        gateway  192.168.1.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#VM LAN

I have a 'VM LAN' bridge where proxmox is also reachable in - All VM's and containers run in the same bridge, along with trusted LAN devices. This network is connected to pfSense VM which provides WAN via another bridge. That said VM is sending rsyslog data to log container in the VM LAN network, and the traffic is witnessed by all containers by the looks.
 
Based on just what you've posted, I'd say the "MAC" is actually the Ethernet Type II header for 52:76:8a:96:1c:be → b6:1b:a4:22:f6:40 IPv4, e.g., guest/VM with MAC 52:76:8a:96:1c:be is sending UDP/514 traffic to guest/VM with MAC b6:1b:a4:22:f6:40 at UDP/1514 and your other VMs "see" the traffic because it is a shared bridge, but drop it based on firewall policy. Hope that helps.
 
I meant shared bridge traffic; any other configurations that could be used to achieve similar functionality to described while not having this behavior.

But for now I've made a firewall rule group where I can match traffic types I don't want logged as a workaround, so I can keep logging enabled for other traffic.
 
ichihaifu said:
I meant shared bridge traffic; any other configurations that could be used to achieve similar functionality to described while not having this behavior.
Click to expand...

Well, as your bridge is already VLAN aware, you might be able to use VLANS to isolate the traffic (private VLAN), but a 1:1 ratio doesn't scale very well. You could also try the SDN (experimental) feature to achieve the same thing with VLAN Zones, but again wouldn't scale very well.
 
Bummer, but anyway thanks for the clarification!
Hopefully this information will be clarifying for others in future too :)
 
You must log in or register to reply here.
Top Bottom