06-10-2013 08:43 AM - edited 03-11-2019 06:55 PM
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
06-10-2013 01:24 PM
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
06-11-2013 09:53 AM
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
06-11-2013 10:05 AM
Hello James,
Have u enabled multicast routing?
If yes can you disable pim on the interface as that will be enabled by default
Regards
06-11-2013 10:20 AM
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
06-11-2013 11:45 AM
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,
06-11-2013 01:16 PM
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
06-11-2013 01:55 PM
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
06-13-2013 09:11 AM
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
06-13-2013 10:06 AM
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.
06-14-2013 08:56 AM
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.
06-17-2013 10:08 AM
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
06-17-2013 03:45 PM
The drop on the packet tracer is expected
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.
06-18-2013 09:25 AM
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
06-18-2013 01:36 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide