Connectivity issue with sync gateway from remote location (even after connected to corporate intranet via VPN)

Connectivity with sync gateway works perfectly fine when we connect from office intranet. But sometimes we are unable to connect to the same sync gateway from home network (connected to corporate intranet via VPN)
We get the below errors

  • (WebSocketDomain / 1006): One or more errors occurred. (This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server).

  • NetworkDomain / 2): One or more errors occurred. (No such host is known)., activity = Offline

  • (POSIXDomain / 108): Unable to read data from the transport connection: An established connection was aborted by the software in your host machine…, activity = Offline

Please guide

Can you reach the SG from home using curl? Try something like curl http://xxxxx:4984/db.

Are proxy servers needed to reach the gateway?

Also, what OS is the client running on?

  • (WebSocketDomain / 1006): One or more errors occurred. (This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server).

Did that error message come from the app? It doesn’t match the error code. (1006 is an abnormal WebSocket close, not anything to do with hostname resolution.)

It looks like a .NET message. This was before I switched to “unexpected error” from “abnormal close” as the default error code.

Is there any way to tackle this issue in our .NET code? Please share if you have any code snippet to handle the issue.

I think it is an environment issue. I know Windows is especially finnicky regarding automatic DNS settings when connected to VPN and I would expect it to give messages similar to that. Are you able to hit sync gateway from a browser with the same environment?

We replicated the issue and the replicator status was offline. Then we hit the https://sync_gateway_url and we got successful response in the browser and right after that the replicator status changed from offline to online. We really don’t know what happened behind the scenes. Looks strange. Please advise

We can replicate the issue over and over again.

  1. Sign into VPN from remote (Home)
  2. Verify good connection
    a. Outlook – Connected, no errors
    b. Skype – Connected, no errors
  3. Open our Application
  4. Offline status.
  5. Refreshed periodically for 5 minutes with no status change
  6. Accessed https://sync_gateway_url in browser, then
  7. Immediately switch tabs back to our application and saw the status change to Online right away after accessing above

Please help us on how we can resolve this issue.

The code snippet used for finding online/offline status is given below

try
{
using (var client = new WebClient())
using (client.OpenRead(“https://sync_gateway_url”))
{
SendNotificationMessage(2002, “Online”);
}
}
catch
{
SendNotificationMessage(2001, “Offline”);
}

I can’t think of any reason why it wouldn’t work. What about directly via IP address for replication?

When I slightly modified the c# code by adding client.UseDefaultCredentials = true, I got rid of the exception

(WebSocketDomain / 1006): One or more errors occurred. (This is usually a temporary error during hostname resolution and means that the local server did not receive a response from an authoritative server)

But still the other 2 issues persist ((NetworkDomain / 2) and (POSIXDomain / 108))

using (var client = new WebClient())
{
client.UseDefaultCredentials = true;
using (client.OpenRead(“https://sync_gateway_url”))
{
SendNotificationMessage(2002, “Online”);
}
}

Is this Couchbase Lite 2? If so, then the scheme of the URL should be “wss:” not “https:”.

Yes, it is Couchbase.Lite version 2.0.3
We use “wss:” for ReplicatorConfiguration
Actually the https we use for getting the Online/Offline status of the sync gateway from the c# code

Clearly something’s going wrong at the .NET layer, or with your VPN. I don’t think this is within the scope of Couchbase Mobile. You’ll need to do some packet sniffing, or looking at your VPN logs, probably.