# Force\_https not working with GCP Ingress

**URL:** https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593
**Category:** Support
**Tags:** unsupported-install
**Created:** [October 9, 2019, 5:16pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593 "2019-10-09T17:16:37Z")
**Posts on this page:** 9
**Page:** 1

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 9, 2019, 5:16pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/1 "2019-10-09T17:16:37Z")

</div>

I’ve got a kubernetes instance on GCP. Everything seems fine, but somehow `force_https` isn’t forcing a redirect and the sill can be retrieved on `http://`.

My solution for now has been to add this stanza to `app.yml`.

```plaintext
    - replace:
        filename: /etc/nginx/conf.d/discourse.conf
        from: ' add_header ETag "";'
        to: |
                  add_header ETag "";
                  if ($thescheme = "http") {
                    return 301 https://$host$request_uri;
                  }

```

(And I’d love to understand how to get `pups` to indent those lines I inserted, but I digress.)

Sometime after that change the ingres controller appears to have stopped serving the site, though it seemed to have been working–and properly redirecting–for at least a while.

Obviously this is #unsupported-install, but if anyone has an idea where to look next, I’d appreciate it.

---

<div class="post-metadata">

### Author: ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)
#### Post date: [October 9, 2019, 9:37pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/2 "2019-10-09T21:37:39Z")

</div>

Are you using a HTTP loadbalancer or a TCP loadbalancer? If HTTP, the protocol seen on ingress may be stuffed in a nonstandard header that Discourse isn’t looking for.

---

<div class="post-metadata">

### Author: ![riking](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/riking/32/170938_2.png) [@riking](https://meta.discourse.org/u/riking)
#### Post date: [October 9, 2019, 9:45pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/3 "2019-10-09T21:45:10Z")

</div>

Looks like the fully-managed setup looks like this:

```plaintext
$ gcloud compute addresses create discourse-ip-address --global
# ^ ~~~~~~~~~~~~~~~~~~~ custom name
# WARNING: reserving an IP address but not using it incurs a 0.010USD/hr penalty charge
---
apiVersion: networking.gke.io/v1beta1
kind: ManagedCertificate
metadata:
  name: discourse-cert
spec:
  domains:
    - discourse.example.com # customize
---
apiVersion: extensions/v1beta1
# if v1.14 or later:
# apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: discourse-web-ingress
  annotations:
    networking.gke.io/managed-certificates: discourse-cert
    kubernetes.io/ingress.global-static-ip-name: discourse-ip-address
spec:
  backend:
    serviceName: discourse-web # verify this is correct
    servicePort: 80

```

sources:

> **[GKE Ingress for Application Load Balancers  |  GKE networking  |  Google...](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/ingress)**

> **[Secure traffic for GKE Ingress  |  GKE networking  |  Google Cloud Documentation](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/secure-traffic-management)**

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 9, 2019, 10:37pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/4 "2019-10-09T22:37:27Z")

</div>

Thanks very much, @riking! Yes, it’s the load balancer that seems to be my issue. I think ingress is OK (and now I have some idea that there is a difference). I switched to the setup that you show and am getting the same results as I was with a somewhat more complicated configuration. I guess one next step would be to figure out `tcpdump` and see what’s in those headers. . .

EDIT: It looks like it _should_ work. Here’s what I see:

```plaintext
GET /thisisatest HTTP/1.1
User-Agent: Wget/1.19.4 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: community.example.com
X-Cloud-Trace-Context: 72c9f7219e6b541cad01153c52fb92c5/13509441707361831434
Via: 1.1 google
X-Forwarded-For: MY-IP-ADDRESS, INGRESS-IP
X-Forwarded-Proto: http
Connection: Keep-Alive

```

I have a `set_real_ip_from` with the ingress IP (and IP numbers are getting logged properly).

---

<div class="post-metadata">

### Author: ![P16](https://avatars.discourse-cdn.com/v4/letter/p/b19c9b/32.png) [@P16](https://meta.discourse.org/u/P16)
#### Post date: [October 9, 2019, 10:52pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/5 "2019-10-09T22:52:05Z")

</div>

@pfaffman I could help with that - I’m on GCP and have solved this issue before. I’m tied up for a few hours though but if you can send me your load balancer setup (along with the health check stuff) here or privately, I can try and find the issue.

PS: TCP and HTTP will both work

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 9, 2019, 11:08pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/6 "2019-10-09T23:08:28Z")

</div>

Thanks a zillion, @p16!

Well, here’s the health check. I changed the path to `/srv/status` but I still see “GoogleHC/1.0” hitting `/`.

 ![image](https://global.discourse-cdn.com/meta/original/3X/a/1/a12808b811d82b27df9d312838c238e7f149849b.png)

---

<div class="post-metadata">

### Author: ![P16](https://avatars.discourse-cdn.com/v4/letter/p/b19c9b/32.png) [@P16](https://meta.discourse.org/u/P16)
#### Post date: [October 9, 2019, 11:17pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/7 "2019-10-09T23:17:58Z")

</div>

Thanks, is the backend showing up as healthy in the load balancer? Please also add `www.yoursite.com` to the host (under more).

Also, here is what I add to my app.yml:

> ```
> after_web_config:
> - replace:
> filename: "/etc/nginx/conf.d/discourse.conf"
> from: /server.+{/
> to: |
> server {
> if ($http_x_forwarded_proto = 'http'){
> return 301 https://$host$request_uri;
> }
> 
> ```

It won’t be necessary for too long as Google will be adding an http to https redirector this quarter.

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [October 9, 2019, 11:29pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/8 "2019-10-09T23:29:18Z")

</div>

Yes. It seems to be working now! I guess I’m confused about the magic port 30182, but I suppose that’s some kind of k8s magic that I’ll understand another day.  
I’ll give your `after_web_config:` stanza a go. It seems a bit cleaner than what I was doing.

Thanks very much.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [November 8, 2019, 11:36pm UTC](https://meta.discourse.org/t/force-https-not-working-with-gcp-ingress/130593/9 "2019-11-08T23:36:39Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
