IRC Servers

Our main server rotation is chat.freenode.net. Pointers to freenode currently include irc.ghostscript.com, irc.gnu.org, irc.handhelds.org, and irc.kde.org. Please see our acknowledgements page for the generous groups and organizations who have helped us to provide this service. The network needs servers on the Pacific Rim and in the Americas. If you think you might be able to help our community in this way, please take a look at the server hosting page and email us at hosting at freenode dot net. Thanks!

The following table lists freenode client servers. Please be aware that the below list is at no time authoritative, and as such our advice is to connect using chat.freenode.net. If you are using one of the servers below and it's not working, please check that it's in chat.freenode.net and select another server from that list if it's not.

The main rotation, chat.freenode.net, has AAAA records for servers with IPv6 capability, so simply telling your client to connect to chat.freenode.net by IPv6 should work. We do not provide regional rotations, except Asia/Pacific Rim, because we aren't very good at keeping them up-to-date as the main rotation changes.

Accessing freenode Via SSL

freenode provides SSL client access on all
servers. If your client is not configured to verify SSL certificates, then you
can simply connect, with SSL enabled, on port 6697, 7000 or 7070. Users
connecting over SSL will be given user mode +Z, and
is using a secure connection will appear in
WHOIS (a 671 numeric). Webchat users will not appear
with +Z or the 671 numeric, even if they connect to webchat via SSL.

If you wish to verify the server certificates on connection, some additional
work may be required. First, ensure that your system has an up-to-date set of
root CA certificates. On most linux distributions this will be in a package
named something like ca-certificates. Many systems install these by default, but
some do not (such as FreeBSD, on which the package you wish to install is
ca_root_nss, and the cafile to use would be
/usr/local/share/certs/ca-root-nss.crt). For most clients this should be
sufficient. If not, you can download the required intermediate cert from Gandi and the root
cert from InstantSSL.

Those of you using irssi will find that it has some oddities in SSL
certificate verification, and will not find the root certificates on its own. To
work around this, use

Once you tell irssi where to find the root certificates, it should be able to
verify the certificate correctly.

Client SSL certificates are also supported, and may be used for identification
to services via CertFP. If you have connected with a client
certificate, has client certificate fingerprint
f1ecf46714198533cda14cccc76e5d7114be4195 (showing
your certificate's SHA1 fingerprint in place of
f1ecf46...)
will appear in WHOIS (a 276 numeric).

Accessing freenode Via Tor

The primary Tor hidden service address for freenode is frxleqtzgvwkv7oz.onion. The service listens on ports 6667, 6697 (SSL), 7000 (SSL), and 7070 (SSL). To connect, a NickServ account is needed, and the IRC client must be configured to support SASL. Information on how to register a nick can be found on our FAQ page, and our SASL pages describe clients that support SASL and how to configure many of them. Tor's wiki also has a page on configuring IRC clients to use Tor.

If your IRC client can handle SOCKS5 with remote DNS, just connect to the .onion address directly, and this is preferred. Otherwise, Tor's "mapaddress" feature can work around the missing remote DNS support. Add a line to your torrc, as in this example:

mapaddress 10.40.40.40 frxleqtzgvwkv7oz.onion

(Note for irssi users: we do not recommend Privoxy; it's unnecessary. Just use mapaddress and torrify irssi.)

User connections through Tor are assigned a gateway cloak of gateway/tor-sasl/ followed by the account name of the user (provided during SASL authentication). If the account name contains characters that cannot be represented in a cloak, then the token /x-NNNNNNNN is also appended. The NNNNNNNN is a set of digits which should be consistent for a given account name, but may otherwise be treated as random.

Channel owners are free to deny access to their channels by various gateway users, but please don't limit access to gateways too broadly or completely. In particular, don't ban all gateways or all of Tor by doing something like /mode #channel +b *!*@gateway/*. A quiet instead of a ban can be just as effective, so please use a quiet if at all possible: /mode #channel +q *!*@gateway/tor-sasl/*. If you do something like this, make it temporary, not permanent. Network staff can turn off new gateway connects on a temporary basis and remove abusive users. We're happy to do so; simply contact a staffer whenever your channel experiences abuse. Remember that some users have very little choice about using gateways, and be considerate in your control of access.

Connections to freenode directly from Tor exit nodes are not allowed, as it is impossible to distinguish traffic originating on that computer from Tor exit traffic. In addition to providing better protection and location privacy, the hidden service gives end-to-end encryption, providing benefits similar to using SSL (ircs/irc-ssl). If you do want to be a Tor exit node and still use freenode, you will have to configure your exit policy to block all of the IRC ports we use, in addition to ports 80 and 443 as these are used for webchat. Alternatively, you can allow any ports in your exit policy, and always connect to freenode using the hidden service.

We encourage you to consider providing "middleman" bandwidth to the Tor network by setting up your host as a Tor relay. Specify how much bandwidth you want to provide and set your exit policy to reject *:*. It will help us make up for the bandwith we use for freenode's hidden service.

Be sure to HUP (reload) Tor if you change your torrc. This applies to both exit policy changes and mapaddress changes. Exit policy changes may take a day or two before the update is reflected and you are able to connect to freenode again. Mapaddress changes should be immediate.

If you have trouble connecting to the hidden service, make sure SASL is working correctly, perhaps by connecting normally (not through Tor) and seeing that you're identified. If SASL works, try shutting down and restarting the Tor daemon. There may be a bug in the Tor hidden service limiting the number of long-lived concurrent connections. If you are still unable to connect after restarting the Tor daemon, then try using a secondary address:

Tor users represent much less than 1% of our total userbase. We appreciate your accessing freenode via the Tor hidden service; however, we have a limited amount of staffer time to troubleshoot and resolve issues. If we have to restart the hidden service, that means disconnecting all the currently-connected Tor users, so we prefer to avoid that if possible.