JSON encoding/decoding error (maybe VPN-dialup & split-DNS related)



  • Hi Forum,

    For some time now, a user has been getting this error repeatedly, with the intervals between errors varying, sometimes more frequently, sometimes not for a long time:
    webapp_JSON_error.png

    Both under WebApp and with DeskApp (2.5.4 win). It appears in the email list view soon after login (without further action) and also, for example, when the mail editor is open.

    Addendum: But if I open the user account as admin-user with DeskApp (also V2.5.4 but Ubuntu_18.04-amd64) as shared account, I don’t get any error messages.

    Addendum2: The time intervals between the errors vary, sometimes more often, sometimes not at all

    Thanks for every hint,
    Robert

    Client system: Win10 (Home)
    WebApp: 3.5.14.2539+111.1
    Kopano Core: 8.7.9
    Server System: UCS 4.3



  • Our research now suggests that the occurrence of the error has something to do with a simultaneous VPN dialup connection (from the home office, it’s a BYOD without domain membership) to the internal company network (where the Kopano server is also located).
    This morning, the errors started to accumulate again with this user, whereupon he terminated the VPN tunnel rather accidentally and then the errors disappeared abruptly.
    When he restarted the VPN tunnel, the errors did not come back, but this was also variable before.
    We use split DNS for the WebApp URL or the respective FQDN, i.e. the internal DNS (Univention UCS) resolves this FQDN “gate.company.tld” to the internal IP address of the Kopano/WebApp server, for external accesses the FQDN “gate.company.tld” is resolved by public DNS to a WAN address of the perimeter firewall, which then passes the sessions on to the inside.
    In my understanding, the network traffic should run completely over the VPN from the start of the VPN tunnel (this is where the internal DNS comes in), even for WebApp.
    Of course, it is possible that WebApp access was started before the VPN login, but shouldn’t it make no difference within a session on which network path the server is reached?

    Does anyone know this problem, should it be a classic homeworker scenario, especially these days? And what can you do about it?

    TIA Robert


  • Kopano

    Hi @PRO123,

    I don’t think this is a particular problem with vpn or split-dns in general, but sounds a bit like establishing the new connection kills existing ones, which then leaves webapp with incomplete requests.

    I’d recommend to take a look into the network tab in your browser to see how these connections are handled. Maybe open a support case if you need direct developer help.



  • @fbartels said in JSON encoding/decoding error (maybe VPN-dialup & split-DNS related):

    but sounds a bit like establishing the new connection kills existing ones, which then leaves webapp with incomplete requests.

    But what then means that you must not start Web-/DeskApp with Split-DNS addressing before a possible VPN dial-in, because Web-/DeskApp is sensitive to this change of the network path to the server?

    We can live with it now (now that we seem to have recognized the problem), but it’s still not very nice. Maybe Web-/DeskApp could try to retry the unanswered requests up to a certain timeout before it throws errors. These further request attempts should then be successful again via VPN.
    In addition, after the VPN dialup these errors should stop after a certain amount of time, but this seems not to be the case.

    Anyway, thanks for your help, maybe there is still room for improvement in Web-/DeskApp in the future.

    Robert


  • Kopano

    @PRO123 said in JSON encoding/decoding error (maybe VPN-dialup & split-DNS related):

    But what then means that you must not start Web-/DeskApp with Split-DNS addressing before a possible VPN dial-in

    I am not sure if i can agree to that statement. I have no problems here switching between (vpn) connections.

    Like I said I would recommend to have a look into the network tab of your browser console. There you should indentify the request that throws above error. maybe there you will also see a reason why.


Log in to reply