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?
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.
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.
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
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.
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?
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.
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.
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.
You can allow the options since they are being cleared.. please check this out:
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?
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.
After thinking about this, am I the only one that finds it irksome that Cisco ASA would clear well-known ip options by default? The 3 options getting cleared in this particular situation are not "unknown" options. They are common options. Am I missing something here?
By design, the asa defaults to clearing the tcp options as it goes through. You are able to allow it through without clearing it as long as you know which bits you need.
This doc (the one i sent earlier has the command needed to allow it.)
tcp-options range 9 255 clear
can modify to:
tcp-options range 50-52 allow
that will allow options 50-52 to be allowed and not cleared.
Of course, you need to set up the advanced options. I would still suggest opening a case for assistance on this.