Info on Multicast

• 224.0.0.0/4 - Multicast IP Range
  • 224.0.0.0/24 - Link Local multicast
    • 224.0.0.13 PIMv2
    • 224.0.0.18 VRRP
    • 224.0.0.22 IGMPv3
  • 224.0.1.0/24 - Reserved for specific applications
  • 232.0.0.0/8 - Source Specific Multicast (SSM)
  • 239.0.0.0/8 - Administratively Scoped, equivalent to RFC1918

When picking a multicast address for labbing, use range 239.0.0.0/8 as that is assigned by RFC 2365 for private use within an organisation.

A good multicast testing tool is here.

Multicast traffic will only be visible in the traffic logs if you tick “Multicast Firewalling” on the Virtual Wire options. The source and destination zones are the vwire source and destination zone. (i.e. it doesn't use the 'multicast' zone). If you don't tick “Multicast Firewalling”, multicast traffic will still flow through the Vwire but there will be no logs.

This is where VLAN interfaces are used to insert the firewall into a single subnet where we can't change the endpoint IP addresses but we can cause the traffic to flow through the firewalls.

• Multicast does work through VLAN insertion.
• The Multicast traffic (while passing through the firewall) does not generate any traffic logs.
• I did a packet capture. There are four stages to PCAP on Palo
  • drop stage is where packets get discarded. The reasons may vary and, for this part, the global counters may help identify if the drop was due to a policy deny, a detected threat, or something else.
  • receive stage captures the packets as they ingress the firewall before they go into the firewall engine. When NAT is configured, these packets will be pre-NAT.
  • transmit stage captures packets how they egress out of the firewall engine. If NAT is configured, these will be post-NAT.
  • firewall stage captures packets in the firewall stage.
• I noticed that I didn’t get anything in the ‘firewall’ filter but I did get captures in drop, receive and transmit.
• I saw that I got four packets in receive, four in drop and twelve in transmit.
• In my lab I had four interfaces in the VLAN insertion. My assumption is that the twelve transmit packets were the four packets received being forwarded on from the receiving interface to the other three interfaces.

However

You can enforce Multicast traffic rules.

• Select a free IP address on the subnet being segmented.
• Create a blank virtual router.
• Create a Layer3 security zone.
• Create a VLAN Interface (Network > Interfaces > VLAN). Set the VLAN to be the same VLAN that the Layer2 interfaces are assigned to. Set the Virtual Router you just created. Select the layer 3 security zone you created.
• Create a security policy that allows the Layer3 security zone to the “multicast” zone (drop down list in destination zone in security policy rule).
• On the new virtual router in the Multicast settings configure
  • Enable - True
  • RP Type - Static
  • RP Interface - <VLAN Interface>
  • RP Address - <IP of VLAN Interface>
  • Group List - IP of Multicast Group. You may have to list many Multicast Groups.
• Commit.

Check that the multicast traffic is now appearing in the logs. If you want to block it, you can create a rule from the Layer3 zone to the multicast zone on that port and block the traffic.

• show routing multicast fib
• show routing multicast route source 234.5.6.7
• show routing multicast igmp membership interface vlan.11
• show routing multicast route virtual-router vr1

This page covers getting multicast working between a VLC streamer and a VLC player that are on separate Layer-3 VLANs connected to a Palo Alto Networks firewall.

The server is a Windows desktop that have VLC 3.0.11 installed and is streaming an MP4 video file over multicast.

The client is a Windows desktop that has VLC 3.0.11 installed and is using that to stream the MP4 video from multicast stream. In this example, we will use the following setup.

multicast address 239.1.2.3 Server subnet 10.5.5.0/24 Server default gateway (firewall interface) 10.5.5.1 Server IP address 10.5.5.5 Server Zone sz-server Client subnet 10.4.4.0/24 Client default gateway (firewall interface) 10.4.4.1 Client IP address 10.4.4.4 Client zone sz-client

1. On the server Windows Desktop, launch VLC media player
2. Click Media → Stream. This opens a pop-up window “Open Media”.
3. Click File → and click 'Add', locate the video file and click Open.
4. Click Stream. This opens “Stream Output” pop-up window.
5. Click Next
6. If you want the transmitter to show the video on its screen while transmitting, tick “Display locally”
7. Set New destination to RTP / MPEG Transport Stream and then click Add.
8. You will be prompted for an Address, Base port and Stream name.
9. Set the address to a multicast IP (e.g. 239.1.2.3) and base port (VLC default is 5004 but this can be set to anything). The Stream name is optional.
10. Click Next
11. Ensure “Activate Transcoding” is ticket, set profile to something (e.g. Video - H.264 + MP3 (MP4) and hten click Next.
12. Untick “Stream all elementary streams”.
13. THIS IS VERY IMPORTANTYou will need to update the “Generated stream output” string. YOu will need to find the rtp section (e.g. rtp{dst=239.1.2.3,port=5004,mux=ts,sap,name=mystream}) and then add ',ttl=3' (e.g. rtp{dst=237.0.0.1,port=5004,mux=ts,sap,name=mystream,ttl=3}). The reason for this is that VLC sets TTL to 1 by default. This prevents the packets from exiting the subnet they are broadcast in.

Click Stream.

1. On the client Windows Desktop, launch VLC media player
2. Media→ Open Network Stream…
3. This will open “Open Media” to the “Network” tab.
4. Set the network URL to

   rtp://239.1.2.3:5004

5. (edit IP and port to match what you set on the transmitter).
6. Click “Play”.

At this point, the player probably won't show anything because the firewall isn't configured.

Remember, the destination zone should be selected from the built-in drop down list. It is a predefined secure zone, not a zone that can be created by the firewall administrator.

On the firewall, edit the virtual router and configuration multicast

1. Click the multicast tab
2. Tick 'enable'
3. Set the local rendezvous point to 'None'
4. Set a remote rendezvous point. The IP should be the IP of the VLC server (e.g. 10.5.5.5). The Group should be the multicast IP you set on the server (e.g. 239.1.2.3) or it could be a subnet that contains that multicast IP (e.g. 239.0.0.0/8). If you choose a subnet, you will be able to pick up on any other multicast streams from that server IP without having to explicitly list them.
5. Create an interface group that that includes the interface for the server zone and the client zone.
6. you can leave group permissions blank.
7. Ensure that IGMP version is set to 2 or 3.
8. Ensure PIM is enabled.

Commit the changes and the client in the client zone should now get the stream of data from server in the server zone.

Remember, it is critical that VLC be edited before streaming to increase the TTL above 1. A TTL above 1 means the packet will not leave the subnet.

A better multicast testing tool is here.

Sometimes you will want the client to be further way than an adjacent subnet. Supposing the client subnet was connected to one firewall, the server subnet was connected to another firewall and the two firewalls have a link to each other. In this case, you set up everything the same on both firewalls except for the following.

1. On the client firewall, the remote rendezvous point IP is the nearest IP of the server firewall.
2. On the server firewall, you configure a local rendezvous point that is on the interface/IP of the interface nearest the client firewall and you include the multicast group IP or a subnet that contains the multicast group IP.