11-04-2010 09:35 AM - edited 03-11-2019 12:05 PM
We have a site outside of our organization that delivers rtmp content. We are unable to view this content inside of our organization. The logs are showing the connection making but then immediately disconnects with a TCP reset from the outside (their side). At home, on satellite broadband, the vids do not play. However, on a different provider with low-latency, the vids play ok. Their player is jplayer, which I know can have certain issues with some flashvar. Is there anything I can look at or do to try to alleviate this problem on my side?
11-04-2010 11:21 AM
hi jcdod,
Just wondering if you are seeing any asp drops for the rtmp traffic which should traverse across http/https. Are you running any http inspections that may be not understanding the embedded rtmp traffic? Also, if you are receiving the tcp reset from the outside, i think a critical piece would be to find out from their side what errors are being received on the server as the server may be the one dropping the connection.
regards,
scott
11-05-2010 07:27 AM
RTMP is coming in over 1935 and both http and rtmp are connecting and then dropping (TCP reset O). It is the far side that is putting it back on me but they haven't provided any sort of info on what they are seeing. I will try to find out. I am not running any special inspections. If there is something I can try on this side, any advice would be considered. Thanks.
11-05-2010 09:39 AM
I think the best way to isolate this is to grab a capture on the outside. You can use the capture commands on the ASA. You can create an acl to limit only the traffic to/from the server. Once you have that, you can isolate the three way handshake and then see if any data is passed after that and if the reset is coming from the outside (which we believe so since you saw it on the logs). You can then take that info back to the server team to further investigate why the traffic is being reset. As for the rtmp, that is correct, the asa does not have any inspections for that. You can verify what inspections are running by doing: show service-policy
regards,
scott
11-05-2010 10:20 AM
I will get a capture on the outside interface. I am only running the default inspections.Thanks!
11-05-2010 10:39 AM
Great.. sounds good. let me know what you see.
thanks,
scott
11-15-2010 07:00 AM
I got the capture on the external interface. What the expert info is showing is "4 NOP's in a row" which wireshark says is a huge problem. I have no idea what they mean. I could really use some input, whether for my side or for the far side. The far side moved their content to a new media server but the issue is still exactly the same. Attached the capture.
11-15-2010 10:11 AM
Hi.. Well, the NOP looks like some options may have been cleared. Is this capture taken before it hits the ASA or right after going through the ASA?
thanks,
scott
11-15-2010 10:48 AM
I would say that this is arriving traffic. I am capturing the outside interface as the ingress. I have been looking into padding and options and it looks to me that those options are stripped already when they arrive....You know what? I have a transparent firewall running between that we are using for filtering (TrendMicro). However, even when I exempt their site in the filtering, it makes no difference. I will get a capture from it. I almost forgot about those guys.
11-15-2010 10:53 AM
Hi, yes, it could be another firewall that is stripping the options. You should take a capture before the other firewall to see which options are being cleared.
thanks,
scott
11-15-2010 11:02 AM
Here is the capture from the outside interface of the transparent ASAs. Looks like the stripping is happening at the transparent firewall. Any idea of what to do? I am running CSC on that ASA. I have tried exempting the ip in question in CSC with no change. Attaching the capture.
11-15-2010 11:10 AM
You can allow the options since they are being cleared.. please check this out:
http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpnorm.html
http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/t.html#wp1524493
thanks,
scott
11-15-2010 11:36 AM
Disabling CSC http scanning didn't affect the issue. I have to chuckle at the links you have sent me. This stuff is new to me and after reading the links, a bit over my head. I don't know how to proceed from here with these instructions. So, I do this on the transparent firewall? (the one that appears to be stripping options?) Can this be done in ASDM? How do I find the options that I have to allow? Now the real issue begins...my lacking level of expertise. What do you advise Scott?
11-15-2010 11:41 AM
hi Jcdod,
Yes, the csc is not the cause of this if the problem is indeed with the tcp options being cleared and the application requiring certain tcp options to be set, then you will have to allow them through. At this point, i would suggest opening up a case with tac for some assistance with the tcp options. The firewall you will want to focus on is the transparent firewall but also need to make sure that none of the other firewalls will be clearing options.
thanks,
scott
11-15-2010 11:47 AM
Sounds good. I will contact TAC. 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