How to protect against MAC spoofing in WiFi network?

Question

I have this scenario:
I want to create a WiFi network for a hotel that the customers should pay to gain access to the internet.
I tried Captive portal, but captive portal is very vulnerable against MAC spoofing.
So I tried wpa2-enterprise without Captive Portal. But NAS(Access Point) in wpa2-enterprise doesn't enforce any rule and each user had unlimited access.
Then finally I tried both together but after first authentication in wpa2-enterprise each user was able to change his/her MAC address to a any other user.
I'm using PFsense as RADIUS server and Mikrotik RB433 for Hotspot(Captive Portal) and wireless AP.

• Is there any way to prevent users from impersonating to an authenticated user in WiFi network with Captive Portal?
  

• Is there a reason that NAS in wpa2-enterprise doesn't enforce any policy or something is wrong in my configuration?
  These are the policies that PFsense generated in users file:

"amir" Cleartext-Password := "amir", Simultaneous-Use := "1"

    Framed-IP-Address = 10.1.3.85,
    Framed-IP-Netmask = 255.255.255.0,
    WISPr-Bandwidth-Max-Up := 50000,
    WISPr-Bandwidth-Max-Down := 50000,
    WISPr-Redirection-URL := http://www.google.com,
    pfSense-Max-Total-Octets := 10485760,

    Exec-Program-Wait = "/bin/sh /usr/local/etc/raddb/scripts/datacounter_auth.sh amir daily"

And this is clients.conf file:

client "mik" {
    ipaddr = 10.1.2.2
    proto = udp
    secret = 'admin123'
    require_message_authenticator = no
    nas_type = other
    ### login = !root ###
    ### password = someadminpass ###
    limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
    }
}

Answer 1

You cannot prevent the user from changing their MAC address. The MAC address is provided by the client and can be changed at any time assuming their hardware allows them to do so. If you are relying on the client machine for implementing an effective control, you will fail because it will be able to be avoided. Most users will not change their MAC address, but a dedicated user can do so without consequences.

In addition, captive portals are a security anti-practice. As outlined in this article, you are basically intentionally tampering with the user's traffic to substitute your content instead of the content they wanted to see, and by any typical definition of network security, that makes you a malicious man-in-the-middle party. In other words, you are a bad actor. Moreover, because most sites are HTTPS with STS these days, it's very hard for a user to actually see your captive portal because their browser literally won't let them in many cases.

You should adopt a solution which doesn't rely on the security of the client and doesn't implement a MITM attack. For example, you could have a set of randomly generated passwords, each one expiring on a different day of the week, and have the person call the front desk to add the charge to the room and get a password. While it would be able to be shared amongst a group, it would not be any less secure than your existing approach and would be less hostile to your users. You could additionally add a limit on the number of MAC addresses as long as you realized that a dedicated user can evade it.