Everything was fine last week so I am not sure what happened. We are using an ext-jwt-signer, and the OIDC login flow works. We can still click on the authorize with IDP, login and the Desktop client shows we have a session.
But when we try to reach any service we get a connection refused error in the browser and those logs on my router pod.
Also the issue seems to persist even for non ext-jwt users (users with a JWT provided by the ziti controller itself).
Lastly, I also tested from a fresh mobile device using the ext-jwt signer and I can access services from my phone.
Seems like there could be an issue with the clients but I am not sure.
Hi @Tetrusp, I'm not exactly sure myself. Version 1.6.12 is marked as latest on github so my guess is that you've hit some sort of bug with 1.7. I am not sure, but I believe we had a couple related to ext-jwt-signers in 1.7 so that'd be my guess. I'd probably tell you to backup your database and then try out v1.8.0-pre4, but to be honest I'm not entirely certain that will fix it as I've not been involved in these bugs of late. It's the holidays here and now the weekend. I'll try to follow up on this next week sometime, sorry you're having a rough go of it and it's been a few days with no reply here... Cheers
If you can tolerate it yes. Since you're already ahead of our latest stable version I would definitely recommend updating controller and routers all to 1.8.0.pre-4. We've found and fixed bugs between 1.6.12 and 1.8.0.pre-4 and a many are in the ext-jwt-signer space.
Make sure you backup the controller database so you can revert if you must. I don't believe there's any state that you'd need to backup for routers so those should be easy to restore if you find something catastrophic, but my guess is all things will be smoother with the latest code.
I’ve updated the infra, the only issue I am running into is that users on Apple products (MacOS and IOS) are not able to reach services using the ext-jwt signer. Windows users seem to be fine.
For now I have them on the JWT provided by the controller as a workaround. This issue was also present in 1.7.x and the temporary solution for those users was to remove the identity and re-add it but over time the session would become invalid again.