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!

If you're running Tor, access is available via our hidden service.

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.

All freenode servers listen on ports 6665, 6666, 6667, 6697 (SSL only), 7000 (SSL only), 7070 (SSL only), 8000, 8001 and 8002.

Asia/Pacific Rimchat.au.freenode.netIPv4/IPv6
Perth, AUbanks.freenode.netIPv4
Perth, AUbradbury.freenode.netIPv4
Singapore, SGbrooks.freenode.netIPv4
Brisbane, AUroddenberry.freenode.netIPv4, IPv6
Europe IPv4/IPv6
Budapest, HUadams.freenode.netIPv4, IPv6
Paris, FRbarjavel.freenode.netIPv4
Milan, ITcalvino.freenode.netIPv4, IPv6
Vilnius, LTcameron.freenode.netIPv4, IPv6
Oslo, NOgibson.freenode.netIPv4, IPv6
Sofia, BGhitchcock.freenode.netIPv4
Bucharest, ROhobana.freenode.netIPv4, IPv6
London, UKholmes.freenode.netIPv4, IPv6
Frankfurt, DEkornbluth.freenode.netIPv4
Umeå, SEleguin.freenode.netIPv4, IPv6
Amsterdam, NLorwell.freenode.netIPv4
Rennes, FRpratchett.freenode.netIPv4
Helsinki, FIrajaniemi.freenode.netIPv4, IPv6
Vilnius, LTsendak.freenode.netIPv4
Manchester, UKwolfe.freenode.netIPv4
United States IPv4/IPv6
Dallas, TXasimov.freenode.netIPv4
Washington, DCcard.freenode.netIPv4
Ashburn, VAdickson.freenode.netIPv4, IPv6
Pittsburgh, PAhubbard.freenode.netIPv4
Austin, TXmoorcock.freenode.netIPv4
Chicago, ILmorgan.freenode.netIPv4, IPv6
Irvine, CAwright.freenode.netIPv4

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

/connect -ssl_verify -ssl_capath /etc/ssl/certs chat.freenode.net 6697

or on FreeBSD

/connect -ssl_cafile /usr/local/share/certs/ca-root-nss.crt chat.freenode.net 6697

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

Tor provides anonymous access to internet services, including IRC, and protects users' privacy from various forms of traffic analysis. The freenode network welcomes Tor users.

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.

Copyright © 2002 – 2014 by freenode Creative Commons License
Comments to email address: support at freenode dot net