Replying back multicast packets into netIface

[michalgarcarz]

Hello Team,

Fenrir working nicely, doing MITM for my 802.1x session: Raspberry Pi connected as 802.1x supplicant to hostIface of Fenrir (and Fenrir itself is actually another Raspberry Pi).
I was troubelshooting why i see multiple sessions/mac addresses on my switch:

9200-1#show access-session interface g1/0/13
Interface                MAC Address    Method  Domain  Status Fg  Session ID
--------------------------------------------------------------------------------------------
Gi1/0/13                 000c.2985.ba94 N/A     UNKNOWN Unauth      078C3E0A00001CC9A9CE92B2
Gi1/0/13                 000c.29cf.a965 N/A     UNKNOWN Unauth      078C3E0A00001CC8A9CD1AAE
Gi1/0/13                 0050.56a5.0be8 N/A     UNKNOWN Unauth      078C3E0A00001CC5A9CA00B2
Gi1/0/13                 0050.56a5.1a64 N/A     UNKNOWN Unauth      078C3E0A00001CC3A9C9DFFE
Gi1/0/13                 0050.56a5.2a81 N/A     UNKNOWN Unauth      078C3E0A00001CD0A9D117D2
Gi1/0/13                 0050.56a5.2cbf N/A     UNKNOWN Unauth      078C3E0A00001CC4A9C9F2D2
Gi1/0/13                 0050.56a5.5f9d N/A     UNKNOWN Unauth      078C3E0A00001CC7A9CAAF46
Gi1/0/13                 0050.56a5.961b N/A     UNKNOWN Unauth      078C3E0A00001CC6A9CA9A86
Gi1/0/13                 c4b2.398a.fd0d N/A     UNKNOWN Unauth      078C3E0A00001CC1A9C9CC12
Gi1/0/13                 d037.456c.c044 dot1x   DATA    Auth        078C3E0A00001CC2A9C9DDF6

Those mac addresses starting with 0050* were VM hosts in my network sending multicast/broadcast traffic into netIface (net vlan). So my 802.1x should be able to receive that traffic but never respond with such source mac addresses. As a result switch should never try to build a session for such mac addresses on that port. Gig1/0/13 is having Fenrir connected with 802.1x Raspbery Pi behind - that is all. We should see only one 802.1x session, nothing more (just a bit more if Fenrir is leaking some traffic sometimes).

And found out that Fenrir is sending back more multicast traffic back.
First we do see traffic on netIface where multicast frames are received (from host 00:50:56:a5:0b:e8 which is VM machine in my network). Then i see my switch trying to send EAPOL frames for that mac, which suggest that some packets from that mac had to be received on this switchport:

root@rpi3:~# tcpdump -i eth1 -en ether host 00:50:56:a5:0b:e8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes

09:21:22.749884 00:50:56:a5:0b:e8 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 65: 10.62.140.133.60142 > 224.0.0.252.5355: UDP, length 23
09:21:22.856499 00:50:56:a5:0b:e8 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 65: 10.62.140.133.60142 > 224.0.0.252.5355: UDP, length 23
09:21:23.109878 00:50:56:a5:0b:e8 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 65: 10.62.140.133.60142 > 224.0.0.252.5355: UDP, length 23
09:21:52.140749 c4:b2:39:8a:fd:0d > 00:50:56:a5:0b:e8, ethertype EAPOL (0x888e), length 60: EAP packet (0) v3, len 5
09:21:52.319874 c4:b2:39:8a:fd:0d > 00:50:56:a5:0b:e8, ethertype EAPOL (0x888e), length 60: EAP packet (0) v3, len 5
09:22:22.141081 c4:b2:39:8a:fd:0d > 00:50:56:a5:0b:e8, ethertype EAPOL (0x888e), length 60: EAP packet (0) v3, len 5

Now when sniffing at the same time on hostIface of Fenrir i could confirm those multicast frames where never forwarded to my 802.1x supplicant:

root@rpi3:~# tcpdump -i eth2 -en ether host 00:50:56:a5:0b:e8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

Now looking closely at netIface again (eth1) i have found out that Fenrir is actually sending back those multicast frames via the same interface (sniffing only traffic sent out via netIface):

root@rpi3:~# tcpdump -i eth1 -en ether host 00:50:56:a5:0b:e8 --direction=out
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:34:00.059875 00:50:56:a5:0b:e8 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 66: 10.62.140.133.60860 > 224.0.0.252.5355: UDP, length 24
09:34:00.479876 00:50:56:a5:0b:e8 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 66: 10.62.140.133.60860 > 224.0.0.252.5355: UDP, length 24

So for me it looks like traffic which is not supported by Fenrir - in this case multicast traffic is send back via the same netIface (instead of being forwarded out via hostIface). Is that expected ?

Also - what would be your recommendation ? Would it be reasonable to use iptables and filter out incoming multicast traffic received on netIface ?

Update, my workaround (for testing) was to block multicast traffic via ACL on the switch (iptables on Fenrir did not work):

9200-1#sh ip access-lists DROP_MULTICAST
Extended IP access list DROP_MULTICAST
    10 deny ip any 224.0.0.0 15.255.255.255
    20 permit ip any any
9200-1#sh run int g1/0/13
Building configuration...

Current configuration : 641 bytes
!
interface GigabitEthernet1/0/13
 ip access-group DROP_MULTICAST out

Thanks,
Michal