PIM Sparse mode through ASA

[StevieOliver_2]

Hi

I'm trying to get PIM SM working throug an ASA.  All works as expected on the side of the firewall where the source (IPTV Server) resides

but am getting nothing on the inside interface.  The traffic originated on a lower security interface.

I have the source connected to a 6500 on the lower security interface which also acts as the RP.

The 6500 on the inside points to the same RP on the lower security interface.

Multicast routing is enabled on the ASA and the relevant interfaces have PIM enabled with the ASA also pointing to the same RP.

I had this working in dense mode but wanted to change to sparse.  Are there any NAT/Access-list issues I may have overlooked on the ASA ?

I did see an issue where the firewall was complaining the the rpf route was not from a PIM neighbour but that was because the route back was via an HSRP address. I changed that to a physical address and that issue cleared.

The first test is to pick up a stream on group 239.255.255.255 which advertises available TV channels.  I never see the channel list on the inside stations.

Any help would be appreciated.

Thanks, Stephen.

[ian.vaughan]

Hello,

I always find multicast tricky and mix that with firewall rules and you double the trouble

Have you explicitly allowed the returning traffic through the ASA?

You can't get a stateful connection with multicast so you have to allow IGMP joins etc back through to the source or RP in your case.

Caught me out a couple of times in the past.

Hope that helps

Ian

[StevieOliver_2]

Ian

Thanks for the reply.

I have no IGMP rules in the firewall.  I have PIM running on the relevant interfaces.  My understanding is IGMP stops at the 1st router and the join is relayed in PIM messages.  I'm sure I have the relevant PIM rules in place.  In fact as a test I have allowed pim any any through both interfaces.

On the more secure side I do see the (*,G) entry and it is marked as being forwarded out the proper interface and incoming on the proper interface.

Likewise on the RP is see an entry for the 2 sources of the stream I need to get.

The firewall sees the (*,G) entry on the proper interface and forwards it on the proper interface.

If I do a packet capture on the incoming interface to see if the stream hits it I don't see anything.  Does a capture show packets even if the appliance would drop them ?  So is the fact I am not seeing them that they are not getting there or is it possible the appliance drops them and doesn't show them ?

Thanks, Stephen.

[ian.vaughan]

Hi Stephen,

The RP can more often than not just be a temporary step as the client host, once set up, finds a better path to the source and prunes the "longer" route via the RP.

Reading your posts again it seems like the 6500 that is configured as the RP is the shortest (only) route anyway so isn't going to get pruned. Just ignore me !

In short it sounds like the registration side of things is working but that you aren't getting any flow when it comes to the media.

Anyhoo - it sounds like you can't see packets getting dropped at the outside interface?

From the top of my head -  I don't think that you see packets against the implicit deny all so what I have done before is (temporarily) make my own explicit "deny any any" and add it at the end of the rule table for that interface. You can then investigate the packets dropped and some of thse should be the multicast stream that is trying to get through.

Furthermore if you go into the logging pane and look for your multicast IP address you should now see your stream getting dropped if there isn't an explicit rule to let it through.

Hope this helps

Ian

[StevieOliver_2]

The latest I have found is when I do a packet trace from the RP to the 239 group address the ASA drops it with the following error.

Drop-reason: (security-failed) Early security checks failed

The explanation for this doesn't help much

This counter is incremented and the packet is dropped when the security appliance:

•Receives an IPv4 multicast packet when the packet multicast MAC address does not match the packet multicast destination IP address

•Receives an IPv6 or IPv4 teardrop fragment containing either small offset or fragment overlapping

•Receives an IPv4 packet that matches an IP audit signature

Recommendation: Contact the remote peer administrator or escalate this issue according to your security policy. For detailed description and System log messages for IP audit attack checks please refer the ip audit signature command.

System log messages: 106020, 400xx in case of IP audit checks

Stephen

[mulhollandm]

stephen

apologies for jumping on your thread but i'm having the same problem - early security checks failed

did you ever get your issue resolved?

[Anu M Chacko]

Hi Stephen,

So your sender is on the outside and the receivers on the inside of the ASA, right? Do you have a static mroute pointing to the inside of the ASA?

Regards,

Anu.

[StevieOliver_2]

Can't quite remember the details of this.  It was a while ago.

If I remember correctly I simply

enabled multicast routing

defined a pim rp address globally

ensured pim was running on the relevant interfaces

configured the appropriate access lists and no nat rules to allow the multicast addresses I use through the firewall.

The source was on a DMZ interface and the receivers were on the dmz and inside.

Regards, Stephen.