To enable for Internet chat I set up Google Chat and Skype. My firewall rules have been extremely restrictive with only known and approved services allowed to connect. Google Chat installed with no noticeable impact to the firewall. Things did not go so well with Skype.
The installation of Skype resulted in lots of warnings on the firewall. Outgoing tests worked with only port 80 and 443 open. Skype’s peer-to-peer approach requires at least one port be opened incoming and and a large range of ports outgoing. They specify all ports over 1024 should be open. Their preferred mode seems to be to use uPnP to dynamically modify the firewall. They do allow you to attempt to set fixed incoming port which is also used for some outgoing UDP traffic.
Setting up Google Chat
Google Chat runs from your Gmail home page or the Chat widget on an iGoogle page. It runs from most current browsers but does require installing a plug-in. The plug-in enables video and voice chat. Once the plug-in is installed and the browser is restarted you should be ready to go. Unlike Skype, I was unable to get Google Chat between computers behind my firewall.
Google inter-works with any Jabber Instant Messaging (IM) client. I installed the Empathy IM client on my Ubuntu desktop. This required enabling outgoing TCP connections on the Jabber port (5222). Some clients use the legacy Jabber Secure port (5233). The use of a Jabber client is currently only documented to provide IM services. However, Google is working towards using XMMP compliance for voice and video signaling. To enable Jabber through the firewall add one or both of these lines (depending on TSL/SSL settings in the clients) to the rules file:
JabberPlain/ACCEPT loc net JabberSecure/ACCEPT loc net
Google Chat will also inter-work with existing Jabber servers. The federation of the servers is automatic. Normally, organizations running a Jabber server will already have the appropriate port(s) open to the server.
Setting up Skype
Installing Skype requires downloading and installing software. Installation packages are available for Windows, iMac, Linux, and other platforms. You will need administrative privileges to install on most platforms. This application uses closed protocols implemented in closed source software and does not inter-work with any other software.
Once the software is installed it is easy to get up and running for outgoing calls. The initial screen gives you the option to create a new account or use an existing account. Accounts are free, but additional services come at a cost. Once you are logged in, there will be an “Echo /Sound Test Service” listed in your contacts. You can test with this until you are ready to add contacts and chat with them. With a closed firewall, outgoing connections will be made using the HTTP and HTTPS ports. I have not tested incoming calls with this configuration.
Skype does not play well with firewalls. Even when set to use a single port Skype uses ephemeral ports for TCP connection. The firewall needs to allow TCP traffic originating on the ephemeral ports. This essentially wipes out most outgoing traffic controls. Controls can be retained over the privileged ports (0-1023).
The other alternative is it enable UPnP on the firewall. This assumes you trust all the applications on all the systems inside your firewall. Again this essentially leaves the firewall open for most outgoing traffic. Neither solution is good from a security standpoint.
Setting up the Firewall
These rules assume a fixed port on the Skype client. The default port is 14357. This is in the unallocated port range. If supporting multiple clients, assign them a nearby port. To configure incoming connections you will need to know the IP address and listening port of each Skype client
You will need to port forward (DNAT) the configured Skype port to the computer running Skype. Both UDP and TCP must be forwarded. You must enable outgoing TCP connections originating from the ephemeral ports for your operating system. The ephemeral ports vary by the operating system. Newer operating systems releases tend to use the ports suggested by IANA. The table may not be correct for your system if its IP configuration has been modified.
| Source | Ephemeral Ports |
|---|---|
| IANA Dynamic Ports | 49152 to 65535 |
| Ubuntu | 31768 to 61000 |
| Windows XP | 1024 to 5000 |
| Windows Vista | 49152 to 65535 |
| Others Operating Systems | within 1024 to 65535 |
The following rules will enable Skype for a client running on using ports 49152 to 65535. Existing outgoing access to TCP ports 80 (HTTP) and 443 (HTTPS) is assumed. The $SKYPEHOST macro contains the IP address of the Skype client. Port 14357 is the default fixed port. If you have multiple clients, you will need to adjust the port on the clients and add DNAT statements for each client. The TCP source port range is the ephemeral port range of the client. The REJECT rule prevents attempts to use UPnP from being logged. This allows Skype to have UPnP enabled without cluttering the logs.
#Action Source Destination Proto Dest Port Source Port DNAT net loc:$SKYPEHOST tcp 14357 DNAT net loc:$SKYPEHOST udp 14357 ACCEPT loc net udp 1024:65535 14357 ACCEPT loc net tcp 1024:65535 49152:65535 ACCEPT loc net udp 80,443 14357 REJECT loc $FW udp 5351
Skype may discover addresses for clients inside the firewall and attempt to connect directly. If you have clients in multiple zones behind the firewall you will need to configure rules to permit inter-zone traffic. The following Shorewall rules work between the zones loc and wifi for clients using the port range 14356-14359. It would be appropriate to use a macro to supply the range.
ACCEPT loc $FW tcp 14356:14359 1024:65535 ACCEPT loc $FW udp 14356:14359 14356:14359 ACCEPT loc wifi tcp 14356:14359 1024:65535 ACCEPT loc wifi udp 14356:14359 14356:14359 ACCEPT wifi $FW tcp 14356:14359 1024:65535 ACCEPT wifi $FW udp 14356:14359 14356:14359 ACCEPT wifi loc tcp 14356:14359 1024:65535 ACCEPT wifi loc udp 14356:14359 14356:14359
Issues
While testing the configuration I noted the following issues.
- As noted above outgoing connections from the ephemeral ports need to be enabled. This essentially destroys any attempt at limiting outgoing traffic. This can be mitigated by limiting the hosts which have this access.
- If Skype is unable to allocate its default port, it will use multiple ports. This can be a problem if you assign a port in the ephemeral range.
- To you have Skype users behind the firewall calling each other, you need to enable the firewall to routeback to the internal interface. Shorewall has a routeback option in the interface definition for this.
- Logging connections from the ephemeral ports will override most rules occurring after the rule being checked. Place such rules at the end of the ruleset.
- The OpenWrt upnpd daemon package, miniupnpd, is missing a patch that allows it to play well with Shorewall. The patch is available in the distribution, but the package builder appears not to have enabled it. As a result, I abandoned tests of UPnP. This UPnP daemon allows port ranges to be restricted, it should be more secure.
- I missed catching any traffic on UDP ports 80 and 443. None of my clients attempted to connect to these ports while the system was up. Only after several days did I catch traffic on these ports. The required rule has been added to the documentation.