RADIUS — Access Reject when issued from AP

UCS - Univention Corporate Server
,
#1

Hello there,

I am trying to integrate a UCS into our infrastructure, such that the UCS acts as: DHCP-, DNS- and RADIUS Server for our network.

The setup is like that:

Our router is a UDM Pro and therein I have created a network like that:

iprange: 10.42.7.0/24
first IP: 10.42.7.10
last IP: 10.42.7.254
DHCP-Relay: 10.42.7.2
GATEWAY: 10.42.7.1

The UCS is running within a VM on my laptop, which itself has a fixed IP (10.42.7.3)

The Network setup of the UCS is:

IP (static): 10.42.7.2
Gateway: 10.42.7.1
External DNS: 10.42.7.1

Additionally I have installed the radius and dhcp app. The Network is configured to use that dhcp and both - dhcp and dns - are working. Launching a second VM shows that a suitable ip is obtained as well as pinging the local domain of the UCS.

Logging into the UCS via ssh and running:

root@ucs:~# univention-radius-check-access --username=hans.wurst --station-id ""
 …
      INFO: [user=hans.wurst; mac=:::::] User is allowed to use RADIUS
     DEBUG: [user=hans.wurst; mac=:::::] --- Thus access is ALLOWED.

Shows that the user may use the network.
BUT logging into the Access Point and running:

sudo tcpdump -npi eth0 port 1812

shows:

12:13:55.253682 IP 192.168.1.32.34550 > 10.42.7.2.1812: RADIUS, Access-Request (1), id: 0x01 length: 233
12:13:55.255011 IP 10.42.7.2.1812 > 192.168.1.32.34550: RADIUS, Access-Challenge (11), id: 0x01 length: 64
12:13:55.281334 IP 192.168.1.32.34550 > 10.42.7.2.1812: RADIUS, Access-Request (1), id: 0x02 length: 242
12:13:56.306366 IP 10.42.7.2.1812 > 192.168.1.32.34550: RADIUS, Access-Reject (3), id: 0x02 length: 44
12:14:06.636493 IP 192.168.1.32.34550 > 10.42.7.2.1812: RADIUS, Access-Request (1), id: 0x03 length: 233
12:14:06.639879 IP 10.42.7.2.1812 > 192.168.1.32.34550: RADIUS, Access-Challenge (11), id: 0x03 length: 64
12:14:06.662891 IP 192.168.1.32.34550 > 10.42.7.2.1812: RADIUS, Access-Request (1), id: 0x04 length: 242
12:14:07.685997 IP 10.42.7.2.1812 > 192.168.1.32.34550: RADIUS, Access-Reject (3), id: 0x04 length: 44

So when Authentication is issued from the AP it is rejected in each an every case. I guess that this is somewhat connected to the fact that the AP is in a different network (192.168.1.32) - but that is nothing but a theory.

/etc/freeradius/3.0/clients.conf contains:

client intranet {
  ipaddr = 192.168.1.0/24
  secret = testing123
}

What am I missing here?

UPDATE

Above I have not mentioned that I have tried to connect my Laptop, which is the host of the UCS, to the wlan and that just did not work. But using my mobile just worked.

#2

Really you should be trying to run the VM inside a server, but not on your own network, it’s potentially dangerous as regards creating traffic that can seriously mess with your network.

Generally I reconstruct the whole network inside a computer with various VM’s acting as the critical systems.and if i need to run wifi, I attach an AP to that server., generally this is NOT connected to my corporate network.

even with this setup I have run into all sorts of problems trying to use the “host” as a computer as well as hosting the VM’s, it makes the NAT far too complex,

it might be your laptop is running services and you try to get it to change state by connecting those services to other MACS/ip addresses (wifi),

generally i leave the host alone, then use a spare scrap computer to act as the client.

Thre is another option of course…, you spin up some client computers (win 10) as vm’s inside you host and use THOSE for testing…
but this is why i have a workstation with 128GB ram… and several gen 4.0 SSD’s

#3

Thanks a lot for Answer!

it’s potentially dangerous as regards creating traffic that can seriously mess with your network.

Somehow I would be interested to know what makes this sort of traffic »dangerous«, but right now it is really enough to know that my obscure lab setup has it’s limits. I really do not have another PC around, so this was my only option.

it might be your laptop is running services and you try to get it to change state by connecting those services to other MACS/ip addresses (wifi),

That sounds pretty reasonable, since the Laptop is a Linux running »NetworkManager« there might happen all sorts of things.

you spin up some client computers (win 10) as vm’s inside you host and use THOSE for testing…

That’s exactly what I did (but with debian clients) in order to figure out if dhcp and dns is working. But those VMs do not have a wireless adapter, or I couldn’t make that happen at least.

Again, thanks a lot!

#4

Finally I think I found the answer to all this wired stuff :wink: It was the WLAN Security Configuration of the Network on my Laptop. It wasn’t set to PEAP so authentication didn’t work …

Mastodon