Allow block

Allow blocks specify who may connect to this server and what class to put the user in. You can have multiple allow blocks.

Syntax

allow {
        mask <mask>;
        class <connection-class>;
        maxperip <max-connections-per-ip-locally>;

        /* All the rest is optional: */
        global-maxperip <max-connections-per-ip-globally>;
        password <connection-password> { <auth-type>; }; /* OPTIONAL */
        redirect-server <server-to-forward-to>; /* OPTIONAL */
        redirect-port <port-to-forward-to>; /* OPTIONAL */
        options {
            <option>;
            <option>;
            ...
        };
};

Do you have multiple allow blocks? Then note that they will be read upside down, so you need specific host/ip allow blocks AFTER your general *@* allow blocks.

If a client does not match any allow block then the client is rejected with the message from set::reject-message.

required items

mask

You must specify a mask such as mask *;. Advanced users may wish to look at Mask item to see a lot more options that can be used for masks, such as lists, negative matching, matching SASL users, certificate fingerprints, etc.

class

Specifies the class name that connections using this allow block will be placed into.

maxperip

With maxperip you specify how many local connections may come from each IP. For example maxperip 4; means that only 4 clients may connect per-IP to this server.

Note that if you use Services then it may have a session limit too. If you bump maxperip in UnrealIRCd and then see kills/quits with the reason "Session limit exceeded" then you know it is not UnrealIRCd doing this but anope or other services. We recommend disabling the os_session module in your services since it is unneeded with UnrealIRCd.

global-maxperip

This specifies the global maximum number of connections from each IP (network-wide). If you don't have this, then it will default to maxperip+1.

optional items

password

The server password or another authentication method that the user authenticates with.

There are two possible behaviors for password control:

optional password to get extra rights

The default behavior is, if the password is incorrect, to continue matching next allow block:

allow { mask *; class clients; maxperip 2; }
allow { mask *; password "iwantmore"; class clients; maxperip 10; }

If a user connects with the password iwantmore then they will get a maxperip of 10. If the user does not connect with that password (either wrong or no password) then the user will get a maxperip of 2.

mandatory password

On the other hand, you may want to use passwords to keep other users out. In this case you need to use allow::options::reject-on-auth-failure as described below:

allow { mask *; class clients; maxperip 2; }
allow { mask *@*.nl; password "tehdutch"; class clients; maxperip 2; options { reject-on-auth-failure; } }

In this case anyone with a hostname of *.nl must provide the password tehdutch. If they don't, they will be rejected access and cannot connect to the server.

redirect-server & redirect-port

When the class is full (class::maxclients) we will redirect new users to this server. This requires support from the IRC client side, popular clients like mIRC support this but this feature is broken in case of SSL/TLS so is likely of little use in the modern world.

redirect-server specifies the server name and redirect-port the port (6667 by default).

options

One option gives you additional flexibility for matching:

• tls: Only match if this client is connected via SSL/TLS.

Meaning, if this doesn't match, UnrealIRCd jumps to next allow block.

There are also two other options that don't have anything to do with matching but will affect the user/host:

• useip: Always display IP instead of hostname.
• noident: Don't use ident but use username specified by client.

And, finally, there's one special option that is rarely used:

• reject-on-auth-failure: Reject the user if the password is not provided or does not match. See also the password option above for a longer explanation.

Example

Example 1: generic block and specific block

allow {
	mask *;
	class clients;
	maxperip 3;
};

allow {
	mask 1.2.3.*;
	class clients;
	maxperip 25;
};

Example 2: extended matching

NOTE: This options is available in UnrealIRCd 6.0.4 and later. If you are using an older version then see example 3 instead

allow {
	mask *;
	class clients;
	maxperip 3;
};

allow {
	mask {
                mask { 1.2.3.0/24; }
                account { TrustedUser1; TrustedUser2; }
                certfp { "1234567890abcdef1234567890abcdef123456"; } /* Add more than one certfp: "secondone"; "thirdone";  */
        }
	class clients;
	maxperip 25;
};

This will:

• Grant the high maxperip 25 to users matching any of the following criteria (OR!):
  • Any user in the IP range 1.2.3.0/24, OR
  • Users identified to services via SASL with the account name TrustedUser1 or TrustedUser2, OR
  • A user which uses certificate fingerprint (sha256) 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef
• All the other clients get a maxperip 3

Example 3: extended matching (before UnrealIRCd 6.0.4)

allow {
	mask *;
	class clients;
	maxperip 3;
};

allow {
	mask 1.2.3.*;
	class clients;
	maxperip 25;
};

allow {
	mask { ~a:TrustedUser1; ~a:TrustedUser2; }
	class clients;
	maxperip 25;
};

This will:

• Grant any user in the IP range 1.2.3.* a high maximum connections per IP of 25
• Grant TrustedUser1 and TrustedUser2, if he identifies to services using SASL, also a maxperip of 25
• All the other clients get a maxperip of 3