IBM Security i2

Expand all | Collapse all

iBase error entering via VPN

  • 1.  iBase error entering via VPN

    Posted Thu February 04, 2021 03:52 PM

    Hello community

     

    We are working with iBase 8.9.11. Due the pandemic situation we need to start working from home using VPN.

     

    When we try to access the iBase databases from outside the network via VPN we get the following error:

     

    SQL Server Network Interfaces: Error Locating Server/Instance Specified [xFFFFFFFF].

    Se produjo el error #-2147467259 en:

    Microsoft SQL Server Native Client 11.0

    idDBEngine:mGetADOConnection

    idDBEngine:Connect

    idDBConnection:Connect

    CDatabases:DoOpen

     

    There is no problem using iBase inside the network.

     

    We have done some tests:

    • .idb and .ids are in the same folder
    • User has permissions to writhe in the directory where .idb and .ids are located.
    • Firewall for the windows server are with profiles off.
    • We did a telnet from the external PC and we were able to ping the ip and port.

     

    Do you have any recommendations to solve this issue?

     

    Thanks and regards,


    Fabricio

     



    ------------------------------
    Fabricio Silveira Alvez, CFE.
    ------------------------------


  • 2.  RE: iBase error entering via VPN

    Posted Fri February 05, 2021 04:23 AM
    Hello Fabricio


    I cannot provide a solution to this, but I can at least provide some hope. 

    We too currently have a number of staff mostly working from home using a VPN and we connect to our iBase server (and for the moment we are still on v8.9.11), so it is feasible.

    I am an iBase admin from the business end rather than the ICT technical end so I do not have details as to how it works.  I do not know what VPN provider we are deploying, but I can state that the entire laptop build is VPN enabled by default rather than turning the VPN on for specific services.  The laptop has limited 'offline' functionality from any locally installed apps, but as soon as the laptop is connected to WiFI or a 4G dongle service, the VPN forms a secure connection back to our network.  Once that secure connection is in place, we can navigate to the file server where our iBase .idb and .ids files are hosted and open the database.

    That isn't to say we haven't had any issues.  iBase is bandwidth hungry (esp any v8.9.x builds), and if the VPN doesn't have enough available bandwidth to cope with traffic iBase demands, iBase can crash out with messages similar to the above.  Just after the first lockdown in the UK last March started, we discovered many of our users could not get into iBase during normal office hours because of the demands on the VPN - they were having to run their iBase searches in the evenings or very early in the morning before the majority of colleagues began their working days.  The only solution was to expand the amount of VPN capacity.

    A further piece of advice on that last point - if iBase crashes because of VPN bandwidth issues whilst someone is using the database, the .ids file can become locked (an error message describes this file as set to "read only") and prevent other users from opening the database once the VPN has sufficient bandwidth again.  The fix is simple - replace the .ids file with a back-up copy.  In line with that, I would suggest that:-
    (a) you take a backup copy of the ids file any time you make a change to the account permissions i.e. add a user, delete a user, change a user's own permissions.
    (b) you recommend that anybody working from home via VPN only has iBase running when they actively need it and shuts the system down afterwards, rather than just leave it open all day.  This will reduce the possibility of the ids file becoming locked because of a crash.

    I hope you get this resolved.


    Ant

    ------------------------------
    Anthony Patamia
    ------------------------------



  • 3.  RE: iBase error entering via VPN

    Posted Fri February 05, 2021 04:31 AM
    Edited by Simon Griffiths Fri February 05, 2021 04:45 AM
    Can you ping the server by its name (rather than IP address)? Maybe DNS issues?

    Alternatively, can you connect to SQL Server through SQL Server management studio on the client to see if that works?

    ------------------------------
    Simon Griffiths
    ------------------------------



  • 4.  RE: iBase error entering via VPN

    Posted Mon February 15, 2021 12:24 PM

    Hello Anthony ,

    We have made several tests at a low connection time and the problem persists. In this case bandwidth is not the cause.

     

    Thanks for your answer

    Regards, 



    ------------------------------
    Fabricio Silveira Alvez
    ------------------------------



  • 5.  RE: iBase error entering via VPN

    Posted Mon February 15, 2021 12:32 PM

    Hello Simon.  Sorry for the delay in the answer. 

     

    We can ping the server and we can access SQL server with no problem.  The problem only happens using iBase. 

    Regards, 



    ------------------------------
    Fabricio Silveira Alvez
    ------------------------------



  • 6.  RE: iBase error entering via VPN

    Posted Tue February 16, 2021 01:04 AM
    Hi Fabrizio

    I just wanted to ask if you have submitted this as a support ticket to our i2 suppport.

    Let me know if you have not and I can help you get in contact with support

    ------------------------------
    Martin Kragh
    ------------------------------



  • 7.  RE: iBase error entering via VPN

    Posted Tue February 16, 2021 01:09 AM

    Hello

     

    We also have many people working from home, using a couple of different processes to get a secure connection to the office environment.  Our iBase and Analyst's Notebook applications are hosted in a virtual environment rather than installed on individual desktops.  We use Citrix to log into the applications.  The back end SQL databases are on a separate server.  It makes no difference with this configuration whether the user is in office, logging onto a desktop computer or sitting at home, logging in via a VPN. We haven't had any issues with iBase databases being slower when working from home.

     

    Regards

     

    Caroline

     

     

     

     

     

    Caroline Cuthbert

    Assistant Director | A&IP Systems Support
    Data Engineering | Smarter Data

    Australian Taxation Office

     

    **********************************************************************

    IMPORTANT

        The information transmitted is for the use of the intended

    recipient only and may contain confidential and/or legally

    privileged material. Any review, re-transmission, disclosure,

    dissemination or other use of, or taking of any action in

    reliance upon, this information by persons or entities other

    than the intended recipient is prohibited and may result in

    severe penalties. If you have received this e-mail in error

    please notify the Privacy Hotline of the Australian Taxation

    Office, telephone 1300 661 542 and delete all copies of this

    transmission together with any attachments.

    *********************************************************************






  • 8.  RE: iBase error entering via VPN

    Posted Tue February 16, 2021 04:57 AM
    Edited by Simon Griffiths Tue February 16, 2021 06:46 AM
    A remote desktop solution (Citrix, Microsoft Remote Desktop, LogMeIn or similar) as discussed in Caroline's post above is generally a better answer for using iBase remotely.

    There are several reasons for this...primarily iBase is not very tolerant of disconnections from the SQL Server which are more likely in remote working - switching from one wireless access point to another for example. Secondly, iBase can be very bandwidth hungry (iBase 9 is much better in this regard) so there may be a lot of traffic across the VPN when iBase is active which can lead to other issues.

    By using a remote desktop instead, only the data required to refresh the screen is sent across the connection/VPN, and if the connection fails it's just a matter of reconnecting to the remote desktop server and carrying on from where you left off, rather than restarting and re-entering any unsaved data.

    Simon

    ------------------------------
    Simon Griffiths
    ------------------------------