Client Authentication Agent disconnects each firewall rules changes

Hi Noel,

Nice observation!

The reported instance can be observed when you change the position of User based Firewall Rule. If you even toggle OFF "Match rule based on user identity", it can result in client disconnection. This is due to the architectural behavior of appliance.

Thanks

Hi Sachin, but in my case isn't only when change the position or  "Match rule based on user identity". Any change I do for a rule that applies to users, the Agent client disconnects after 10 seconds aprox.

Hi Noel,

Greetings.

That's rare. Have you upgraded to SF-OS MR 1.1 ? 

I think an upgrade will resolve the issue.

Thanks

Sachin

Hi Sachin,

Actually, I have upgraded to SFOS 15.01.0 MR-2 and the problem persists.
For example, I edited the rule to change the web filter policy, then client was disconnected and I need go to the computer, do a right click, set credentials, OK, to login again.

Sachin,

I am on MR2 and using MAC as client. Upgraded even the authentication agent but the problem persists.

Not a nice behavior. Everytime I have to go on the icon and reconnect! It could be an issue when is deployed in a small environment where 40 computer exist and the customer does not hold a AD architecture.

Also,

if on my MAC I close the lid, the Agent does not connects automatically. It should be a sort of heartbeat or retry process once the agent is being disconnected and a pop-up alerting the user that the agent is not connected anymore and it will reconnect automatically.

Client agent need to be improved!

Also,

if on my MAC I close the lid, the Agent does not connects automatically. It should be a sort of heartbeat or retry process once the agent is being disconnected and a pop-up alerting the user that the agent is not connected anymore and it will reconnect automatically.

Client agent need to be improved!

More observation on the subject.

Captive portal detection does work on a Mac, but it only works for a few minutes. I suppose it it designed to work with hotspots where grace period is somewhat longer than on XG.

I also don't think that client agent is here to be blamed because it wasn't changed and stopped to work. I think something was broken in captive portal code on the XG side.

The only workaround is to create clientless users but this solution has some drawbacks.

Hi Slawek,

The Captive Portal by default uses a Keep Alive packet in the browser window to maintain the log in, if the browser window/tab for captive portal is closed it will time out quickly (which will result in a log out)

The is an alternate tracking mechanism available whereby the active login is tracked by data transfer limits, basically you set a minimum transfer rate + time windows (for example 100 bytes in 3 minutes, change these numbers to suite your network)

System > Authentication > Authentication Services (right down the bottom of the page)

Also,

everytime a Policy is changed on XG, it is a nightmare.
Fix it!

[:@]