This is really bugging me, so I’m hoping someone can help me out here.
I have a Wowza server that sits behind a proxy server I do not control.
When I try to stream from that server through the ESA HD player (which has worked for a long time before this proxy came into play) it won’t stream. In looking at the logs, the proxy’s ip address is what’s showing up. On the firewall sitting between the Wowza server and the proxy it looks like all responses are going back to the proxy IP. I can access the Wowza server (in a non-production setting) directly through the firewall and it works, so I know my Wowza configuration is good.
This is streaming VOD and MP3 audio files, nothing live, all over RTMPT (I know there’s a perf hit here, other reasons for this).
I have web servers that sit behind that same proxy, and I don’t have that issue. I have a load balancing engine in front of my web servers and it effectively uses the X-Forwarded-For header mechanism to make sure the web servers know who they’re talking to, and it all works fine.
What am I missing here? I don’t have a ton of experience working with proxies, and like I say I don’t control the one production will ultimately be behind, but is there something I should be having the proxy provider do (like an X-Forwarded-For setting or something similar) to make sure Wowza’s getting the actual client IP and can respond properly?
I do not have proxy configuration experience, and this is not directly a Wowza issue, but maybe this problem has to do with with how you are handling load balancing and that RTMPT uses port 80…
Sorry that I’m not able to help more with this issue. I don’t see the comment you refer to, but Charlie’s comment is probably still true unless you find more recent info from him.
I recognize it’s not a Wowza issue per se, just seeing if anyone else has experience doing this as everything else I have going across port 80 was working fine, just not the Wowza rtmpt traffic.
The proxy provider seems to have figured out what their proxy was doing and streaming has started working, albeit with some performance issues we’re working through.
What IS a Wowza issue (at least to me) is a question that seems to have been asked several times but not adequately answered (that I can find) regarding the proxy IP and logging. In an Apache context, mod_rpaf can take the X-Forwarded-For header and strip out the proxy IP so you get visibility to your actual client. I’ve been unable to find a way to do this for Wowza, and I saw in another post Charlie comment that the rtmtp headers aren’t exposed or available? Is that the case?
More and more proxying is being done to protect against DDoS attacks and utilize this technology in corporate settings and training extranets, and not being to track actual users is a problem.
We’re noticing some really odd performance behavior from behind this proxy, and I’m trying to turn over every rock in my attempt to determine the issue. I think I know the answer to this question, but since I can’t explicitly find anything in the User Guide or on the forum thus far, I thought I’d ask.
Does Wowza, by default, do any sort of connection rate limiting? The proxy admin figured out what was causing the traffic to not be forwarded, and now it is, but it is taking forever to connect and start loading media files. I’ve setup the bwchecker, and when we go through the proxy to our test app, it gets a consistent 30K/s w/100ms response. When I go straight to my firewall, I get much, much higher numbers 2M+ fairly consistently, w/response in the 75-200ms range, and when going straight to firewall videos begin playing almost right away.
I’m not seeing anything in the error logs that throws me a clue. The proxy admin says he’s not rate limiting anything to this host, but something, somewhere along the way is doing it, and I’ve got to find out if Wowza has any of that ability.