Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Does PfSense support Change-of-Authorization (CoA) packets?

    Scheduled Pinned Locked Moved
    Captive Portal
    2
    4
    724
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      nemesisdev
      last edited by

      Does PfSense support "Change-of-Authorization (CoA) Messages"?

      I need to change the Session-Timeout of some logged-in users when they perform some account verification actions while being logged in. I tried logging out the users and log them in again but after logging them out it takes a long time for the user to be able to do HTTP requests again which basically breaks this functionality.

      GertjanG 1 Reply Last reply Reply Quote 0
      • GertjanG
        Gertjan @nemesisdev
        last edited by

        @nemesisdev said in Does PfSense support Change-of-Authorization (CoA) packets?:

        it takes a long time for the user to be able to do HTTP requests again which basically breaks this functionality

        As you already know, the captive portal login page shows up immediately.
        It does so, because the OS of the device you are using, does a test right after the network connection comes up. This event happens when you plug in the network cable, or when you select a Wifi network.
        A very know event at that moment is : the DHCP clients kick in, and asks for a IP, mask, gateway and DNS.
        After this DHCP event, a less known event is happening : your Windows PC, Samsung phone, iPhone, portable etc etc also does a http (not https !) request. Every OS has its own hard coded http URL for this.
        For an iPhone or MAC, this is "http://captive.apple.com". The returned file (page actually) should read the word "Success". Click on the link to see for yourself. If that isn't that case - and itw ill not be the case if your device is behind a captive portal, the OS will launch a web browser, and instructs this web browser to visit (again !) the same "http://captive.apple.com".
        Again, something comes back. And this something is ... your captive portal login page. The user can interact with this page.

        Actually, we tend to say that pfSense has captive portal capabilities.
        Not entirely exact. The devices we use have captive portal capabilities.
        pfSense is just using a firewall with some rules and a mini web server. And voila : the captive portal is created.

        So, the answer is : if the user provokes a network down->up event, he can login right away, as he executes the needed 'network' sequence.
        Or have them visit some known "http" only site (not https), like the one I sited above.
        Remember : "http" request can get redirected without our browser complaining. This is not possible with "https" requests.
        And no, you can't visit https://www.google.com because your browser has contacted this site before, and already knows ( and for the next 12 months !!! this is HSTS working for you) that a https version exists, so your nrowser will force the https version ... and that request can't get redirected.
        redirection. This is what TLS is all about.

        Think about it : pfSense uses a couple of firewall rules, and a browser that intercepts "port 80" = http traffic. If the user isn't logged in, the traffic falls through the firewall rules, to hit the last rule where http (port 80) traffic is redirected to the captive portal login page server.

        after logging them out it takes a long time for the user

        if the user want to wait for some magic happens, then, yeah, maybe the OS will test the connection again, as it knows that the connection isn't pretty unusable at the moment.
        So : they wait ....
        Or do the wifi or cable hardware trick.
        Or they visit a known http only site.

        Btw : "Change-of-Authorization (CoA) Messages" is a (Free) Radius thing.

        No "help me" PM's please. Use the forum, the community will thank you.
        Edit : and where are the logs ??

        N 1 Reply Last reply Reply Quote 0
        • N
          nemesisdev @Gertjan
          last edited by

          @gertjan I have 3 different pfsense instances and I tested this on all 3 of them. After log out from captive portal, any HTTP request to allowed hostnames or ip address, fails. Making the functionality I described in my original post impossible to implement. I had to resort to an arbitrary sleep time of several seconds and a "please wait" message.

          1 Reply Last reply Reply Quote 0
          • N
            nemesisdev
            last edited by nemesisdev

            I want to bring up this subject again.

            CoA, Change of Authorization, basically consists in a UDP packet which a RADIUS server can send to a NAS (like the pfSense captive portal) to change reply attributes or disconnect a user.

            This is particularly helpful in implementing authorization flows in which the user gets a basic connection first and then is upgraded to different limitations (eg: more bandwidth, more traffic, more connection time, etc).
            It also helps to manage radius sessions for multiple NAS from a central point.

            I have been able to implement something with Coova-Chilli, which supports CoA and I think it would be great for PfSense to support this as Chilli does so I opened a feature request: https://redmine.pfsense.org/issues/13625.

            CoA RFC https://www.ietf.org/rfc/rfc3576.txt.

            Peace.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post