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

James Leinweber · ‎06-10-2013

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

Julio Carvajal · ‎06-10-2013

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

James Leinweber · ‎06-11-2013

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

Julio Carvajal · ‎06-11-2013

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

James Leinweber · ‎06-11-2013

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

Julio Carvajal · ‎06-11-2013

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

James Leinweber · ‎06-11-2013

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

Julio Carvajal · ‎06-11-2013

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

James Leinweber · ‎06-13-2013

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

Julio Carvajal · ‎06-13-2013

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

Julio Carvajal · ‎06-14-2013

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

James Leinweber · ‎06-17-2013

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

Julio Carvajal · ‎06-17-2013

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

James Leinweber · ‎06-18-2013

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

Julio Carvajal · ‎06-18-2013

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

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