dial tcp no such host behind a vpn

[millouzgc]

GitLab Provider version

3.18.0

GitLab version

GitLab Community Edition 14.0.10

Terraform version

1.2.9

Relevant Terraform Configuration

provider "gitlab" {
  token    = var.gitlab_token
  base_url = "https://xxxxxxxxxxxxxxxxx.fr/api/v4"
  insecure = true
  # or false
}

Relevant log output

2022-09-21T21:40:11.428+0200 [TRACE] dag/walk: upstream of "root" errored, so skipping
2022-09-21T21:40:11.428+0200 [INFO]  backend/local: plan operation completed
╷
│ Error: Get "https://xxxxxxxxxxxxx.fr/api/v4/user": dial tcp: lookup xxxxxxxxxxxxx.fr on 10.0.0.1:53: no such host
│ 
│   with provider["registry.terraform.io/gitlabhq/gitlab"],
│   on provider.tf line 16, in provider "gitlab":
│   16: provider "gitlab" {
│ 
╵
2022-09-21T21:40:11.429+0200 [TRACE] statemgr.Filesystem: removing lock metadata file terraform.tfstate.d/development/.terraform.tfstate.lock.info
2022-09-21T21:40:11.429+0200 [TRACE] statemgr.Filesystem: unlocking terraform.tfstate.d/development/terraform.tfstate using fcntl flock
2022-09-21T21:40:11.431+0200 [DEBUG] provider.stdio: received EOF, stopping recv loop: err="rpc error: code = Unavailable desc = transport is closing"
2022-09-21T21:40:11.433+0200 [DEBUG] provider: plugin process exited: path=.terraform/providers/registry.terraform.io/gitlabhq/gitlab/3.18.0/linux_amd64/terraform-provider-gitlab_v3.18.0 pid=10280
2022-09-21T21:40:11.433+0200 [DEBUG] provider: plugin exited
makefile:67: recipe for target 'tp' failed
make: *** [tp] Error 1

Description

Hello, I have the error in the new version 3.18.0 during the plan while in the same conditions with version 3.17.0, I do not have the problem.

I have the problem only behind our VPN.

• 3.17.0 + internal network = ok
• 3.17.0 + vpn = ok
• 3.18.0 + internal network = ok
• 3.18.0 + vpn = KO

[Shocktrooper]

I have not dived into this but it appears you are using a very old version of GitLab. The provider is updated to keep up with the support schedule of GitLab which is the previous three releases (15.2, 15.3, 15.4 as of this comment). With that said if you are not able to upgrade you can pin a previous version of the provider that works for your installation.

[timofurrer]

I don't see any change between 3.17.0 and 3.18.0 which would "obviously" lead to that behavior. Could it be that your VPN blocks somethings?

Does it really "always" break for 3.18.0 and "never" for 3.17.0 ?

[millouzgc]

Hello, yes, it blocks all the tests

[Shocktrooper]

I took a look at the diff between 3.17 and 3.18 and we did bump go from 1.17 to 1.19. I didn't dive into those patch notes but that could be the only thing I see on our end. I am more in agreement with Timo that there is a corporate configuration on the VPN or a firewall that is blocking this from working. Potentially a user agent block or something of the sort