ip-accept
References an IP address pre-admission filter list. Connections from IP addresses not in the specified list are rejected immediately, before any protocol-specific processing occurs.
This is not a replacement for a network firewall. It is intended as a second level of security.
Syntax
ip-accept "LIST_NAME";
The referenced list must be defined in the clients block using the same name.
Purpose
IP-accept lists provide an early security layer that:
- Rejects unauthorized connections immediately before resource-intensive protocol processing
- Protects against attacks by limiting which IPs can even attempt connections
- Essential for PROXY protocol to ensure only trusted proxies can provide client IP addresses
- Reduces log noise from unauthorized connection attempts
Rejection Behavior
The rejection behavior differs by protocol:
- TCP/TLS: Connection is actively closed/rejected. Client receives connection refused or connection reset.
- UDP: Packets are silently dropped with no response. Client will timeout waiting for a reply.
Example
Define the IP-accept list in the clients block:
clients {
ip-accept "TRUSTED_PROXIES" {
client "LOAD_BALANCERS" {
source {
ip 10.0.1.0/24;
ip 10.0.2.0/24;
}
timeout 30s;
}
}
ip-accept "MANAGEMENT_ACCESS" {
client "ADMIN_NETWORKS" {
source {
ip 192.168.1.0/24;
ip 172.16.0.0/16;
}
}
}
}
Reference it in the server listen configuration:
servers {
radius "RADIUS_TCP" {
listen {
protocol tcp;
port 1812;
ip 0.0.0.0;
ip-accept "TRUSTED_PROXIES";
proxy-protocol v2;
}
clients "CLIENTS_RADIUS_ALL";
}
http "MANAGEMENT_API" {
listen {
protocol tls;
port 8443;
ip 0.0.0.0;
ip-accept "MANAGEMENT_ACCESS";
tls {
certificate "SERVER_CERT";
certificate_key "SERVER_KEY";
}
}
}
}
Key Behaviors
With PROXY Protocol
When using PROXY protocol, ip-accept checks the proxy's IP address (the direct peer), not the original client IP. This is a critical security feature that prevents untrusted proxies from spoofing client addresses.
See the PROXY Protocol Guide for detailed examples and configuration patterns.
Logging and Statistics
Rejected packets and connections are logged at debug level with protocol-specific messages. Each message has an associated counter under the server namespace.
When debug logging is filtered, Radiator promotes these messages to info according to the
global promotion configuration. The counters still
increment for every rejection. See the
application log message index for the matching messages.
Management Interface Restriction
Restrict management API access to specific networks:
clients {
ip-accept "ADMIN_ONLY" {
client "ADMIN_NETWORKS" {
source {
ip 192.168.1.0/24;
ip 10.0.0.0/8;
}
}
}
}
servers {
http "MANAGEMENT" {
listen {
protocol tls;
port 8443;
ip 127.0.0.1;
ip ::1;
ip-accept "ADMIN_ONLY";
tls {
certificate "SERVER_CERT";
certificate_key "SERVER_KEY";
}
}
}
}
Performance
IP-accept filtering is extremely efficient:
- Constant-time lookup for exact IP matches
- Logarithmic time for CIDR range matches using prefix tree
- Minimal memory overhead per connection
- Early rejection prevents wasted resources on unauthorized connections
A machine able to handl 40k TPS of radius TCP will be able to refuse connections on a typical IP list at the rate of hundreds of thousands per second. We recommend using a proper firewall.
See Also
- PROXY Protocol Guide - Using ip-accept with PROXY protocol
- Server Configuration - Server listen configuration