cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1388
Views
0
Helpful
15
Replies

does anyone have a working 9.x igmp stub multicast configuration?

James Leinweber
Enthusiast
Enthusiast

In ASA 8.2 in single-context routed mode I had multicast stub forwarding working with

    igmp forward interface outside

on relevant inside interfaces with public-scoped IP addresses (no NAT), plus access rules on the outside interface such as

   access-list outside-in extended permit udp any 239.0.0.0 255.0.0.0

After upgrading to 9.0(2), this isn't working anymore.  If I place a host on the transit network upstream of a firewall multicast works there, so I'm confidient that the upstream router (not managed by me) is doing PIM with the actual in-AS rendevous point correctly.  I don't particularly want any PIM, just IGMP forwarding on the firewall to the upstream router.  I've tried both with PIM and without; by default the ASA pim priority tends to cause ti to win the DR election with the upstream router, which is counter-productive, as it has to lose for any traffic to flow.

Packet captures on the outside interface with IGMP and without PIM such as:

   access-list mc extended permit igmp any4 any4

   access-list mc extended permit udp any4 239.0.0.0 255.0.0.0

   capture xx access-list mc interface outside

show that when an inside client tries to join a multicast AV stream the firewall sends igmp join message to the upstream router as expected, and UDP data starts flowing down as expected.  However, in spite of having permit rules on the outside interface to let the UDP streams in, I'm instead logging messages like:

    %ASA-7-710005: UDP request discarded from 128.104.128.182/3078 to outside:239.1.1.78/3078

and the inside clients which sent the igmp joins in the first place do not get any traffic.

Have I overlooked something?   Do I need an "igmp access-group ...." command on the interfaces to allow the joins?  Should there be an "access-group .... control-plane" rule to allow in the UDP traffic?   I've tried several variations, and so far nothing has worked for me.

Does anyone have a working multicast configuration for UDP data on ASA 9.0 or 9.1?   I'm trying to receive IP TV channels via a "vfurnace" client on windows 7.  As I said, this works upstream of the ASA firewalls, but not downstream.

The 9.1 documentation in the CLI firewall configuration guide, book 2 page 6-5 has the rather alarming statement that:

   "In routed firewall mode, broadcast and multicast traffic is blocked even if you allow it in an access rule ..."

which is a little worrying.  I realize that such traffic is inherently link-local in scope, but was hoping that enabling "multicast-routing" would result in some kind of forwarding behavior when it hit an interface which was a multicast group member.

-- Jim Leinweber, WI State Lab of Hygiene

15 Replies 15

Julio Carvajal
Advisor
Advisor

Hello James,

Well I have not played with that on that version but I would like to see some outputs from both the ASA and the Upstream router,

From the ASA

sh igmp groups detail

sh igmp interface nameif

cap asp type asp-drop all circular-buffer

Then send some multicast traffic

show cap asp | include 239.x.x.x (Multicast group IP address)

show run interface

show mfib

Then we will go further (it should be working by the way)

Regards

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

The topology is

  (AS 59 with RP ) -- router @ 144.92.136.113 -- | ASA 5525-x firewall running 9.0(2) |

On the firewall we have

     144.92.136.116/29 = aa-out interface  --  wc-pubtest interface 144.92.248.25/29 -- client win7 laptop @ 144.92.248.26/29

The multicast group we're trying to join is 239.1.1.78.

show igmp groups detail before launching the client (excerpted to remove irrelevant interfaces)

...

Interface:    wc-pubtest

Group:        239.255.255.250

Uptime:        00:15:09

Router mode:    EXCLUDE (Expires: 00:02:54)

Host mode:    INCLUDE

Last reporter:    144.92.248.26

Source list is empty

...

show igmp interface (excerpts)

...

aa-out is up, line protocol is up

  Internet address is 144.92.136.116/29

  IGMP is disabled on interface

...

wc-pubtest is up, line protocol is up

  Internet address is 144.92.248.25/29

  IGMP is enabled on interface

  Current IGMP version is 2

  IGMP query interval is 125 seconds

  IGMP querier timeout is 255 seconds

  IGMP max query response time is 10 seconds

  Last member query response interval is 1 seconds

  Inbound IGMP access group is:

  IGMP limit is 500, currently active joins: 0

  Cumulative IGMP activity: 1 joins, 1 leaves

  IGMP forwarding on interface aa-out

  IGMP querying router is 144.92.248.25 (this system)

...

After connecting to http://datn.wisc.edu and launching the vfurnace client from http://vfurnace.discovery.wisc.edu, and requesting a stream for CNN (239.1.1.78 inside AS59):

sho igmp groups detail

...

Interface:    wc-pubtest

Group:        239.1.1.78

Uptime:        00:00:44

Router mode:    EXCLUDE (Expires: 00:04:12)

Host mode:    INCLUDE

Last reporter:    144.92.248.26

Source list is empty

Interface:    wc-pubtest

Group:        239.40.31.100

Uptime:        00:01:20

Router mode:    EXCLUDE (Expires: 00:04:18)

Host mode:    INCLUDE

Last reporter:    144.92.248.26

Source list is empty

Interface:    wc-pubtest

Group:        239.255.255.250

Uptime:        00:17:54

Router mode:    EXCLUDE (Expires: 00:02:13)

Host mode:    INCLUDE

Last reporter:    144.92.248.26

Source list is empty

sho igmp interface

...

f-slh-aa# sho igmp interface wc-pubtest

wc-pubtest is up, line protocol is up

  Internet address is 144.92.248.25/29

  IGMP is enabled on interface

  Current IGMP version is 2

  IGMP query interval is 125 seconds

  IGMP querier timeout is 255 seconds

  IGMP max query response time is 10 seconds

  Last member query response interval is 1 seconds

  Inbound IGMP access group is:

  IGMP limit is 500, currently active joins: 3

  Cumulative IGMP activity: 4 joins, 1 leaves

  IGMP forwarding on interface aa-out

  IGMP querying router is 144.92.248.25 (this system)

f-slh-aa# sho igmp interface aa-out   

aa-out is up, line protocol is up

  Internet address is 144.92.136.116/29

  IGMP is disabled on interface

Doing:

  cap asp typ asp-drop all circular-buffer

running the client, and then:

  sho cap asp | include 239.1.1.78

produced no output.

sho run interface (excerpted)

interface GigabitEthernet0/0

description uplink - ag+wc to DoIT vlan 427 via MUFN

nameif aa-out

security-level 0

ip address 144.92.136.116 255.255.255.248

ipv6 address 2607:f388:0:2006::2/64

ipv6 nd suppress-ra

no pim

interface GigabitEthernet0/3.434

description wc-pubtest, public test clients, multicast, v6

vlan 434

nameif wc-pubtest

security-level 2

ip address 144.92.248.25 255.255.255.248

ipv6 address 2607:f388:1084:2080::1/64

ipv6 address fe80::2080:1 link-local

no pim

igmp forward interface aa-out

sho mfib

f-slh-aa# sho mfib

Entry Flags: C - Directly Connected, S - Signal, IA - Inherit A flag,

             AR - Activity Required, K - Keepalive

Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kbits per second

Other counts: Total/RPF failed/Other drops

Interface Flags: A - Accept, F - Forward, NS - Negate Signalling

             IC - Internal Copy, NP - Not platform switched

             SP - Signal Present

Interface Counts: FS Pkt Count/PS Pkt Count

(*,224.0.1.1) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(132.246.1.4,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 13/0/13

   aa-out Flags: A

(132.246.2.33,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 30/0/30

   aa-out Flags: A NS

(132.246.127.1,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 29/0/29

   aa-out Flags: A

(134.207.12.226,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 10/0/10

   aa-out Flags: A

(134.207.18.226,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 10/0/10

   aa-out Flags: A

(134.207.250.3,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 10/0/10

   aa-out Flags: A

(134.207.254.226,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 10/0/10

   aa-out Flags: A

(136.165.237.66,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 7892/0/7892

   aa-out Flags: A

(138.18.23.35,224.0.1.1) Flags: K

   Forwarding: 0/0/0/0, Other: 10/0/10

   aa-out Flags: A

(*,224.0.1.24) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,224.0.1.55) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,228.5.6.7) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,229.111.112.12) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,232.0.0.0/8) Flags: K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,239.1.1.78) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(128.104.128.182,239.1.1.78) Flags: K

   Forwarding: 0/0/0/0, Other: 14324/0/14324

   aa-out Flags: A

(*,239.40.31.100) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(128.104.153.215,239.40.31.100) Flags: K

   Forwarding: 0/0/0/0, Other: 1683/0/1683

   aa-out Flags: A

(*,239.77.124.213) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,239.192.83.80) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

(*,239.255.255.250) Flags: S K

   Forwarding: 0/0/0/0, Other: 325808/325808/0

(144.92.88.133,239.255.255.250) Flags: K

   Forwarding: 0/0/0/0, Other: 59024/0/59024

   aa-out Flags: A

(*,239.255.255.254) Flags: S K

   Forwarding: 0/0/0/0, Other: 0/0/0

Meanwhile, on the syslog server, I'm logging:

1) no relevant blocks for the client IP 144.92.248.26

2) lots of above cited UDP discards while the multicast client is running and the IGMP join is active, but no other messages involving 239.1.1.78

Thanks for looking into this with me,

-- Jim Leinweber, WI State Lab of Hygiene

Hello James,

Have u enabled multicast routing?

If yes can you disable pim on the interface as that will be enabled by default

Regards

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Yes, I have enabled multicast routing:

   f-slh-aa# sho run | i multicast-r

   multicast-routing

I have PIM off on all interfaces, and igmp forwarding on on 3:

f-slh-aa# sho run | incl ^interface|pim|igmp

interface GigabitEthernet0/0

no pim

interface GigabitEthernet0/1

no pim

igmp forward interface aa-out

interface GigabitEthernet0/2

no pim

no igmp

interface GigabitEthernet0/3

interface GigabitEthernet0/3.428

no pim

igmp forward interface aa-out

interface GigabitEthernet0/3.430

no pim

no igmp

interface GigabitEthernet0/3.431

no pim

no igmp

interface GigabitEthernet0/3.432

no pim

no igmp

interface GigabitEthernet0/3.433

no pim

no igmp

interface GigabitEthernet0/3.434

no pim

igmp forward interface aa-out

interface GigabitEthernet0/3.435

no pim

no igmp

interface GigabitEthernet0/3.436

no pim

no igmp

interface GigabitEthernet0/3.543

no pim

no igmp

interface GigabitEthernet0/3.544

no pim

no igmp

interface GigabitEthernet0/3.545

no pim

no igmp

interface GigabitEthernet0/4

interface GigabitEthernet0/5

interface GigabitEthernet0/6

interface GigabitEthernet0/7

interface Management0/0

Interfaces 4-7 are currently shutdown; Management0/0 has no ip and no nameif and is destined to be used to manage the software IPS module later on.

The IGMP forwarding is working, I think; when I ran captures on the outside interface (Gi0/0 namif "aa-out") I could see the IGMP joins going up to the router, and the UDP multicast data stream coming back down.   What I can't yet figure out is how to get the UDP data to flow across the firewall to the client.

Let me know if I need to open a TAC on this.

-- Jim Leinweber, WI State Lab of Hygiene

Hello James,

All you need to do is to have the right ACL on the outside interface,

Interesting enough you capture nothing on the ASP capture,

Can you enable 3 captures

cap capout ( matching multicast traffic on the outside interface)

cap capin ( matching multicast traffic on the inside interface )

cap asp type asp-drop all circular buffer

Generate the traffic and show the captures,

Let's see what happens,

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

We progress.   After:

    access-list mc extended permit igmp any4 any4

    access-list mc extended permit udp any4 239.1.0.0 255.255.0.0

    cap capin access-list mc interface wc-pubtest circular-buffer

    cap capout access-list mc interface aa-out circular-buffer

    cap asp type asp-drop all circular-buffer

sho cap capin produces the expected IGMP joins going up from the client (*.26), and membership queries coming down from the wc-pubtest interface on the firewall (*.25):

   1: 19:48:49.333143       802.1Q vlan#434 P0 144.92.248.25 > 224.0.0.1:  ip-proto-2, length 8

   2: 19:48:50.210423       802.1Q vlan#434 P0 144.92.248.26 > 239.40.31.100:  ip-proto-2, length 8

   3: 19:48:51.718834       802.1Q vlan#434 P0 144.92.248.26 > 239.255.255.250:  ip-proto-2, length 8

   4: 19:48:53.714181       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.252:  ip-proto-2, length 8

   5: 19:49:08.597610       802.1Q vlan#434 P0 144.92.248.26 > 239.1.1.78:  ip-proto-2, length 8

   6: 19:49:18.082377       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.2:  ip-proto-2, length 8

   7: 19:49:18.082515       802.1Q vlan#434 P0 144.92.248.25 > 239.40.31.100:  ip-proto-2, length 8

   8: 19:49:18.514225       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.2:  ip-proto-2, length 8

   9: 19:49:18.514331       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

  10: 19:49:19.336972       802.1Q vlan#434 P0 144.92.248.25 > 239.40.31.100:  ip-proto-2, length 8

  11: 19:49:19.837008       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

  12: 19:50:54.349225       802.1Q vlan#434 P0 144.92.248.25 > 224.0.0.1:  ip-proto-2, length 8

  13: 19:50:54.716027       802.1Q vlan#434 P0 144.92.248.26 > 239.255.255.250:  ip-proto-2, length 8

  14: 19:51:02.724053       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.252:  ip-proto-2, length 8

  15: 19:52:59.365276       802.1Q vlan#434 P0 144.92.248.25 > 224.0.0.1:  ip-proto-2, length 8

  16: 19:52:59.722527       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.252:  ip-proto-2, length 8

  17: 19:53:00.221012       802.1Q vlan#434 P0 144.92.248.26 > 239.255.255.250:  ip-proto-2, length 8

sho cap capout shows IGMP group membership queries from the upstream router and the multicast data stream:

   1: 19:49:19.069927       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   2: 19:49:19.072948       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   3: 19:49:19.075664       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   4: 19:49:19.078654       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   5: 19:49:19.081126       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   6: 19:49:19.084697       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   7: 19:49:19.085063       144.92.136.113 > 239.40.31.100:  ip-proto-2, length 8

   8: 19:49:19.086924       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   9: 19:49:19.089625       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

  10: 19:49:19.092341       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

...

116: 19:49:19.516300       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

117: 19:49:19.519229       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

118: 19:49:19.521289       144.92.136.113 > 239.1.1.78:  ip-proto-2, length 8

119: 19:49:19.522189       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

120: 19:49:19.524844       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

...

377: 19:49:20.521350       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

378: 19:49:20.524493       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

379: 19:49:20.526828       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

380: 19:49:20.588851       144.92.136.113 > 239.1.1.78:  ip-proto-2, length 8

...

The asp capture is much noisier, because there are about 300 other users and 900 other devices sending traffic between various interfaces on this firewall.   It is, of course, getting stuff:

f-slh-aa(config)# sho cap asp

7749 packets captured

   1: 19:53:27.462744       802.1Q vlan#428 P0 10.0.0.11.1900 > 239.255.255.250.1900:  udp 282

   2: 19:53:27.643658       802.3 encap packet

   3: 19:53:27.664455       144.92.155.140.137 > 144.92.155.255.137:  udp 50

   4: 19:53:27.664501       144.92.155.140.137 > 144.92.155.255.137:  udp 50

   5: 19:53:27.869156       802.1Q vlan#543 P0 10.1.1.100.137 > 144.92.155.50.137:  udp 50

   6: 19:53:27.998773       802.1Q vlan#428 P0 144.92.86.130.17500 > 255.255.255.255.17500:  udp 123

   7: 19:53:27.999154       802.1Q vlan#428 P0 144.92.86.130.17500 > 144.92.87.255.17500:  udp 123

   8: 19:53:28.056561       144.92.155.172.49732 > 239.255.255.250.1900:  udp 133

   9: 19:53:28.066128       802.3 encap packet

  10: 19:53:28.100382       802.1Q vlan#428 P0 10.0.0.11.1900 > 239.255.255.250.1900:  udp 291

...

After a few rounds of experiments, I was able to pull out this before the buffer wrapped and overwrote it:

sho cap asp det | i 128.104.128

...

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4696)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4742)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4838)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4878)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4926)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 4974)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 5019)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 5061)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 5110)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 5213)

      128.104.128.182.3078 > 239.1.1.78.3078:  [no cksum] udp 1316 (ttl 60, id 5256)

...

I haven't tested the upstream data from the transit network to see if the lack of UDP checksum is also seen by, say, wireshark.

Opinions or suggestions or interpretations?

-- Jim Leinweber, WI State Lab of Hygiene

Hello James,

Well, lets download the captures on the outside interface of the ASA and check the checksum,

Now, what happens if you send and ICMP ping packet from the source IP address (128.x.x.x),

Can you capture those traffic, and see if it works,

If it works then the multicast enviroment is good,

The problem would be with the application sending those invalid UDP packets for the ASA,

Remember to rate all of the helpful posts

Julio Carvajal

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

I ran some wireshark captures on the upstream transit network and  verified that the multicast stream has null UDP checksums.  Other UDP  traffic such as DNS queries has correct checksums (after disabling tx/rx  checksum offload in the OS ethernet driver and enabling checksums in  wireshark). 

Is there any way to use class maps / policies to ignore UDP checksums for a specific access list?

-- Jim Leinweber, WI State Lab of Hygiene

Hello James,

I would say there is no command for that,

So in this case the behavior is expected, that's why it would be a good idea to use the ICMP multicast traffic,

Let me know if that one works

Regards

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

Hello James,

Is there any other question u have on this?

Otherwise u can mark the question as answered.

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

A couple more things:

1) ICMP payloads are illegal for IPv4 multicast (some link-local IPv6 payloads are legal, e.g. RS/RA & NS/NA), so using those for testing isn't feasible.  Using iperf or something to generate UDP streams could be feasible.

2) After perusing sundry RFC's, null UDP checksums are legal for IPv4, although not particularly encouraged.  Since the default tcp-map policy of ASA 9.0 is to not validate TCP checksums I'm inferring that probably UDP checksums aren't being validated by default either.    The inference is that in the "sho capture asp" output above with the "[no cksum]" annotation, the asp drop reason is not  due to the lack of checksum.

3) Launching the multicast client to provoke IGMP group memberships and then running packet-tracer gives me a drop reason I don't understand:

-------

packet-tracer input aa-out udp 128.104.20.20 3078 239.1.1.78 3078 detail

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7fff383e55a0, priority=1, domain=permit, deny=false

    hits=2101222525, 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=aa-out, output_ifc=any

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group AA-OUT-INGRESS-06 in interface aa-out

access-list AA-OUT-INGRESS-06 extended permit udp any object-group MCAST-IANA

access-list AA-OUT-INGRESS-06 remark - EPA access to RadNet station

object-group network MCAST-IANA

description: multicast ranges in use by IANA: 224, 232 ssm, 233 glop, 239 admin

network-object 239.0.0.0 255.0.0.0

network-object 224.0.0.0 255.0.0.0

network-object 232.0.0.0 254.0.0.0

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7fff38baaa70, priority=13, domain=permit, deny=false

    hits=3169, user_data=0x7fff30cbe900, cs_id=0x0, use_real_addr, flags=0x0, protocol=17

    src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0

    dst ip/id=239.0.0.0, mask=255.0.0.0, port=0, tag=0 dscp=0x0

    input_ifc=aa-out, output_ifc=any

Phase: 3

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7fff378685f0, priority=0, domain=nat-per-session, deny=true

    hits=88780704, 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=0

    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

    input_ifc=any, output_ifc=any

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0x7fff383edaa0, priority=0, domain=inspect-ip-options, deny=true

    hits=30041880, 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=0

    dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0

    input_ifc=aa-out, output_ifc=any

Result:

input-interface: aa-out

input-status: up

input-line-status: up

Action: drop

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

----------

It's looking more like the ASA is failing to identify the output interface, in spite of:

   show igmp groups | include 239.1

yielding:

  239.1.1.78       wc-pubtest           00:00:25  00:04:16  144.92.248.26

which seems completely correct (right group number, right output interface, right downstream client IP).

Any idea how to get more information about that mysteriously failed "early security check"?   The syslog message for the drop is tagged "%ASA-7-710005: UDP request discarded" which is equally mysterious to me.  The description of #7100005 in the error message catalog was not enlightening on this point.

-- Jim Leinweber, WI State Lab of Hygiene

The drop on the packet tracer is expected

CSCua70248

Can u try with the ICMP packets, it's still a valid point for troubleshooting, at least try it.

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC

I believe you about the packet-tracer drop being expected, but can't access the CSCua70248 URL you linked to, even when already logged into cisco.com.

For an ICMP experiment I put a laptop running nmap on our transit network upstream of our 5525-x firewall, and had a windows 7 client downstream on one of our multicast-enabled subnets.   On the downstream client I launched the vfurnace client and connected to our CNN multicast stream; the firewall showed the expected 239.1.1.78 group joins, continued blocking the UDP multimedia stream traffic (the problem we're trying to solve), etc. as previously described.

On the laptop (ubuntu 12.04) I ran sudo nmap -sP --max-retries 40 239.1.1.78

The results were about as expected:

   a) wireshark on the laptop showed the ICMP packets (echo-request, timestamp) going out

   b) no ICMP packets came back from the firewall, which is the expected & correct behavior

   c) no ICMP packets were delivered through the firewall to the inside client, which was also running wireshark

   d) no ICMP drop messages were logged by the firewall related to either the sending unicast IP or the receiving multicast IP

   e) three misconfigured hosts listening to the same multicast group elsewhere at the UW-Madison responded with echo-reply or timestamp reply packets to the ICMP requests to the multicast group

   f) the nmap probe from the laptop included a few tcp syn and ack packets to the multicast group; the firewall logged blocking them

I'm still stumped about how to get the UDP multicast traffic through the firewall to the client.

-- Jim Leinweber, WI State Lab of Hygiene

Did u saw the packets reaching the outside interface and going out the inside interface?

Not sure I get that,

Regards

Remember to rate all of the helpful posts.

For this community that's as important as a thanks.

Julio Carvajal
Senior Network Security and Core Specialist
CCIE #42930, 2xCCNP, JNCIP-SEC
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers