search

opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.34k stars 749 forks source link

Wrong Multicast MAC addresses #3629

Closed poggenpower closed 5 years ago

poggenpower commented 5 years ago

Describe the bug On my main LAN interface Muticasts are send with the wrong MAC addresses: Here some examples. If traffic is originating from 192.168.2.248 the destination mac is wrong, if another host is sending to the same multicast address the MAC address is correct.

20:01:21.465412 00:0c:29:27:4d:46 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 64: 192.168.2.40.51545 > 224.0.0.252.5355: UDP, length 22
20:01:21.573753 00:0c:29:27:4d:46 > 01:00:5e:00:00:fc, ethertype IPv4 (0x0800), length 64: 192.168.2.40.51545 > 224.0.0.252.5355: UDP, length 22
20:01:31.647141 00:0d:b9:49:91:c4 > 01:00:5e:28:02:fc, ethertype IPv4 (0x0800), length 54: 192.168.2.248 > 224.0.0.22: igmp v3 report, 1 group record(s)
20:01:32.046465 00:0d:b9:49:91:c4 > 01:00:5e:28:02:fc, ethertype IPv4 (0x0800), length 54: 192.168.2.248 > 224.0.0.22: igmp v3 report, 1 group record(s)
37.038625 34:29:8f:92:07:bc > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 949: 192.168.2.61.5353 > 224.0.0.251.5353: 0 [33a] [4q] PTR (QM)? _services._dns-sd._udp.local. PTR (QM)? _http._tcp.local. PTR (QM)? _https._tcp.local. PTR (QM)? _airplay._tcp.local. (907)
19:48:37.074513 00:0c:29:4a:28:5d > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 192: 192.168.2.47.5353 > 224.0.0.251.5353: 0*- [0q] 3/0/0 (Cache flush) A 192.168.2.47, (Cache flush) TXT "path=/" "name=ubuntu1710.wupp", (Cache flush) SRV ubuntu1710.local.:8080 0 0 (150)
19:48:49.555900 00:0c:29:0c:40:7e > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 86: 192.168.2.230.5353 > 224.0.0.251.5353: 0 SRV (QM)? bunt-laser._ipp._tcp.local. (44)
19:48:49.559983 c8:cb:b8:5f:73:13 > 01:00:5e:00:00:fb, ethertype IPv4 (0x0800), length 165: 192.168.2.127.5353 > 224.0.0.251.5353: 0*- [0q] 1/0/3 (Cache flush) SRV bunt-laser.local.:631 0 0 (123)
19:48:58.718201 00:0d:b9:49:91:c4 > 01:00:5e:28:02:fc, ethertype IPv4 (0x0800), length 54: 192.168.2.248 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:48:58.929877 00:0d:b9:49:91:c4 > 01:00:5e:28:02:fc, ethertype IPv4 (0x0800), length 54: 192.168.2.248 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:49:05.393402 00:0d:b9:49:91:c4 > 01:00:5e:28:02:fc, ethertype IPv4 (0x0800), length 178: 192.168.2.248.5353 > 224.0.0.251.5353: 0 [4q] [1au] PTR (QU)? _companion-link._tcp.local. PTR (QU)? _homekit._tcp.local. PTR (QU)? _services._dns-sd._udp.local. PTR (QU)? _sleep-proxy._udp.local. (136)

Saw this behaviour for MDNS, IGMP and UPNP. In this interface regardless of the Multicast Group the MAC 01:00:5e:28:02:fc was not able to correlate to local MAC addresses.

To Reproduce Create a route though an internal interface, that e.g. is also part of the mdns-repeater config. This will introduce a rule like: pass out log route-to (igb0 192.168.2.252) inet from 192.168.2.248 to ! (igb0:network:1) flags S/SA keep state allow-opts label "let out anything from firewall host itself" which matches the multicast traffic and places the wrong MAC Address in the packets.

Expected behavior Traffic for e.g. 224.0.0.251 (MDNS) should be send to MAC 01:00:5e:00:00:fb but not 01:00:5e:28:02:fc same for other Multicast protocols.

Relevant log files See above.

Additional context I expect something similar to https://github.com/opnsense/core/issues/3468 but I am not sure how to do further test here. I am not using policy routing here, at least I am not aware of.

Environment OPNsense 19.1.10_1-amd64 FreeBSD 11.2-RELEASE-p10-HBSD OpenSSL 1.0.2s 28 May 2019 AMD GX-412TC SOC (4 cores)

Saw the same behaviour with older Release too.

poggenpower commented 5 years ago

if I disable pf ( pfctl -d ) the MAC addresses are seen as expected.

poggenpower commented 5 years ago

But I have no multi WAN Setup. But I have a route through this effected interface. Which generated a rule pass out log route-to (igb0 192.168.2.252) inet from 192.168.2.248 to ! (igb0:network) flags S/SA keep state allow-opts label "let out anything from firewall host itself" If I remove the route, the MAC addresses are correct. I think this rules needs an exception for the Multicast IP range.

poggenpower commented 5 years ago

Workaround is to disable: 

Disable force gateway | Disable automatic rules which force local services to use the assigned interface gateway.                                       Outgoing packets from this firewall on an interface  which has a gateway will normally use the specified gateway for that  interface. When this option is set the route will be selected by the  system routing table instead.

In my setup the OS routing table works fine, but in general Multicast Traffic should not be influenced by such routing features.

AdSchellevis commented 5 years ago

With https://github.com/opnsense/core/issues/3594 you can add egress rules to exclude certain outbound traffic on the interface (expected 19.7.3), in 19.1.x you should be able to do so using floating rules.

I don't expect we're going to increase logic on the automatic rules, since you can easily disable those and create your own more fine grained rules.

poggenpower commented 5 years ago

I understand that this will increase to complexity of automatic rule creation. But you should consider following. Not every user is so deep in Opnsense and pf, that he/she is aware of the impact of such rules created by adding routing entries. It took me ours to find out what the root cause is, because I oversaw the route-to (igb0 192.168.2.252) and was not ware of the impact. I think a few hints in the documentation/ui would help to find the root cause faster and make aware of this extra functionality.

Multicast is used for several things in modern networks. Admins should be able to handle this easily.

Thanks Thomas

AdSchellevis commented 5 years ago

Hi Thomas,

I agree it's the responsibility of the plugin, for example frr does add a rule for its requirements.

https://github.com/opnsense/plugins/blob/0ce2c7b268914a5b7df46bc1dde9c482b6498600/net/frr/src/etc/inc/plugins.inc.d/frr.inc#L50-L65

Ideally the plugin should either explain what it needs (documentation) and/or supports an option to generate the rules for you if needed (although personally I would rather see the option to disable the automatic rule).

As of 19.7, automatic rules can be shown in the filter, which helps debugging a lot. If the plugin author supports it, you can also point to the setting that influences a specific rule.

Policy based routing is indeed rather complex, always remember to look at the firewall rules first, they should (as of 19.7) show the gateway on automatic rules as well.

If you would like to improve our documentation on this point, that would be very welcome, you can find our GitHub repository here https://github.com/opnsense/docs

Since there's no work to be done in core, I'll close this issue now.

Best regards,

Ad