[Unifi] USG L2TP VPN not working with RADIUS Authentication

For quite a long time I was unable to connect to my network through VPN on the USG device. Unifi 6.4.54.0, and somewhere since 6.2.x or so..

Quick scroll for solution?!

Step-by-step

I connected through SSH to the USG to investigate, to see what went wrong when trying to connect. Below, you see the cut out from /var/log/messages when attempting to connect through VPN. (IP and username x’d out).

tail -15 /var/log/messages
Nov 10 21:03:32 Heimdal xl2tpd[974]: Connection established to 80.xx.xxx.xxx, 59435.  Local: 5857, Remote: 8 (ref=0/0).  LNS session is 'default'
Nov 10 21:03:32 Heimdal xl2tpd[974]: Call established with 80.xx.xxx.xxx, PID: 2174, Local: 64011, Remote: 3350, Serial: 1
Nov 10 21:03:32 Heimdal pppd[2174]: pppd 2.4.4 started by root, uid 0
Nov 10 21:03:32 Heimdal zebra[758]: interface ppp0 index 22 <POINTOPOINT,NOARP,MULTICAST> added.
Nov 10 21:03:32 Heimdal pppd[2174]: Connect: ppp0 <-->
Nov 10 21:04:05 Heimdal pppd[2174]: rc_send_server: no reply from RADIUS server setup.ubnt.com:1812
Nov 10 21:04:05 Heimdal pppd[2174]: Peer xxxxxx failed CHAP authentication
Nov 10 21:04:11 Heimdal pppd[2174]: Connection terminated: no multilink.
Nov 10 21:04:11 Heimdal zebra[758]: interface ppp0 index 22 deleted.
Nov 10 21:04:11 Heimdal pppd[2174]: Modem hangup
Nov 10 21:04:17 Heimdal kernel: Process 930 (freeradius) has crashed (parent 1 (init) signal 6, code -6, addr 000003a200000066), coredumps disabled

As seen it does make a connection, however appears to not get a reply from the RADIUS server, and then proceed to fail CHAP authentication. (Nice crash at the end there, freeradius, by the way).

…Investigating further into the VPN logs… (IPs x’d out).

show vpn log
Nov 10 21:03:30 15[IKE] <1> 80.xx.xxx.xxx is initiating a Main Mode IKE_SA
Nov 10 21:03:31 01[IKE] <remote-access|1> IKE_SA remote-access[1] established between 91.xx.xxx.xxx[91.xx.xxx.xxx]...80.xx.xxx.xxx[10.xx.xxx.xxx]
Nov 10 21:03:32 12[IKE] <remote-access|1> CHILD_SA remote-access{1} established with SPIs cddf1472_i 06729c76_o and TS 91.xx.xxx.xxx/32[udp/l2f] === 80.xx.xxx.xxx/32[udp/59435]
Nov 10 21:04:05 02[IKE] <remote-access|1> closing CHILD_SA remote-access{1} with SPIs cddf1472_i (1548 bytes) 06729c76_o (502 bytes) and TS 91.xx.xxx.xxx/32[udp/l2f] === 80.xx.xxx.xxx/32[udp/59435]
Nov 10 21:04:05 15[IKE] <remote-access|1> deleting IKE_SA remote-access[1] between 91.xx.xxx.xxx[91.xx.xxx.xxx]...80.xx.xxx.xxx[10.xx.xxx.xxx]
Nov 10 21:04:11 04[KNL] interface ppp0 deleted

Establishes connection, but quickly after kills connection and deletes the ppp0 interface. Didn’t feel like a firewall issue at this point.

So far it looks to be a RADIUS issue, so next log I checked was /var/log/freeradius/radius.log

sudo tail -25 /var/log/freeradius/radius.log
Wed Nov 10 20:03:35 2021 : Error: Ignoring request to authentication address * port 1812 from unknown client 13.37.0.1 port 40914
Wed Nov 10 20:03:45 2021 : Error: Ignoring request to authentication address * port 1812 from unknown client 13.37.0.1 port 40914
Wed Nov 10 20:03:55 2021 : Error: Ignoring request to authentication address * port 1812 from unknown client 13.37.0.1 port 40914

In here, there’s a match for several “Error: Ignoring request to authentication address * port 1812 from unknown client 13.37.0.1 port XXXXX” – any high-port.

As it appears, it is ignoring the request, due to the fact that it does not know the client.

Going back to the RADIUS page on the controller web UI, you can see the Configure clients section for whole network is indeed “not supported right now”. Doing a bit of good old Googlin’ narrowed it down to 2 solutions. One more silly than the other.

Solution 1

… from UI-Team https://community.ui.com/questions/USG-L2TP-issue-Authentication-Failed/17ecd602-5c95-4b35-8dd6-7fcacbfd892c#answer/88d832b6-3a68-490c-a3bb-d70b5fdbf29c

First off, this post confirms that there is indeed an issue configuring RADIUS using New Settings. The steps below will disable the RADIUS server, but the Clients tick box will be enabled after re-enabling the RADIUS server.

Suggestion is to SSH to the controller and type in the following commands:

mongo localhost:27117/ace
db.setting.deleteOne({"key":"radius"})
exit

This throws an error on my server, as I’m using an older version of MongoDB. Try the below code for removing if you get the same:

db.setting.remove({"key":"radius"})

Reloading the page and re-enabling the RADIUS server, we get the following:

… and more importantly – it worked.

Solution 2

…this is my favorite (and “silly”). https://community.ui.com/questions/L2TP-with-USG-Radius-not-working/4e82b542-f165-4356-ba52-d419f29722f8#answer/bec569d7-7947-407b-b43c-d5534107587d

Open eg. Chrome. Right-click on the checkbox in Clients and click Inspect.

Navigate to the part where it says disabled – mark it and delete it.

The checkbox will now be clickable – click it and remember to click the green APPLY CHANGES button.

For giggles you can run the following command when you attempt next connection to double verify your connection:

sudo tail -f /var/log/freeradius/radius.log

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *