Radius Authentication + Captive Portal + Mac Auth

CuteBoi

Version 2.2.2-RELEASE (amd64)
built on Mon Apr 13 20:10:22 CDT 2015
FreeBSD 10.1-RELEASE-p9

I have set up my Radius Authentication, using PAP protocol, I also enabled Radius MAC Authentication and specified a MAC authentication secret, configured the redirect pre auth url as needed, so I can do remote radius registration/management of MAC addresses for the user.

There is a custom portal page with this content:


If you are not redirected automatically, please click [here](#PORTAL_REDIRURL#/login?site=#PORTAL_ZONE#&mac=#CLIENT_MAC#)

I did not use the php redirect, because it would redirect too soon, before the PORTAL_ZONE and CLIENT_MAC are populated.

I also modified the NAS Identifier for post auth radius queries to Postgres.

So, the user goes to imgur, but can't so it is stuck loading/waiting, I see activity on the 'radiusd -X' at the remote end, and I see that the user is authenticated:

ad_recv: Access-Request packet from host <hidden>port 27301, id=239, length=124
	NAS-IP-Address = 10.0.100.75
	NAS-Identifier = "142"
	User-Name = "10:bf:48:05:b3:ea"
	User-Password = "radius_auth_mac"
	Service-Type = Login-User
	NAS-Port-Type = Ethernet
	NAS-Port = 2310
	Framed-IP-Address = 192.168.1.104
	Called-Station-Id = "10.0.100.75"
	Calling-Station-Id = "10:bf:48:05:b3:ea"
# Executing section authorize from file /etc/raddb/sites-enabled/service
+- entering group authorize {...}
++[preprocess] returns ok
[auth_log] 	expand: /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d -> /var/log/radius/radacct/<hidden>/auth-detail-20150430
[auth_log] /var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y%m%d expands to /var/log/radius/radacct/<hidden>/auth-detail-20150430
[auth_log] 	expand: %t -> Thu Apr 30 20:34:33 2015
++[auth_log] returns ok
[suffix] No '@' in User-Name = "10:bf:48:05:b3:ea", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[sql] 	expand: %{User-Name} -> 10:bf:48:05:b3:ea
[sql] sql_set_user escaped user --> '10:bf:48:05:b3:ea'
rlm_sql (sql): Reserving sql socket id: 4
[sql] 	expand: SELECT id, UserName, Attribute, Value, Op   FROM radcheck   WHERE Username = '%{SQL-User-Name}'   ORDER BY id -> SELECT id, UserName, Attribute, Value, Op   FROM radcheck   WHERE Username = '10:bf:48:05:b3:ea'   ORDER BY id
rlm_sql_postgresql: query: SELECT id, UserName, Attribute, Value, Op   FROM radcheck   WHERE Username = '10:bf:48:05:b3:ea'   ORDER BY id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: query affected rows = 3 , fields = 5
[sql] User found in radcheck table
[sql] 	expand: SELECT id, UserName, Attribute, Value, Op   FROM radreply   WHERE Username = '%{SQL-User-Name}'   ORDER BY id -> SELECT id, UserName, Attribute, Value, Op   FROM radreply   WHERE Username = '10:bf:48:05:b3:ea'   ORDER BY id
rlm_sql_postgresql: query: SELECT id, UserName, Attribute, Value, Op   FROM radreply   WHERE Username = '10:bf:48:05:b3:ea'   ORDER BY id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: query affected rows = 1 , fields = 5
[sql] 	expand: SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority -> SELECT GroupName FROM radusergroup WHERE UserName='10:bf:48:05:b3:ea' ORDER BY priority
rlm_sql_postgresql: query: SELECT GroupName FROM radusergroup WHERE UserName='10:bf:48:05:b3:ea' ORDER BY priority
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: query affected rows = 0 , fields = 1
rlm_sql (sql): Released sql socket id: 4
++[sql] returns ok
++[expiration] returns noop
++[logintime] returns noop
Found Auth-Type = Accept
Auth-Type = Accept, accepting the user
# Executing section post-auth from file /etc/raddb/sites-enabled/service
+- entering group post-auth {...}
[sql] 	expand: %{User-Name} -> 10:bf:48:05:b3:ea
[sql] sql_set_user escaped user --> '10:bf:48:05:b3:ea'
[sql] 	expand: UPDATE users SET site = %{NAS-Identifier} 	WHERE user_id = (SELECT user_id FROM macs WHERE address = '%{User-Name}') -> UPDATE users SET site = 142 	WHERE user_id = (SELECT user_id FROM macs WHERE address = '10:bf:48:05:b3:ea')
[sql] 	expand: /var/log/radius/sqltrace.sql -> /var/log/radius/sqltrace.sql
rlm_sql (sql) in sql_postauth: query is UPDATE users SET site = 142 	WHERE user_id = (SELECT user_id FROM macs WHERE address = '10:bf:48:05:b3:ea')
rlm_sql (sql): Reserving sql socket id: 3
rlm_sql_postgresql: query: UPDATE users SET site = 142 	WHERE user_id = (SELECT user_id FROM macs WHERE address = '10:bf:48:05:b3:ea')
rlm_sql_postgresql: Status: PGRES_COMMAND_OK
rlm_sql_postgresql: query affected rows = 1
rlm_sql (sql): Released sql socket id: 3
++[sql] returns ok
++[exec] returns noop
Sending Access-Accept of id 239 to 206.126.50.2 port 27301
	Mikrotik-Group = ""
Finished request 5.
Going to the next request</hidden></hidden></hidden>

I see it says Auth-Type = Accept, meaning it should have been accepted and added.

The user is directed to the PORTAL_REDIR_URL, when it should already be online, since the mac address exists, and the Accept Auth-Type is already set.

I previously cleared the Status > Portal Auth logs prior to testing this laptop to get online, but no logs have appeared since.

Is there anything I can provide to get some assistance, or is this a bug that I stumbled on?

CuteBoi

I also tested with a modified radtest program on a local box:

[ec2-user@ip-10-0-1-195 ~]$ radtest 10:bf:48:05:b3:ea radius_auth_mac localhost 2310 testing123
Sending Access-Request of id 16 to 127.0.0.1 port 1812
User-Name = "10:bf:48:05:b3:ea"
User-Password = "radius_auth_mac"
NAS-IP-Address = 10.0.1.195
NAS-Port = 2310
Message-Authenticator = 0x00000000000000000000000000000000
NAS-Identifier = "142"
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=16, length=20

I modified the radtest app to add in the NAS-Identifier with 142, since it's required, as it is sent by pfsense.

The user exists, the user is access-accept, not sure where I'm going wrong with pfsense.

CuteBoi

Fixed:

I had multiple routes behind a VPC and behind an elastic IP. the Elastic IP handled incoming, but the outgoing went through an invisible nat outbound.

The server would answer on the EIP, but the response was sent through a different public IP,

AWS doesn't allow hard binding to the public IP< so that was out of the question. I remove the ECS away from the VPC and assigned the EIP to itself, and gave it another interface for database access.

Problem resolved.