Unable to update Xlink behind firewall (DNS resolving failed)

Unity Services
,
1

Hi there, I have a quite annoying bug I cannot really resolve.

We set up a WireGuard server at our company making working for home easier. I’m on Windows using the Plastic SCM / Unity Version Control DVCS client. Our Plastic server runs at the company and is accessible over on our network either by direct ipv4 access or over a custom hostname configured on the router in the following format ‘server.int.company.com:8087’. DNS resolving works fine.

Now the exact setup that gives me problems looks at follows:

  • I’m connected with the VPN having access on the whole company network, DNS resolving works fine.
  • I have a local repository, lets call it A, that is synced from a corresponding source repository on the company server (using the custom host name ‘server.int.company.com:8087’) using a Sync View. Syncing in any direction works fine.
  • I have the another repository, lets call it B, on the company server on which I work directly (not using a Sync View). So I point my client straight at ‘repositoryB@server.int.company.com:8087’. All is fine, no DNS errors here, I can work on this repo without any problems
  • There is a read-only Xlink on ‘repositoryA@server.int.company.com:8087’ pointing to and receiving data from ‘repositoryB@server.int.company.com:8087’

However, updating this Xlink (updating workspace) on my workstation at home fails with:

Error: Can't resolve DNS entry for server

I sync ‘repositoryA@server.int.company.com:8087’ to ‘repositoryA@local’ just fine. I can access ‘repositoryB@server.int.company.com:8087’ and work directly on the server just fine. I can ping and trace the route to ‘server.int.company.com:8087’ just fine. But updating the Xlink in ‘repositoryA@local’ will not work whatsoever.
Updating the Xlink on my workstation at the company works too (however, on-site I do not use DVCS, and access all the repositories directly from the server, no Sync View for repository A). Also using ipv4 everywhere instead of hostnames does not change anything; still having DNS errors.

This seems like a bug or a weird firewall issue. How can I debug this further?
Cheers and thanks in advance!

2

Hi,

Let’s try to debug and resolve this following the next steps:

  1. Check Xlink Resolution with VPN
    Since everything works fine on-site, but the issue arises over VPN, it could be related to how Xlinks handle DNS resolution remotely. Plastic SCM relies on correct server resolution when updating Xlinks, and it appears there’s a conflict when trying to resolve repositoryB@server.int.company.com:8087 during the update process.

  2. Verify Hostname Resolution in Your VPN Configuration
    Test with IPv4: Even though you mentioned that using IPv4 addresses directly didn’t solve the issue, we should ensure the IP address mappings and routes are correctly set in your VPN for all repositories involved. Try hardcoding the IP address of the server into your hosts file as a temporary fix to see if this improves resolution for repositoryB.
    DNS Settings in WireGuard: Double-check if your WireGuard VPN configuration properly forwards DNS queries to the company’s internal DNS server. The fact that the rest of the setup works but updating the Xlink fails suggests that DNS resolving over the VPN may not be consistent for all requests.

  3. Check for Split Tunneling or Firewall Issues
    Some VPNs use split tunneling to route only certain traffic through the VPN, which might affect how Plastic handles the Xlink update. Ensure all traffic (including DNS resolution for Xlinks) goes through the VPN.
    Firewall or Router Configurations could block certain requests when coming from the external VPN. The Xlink might be hitting a different route than your direct repository access. You may need to configure firewall rules to ensure that the traffic between repositories over VPN is not restricted.

  4. Plastic SCM Log Analysis
    You can enable more detailed logging in Plastic SCM to help diagnose the issue. In your plastic client, go to the configuration file (plastic.debug.conf) and set it to a debug level, particularly for network operations. This might show where the process is failing during the Xlink update.

If after these steps the issue persists, it might be helpful for us to look at your specific configuration (VPN, DNS, and Plastic settings) in more detail. You could also try replicating this with a different VPN setup to confirm if the issue is specific to WireGuard or network configuration. In that case please share the logs and reach us to devops-vcs-support@unity3d.com.

Let us know how it goes, and we’re happy to assist further.

3

After some debugging of our network, I have resolved my issue. The culprit was that our WireGuard server did not correctly translate all the distributed hostnames. Some Plastic clients were configured to access our servers with repositoryA@server:8087 (no FQDN, only hostname), those clients ended up having this error. Using hostname + domain resolved our issue.

While this DNS error is now resolved, I now have other problems related to partial xlinks that are very frustrating to work with. I basically have now a similar problem like the person in this thread. As this is however unrelated to this thread here, I will post over there.

Thanks for reaching out, the listed steps did help to further find our errors in our network setup.