TunnelConfig ProxyType not working

[bradyburke]

What happened?

When using the following TunnelConfig:

new TunnelConfig(
      `${kubectlTunnelName}-config`,
      {
        accountId: accountId,
        tunnelId: this.kubectlTunnel.id,
        config: {
          warpRouting: {
            enabled: true,
          },
          originRequest: {
            proxyType: "socks",
          },
          ingressRules: [
            {
              hostname: kubectlTunnelDns,
              service: "tcp://kubernetes.default.svc:443"
            },
            {
              // Catch all
              service: "http_status:404",
            },
          ],
        },
      },
      { ...this.opts, dependsOn: [this.kubectlTunnel] }
    );

this does not get set when I view the Tunnel Configuration in the UI.

Expected Behavior

The expected behavior is the the proxyType gets set propery.

Steps to reproduce

Deploy the above code to a tunnel. Check proxyType through the UI

Output of pulumi about

❯ pulumi about
CLI
Version 3.52.1
Go Version go1.19.5
Go Compiler gc

Plugins
NAME VERSION
aws 5.10.0
azure-native 1.79.2
cloudflare 4.15.0
eks 0.41.2
gcp 6.45.0
kubernetes 3.20.3
nodejs unknown
random 4.8.1
tls 4.6.0

Host
OS darwin
Version 13.1
Arch arm64

Additional context

No response

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

[guineveresaenger]

Hi @bradyburke - thank you for filing this bug!

Would it be possible for you to create a minimal program sample that we can run on our end to reproduce this behavior? It would help us help you faster - you are likely far more familiar with the regular ins and outs of the Cloudflare API.

[bradyburke]

@guineveresaenger

const kubectlTunnelName = "myTunnel";
const kubectlTunnel = new ArgoTunnel(
      kubectlTunnelName,
      {
        accountId: REDACTED,
        name: kubectlTunnelName,
        secret: REDACTED,
      }
    );

    new TunnelConfig(
      `${kubectlTunnelName}-config`,
      {
        accountId: REDACTED,
        tunnelId: kubectlTunnel.id,
        config: {
          warpRouting: {
            enabled: true,
          },
          originRequest: {
            proxyType: "socks",
          },
          ingressRules: [
            {
              hostname: "mydomain.com",
              service: "tcp://kubernetes.default.svc:443"
            },
            {
              // Catch all
              service: "http_status:404",
            },
          ],
        },
      }
    );

[bradyburke]

@AaronFriel @guineveresaenger any update? This is a blocker for us using these tunnels in our environments

[bradyburke]

Additionally, this behavior can be seen when using proxy configurations:

    new TunnelConfig(
      `${kubectlTunnelName}-config`,
      {
        accountId: REDACTED,
        tunnelId: kubectlTunnel.id,
        config: {
          warpRouting: {
            enabled: true,
          },
          originRequest: {
            proxyType: "socks",
            proxyAddress: "kubernetes.default.svc",
            proxyPort: 443,
          },
          ingressRules: [
            {
              // Catch all
              service: "http_status:404",
            },
          ],
        },
      }
    );
    ```

[bradyburke]

Additionally, per this page. OriginRequest should be a child of an ingress rule. However, in the Cloudflare Provider, it is an entirely separate configuration at the same level as ingressRules, which may have an effect.

ingress:
  - hostname: azure.widgetcorp.tech
    service: tcp://kubernetes.docker.internal:6443
    originRequest:
      proxyType: socks
  - service: http_status:404

[bds-congnguyen]

@bradyburke correct, the OriginRequest must have specific values for each service
same behavior with Terraform https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/tunnel_config
that also have reported at cloudflare/terraform-provider-cloudflare#2275
and fixed at https://github.com/cloudflare/terraform-provider-cloudflare/releases/tag/v3.35.0

[mikhailshilkov]

It looks like this has been fixed upstream in cloudflare/terraform-provider-cloudflare#2477 and is available in Pulumi Cloudflare 5.3.0 or later