RADIUS Timeouts

When MikroTik’s PPP log says radius incoming packet timeout or no reply from radius server, the RADIUS request never came back. Unlike an Access-Reject (which is a valid answer meaning “no”), a timeout means the BNG didn’t hear anything — either the packet didn’t arrive, the server didn’t process it, or the response didn’t return. Four common causes; this page walks them in order.

Symptoms

• MikroTik log: radius incoming packet timeout from 1.2.3.4:1812
• MikroTik log: no reply from radius server
• docker logs proxpanel-radius shows nothing for the failing user (no Access-Accept, no Access-Reject)
• All users on a NAS disconnect simultaneously when the link to the panel hiccups
• CoA-based actions (FUP enforcement, plan changes) silently fail — no speed change, no kick

Diagnostic flow

1. Confirm RADIUS is alive on the panel side. A single packet from the dev box should produce a log line.

   docker exec proxpanel-radius netstat -ulnp | grep -E ":1812|:1813"

   You should see udp 0.0.0.0:1812 and udp 0.0.0.0:1813.

2. Confirm the NAS can reach the panel. From the MikroTik:

   /tool ping 1.2.3.4 count=4

   If ping fails, the issue is L3 — firewall, routing, or the panel is down. Stop here, fix that.

3. Capture the actual packet. On the ProxPanel host:

   sudo tcpdump -ni any -vv 'udp port 1812 or udp port 1813' -c 20

   Trigger a dial on the customer. If you see no packet, the issue is reachability — the NAS isn’t sending, or a firewall is dropping. If you see a packet but no response, the issue is shared-secret mismatch or packet size (see below).

4. Check the CoA path separately. CoA uses 1700 by default (3799 on older configs). Timeouts on auth are not the same as timeouts on CoA — they’re different code paths and different ports.

Cause 1 — ProxPanel unreachable

The NAS can’t reach the panel at all. Firewall, wrong server IP in the MikroTik’s /radius entry, ProxPanel host network broken, ProxPanel RADIUS container down.

Diagnostic:

# Is the container up?
docker ps | grep proxpanel-radius

# Is it listening on 1812/1813 UDP?
ss -ulnp | grep -E ":1812|:1813"

# From the NAS subnet, can you reach 1812?
nc -uvz YOUR_PANEL_IP 1812

From the MikroTik:

/tool ping YOUR_PANEL_IP count=10
/system resource print

Fix:

1. If the container is down, start it with docker compose -f /opt/proxpanel/docker-compose.yml up -d radius.
2. If the host firewall is blocking, allow UDP 1812 and 1813:

   ufw allow 1812/udp
   ufw allow 1813/udp
   ufw reload

3. If the MikroTik’s /radius entry points at the wrong IP (e.g. you migrated the panel to a new server), fix it:

   /radius set [find] address=NEW_PANEL_IP

4. If the panel is behind NAT / a load balancer that doesn’t proxy UDP, point the NAS at the real backend. Do not try to put 1812/1813 behind Cloudflare or any HTTP proxy — they don’t carry UDP.

Caution

Cloudflare’s orange-cloud proxy does not carry RADIUS. If you put license.proxrad.com or the panel hostname behind Cloudflare and the NAS resolves to a Cloudflare IP, RADIUS will time out 100%. Grey-cloud (DNS-only) any record that NASes resolve.

Cause 2 — Shared-secret mismatch

The packet arrives at the panel, the panel decodes the headers, fails the HMAC check, and silently drops it. This is the most common timeout cause when ping works.

Symptom: tcpdump shows packets arriving but docker logs proxpanel-radius shows nothing for that NAS. The RADIUS server doesn’t log secret-mismatch by default — it just drops the malformed packet.

Diagnostic:

# What secret does the panel think this NAS uses?
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT name, ip_address, LEFT(secret, 4) || '****' AS secret_preview FROM nas_devices WHERE ip_address='<bng-private>';"

On the MikroTik:

/radius print detail

Compare the secret value byte-for-byte. Common gotchas: trailing whitespace, smart-quotes from a Word doc, missing characters when copied from a small dialog box.

Fix:

1. Pick one secret as canonical (longer is better — 32+ random chars).
2. Update it on the panel: NAS / Routers → Edit → Shared Secret.
3. Update it on the MikroTik: /radius set [find] secret=NEW_SECRET.
4. Restart the RADIUS container to flush cached secrets: docker restart proxpanel-radius.
5. Re-test — first packet should produce a log line.

Cause 3 — Packet too large (fragmentation)

RADIUS is UDP. When the attribute list grows beyond ~1472 bytes (Ethernet MTU minus IP+UDP headers), the IP layer fragments. Some MikroTik builds, and many CGNAT paths, drop fragmented UDP. Symptom: small users work, the user with a long CoA reply or many Mikrotik VSAs times out.

When this hits you:

• Generic-RADIUS mode with long Filter-Id chains
• Heavy CoA payloads (many session attributes)
• A Class attribute storing a 200+ byte session token
• Some IPSec / GRE tunnels between panel and NAS with a low MTU

Diagnostic:

sudo tcpdump -ni any -vv 'udp port 1812' -s 0 -w /tmp/radius.pcap
# Reproduce, then:
sudo tcpdump -r /tmp/radius.pcap -nn -v | grep -E "length|frag"

If you see frag flagged on the inbound packet, that’s the culprit.

Fix:

1. Reduce the reply size. On the service: remove redundant attributes, shorten the FUP rate-limit string, drop unused VSAs.
2. Raise the path MTU if you control the tunnel — mtu=1500 on both ends; ip mss-clamp if there’s an L7 device in between.
3. Switch to RadSec / RADIUS-over-TLS if you genuinely need >MTU payloads. (Not currently supported in ProxPanel — contact info@proxrad.com if this is blocking you.)

Cause 4 — Wrong CoA port

CoA / Disconnect packets are a separate protocol on a separate port. ProxPanel defaults to 1700 (MikroTik’s RouterOS default). Some older configs and FreeRADIUS-style deployments use 3799 (the RFC default). If the panel sends to 1700 and the MikroTik is listening on 3799 — or vice versa — every FUP enforcement, plan change, and force-disconnect silently fails.

Symptom:

• Subscriber crosses FUP, log says CoA: Sending rate-limit change ... followed by CoA error: read udp ...: i/o timeout
• Force-disconnect button in the UI completes successfully, user stays online
• Speed change shows as “applied” but MikroTik’s queue is unchanged

Diagnostic:

# What CoA port is configured in the NAS row?
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT name, ip_address, coa_port FROM nas_devices;"

# Look for the CoA logs:
docker logs proxpanel-api 2>&1 | grep -E "CoA:" | tail -20

On the MikroTik:

/radius incoming print

The output shows the port RouterOS will accept CoA on (default port=3799 on older RouterOS, 1700 on modern).

Fix:

1. Match the ports. Easiest: leave RouterOS at its default and set ProxPanel’s NAS row to match. On RouterOS 7.x with port=1700:

   docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
     "UPDATE nas_devices SET coa_port=1700 WHERE id=1;"

2. Or set RouterOS to 3799 if the panel is configured that way:

   /radius incoming set port=3799 accept=yes

3. Make sure accept=yes on RouterOS — if it’s no, CoA packets are dropped silently.
4. Restart the API container so the connection pool re-reads NAS rows:

   docker restart proxpanel-api

5. Trigger a FUP enforcement (or a plan change) and watch the API log:

   docker logs -f proxpanel-api 2>&1 | grep "CoA"

   You want CoA: Sending rate-limit change ... followed by no error.

Cause 5 — RADIUS server overloaded

At extreme scale (50K+ subscribers reconnecting simultaneously, e.g. after a CGNAT flap), the RADIUS server’s request queue can back up. ProxPanel’s RADIUS handles >200 q/s comfortably on 4 cores, but a thundering-herd event after a panel restart can spike beyond that.

Diagnostic:

# Are CPU cores saturated?
docker stats proxpanel-radius --no-stream

# Are auth latencies climbing?
docker logs proxpanel-radius 2>&1 | grep -oP "duration=\d+ms" | sort -n | tail -20

If you see latencies past 2000 ms, the server is under-provisioned for the burst.

Fix:

• Stagger the reconnect storm: bring NASes back online one at a time, not all at once.
• Add CPU to the host — RADIUS is largely CPU-bound on cryptographic verification.
• Tune “ (env var on the radius container).

Still stuck?

Collect:

# Packet capture both sides
sudo tcpdump -ni any -vv -s 0 'udp port 1812 or udp port 1813 or udp port 1700 or udp port 3799' -w /tmp/radius.pcap

# Last 15 min of RADIUS + API logs
docker logs --since=15m proxpanel-radius > /tmp/radius.log
docker logs --since=15m proxpanel-api > /tmp/api.log

# NAS config
docker exec proxpanel-db psql -U proxpanel -d proxpanel -c \
  "SELECT id, name, ip_address, auth_port, acct_port, coa_port, is_active FROM nas_devices;" > /tmp/nas.txt

Send to info@proxrad.com with the MikroTik’s /radius print detail output and the panel version (curl -s localhost:8080/health).

Related pages

• PPPoE Auth Issues — when the packet does arrive and you get a rejection.
• NAS / Routers — secret, CoA port, allowed realms.
• Wrong Speeds — when CoA “succeeds” but the queue is wrong.