Skip to main content
eby
eby
New Member
January 28, 2017
Question

Strange RSSO issue in FortiOS 5.0.7 onwards.

  • January 28, 2017
  • 1 reply
  • 6816 views

Freeradius server is configured to send Radius accounting packets to our firewall running 5.0.7. Wireless users get network access thru Radius authentication. We use user email address as the username, and email address contain up to 55 characters. And on Fortigate, RSSO endpoint-attribute is set to user-name, so to display usernames in the logs and reports. This Setup was working fine up until November 2016. Somewhere in November, none of the RSSO users are able to access internet or other networks. Troubleshooting RSSO revealed "Parse error: Carrier Endpoint". When RSSO endpoint-attribute is unset, the users are able to access relevant networks and the Parse error vanished. Setting RSSO endpoint-attribute to User-name would work for few minutes and stop RSSO with the same "Parse error".

 

To resolve the issue, we have rebooted the firewall and finally upgraded to 5.2, the same problem persist ever after upgrading. Now the firewall logs/reports only show the client mac-address. Fortigate TAC team confirmed this as a bug after one month of followups and they have escalated to the engineering team. Till now no resolution. Have anyone here experienced this problem and know any workarounds for this ?. I need user names in firewall logs and reports. Thanks.

1 reply

xsilver_FTNT
Staff
xsilver_FTNT
Staff
February 1, 2017

Hi eby,

that might be relevant to the old (FOS 5.0.0 mid 2012) engineering bug #174693 we have seen a long time ago, which turned to not-a-bug but technological limitation of what RADIUS daemon inside the FortiOS can handle as endpoint attribute.

Limit was claimed as to be 48 bytes. I'm not sure that limit stayed the same but it is highly probable.

Those data are stored in memory, so limiting their volume to necessary minimum is good, as in result it will either use less memory or allow higher amount of the logged on users within same amount of memory consumed.

 

Therefore as a workaround I'd suggest to shorten User-Name or use another AVP as endpoint attribute.

Something which can still perfectly identify user or his workstation as source of the data, but is also considerably shorter.

 

Best regards,

Tomas

eby
ebyAuthor
New Member
February 16, 2017

Hi Tomas, Many thanks for the insights, do you work for Fortinet ?.

Shortening User-Name is not possible. If that 48byte user-name limitation is still there, any idea what other AVP supports at least 56byte length to be set as endpoint attribute ?. On Fortigate 5.2, the following can be set for rsso-endpoint-attribute, and for sso-attribute, i'm using "Class" to pass the user_group_name to Fortigate. 

User-Name
User-Password 
CHAP-Password
NAS-IP-Address
NAS-Port
Service-Type
Framed-Protocol
Framed-IP-Address
Framed-IP-Netmask
Framed-Routing
Filter-Id
Framed-MTU
Framed-Compression
Login-IP-Host
Login-Service
Login-TCP-Port
Reply-Message
Callback-Number
Callback-Id
Framed-Route
Framed-IPX-Network
State
Class
Session-Timeout
Idle-Timeout
Termination-Action
Called-Station-Id
Calling-Station-Id
NAS-Identifier
Proxy-State
Login-LAT-Service
Login-LAT-Node
Login-LAT-Group
Framed-AppleTalk-Link
Framed-AppleTalk-Network
Framed-AppleTalk-Zone
Acct-Status-Type
Acct-Delay-Time
Acct-Input-Octets
Acct-Output-Octets
Acct-Session-Id
Acct-Authentic
Acct-Session-Time
Acct-Input-Packets
Acct-Output-Packets
Acct-Terminate-Cause
Acct-Multi-Session-Id
Acct-Link-Count
CHAP-Challenge
NAS-Port-Type
Port-Limit
Login-LAT-Port
Thanks, Eby

xsilver_FTNT
Staff
xsilver_FTNT
Staff
February 17, 2017

Hi eby,

 

Q: do you work for Fortinet ?

A: yes, on TAC support center.

Therefore I have no direct access to the code to know the lengths of all possible attributes.

My previous idea was NOT to shorted username, or use another attribute which can hold that loooong username. Idea was to use another of user attributes, like email address or UserPrincipalName (UPN) or just anything which do serve both purposes:

- is short enough to be <48 bit long

- is unique user identifier

 

Therefore you'll be able to uniquely identify user who committed actions but without the limit hit.

 

Your other option is to contact our sales team and with their help open NFR (New Feature Request). Which is basically code change request which is not a bug but modification to enhance feature set or particular feature.

 

Best regards,

Tomas

Terms & ConditionsAccessibility statement