FreeRADIUS Login incorrect when setting subnetmask / gateway

slth

Hi all

I am new to both FreeRADIUS and pfSense so please forgive me if this is a stupid question.

What I am trying to do is set up a captive portal with all users and their attributes stored in FreeRADIUS. Moreover, I'd like to specify which ip address, subnetmask and gateway each user should be forced to use.

When I set subnetmask and gateway at the FreeRADIUS: Users tab, each user is unable to login at the captive portal page saying "Login incorrect: [user/password] (from client cportal port 2 cli 00:00:00:00:1a:00)"

If I only set the IP address tab, FreeRADIUS does accept the login:

rad_recv: Access-Request packet from host 192.168.1.1:41977, id=225, length=121
NAS-IP-Address = 192.168.1.1
NAS-Identifier = "pfSense.lan"
User-Name = "user"
User-Password = "password"
Service-Type = Login-User
NAS-Port-Type = Ethernet
NAS-Port = 3
Framed-IP-Address = 192.168.1.2
Called-Station-Id = "192.168.1.1"
Calling-Station-Id = "00:00:00:00:1a:00"
Login OK: [user/password] (from client cportal port 3 cli 00:00:00:00:1a:00)
Sending Access-Accept of id 225 to 192.168.1.1 port 41977
Framed-IP-Address = 192.168.1.27

but fails to force the user to use IP Address 192.168.1.27.

How can one force each FreeRADIUS user to use specific network settings after they have been successfully authenticated?

Thanks a lot :)

Nachtfalke

Try to enter this for gateway:

192.168.1.0 192.168.1.1 1

first is subnet:
second is gateway-IP
third is metric
separated by spaces
http://freeradius.org/rfc/rfc2865.html#Framed-Route

Not all freeRADIUS attributes are working really good. Some are just hacked in the config-files and GUI.

slth

Thanks for your reply.

I tried setting the /usr/local/etc/raddb/users file to the folllowing:


user           User-Password == "password", Simultaneous-Use := 1
                Framed-Route = "192.168.1.0/24 192.168.1.1 1",
                Framed-IP-Address = 192.168.1.24

FreeRADIUS reply:


rad_recv: Access-Request packet from host 192.168.1.1:2832, id=160, length=121
        NAS-IP-Address = 192.168.1.1
        NAS-Identifier = "pfSense.lan"
        User-Name = "user"
        User-Password = "password"
        Service-Type = Login-User
        NAS-Port-Type = Ethernet
        NAS-Port = 2
        Framed-IP-Address = 192.168.1.2
        Called-Station-Id = "192.168.1.1"
        Calling-Station-Id = "0:00:00:00:1a:00"
Login OK: [user/password] (from client cportal port 2 cli 0:00:00:00:1a:00)
Sending Access-Accept of id 160 to 192.168.1.1 port 2832
        Framed-Route = "192.168.1.0/24 192.168.1.1 1"
        Framed-IP-Address = 192.168.1.24

But still, the user has its dhcp lease configured by the pfSense DHCPd. When I try with a static ip in the same /24 range as the LAN if, the captive portal isn't even working ???

cmb

RADIUS attributes cannot configure client IPs with captive portal, captive portal has no ability to control client IPs.

slth

Should I then be looking at an external (Free)RADIUS server where clients must authenticate using user credentials at the 802.1X authentication (for windows systems)?

Nachtfalke

@slth:

Should I then be looking at an external (Free)RADIUS server where clients must authenticate using user credentials at the 802.1X authentication (for windows systems)?

The problem in your case seems to be the captive portal. It doesn't matter which RADIUS server you are using as long as the captive portal cannot handle it.

slth

I just want to be able to do AAA for ~30 users, a captive portal isn't compulsory.

As the LAN doesn't have managed switches, I thought of giving each user their own user credentials, which then are stored together with the mac address.
Users are only allowed access if their credentials match AND their mac address. This way, they'd need both to exchange credentials and spoof the mac address to get access.

What I meant with my previous post was this 802.1x authentication tab in windows:

After there has been a successful authentication, I would like to force each user to have their specific ip address.

Using this method, I could then set up a policy regarding a bandwidth quota, QoS etc for each user being more or less sure they are the ones I think they are, without having to set up certificates manually on each client.

Does this solution make any sense?

Thanks for all your help so far!

Nachtfalke

I am no RADIUS expert but think about that:
A client is connected to a switch, access point, captiveportal. The user send the credetials to one of these three parts.
After this the switch, captiveportal, AP first block the access of the client until they get a positive response from the RADIUS. The RADIUS only tells "yes" or "no" in simple words. And after that the switch, CP, AP just reacts on the response. Of course the RADIUS could transmit additional options like IP addresses but then the switch, AP, CP must be able to handle that.

So if you just have clients and a RADIUS server and the clients are sending the credetials to the RADIUS itself what should the RADIUS do. If RADIUS tells "no" then there is no additional hardware which blocks the client. There is no additional hardware which can check if the client is using the correct IP of if the client spoofed the MAC.

There is no way around network hardware which can communicate with RADIUS as far as I know.

Couldn't you assign static IP addresses by DHCP ? Disable concurrent connections on captive portal so there could be only one connection per MAC. CaptivePortal recognizes if someone is connected and changed IP or MAC.

slth

Assigning static ip's by DHCP was my first thought all along, until I read http://doc.pfsense.org/index.php/Why_can%27t_I_have_static_mappings_inside_my_DHCP_range%3F

ISC dhcpd only checks via ping to ensure that an IP is not actively in use when making assignments. Making a static mapping does not "reserve" that IP out of the pool. The static mapping in this case merely represents a preference for an IP, and others are not prevented from taking the IP if it is not in use.

So suppose I'd have a DHCP pool 192.168.0.10-192.168.0.50 with static IP mappings for ip 192.168.0.20 and 192.168.0.30, associated to the respective mac addresses.

When ISC dhcpd doesn't receive a valid ping reply for 192.168.0.20, it could assign this ip address to a mac address that isn't entitled to this ip address?

Also, depending solely on the mac address to identify the physical user would be not so secure. Mac addresses are easy to spoof and would enable users to bypass quota / bandwidth restrictions.

wallabybob

@slth:

ISC dhcpd only checks via ping to ensure that an IP is not actively in use when making assignments. Making a static mapping does not "reserve" that IP out of the pool. The static mapping in this case merely represents a preference for an IP, and others are not prevented from taking the IP if it is not in use.

So suppose I'd have a DHCP pool 192.168.0.10-192.168.0.50 with static IP mappings for ip 192.168.0.20 and 192.168.0.30, associated to the respective mac addresses.

The text you quoted is meant to say that DHCP static IP mappings must be outside the range reserved for dynamic IP addresses. So if you have a DHCP pool of 192.168.0.10 to 192.168.0.50 you can have (for example) static DHCP mappings for 192.168.0.60 and 192.168.0.70.