Andrew Danson
2013-05-16 02:11:18 UTC
Hi Neil and others,
To get the client working from a private address using only firewall rules is a little tricky because of the way the client works with bridging.
When you first connect to a venue via a bridge the client makes contact with the bridge via TCP to it's main port to ask where to connect when setting up video and audio. The bridge then decides at run time where the RAT and VIC tools need to connect. (I'm not sure if this is statically defined, I suspect it's dynamic) The bridge tells the venue client where to connect and then the client sets up it's services accordingly.
Both VIC and RAT use UDP packets to send and receive data to and from the bridge. They each require two ports, one for the main data and another for the control data for the streams. As the ports are decided upon at run time by the bridge it is really hard to set up firewall rules for. I'd say that your firewall is having difficulties handling the UDP packets or is simply blocking them all together. You can even end up with the situation that you can get the UDP packets going in one direction only, this would result in either being able to see and hear but not transmit, or vice versa. Sometimes firewalls are set up to completely block UDP packets, as they are rarely needed for most common internet usage (most being via TCP and port 80)
So for a client to be able to connect to a bridge it needs to be able to talk to it via TCP to its main control port, and also be able to communicate via UDP (in both directions) on the four ports required for video and audio. The ports required for UDP vary, I was connected to a bridge today on port numbers in the ~30,000 - 31,000 range. It may depend on the bridge.
Whilst it is technically possible to set up firewall rules to accommodate running a client this way, I tend to agree with your network guys that it's not a elegant solution and is really hard to maintain. So I would suggest what I think David was suggesting. Run a bridge server of your own on a public address within your network, and then set up the firewall rules to allow machines behind the NAT firewall to communicate with it via UDP in both directions. The downside being the machine that is a bridge server pretty much must have multicast access to the internet and be on a public address in order for this to really work properly. The upside is that it will be much simpler to manage for both your IT department and yourselves when you set up a new client machine. Of course as Jason said you should also have a backup plan should the bridge server happen to fail.
I hope that is of some help
Cheers
Andrew
Greetings,
I am having difficulty in running Access Grid from behind a Firewall on a Private IP Address.
The PC works fine on a public address from behind the same firewall, but as soon as I put the PC on a 10.x.x.x IP Address
I can no longer see other nodes in both RAT and VIC, I can see my own there by nothing else.
I have checked the firewall network activity and while on the Public address can see at the firewall traffic coming back from the bridge in to the address.
But while on the public address there is no return traffic from the bridge (APAG for both tests) to the firewall even, so nothing.
It does not seem to matter if I put in Proxy settings in Access Grid same issue.
It is as if the bridge isn't even trying to return traffic to the private address at all.
Can anyone please advise on how the Access Grid protocols work for setting up a session, we are only using unicast here.
Our network guys comments below.
To get the client working from a private address using only firewall rules is a little tricky because of the way the client works with bridging.
When you first connect to a venue via a bridge the client makes contact with the bridge via TCP to it's main port to ask where to connect when setting up video and audio. The bridge then decides at run time where the RAT and VIC tools need to connect. (I'm not sure if this is statically defined, I suspect it's dynamic) The bridge tells the venue client where to connect and then the client sets up it's services accordingly.
Both VIC and RAT use UDP packets to send and receive data to and from the bridge. They each require two ports, one for the main data and another for the control data for the streams. As the ports are decided upon at run time by the bridge it is really hard to set up firewall rules for. I'd say that your firewall is having difficulties handling the UDP packets or is simply blocking them all together. You can even end up with the situation that you can get the UDP packets going in one direction only, this would result in either being able to see and hear but not transmit, or vice versa. Sometimes firewalls are set up to completely block UDP packets, as they are rarely needed for most common internet usage (most being via TCP and port 80)
So for a client to be able to connect to a bridge it needs to be able to talk to it via TCP to its main control port, and also be able to communicate via UDP (in both directions) on the four ports required for video and audio. The ports required for UDP vary, I was connected to a bridge today on port numbers in the ~30,000 - 31,000 range. It may depend on the bridge.
Whilst it is technically possible to set up firewall rules to accommodate running a client this way, I tend to agree with your network guys that it's not a elegant solution and is really hard to maintain. So I would suggest what I think David was suggesting. Run a bridge server of your own on a public address within your network, and then set up the firewall rules to allow machines behind the NAT firewall to communicate with it via UDP in both directions. The downside being the machine that is a bridge server pretty much must have multicast access to the internet and be on a public address in order for this to really work properly. The upside is that it will be much simpler to manage for both your IT department and yourselves when you set up a new client machine. Of course as Jason said you should also have a backup plan should the bridge server happen to fail.
I hope that is of some help
Cheers
Andrew
Greetings,
I am having difficulty in running Access Grid from behind a Firewall on a Private IP Address.
The PC works fine on a public address from behind the same firewall, but as soon as I put the PC on a 10.x.x.x IP Address
I can no longer see other nodes in both RAT and VIC, I can see my own there by nothing else.
I have checked the firewall network activity and while on the Public address can see at the firewall traffic coming back from the bridge in to the address.
But while on the public address there is no return traffic from the bridge (APAG for both tests) to the firewall even, so nothing.
It does not seem to matter if I put in Proxy settings in Access Grid same issue.
It is as if the bridge isn't even trying to return traffic to the private address at all.
Can anyone please advise on how the Access Grid protocols work for setting up a session, we are only using unicast here.
Our network guys comments below.