Voucher tickets fails sometimes after updating
-
Hi,
before starting i want to apologize for my english, my level is not very good.
I updated the version of pfSense from 2.0 to 2.4.3-p1 and in this moment all work correctly but there is a problem with the tickets, I did some tests and it seems that if a device has been conected previously with a ticket before the update it can't connect right now, but if the device has never been connected it works perfectly.
Has anyone the same problem or knows how to fix this problem?
I think it is possible that the problem can be the public key stored in the device but i'm not sure if this is the problem.
I'm going to search info about where to find the stored keys in the devices, but if you have more info i appreciate any help.
Thanks.
-
@becasist2 said in Voucher tickets fails sometimes after updating:
I’m going to search info about where to find the stored keys in the devices, but if you have more info i appreciate any help.
Keys are stored on the GUI page : Services => Captive Portal => [zone] => Vouchers
What do you see when a non used voucher is tested with Status => Captive Portal => [zone] => Test Vouchers
And already used, but still valid in time - voucher ?it seems that if a device has been conected previously with a ticket before the update it can’t connect right now
What was the error message ?
-
I wanted to say "where to find the stored key in the devices connected to the captive portal like smartphones, tablets or laptops", I know the public and private key is in Services => Captive Portal => [zone] => Vouchers.
When a device that has been previously connected tries to connect sometimes shows the Auth error page contents html file and sometimes returns to the index captive portal website and the tickets are correct because if I test it on Diagnostics / Test Vouchers it says that is correct.
Thanks for your reply.
-
@becasist2 said in Voucher tickets fails sometimes after updating:
I wanted to say "where to find the stored key in the devices connected to the captive portal like smartphones, tablets or laptops", I know the public and private key is in Services => Captive Portal => [zone] => Vouchers.
Northing is stored on devices.
A vouchers is like a unique login code - without password.Example : you could login using a navigator like Chrome, and then use IE or FF afterwards, your are still connected.
These browsers do not share cache - cookies or anything else.When a device that has been previously connected tries to connect some times shows the Auth error page contents html file and sometimes returns to the index captive portal website and the tickets are correct because if I test it on Diagnostics / Test Vouchers it says that is correct.
You saw this :
when testing a used vouchers ? -
@gertjan ![alt text]
That's right, I've tested one ticket and it doesn't work in a mobile phone that has been previously connected before the update, but the ticket appears like Active Voucher and it shows this message at testing it.
(https://imgur.com/a/iprkJjS)
-
@becasist2 said in Voucher tickets fails sometimes after updating:
mobile phone that has been previously connected before the update
Just to be sure :
See https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting
Use :ipfw table all listis the device "mobile phone" listed in the xxxx_auth_up and xxxx__auth_down tables?
Btw :
A reboot shouldn't change settings.
This means that vouchers generated before a reboot should work after a reboot.
Even updates / upgrades shouldn't interfere with already generated voucher, but : if the code that handles vouchers has been changed I'm wouldn't be surprised if 'old' vouchers didn't work anymore.
Also, there should be a place, probably a file, where the information is stored when a vouchers became active. I'm pretty sure this is not in main config file, the one you can save and restore. I'm wondering why it is stored elsewhere as this info should be persistent - should survive reboots and - if possible - upgrades.edit : they are here :
ls -al /var/db/voucher*Debugging the issue is possible, if your are friends with a lot of black magic code (public/private keys coding is not easy) and you understand all the in's and out's of openssl (the command line tool).
If not : consider used but not consumed vouchers as 'dead' hand over new ones.
Myself, I consider vouchers useful for small periods like an hour or max a day. If you need to deal with more time, consider FreeRadius. It has been invented for just that very reason.
-
No, a reboot doesn't fix it.
Using the commands ipfw table all list or <zone>_auth_up/down there isn't the device that it's trying to connect, but it's normal because it's not authentified yet, but the MAC is in the "pipe_mac" list.
In the Captive Portal Troubleshooting there isn't information about this particular topic.
About FreeRadius, this is not a possibility because this is not for my own using, it has to be adequated to the environment of a company.
Anyway, thanks for your help.I can "resolve" the problem adding the MAC in the pass-trough-mac list, but it's a patch, not a definitive solution.
If anybody had the same problem and the way to fixit i appreciate any help.
-
@becasist2 said in Voucher tickets fails sometimes after updating:
but the MAC is in the “pipe_mac” list.
So the device that can't connect has his MAC on this list : GUI : Services => Captive Portal => [zone] => MACs ?
On the Captive portal settings page, "Pass-through MAC Auto Entry" is set ?
-
No, it's not in the MAC or Pass-trough MAC list, but this is not necessary to connect using the Captive Portal.
The devices with the MAC included in those lists can connect without a Ticket, the devices without the MAC in this lists have to put the ticket code in the Portal Captive Index page, am I wrong?
-
@becasist2 said in Voucher tickets fails sometimes after updating:
The devices with the MAC included in those lists can connect without a Ticket, the devices without the MAC in this lists have to put the ticket code in the Portal Captive Index page, am I wrong?
Noop, you're right - it works like that.
