A rare use case on a Palo (at least from my point of view): Multicast Routing. And it can become as complex as you want. Fortunately, the basics are relatively easy to configure, at least if you have a rough understanding of multicast and routing with PIM and IGMP. (Recommended YouTube session here.) Let’s have a look at the common configuration steps on PAN-OS, the needed security policies to the special destination zone type of “multicast”, as well as some “show” outputs that can be used for troubleshooting:

The Lab

• My lab consists of 3x Cisco routers (2811, IOS Version 15.1(4)M12a) and 1x PA-440 “pa-lab” with PAN-OS 11.1.10-h1, ARE enabled, hence: logical routers.
• (Note that with PAN-OS 11.2 and ARE, multicast routing is not supported at all.)
• PIM-SM (sparse-mode) is used all over the lab. The rendezvous point (RP) is statically configured on R1’s loopback interface.
• Since Palo only supports legacy IP (IPv4) with multicast, IPv6 is not of interest in this setup. 😢
• A Raspberry Pi on the right-hand side offers a multicast stream at 239.23.11.10:1234. Accomplished by: ffmpeg -f lavfi -re -i "testsrc=size=640x360:rate=25:decimals=2" -c:v libx264 -f mpegts "udp://239.23.11.10:1234?pkt_size=1316".
• The Palo serves a client subnet directly (VLAN 51, client 1 aka receiver, IGMP), and is additionally connected to another “internal” router (R3, PIM), in which another receiver (client 2) resides.

The Config

The following screenshots provide an overview of the multicast settings needed for this kind of setup. Almost all settings were left at their defaults.

Special attention needs to be paid to the security policies:

• Allowing “pim” is only necessary if another router must communicate with the RP *through* the Palo, or if the Palo itself provides the RP. If the Palo is only terminating receivers (IGMP), there’s no PIM policy needed. (I’m not fully sure why, since for other routing protocols such as OSPF or BGP, those allow rules are a must. Yes, I’ve checked an explicit intrazone-deny rule as well. Still no hits.)
• IGMP must be allowed from the receiver’s zone to the special “multicast” destination zone. Of course, destination address objects can be used to further restrict the traffic.
• For the actual multicast traffic, in my case, a video stream on UDP port 1234, a policy has to allow this type of traffic from the multicast source (in my case: zone “transfer”) to the special “multicast” destination zone.

The Show

The following screenshots and CLI outputs were taken while both receivers were consuming the stream. (Using the VLC media player with udp://@239.23.11.10:1234.)

Session Browser during the stream: (the IGMP session was already gone)

Traffic Log *after* the receivers stopped consuming the stream:

Traffic Log for “pim”, in which router R3 contacted the RP:

Almost the same via the CLI show commands. One note, though: The show advanced-routing multicast pim state command is the only one that gives an output comparable to that from the Cisco world. E.g., only this one lists the Rendezvous Point for the (*,G) groups.

Finally, this is how R3 looked like during the session:

The End

Uff. ;) That’s it for now. Of course, you can configure other scenarios, such as setting the Rendezvous Point on the Palo itself or using filters for various settings. But not for me this time.

Soli Deo Gloria!

Photo by Jeanson Wong on Unsplash.