Firewall Configuration for the Access Grid
The Access Grid is a software suite that provides video, audio and file collaboration, built on well-known streaming audio (Robust Audio Tool, or RAT) and Vic (Video Conferencing tool). This document seeks to help network administrators implement Access Grid with respect to local security policies and firewalls.
Please send any questions or concerns about this document to firstname.lastname@example.org, or file a bug against it under Documentation in the Access Grid Bugzilla (1).
This document was written by Lev Lafayette and derives heavily from a version was written by Tom Uram with additional material from Jason Bell.
The Access Grid Venue Client operates best with multicast which is the preferred solution for one-to-many content distribution. The network address range for multicast, as defined by IANA, is 126.96.36.199 to 188.8.131.52 or 224.0.0./4 (2)
Multicast does not present a threat to your network. Consider an analogy with firewalls; a firewall will commonly allow incoming UDP traffic on a port if a client behind the firewall has sent data out on that port first (a "reflexive firewall rule"). Multicast operates in a similar fashion. If a client wishes to receive data from a particular multicast group, he must first subscribe to that group. Data flows to the user until membership is terminated.Unwanted influx of data is not an option.
Outgoing multicast data can be read by parties unknown to the sender. If this is an important concern "AG Virtual Venues" can be secured using X.509 certificates to control who has access to the Venue. Only individuals authorized to join the Venue would have access to the multicast addresses and media encryption keys, so even if an outsider were to discover the multicast addresses, he would still not be able to read the data. If a Venue is configured with encrypted media, AES encryption is used (3).
It should be noted that traffic on port 5353 is required for Multicast DNS (eg Zeroconf, Apple Bonjour or Avahi).
Additionally, the multicast beacon (DAST) [Linux install guide can be found at http://www.accessgrid.org/node/1773] is a useful tool to help you debug your multicasting problems. The beacon provides useful information regarding a particular multicast group’s connection activity. Therefore it is recommended to have the beacon software installed and running to assist with identifying any multicast problems.
Therefore, to ensure the multicast beacon works, traffic needs to be accepted from the following ports:
Client-to-Client (RTP) multicast traffic on port: 10002
RTCP traffic on port: 10003
TCP unicast reports going back to the Central Server on port 10004
As an alternative to multicast, an Access Grid can use unicast bridges to exchange traffic. Unicast bridges join a ‘bridge network’. Venue Clients then query this bridge network for available bridges. Unicast bridges forward data using UDP; any firewalls between the bridge and the Venue Client must be configured to allow this connectionless protocol.
The information required, including the bridge hostname and port range, can be determined by looking at the Venue Client Preferences dialogue under Bridging (see figure 1). The list of bridges should be in order of network proximity; starting from the top of the list select a number of bridges and accept traffic from them in your firewall.
The default unicast port range is 50000 to 52000; this can be modified, so one should always check the port range in the Preferences dialogue of the Venue Client.
One thing to note, it is recommended to have available connections to your regional list of unicast Access Grid bridges, as can be found at http://www.accessgrid.org/unicast-bridges.
For routers that perform Network Address Translation (NAT), the port range will need to be forwarded for each bridge to the target computer.
Accept everything from localhost. This might sound obvious but it is also an AG requirement for software like RAT.
Accept incoming traffic from ports 11000, required for NodeService Manager.
Accept port 21 traffic, as Access Grid uses FTPS; initial connection is via port 21 and thereafter may negotiate a secure TLS session (and therefore port 443, HTTPS, TLS, SSL).
Accept incoming traffic from ports 8000, 8002, 8003, 8004 and 8006 ; this is absolutely required for VenueServers.
Specifically Port Protocol Purpose
8000 TCP Virtual Venue Server Port (machine hosting the Venue Server)
8002 TCP Event Port
8004 TCP Text port
8006 TCP Data port
||Incoming / Outgoing
|21||TCP/UDP||Both||Required for FTPS - Data Transfer|
|443||TCP/UDP||Both||Required for HTTPS, TLS, SSL|
|5353||TCP/UDP||Both||Required for multicast DNS|
|5909||TCP/UDP||IN (OUT - Only required if running your own VenueVNC Server)||Required for VenueVNC|
|8000||TCP||IN (OUT - Only required if running your own Venue Server)||Virtual Venue Server Port (machine hosting the Venue Server)|
|8002||TCP||IN (OUT - Only required if running your own Venue Server)||Virtual Venue Server Event Port|
|8004||TCP||IN (OUT - Only required if running your own Venue Server)||Virtual Venue Server Text Port|
|8006||TCP||IN (OUT - Only required if running your own Venue Server)||Virtual Venue Server Data port|
|10002||UDP||Both||Required for Multicast Beacon|
|10003||UDP||Both||Required for Multicast Beacon|
|10004||TCP||Both||Required for Multicast Beacon|
|11000||TCP||IN (OUT - Only required if running your NodeManager)||Required for NodeService Manager|
|50000 - 52000||UDP||Both||
Required for connections to Unicast Bridges
(Note that the port range might change for different bridges)
|Other Firewall considerations|
|22||TCP/UDP||Required for SSH|
|80||TCP||IN||Required for HTTP|
|ICMP||Both||Required for Ping|
|Local Host Firewall considerations|
|localhost||TCP/UDP||Both||Required for Rat and other applications|
1) Access Grid Bugzilla, http://bugzilla.mcs.anl.gov/accessgrid
2) Internet Multicast Addresses, http://www.iana.org/assignments/multicast-addresses
3) AES Algorithm (Rijndael) Information, http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html
This document has been made possible by the support of the Australian Research Collaboration Service (ARCS - http://www.arcs.org.au/)
5th / May / 2009
6th / May / 2009