captive + radius doesn't seems to work.

[seborin]

hi all. I'm migrating from Monowall to opnsense 15.7. unfortunatelly the config is not portable. In mono I was already using a radius server and all was working perfectly. In opn  for some reason It does not. The radius is on wan zone, receive requests and provide answer to the opn: " Access-Accept" but the auth login page provide a "error sending request: Non valid RADIUS RESPONSES received".
Is there something I should do/enable? I also have a rule: tcp/udp accept all in wan adress, which is the side the radius is located. This should allow everithing from that zone.

in logs/firewall the relative track is:

@61 pass in log quick on bge0 reply-to (bge0 192.168.2.98) inet proto udp from any to 192.168.2.38 keep state label "USER_RULE: tutto da zenone"

which seems it means the answer did pass.

furthermore in mono I had a rule "any -> 192.168.2.50    radius server" which did enable browsing that server also before authentication. the same rule in opnsense redirects me to the login page.

any help is really wellcome.

Sebastiano

[franco]

The RADIUS backed has a couple of issues, especially WRT accounting. It's on my mid-term TODO list.

Authentication is working in general, there are some tips to troubleshoot in this thread:

https://forum.opnsense.org/index.php?topic=686.0

Under "Diagnostics: Authentication" you can test your RADIUS server set up under "System: User Manager: Servers". Note this is not for the captive portal, only for testing/troubleshooting.

[seborin]

Hi Franco, tnx for the quick answer.
I did configure the server under "system autentication/servers" where there's no much to mistake. ip and shared secret. diagnostic authentication do not even reach the radius server. No track. I mean:
radiusd -X do not even receive requests .. (where is the radius server supposed to be for the test? wan or lan?)

while with captive and radtest and monowall it does.

I already read the post you suggested me but jstrebel left us with a question point:
"will be back in the office end of the day. Will report tomorrow. Jakob"
so now I don't know wich rule has to be setted up.

I'm sorry to bother but I have no ideas.
anywhay I guess the point is close to an access rule allowing the answer from the radius to get in or to the right interface. since the radius answers "ok -- access granted" and the CP do not even hear the answer.


cheers
Sebastiano

[seborin]

with the diagnostic authentication the diagnostic answers:
The following input errors were detected:
    Authentication failed.

the radious answers:

rad_recv: Access-Request packet from host 192.168.2.38 port 11723, id=203, length=69
NAS-IP-Address = 0.0.0.0
NAS-Identifier = "OPNsense.axess"
User-Name = "r999"
User-Password = "999"
# Executing section authorize from file /usr/local/etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok ++[chap] returns noop
++[mschap] returns noop ++[digest] returns noop
[suffix] No '@' in User-Name = "r999", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns updated
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
Found Auth-Type = PAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "999"
[pap] Using CRYPT password "$1$VNqD1/Xj$RSqCIQ0DAL5o/VglmDnrn/"
[pap] User authenticated successfully ++[pap] returns ok
# Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/default
+- entering group post-auth {...}
++[exec] returns noop
Sending Access-Accept of id 203 to 192.168.2.38 port 11723
Finished request 1.
Going to the next request
Waking up in 4.9 seconds.
rad_recv: Access-Request packet from host 192.168.2.38 port 11723, id=203, length=69
Sending duplicate reply to client 192.168.2.38 port 11723 - ID: 203
Sending Access-Accept of id 203 to 192.168.2.38 port 11723
Waking up in 4.9 seconds.
Cleaning up request 1 ID 203 with timestamp +1141
Ready to process requests.