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

[James Leinweber]

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

[James Leinweber]

The topology looks like this:

For test purposes, the laptop on the wc-pubtest subnet had its vfurnace multicast video client join the 239.1.1.78 group.

Then the desktop on the aa-out subnet ran sudo nmap -sP 239.1.1.78

Meanwhile on the firewall, we were running:

      access-list mc extended permit ip any4 239.1.0.0 255.255.0.0

      capture capup access-list mc interface aa-out

      capture capdown access-list mc interface wc-pubtest

      capture asp type asp-drop all

The firewall interfaces look like:

interface GigabitEthernet0/0

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

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 address 2607:f388:0:2006::4/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

On the downlink interface wc-pubtest we get only the IGMP traffic for joining the group:

f-slh-aa# sho cap capdown

4 packets captured

   1: 16:01:16.183553       802.1Q vlan#434 P0 144.92.248.26 > 239.1.1.78:  ip-proto-2, length 8

   2: 16:02:02.409799       802.1Q vlan#434 P0 144.92.248.26 > 239.1.1.78:  ip-proto-2, length 8

   3: 16:03:18.109354       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

   4: 16:03:19.241106       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

On the uplink interface aa-out we get an IGMP join going up from the firewall, followed by UDP data coming down:

f-slh-aa# sho cap capup

382 packets captured

   1: 16:01:16.183706       144.92.136.116 > 239.1.1.78:  ip-proto-2, length 8

   2: 16:01:17.324781       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   3: 16:01:17.326078       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

   4: 16:01:17.327207       128.104.128.182.3078 > 239.1.1.78.3078:  udp 1316

...

The first capture doesn't show the ICMP probes from the desktop.

Repeating the experiment with different captures:

access-list t7 extended permit ip host 144.92.136.118 any4

access-list t7 extended permit ip any4 host 144.92.136.118

access-list t7 extended permit icmp host 144.92.136.118 any4

f-slh-aa(config)# sho cap

capture capup type raw-data access-list t7 interface aa-out [Capturing - 2176 bytes]

capture capdown type raw-data interface wc-pubtest [Capturing - 2322 bytes]

capture asp type asp-drop all headers-only [Capturing - 518539 bytes]

Gets us: nmap TCP packets being correctly dropped by the firewall:

f-slh-aa(config)# sho cap asp | i 144.92.136.118

1625: 16:44:56.078822       144.92.136.118.51171 > 239.1.1.78.443: S 1871815673:1871815673(0) win 1024

1626: 16:44:56.078838       144.92.136.118.51171 > 239.1.1.78.80: . ack 1871815673 win 3072

2023: 16:44:58.080867       144.92.136.118.51172 > 239.1.1.78.80: . ack 1871750136 win 3072

2024: 16:44:58.080882       144.92.136.118.51172 > 239.1.1.78.443: S 1871750136:1871750136(0) win 4096

4164: 16:45:09.096674       144.92.136.118.39406 > 239.1.1.78.443: S 4133838991:4133838991(0) win 1024

4165: 16:45:09.096705       144.92.136.118.39406 > 239.1.1.78.80: . ack 4133838991 win 2048

4557: 16:45:11.098704       144.92.136.118.39407 > 239.1.1.78.80: . ack 4133773454 win 1024

4558: 16:45:11.098719       144.92.136.118.39407 > 239.1.1.78.443: S 4133773454:4133773454(0) win 2048

ICMP and TCP packets arriving at the outside interface with the multicast group destination:

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

32 packets captured

   1: 16:44:30.040509       144.92.136.118 > 239.1.1.78: icmp: echo request

   2: 16:44:30.040555       144.92.136.118.50802 > 239.1.1.78.443: S 4243417927:4243417927(0) win 2048

   3: 16:44:30.040586       144.92.136.118.50802 > 239.1.1.78.80: . ack 4243417927 win 2048

   4: 16:44:30.040601       144.92.136.118 > 239.1.1.78: icmp: time stamp query id 21368 seq 0

   5: 16:44:32.042524       144.92.136.118 > 239.1.1.78: icmp: time stamp query id 56567 seq 0

   6: 16:44:32.042539       144.92.136.118.50803 > 239.1.1.78.80: . ack 4243352390 win 4096

   7: 16:44:32.042569       144.92.136.118.50803 > 239.1.1.78.443: S 4243352390:4243352390(0) win 1024

   8: 16:44:32.042585       144.92.136.118 > 239.1.1.78: icmp: echo request

   9: 16:44:43.060803       144.92.136.118 > 239.1.1.78: icmp: echo request

  10: 16:44:43.060848       144.92.136.118.63922 > 239.1.1.78.443: S 3849553901:3849553901(0) win 3072

  11: 16:44:43.060879       144.92.136.118.63922 > 239.1.1.78.80: . ack 3849553901 win 2048

  12: 16:44:43.060894       144.92.136.118 > 239.1.1.78: icmp: time stamp query id 18441 seq 0

  13: 16:44:45.062908       144.92.136.118 > 239.1.1.78: icmp: time stamp query id 19906 seq 0

  14: 16:44:45.062923       144.92.136.118.63923 > 239.1.1.78.80: . ack 3849488364 win 3072

  15: 16:44:45.062939       144.92.136.118.63923 > 239.1.1.78.443: S 3849488364:3849488364(0) win 1024

  16: 16:44:45.062954       144.92.136.118 > 239.1.1.78: icmp: echo request

  17: 16:44:56.078746       144.92.136.118 > 239.1.1.78: icmp: echo request

...

But neither ICMP nor UDP multicast getting through the firewall to the wc-pubtest client:

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

18 packets captured

   1: 16:45:07.565186       802.1Q vlan#434 P0 arp who-has 144.92.248.25 tell 144.92.248.26

   2: 16:45:07.565217       802.1Q vlan#434 P0 arp reply 144.92.248.25 is-at e0:2f:6d:bb:ea:6a

   3: 16:45:07.565858       802.1Q vlan#434 P0 144.92.248.26.62363 > 128.104.153.215.4902:  udp 128

   4: 16:45:07.566712       802.1Q vlan#434 P0 128.104.153.215.4902 > 144.92.248.26.62363:  udp 48

   5: 16:45:07.665203       802.1Q vlan#434 P0 144.92.248.26.62363 > 128.104.153.215.4902:  udp 48

   6: 16:45:07.665889       802.1Q vlan#434 P0 128.104.153.215.4902 > 144.92.248.26.62363:  udp 48

   7: 16:45:07.765249       802.1Q vlan#434 P0 144.92.248.26.62363 > 128.104.153.215.4902:  udp 32

   8: 16:45:07.766073       802.1Q vlan#434 P0 128.104.153.215.4902 > 144.92.248.26.62363:  udp 48

   9: 16:45:10.887222       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.2:  ip-proto-2, length 8

  10: 16:45:10.887359       802.1Q vlan#434 P0 144.92.248.25 > 239.40.31.100:  ip-proto-2, length 8

  11: 16:45:11.287308       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.2:  ip-proto-2, length 8

  12: 16:45:11.287399       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

  13: 16:45:12.064266       802.1Q vlan#434 P0 144.92.248.25 > 239.40.31.100:  ip-proto-2, length 8

  14: 16:45:12.564301       802.1Q vlan#434 P0 144.92.248.25 > 239.1.1.78:  ip-proto-2, length 8

  15: 16:45:32.946911       802.1Q vlan#434 P0 fe80::2080:1 > ff02::1: icmp6: router advertisement [class 0xe0]

  16: 16:45:41.818088       802.1Q vlan#434 P0 144.92.248.25 > 224.0.0.1:  ip-proto-2, length 8

  17: 16:45:46.454825       802.1Q vlan#434 P0 144.92.248.26 > 239.255.255.250:  ip-proto-2, length 8

  18: 16:45:50.951229       802.1Q vlan#434 P0 144.92.248.26 > 224.0.0.252:  ip-proto-2, length 8

18 packets shown

To recap:

(1) the IGMP joins are working; the client sends a join on the wc-pubtest subnet, the firewall picks it up, and forwards it out the aa-out interface to the upstream UW-Madison router.  UDP data comes back down and arrives at the firewall.  When the client sends an IGMP remove or stops responding to membership queries, the firewall leaves the group and the UDP data stops flowing, as expected and desired and correctly.

(2) nmap probes from the aa-out transit subnet to the firewall on the aa-out subnet are received by the firewall.  The illegal TCP multicast traffic correctly logs drops in both asp and syslog.  The illegal ICMP multicast traffic silently vanishes in the firewall, with no response packets sent (correct RFC behavior), but neither asp drops nor syslog messages (???).

(3) Nothing addressed to the multicast group gets through to the downstream client: not illegal ICMP, not illegal TCP, not legal multicast UDP.  Client initiated UDP traffic creates xlate entries and works; the firewall sends IGMP membership queries and gets responses.  The firewall logs ASP drop messages for the subscribed UDP multimedia multicast destination traffic, but the drop reason is mysterious.

-- Jim Leinweber, WI State Lab of Hygiene