Project

General

Profile

Bug #1013

Captive Portal Reauthentication broken

Added by L J over 8 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Captive Portal
Target version:
Start date:
11/16/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

B.0-BETA4 (i386)
built on Sun Nov 14 03:54:29 EST 2010

If the option "Accounting updates" with "no accounting updates
" is enabled nothing happens.

pfsense.pcap (1.43 KB) pfsense.pcap L J, 01/05/2011 02:24 PM
config-pfsense.20110105192745.xml (18.2 KB) config-pfsense.20110105192745.xml L J, 01/05/2011 02:26 PM

Associated revisions

Revision eb7aa263 (diff)
Added by Ermal Luçi over 8 years ago

  • Use exclusive locking for parts of config involving CP db.
  • Use more strict checking against empty/not set values for timeout and idletimeout
  • Do not overwrite idletimeout value with the per user idletimeout value during processing
  • Make distinction between radius accounting and re-authentication with radius to allow the code to be executed correctly. Ticket #1013

Revision d0d70b03 (diff)
Added by Ermal Luçi over 8 years ago

Ticket #1013. Force NAS_PORT to be of type integer to avoid it being interpreted as char and generate wrong radius packet.

History

#1 Updated by Chris Buechler over 8 years ago

  • Target version set to 2.0
  • Affected Version set to 2.0

#2 Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Closed

This is working as mentioned.
Read the radius accounting RFC to understand why.
You will get data only after the client is disconnected.

#3 Updated by L J over 8 years ago

But then there would be a bug in older beta releases and in 1.2.3 Stable.

There every minute the client is reauthenitcated.

#4 Updated by Chris Buechler over 8 years ago

  • Status changed from Closed to Feedback

#5 Updated by L J over 8 years ago

Please change status to new.

Bug1050:
As described in Bug#1013 the reauthentication feature is broken! I installed a 1.2.3 stable machine and configured the following:

X Reauthenticate connected users every minute

If reauthentication is enabled, Access-Requests will be sent to the RADIUS server for each user that is logged in every minute. If an Access-Reject is received for a user, that user is disconnected from the captive portal immediately.
Accounting updates

X no accounting updates
stop/start accounting
interim update

with this configuration the pfsense server sendsa radius authentication to the RADIUS server every minute.

If i do EXACTLY the same configuration with 2.0beta4 the logon pocess works but there a no packages witch are send to the RADIUS server every minute after authentication!

An update from the 1.2.3 to the 2.0beta4 does not work either (same result).

#6 Updated by Ermal Luçi over 8 years ago

I just committed fixes to this please test latest snapshots.

#7 Updated by L J over 8 years ago

Does still not work at
2.0-BETA5 (i386)
built on Sun Dec 26 01:03:42 EST 2010

Same behaviour.

#8 Updated by Ermal Luçi over 8 years ago

Can you give me a packet trace and your config.xml about this?

#9 Updated by L J over 8 years ago

I reinstalled pfsense from CD. I created the complete configuration via webinterface.

Is there any option to create a packet capture with pfsense?

#10 Updated by L J over 8 years ago

An internal server error happens if I try to upload the config.xml.

http://depositfiles.com/files/3dwu89fko

#11 Updated by L J over 8 years ago

There seems to be no feature for packet sniffing ;-). I used Wireshark at the RADIUS Server. The used user was test, the password 0000.

#12 Updated by L J over 8 years ago

config file again (now it works ?!?)

#13 Updated by Ermal Luçi over 8 years ago

I just tested this and it works fine.
19:02:26.807863 IP 192.168.30.1.30906 > pfSense.localdomain.radius: RADIUS, Access Request (1), id: 0x77 length: 126
19:02:26.808225 IP pfSense.localdomain.radius > 192.168.30.1.30906: RADIUS, Access Accept (2), id: 0x77 length: 26
19:02:27.564663 IP 192.168.30.1.39478 > pfSense.localdomain.radius: RADIUS, Access Request (1), id: 0xae length: 126
19:02:27.564953 IP pfSense.localdomain.radius > 192.168.30.1.39478: RADIUS, Access Accept (2), id: 0xae length: 26
19:03:27.111498 IP 192.168.30.1.40081 > pfSense.localdomain.radius: RADIUS, Access Request (1), id: 0xe5 length: 126
19:03:27.111854 IP pfSense.localdomain.radius > 192.168.30.1.40081: RADIUS, Access Accept (2), id: 0xe5 length: 26

Can you please do a ps -ax | grep prune?

The prunning process is run every 60secs by default possibly you are not waiting enough ?

#14 Updated by L J over 8 years ago

The command above gives no result. I captured the traffic for 2 minutes after logging in.

Could you please post whitch snapshot you used, I will retry.

#15 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to New

There is still a regression here with reauthentication. It does re-authenticate, but at least MS IAS refuses the request as malformed where it accepts the initial auth request.

A malformed RADIUS message was received from client pfs-test1. The data is the RADIUS message.

The exact same config on 1.2.3 re-authenticates fine, and gets an access-accept in response.

will email pcaps to Ermal.

#16 Updated by Ermal Luçi over 8 years ago

I just committed a fix for the issue Chris reported.

L J -> if you ahve no output from that command means you will never see re-authentication because the script that is supposed to do that is not running. Try upgrading to latest version and click again save with the proper options selected and see what happens.

#17 Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Feedback

#18 Updated by L J over 8 years ago

Update to new version did not work, reinstall did. Ticket could be closed!

Thx.

#19 Updated by Ermal Luçi over 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF