Multicast through firewall

[Jeff Horton]

I am getting the log below:

Deny udp src outside:192.168.20.11/21002 dst identity:239.224.20.7/1007 by access-group "outside_access_in" 

The systems (192.168.20.11) sits on the outside port of the firewall and does the streaming to 239.224.20.7/1007.. In my ACL i allow the 192.168.20.0/24 and the 239.224.20.0/24 into the firewall to be accessed by our 192.168.200.0/24 and 192.168.2.0/24 networks.

I have a pim rp-address of an outside pim router that also has an access-list associated with it. This access-list allows 239.224.20.0/24 into the router.

I am assuming my ACL is incomplete and not sure why..Shouldn't my inside system requesting to join 239.224.20.0/24 feeds, pull the feeds from the outside? Or does that feed need to have access to the switch/router on the inside for the it to push the multicast through the firewall? 

My work around right now is to allow any any through.. The is a standalone network so it has no internet access.. I will upload the firewall configuration also. Just note that I have done a lot of additional objects that will later allow me to lock down the firewall more. 

Currently there is only one system on the outside of the firewall that will supply multicast streams but eventually we will have multiple systems with different subnets...

[Upgrading_To_CheckPoint!]

I would also include an acl to allow the pim protcol, (attached), place it above your allow udp rule.

[Jeff Horton]

Did that but no help... Still getting the denies...

[Jeff Horton · Accepted solution]

I think I just figured this out... Since the 192.168.20.11 system needs to communicate with the multicast address of 239.224.20.* on the inside of the firewall, I added the multicast subnet to the destination of the outside ACL and the denies are gone.. Weird thing is that I have done this before and never had to do that.... Anyone with a good explanation of this? I was under the assumption that the request for the multicast would be to join the outside multicast address so that is why the 239.224.20.0/24 is allowed into the network.

[Upgrading_To_CheckPoint!]

post the complete output of

packet-tracer input outside udp 192.168.20.11 12345 239.224.20.7 1007 det

[Jeff Horton]

I have removed the solution I had just to see what your packet-tracer finds..

[Jeff Horton]

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaadfffa0f0, priority=1, domain=permit, deny=false
hits=1682, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=outside, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.3.1.1 using egress ifc outside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.3.1.1 using egress ifc outside

Phase: 4
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaae01b1b10, priority=11, domain=permit, deny=true
hits=1488, user_data=0x6, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[Jeff Horton]

Here is the packet-tracer where I put the multicast subnet in the outside ACL..

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaadfff9e30, priority=1, domain=permit, deny=false
hits=134954, user_data=0x0, cs_id=0x0, l3_type=0x8
src mac=0000.0000.0000, mask=0000.0000.0000
dst mac=0000.0000.0000, mask=0100.0000.0000
input_ifc=outside, output_ifc=any

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.3.1.1 using egress ifc outside

Phase: 3
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.3.1.1 using egress ifc outside

Phase: 4
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside_access_in in interface outside
access-list outside_access_in extended permit ip object-group DM_INLINE_NETWORK_4 object-group DM_INLINE_NETWORK_3
object-group network DM_INLINE_NETWORK_4
network-object 192.168.20.0 255.255.255.0
network-object 239.224.20.0 255.255.255.0
network-object object pim_ip
object-group network DM_INLINE_NETWORK_3
network-object 192.168.2.0 255.255.255.0
network-object 192.168.200.0 255.255.255.0
network-object 239.224.20.0 255.255.255.0
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaadfa1bfe0, priority=13, domain=permit, deny=false
hits=1, user_data=0x2aaad42af040, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=any
dst ip/id=239.224.20.0, mask=255.255.255.0, port=0, tag=any, dscp=0x0
input_ifc=outside, output_ifc=any

Phase: 5
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaadece3d90, priority=0, domain=nat-per-session, deny=true
hits=127, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=any, output_ifc=any

Phase: 6
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in id=0x2aaae0002230, priority=0, domain=inspect-ip-options, deny=true
hits=3, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any
dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0
input_ifc=outside, output_ifc=any

Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (security-failed) Early security checks failed

[Upgrading_To_CheckPoint!]

The implicit deny rule at the is picking up the traffic before your matching udp traffic does. In the order of things,

show access-list outside_access_in

the last rule line # should be the implicit 'outside_access_in line # deny ip any any'

and your udp/pim matching traffic rule should come before it. example:

access-list outside_access_in line 100 extended permit udp .....
access-list outside_access_in line 101 extended deny ip any any log

not the other way around.

the extend permit IP workaround is likely above the implicit deny rule line number if that's working.

[Jeff Horton]

I totally understand what your saying but I only use the global deny any any on the ASA 5508-X. If you look into the config file I attached on my original post, you will see the following:
access-list outside_access_in extended permit ip object-group DM_INLINE_NETWORK_4 object-group DM_INLINE_NETWORK_3
access-list inside_access_in extended permit ip object-group DM_INLINE_NETWORK_6 object-group DM_INLINE_NETWORK_5

The DM's are just groups that the firewall itself creates when having multiple objects in the ACL..
So far I have done some test with adding the multicast address subnet as a destination for the outside ACL.. I also removed the multicast from the source as I have found that it is not needed....