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 ; class ; maxperip ;

/* All the rest is optional: */ global-maxperip ; password  { ; }; /* OPTIONAL */ ipv6-clone-mask ; /* OPTIONAL */ redirect-server ; /* OPTIONAL */ redirect-port ; /* OPTIONAL */ options { ;           ;            ...        }; };

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.

mask
You must specify a mask such as. 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.

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.

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.

ipv6-clone-mask
This option controls clone detection and is basically IPv6's variant of maxperip. If you don't have IPv6 enabled then this option has no effect. If two clients connect from different IPv6 addresses but only the last few bits are different, there is almost a guarantee that both clients are really one person. This option only affects the enforcement of allow::maxperip. For example, if you set this option to 128, then each IPv6 address will be considered unique. Because of current IP allocation policies, it is recommended that your most general allow block use a value of 64. Since 64 is already the default in set::default-ipv6-clone-mask you probably don't need to change this.

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: Meaning, if this doesn't match, UnrealIRCd jumps to next allow block.
 * tls: Only match if this client is connected via SSL/TLS.

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 1: generic block and specific block
allow { mask *; class clients; maxperip 3; };

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

Example 2: match by services account and more
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