Firewall document
Robert Olson
olson at mcs.anl.gov
Mon Dec 8 15:56:02 CST 2003
> The port tables confuse me.
I agree; the distinction of when bridge server ports are required is also
not clear in the txt. it might be clearer to enumerate the ports instead
of marking them as [1234/1235]
the beacon server doesn't use odd ports on its multicast?
might be interesting to bounce this off caren or bill.
>
> * I think there should be two tables: one for "minimal ports
> necessary to make things work", and one for optional ports.
>
>
> In the table under the text "These services make no /wide area/ network
> connections, but do require any firewall on the local machine be
> configured appropriately"
>
> * "Services" should say that they use dynamically assigned ports.
>
>
>
>
>
>
>
> Ivan R. Judson wrote:
>
> >Here's what I have; if there's nothing more to add, this should be
> >sufficient for the APS folks.
> >
> >I'd like Bob and Tom to read it over and verify there's nothing missing. The
> >APS folks are waiting for this document and I'd like it out the door today.
> >
> >--Ivan
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> >
> > Firewall Configuration Information for AGTk 2.0
> >
> > Author: Ivan R. Judson
> > Status: Draft
> > Contact: ag-info at mcs.anl.gov <mailto:ag-info at mcs.anl.gov>
> > Copyright: University of Chicago, 2003
> > Date: 04-12-2003
> >
> >
> > Abstract
> >
> > This document specifies what firewall configuration options need to be
> > considered to use the Access Grid in a firewalled network environment.
> > Specific firewall solutions are not addressed in this document.
> >
> >
> > Copyright
> >
> > This document falls under the AGTkPL.
> >
> >
> > Discussion
> >
> > The Access Grid Toolkit provides distributed collaboration system with
> > parts that communicate over both the local area and wide area network.
> > In order to function properly the various parts of the system need to
> > be able to initiate and use network connections in various directions
> > (both incoming and outgoing). When the term connection is used it is
> > meant to mean a GSI Secured TCP Socket.
> >
> > For the streaming media, which is carried via RTP, two ports are
> > required. The first (even numbered) port is the data port, the next
> > odd port (first port + 1) is used for RTP Control data.
> >
> > In the current version of the toolkit, the network interfaces are
> > served via SOAP. These interfaces are exposed on:
> >
> > Service Default Port(s)
> > Services dynamically assigned
> > Service Manager 11000
> > Node Service 12000 and 1 dynamically assigned
> > Venue Client ^* <#id3> /optional/ 1 dynamically assigned
> > Venue Server 8000, 8002, 8004, 8006
> > Bridge Server Each stream is statically configured or dynamically
> > assigned
> > Beacon Server (233.4.200.21, 10002/10004), beacon.dast.nlanr.net:10004
> >
> > The following services need special configuration to operate correctly.
> >
> > Service Default Port(s)
> > Venue Client /optional/ 1 dynamically assigned
> > Venue Server 8000, 8002, 8004, 8006
> > Bridge Server Each stream is statically configured or dynamically
> > assigned
> > Beacon Server (233.4.200.21, 10002/10004), beacon.dast.nlanr.net:10004
> >
> > These services make no /wide area/ network connections, but do require
> > any firewall on the local machine be configured appropriately ^+ <#id4>.
> >
> > Service Default Port(s)
> > Services none
> > Service Manager 11000
> > Node Service 12000 and 1 dynamically assigned
> >
> > [*] <#id1> Disabling incoming connections to the Venue Client is
> > possible and doesn't significantly hinder collaboration. Personal data
> > sharing is not possible if incoming connections are not allowed.
> >
> > [+] <#id2> Host based firewalls like Microsofts XP Firewall will
> > interfere not only with local area connectivity but it will also stop
> > multicast from working properly. Currently, the best advice is to turn
> > the firewall off.
> >
> >
> > Service Details
> >
> > *
> >
> > Venue Server (defaults to port 8000, 8002, 8004, 8006)
> >
> > The venue server listens for incoming connections on four ports,
> > which are configurable. These ports are for incoming connections
> > only, there are no outbound connections from the venue server.
> >
> > *
> >
> > Bridge Server (multiple ports used)
> >
> > The bridge server can use either statically assigned ports for
> > the media bridges it starts, or it can dynamically assign the
> > ports for media bridges.
> >
> > *
> >
> > Beacon Server (one group, one outgoing connection)
> >
> > The beacon server uses one multicast group and one outbound
> > connection to a reporting server. These are both configurable,
> > but the defaults are the correct configuration to be a part of
> > the Access Grid Multicast Beacon infrastructure.
> >
> >
> > Multicast
> >
> > In order for audio and video to flow among users multicast needs to be
> > able to be allowed through the firewall. There is currently no set of
> > static configurations that are used for multicast (although they could
> > be used, if needed), so ideally the firewall would allow data from any
> > group /that is subscribed to from inside/ the firewall to come through
> > the firewall from the outside.
> >
> > The media tools we use have two different behaviors for how they send
> > data. For audio the source port for the data is identical to the
> > destination port for the data. For video, the source port for the data
> > is selected randomly.
> >
> >
> > Example of a Secured Static Environment
> >
> > This is an example of a small installation configured for a paranoid
> > network configuration. The configuration has only three venues to keep
> > the example simple.
> >
> > To keep this example even more simple, the bridge, data and venue
> > server are all running on the same machine, /host.domain/.
> >
> >
> > Meeting Room Venue
> >
> > Media Multicast Groups Bridge Ports
> > static video 224.1.2.3/[1234/1235] 9000/9001
> > static audio 224.1.2.3/[1236/1237] 9002/9003
> >
> >
> > Laboratory #1 Venue
> >
> > Media Multicast Groups Bridge Ports
> > static video 224.1.2.4/[1234/1235] 9004/9005
> > static audio 224.1.2.4/[1236/1237] 9006/9007
> >
> >
> > Laboratory #2 Venue
> >
> > Media Multicast Groups Bridge Ports
> > static video 224.1.2.5/[1234/1235] 9008/9009
> > static audio 224.1.2.5/[1236/1237] 9010/9011
> >
> >
> > Venue Server
> >
> > * running on host.domain
> > * ports: 8000, 8002, 8004, 8006
> >
> > *If the firewall is configured to allow multicast through*, then
> >
> >
> > Bridge Server
> >
> > * running on host.domain
> > * ports: 9000-9011
> >
> > *otherwise*,
> >
> >
> > Bridge Server
> >
> > * running on some host with working multicast
> > * ports: 9000-9011
> >
> >
> > Beacon Service
> >
> > * running on host.domain
> > * Multicast Group: (233.4.200.21, 10002/10004)
> > * Outbound TCP: beacon.dast.nlanr.net:10004
> >
> >
> > Summary Configuration
> >
> > Incoming *to host.domain* from the rest of the world:
> >
> > * /Ports:/ 8000, 8002, 8004, 8006
> > * If Bridge Server is *inside the firewall*: 9000-9011
> >
> > Outgoing Conduits *from host.domain* to the rest of the world:
> >
> > * beacon.dast.nlanr.net:10004
> > * If Bridge Server is *outside the firewall*:
> > bridgehost.domain:9000-9011
> >
> > Multicast Group Conduits:
> >
> > All hosts on the local network should be able to send and receive
> > traffic via these multicast groups.
> >
> > * (224.1.2.3,1234)
> > * (224.1.2.3,1235)
> > * (224.1.2.3,1236)
> > * (224.1.2.3,1237)
> > * (224.1.2.4,1234)
> > * (224.1.2.4,1235)
> > * (224.1.2.4,1236)
> > * (224.1.2.4,1237)
> > * (224.1.2.5,1234)
> > * (224.1.2.5,1235)
> > * (224.1.2.5,1236)
> > * (224.1.2.5,1237)
> > * (233.4.200.21, 10002)
> > * (233.4.200.21, 10004)
> >
> >
> > Conclusion
> >
> > This document describes the firewall requirements for the AGTk 2.0
> > software, for both clients and services. For more information please see:
> >
> > * The AGTk Home Page <http://www.mcs.anl.gov/fl/research/accessgrid>
> > * The Access Grid Project Home Page <http://www.accessgrid.org/>
> > * The Access Grid Documentation Project Home Page
> > <http://www.accessgrid.org/agdp>
> >
>
More information about the ag-dev
mailing list