User Authenticated in Current Activities but not being used in Firewall/Web

What does the output of "ipset -L lusers" show for the source address ? when a packet comes into the LAN, the firewall first looks to see if it knows any "stas" status on it, if it does not it sends of a query to the collector, the collector will try and wmi query or registry query the client, and based on the results of the query from the collector to the client it will pass back the results to the firewall. During the query time its a bit of a grace period where traffic is allowed until the query times out or the collector responds.

the output of "ipset -L lusers" has 4 states: Learning, LearningRetry1, Unauthenticated. the other state is authenticated but it is indicated by the users numeric "id" being appended to the address within the output.

Learning: the first state an unknown packet has arrived

LearningRetry1: second attempt at correlating a user to ip

Unauthenticated: the Learning and LearningRetry1 phase unsuccessful, source address traffic dropped for time period defined by "unauth-traffic" value. 

It would be interesting to see what stas state your test system is in when you see the problem.

Tom

Could you also double check the registered AD servers, make sure the search queries are correct. You can also do a tail on the access_server.log it may shed light on the issue. 

>tail -f /log/access_server.log

Regards,

Tom 

Hi Tom,

As somewhat alluded to in the email, I think we are tangenting off into STAS territority which is far disconnected to the issue I am actually suffering.

However, Macs are on the same network as PCs, suggestion is unfeasible.

To put this thread back on topic, there is not issue with logon and logoff between devices on the network and STAS, the issue lies between the XGs Current Activities > Live Users and the ipset list wherein the user will be authenticated (Mac or Windows), briefly visible in the logging data with their name against actions, then will not be visible against logging data shortly later. You can still see the user in Current Activities > Live Users but ipset is now stating that the ipset IP is unauthenticated. Unless the XG is polling constantly to STAS to constantly check and it's constantly logging out the user from ipset but not Live Users, I think this issue is being caused by something else.

As mentioned in my previous couple of replies, rebuilding it completely and resetting the unauth timeout seemed to drastically help the issue.

Emile

Update: This is being investigated, will provide details as and when they are received. If anyone else discovers this, please feel free to pop your notes and findings down as well :)

Emile,

could you try out a STAS config on the XG with timeout set to 120 seconds and no user inactivity (Enable user inactivity option disabled)? Or even a fresh install with the settings I just specified.

Thanks

Hi Sivu,

Had done both, same behaviour. This does not look to be directly STAS related but how the XG does its unknown IP auth procedure and it looks like it may be interfering with normal log ons in some cases.

Emile

OK, was asking this because I've checked logs provided by Tom, and there there was some continuous login and (shortly after) logout going on, which could explain some side effect in the ipset. 

From what I've seen, this isn't a problem on the STAS side (as you confirmed) and also not on the authentication front, but with wrong information inside the ipset.

If you still face the issue after all this trying out, would be awesome if you could help us reproduce this.

Hi Sivu,

This issue is live in an environment that i can provide access to. I can see you are Sophos Staff so if you can email me then we can organise access to the environment it is currently occurring in.

Since early v17 i have noticed inflated numbers of logout logins but do not seem to be related to ipset.

Emile

Hello Sivu 

I am getting very concerned that we are getting to two weeks till v17.5 GA and I have an issue here which is binning 15% of all logged on traffic and in my eyes, this is quite a serious problem.

If you have managed to re-create this issue, please can you report that here and if you haven't then I have a live system with this issue on I can provide access to.

If v17.5 drops and it kills 15% of authenticated traffic that really isn't going to look good considering how near brilliant each major version deployment has gone in the past.

Emile

Emile has provided access to an appliance and several logs. The issue is being currently investigated offline.

I was having this issue also, when I rolled back to 17.1 users were matched against connections correctly.

Is it exactly like Emile described it? using STAS? or you noticed it using another authentication client.

Any detail you can spare would be really appreciated.

Thanks

Is it exactly like Emile described it? using STAS? or you noticed it using another authentication client.

Any detail you can spare would be really appreciated.

Thanks

Both STAS and RADIUS SSO. Users would display in the Live Users screen, but web filter logs would have no user against them. I was unaware of the ipset command, and am back on 17.1 where the issue does not occur.

Hi Dean,

That's really useful information and what you've described was the behaviour I was seeing which led me further to find what I have described above.

Can you provide an overview of your setup so we can try and align and understand more?

Like network config, size & number of devices/users, number of DCs, STAS config, general overview of the configuration of your XG?

Thanks,

Emile