OK, I've googled my brains out on this. I think I know what the problem is, but I can't find the answer. Here is how things are laid out.
I have a static IP. I have an AirportExtreme with that Static IP assigned to it. The AE is doing the normal NAT/DHCP to the internal network. I have a Mac with a private static IP and QTSS (10.6.1 server) running on it. All the relevant ports in the AE are open.
THE GOAL - to be able to use QTSS to stream live events to the world using QTB both inside and outside the private network as needed.
On my private network I can use QuickTime Broadcaster (QTB) to send a live feed (Automatic Unicast) to the QTSS and I can "tune in" to that live feed on another Mac on the private network. All happy.
If I use QTB to send a feed to my QTSS, and I try to view that feed from outside the private network, QuickTime Player endlessly tries to connect. (I do have all the ports open, I even put the QTSS in the DMZ and the same results). In the log I can see the outside IP connecting to the QTSS so I know it's making it through the AE NAT mapping.
If I use QTB to try and send a feed to the QTSS from the outside I get a -3285 Disconnected error (again, I tried it in the DMZ same effect).
HERE IS WHAT I THINK IS HAPPENING.
I think QTSS is encapsulating the IP of the QTSS machine (a private IP) in the packets going back out to the client, which of course the client on the outside can't get to. I've seen Oracle do the same thing behind a router/firewall. Logs show the client can reach the server, but the returning packets have the IP of the server encapsulated as part of the data, not in the normal way they are when going through a NAT/router.
Can anyone verify this? Has anyone ever been able to successfully run a QTSS behind a NAT/router and have it behave as through it were on the public internet? I can do a manual unicast from the outside and watch it on the QTSS box so, again, that tells me it isn't an open port problem.
The closest thing I could come close it is tweaking this in the config file. <PREF NAME="alt_transport_src_ipaddr" >public.ip.goes.here</PREF> I've done that, but it makes no difference, unless it's a legacy setting from an older version of QTSS.
Email, web, iChat, FTP, every other service works fine from the outside. It's QTSS that is killing me. Thanks in advance.
I have a static IP. I have an AirportExtreme with that Static IP assigned to it. The AE is doing the normal NAT/DHCP to the internal network. I have a Mac with a private static IP and QTSS (10.6.1 server) running on it. All the relevant ports in the AE are open.
THE GOAL - to be able to use QTSS to stream live events to the world using QTB both inside and outside the private network as needed.
On my private network I can use QuickTime Broadcaster (QTB) to send a live feed (Automatic Unicast) to the QTSS and I can "tune in" to that live feed on another Mac on the private network. All happy.
If I use QTB to send a feed to my QTSS, and I try to view that feed from outside the private network, QuickTime Player endlessly tries to connect. (I do have all the ports open, I even put the QTSS in the DMZ and the same results). In the log I can see the outside IP connecting to the QTSS so I know it's making it through the AE NAT mapping.
If I use QTB to try and send a feed to the QTSS from the outside I get a -3285 Disconnected error (again, I tried it in the DMZ same effect).
HERE IS WHAT I THINK IS HAPPENING.
I think QTSS is encapsulating the IP of the QTSS machine (a private IP) in the packets going back out to the client, which of course the client on the outside can't get to. I've seen Oracle do the same thing behind a router/firewall. Logs show the client can reach the server, but the returning packets have the IP of the server encapsulated as part of the data, not in the normal way they are when going through a NAT/router.
Can anyone verify this? Has anyone ever been able to successfully run a QTSS behind a NAT/router and have it behave as through it were on the public internet? I can do a manual unicast from the outside and watch it on the QTSS box so, again, that tells me it isn't an open port problem.
The closest thing I could come close it is tweaking this in the config file. <PREF NAME="alt_transport_src_ipaddr" >public.ip.goes.here</PREF> I've done that, but it makes no difference, unless it's a legacy setting from an older version of QTSS.
Email, web, iChat, FTP, every other service works fine from the outside. It's QTSS that is killing me. Thanks in advance.
