# White list IP restriction nor working anymore

**URL:** <https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048>\
**Category:** Questions\
**Tags:** kubernetes\
**Created:** [December 2, 2019, 1:49pm UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048 "2019-12-02T13:49:50Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![samsja](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/samsja/32/1381_2.png) [@samsja](https://discuss.konghq.com/u/samsja)\
**Post date:** [December 2, 2019, 1:49pm UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/1 "2019-12-02T13:49:50Z")

</div>

We are using kong with ingress in production and it is deploy with helm chart  
Version:

- kong : 1.3
- Ingress Controller : 0.6.0

We use to deploy via [https://bit.ly/k4k8s](https://bit.ly/k4k8s) and we managed to configure IP restrcition.

The only difference is that we used our own database (google cloud SQL) to store the data.

Unfortunetly it is not the case anymore, we try a simple whilte list Ip restriction to protect some of our services but all the request are block for every Ip including the one in the whitelist group

```yaml

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: white-list-intra
  namespace : A
config:
  whitelist:
      -SOME_IP
plugin: ip-restriction

```

then we patched the ingress

```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 annotations:
   kubernetes.io/ingress.class: "kong"
   nginx.ingress.kubernetes.io/use-regex: "true"
   certmanager.k8s.io/cluster-issuer: letsencrypt-production-issuer
   plugins.konghq.com: white-list-intra
 name: ingress-A
 namespace: default

```

Are we doing something wrong or is it a bug? Could it come from the google cloud sql kong database ?

---

<div class="post-metadata">

**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\
**Post date:** [December 2, 2019, 8:52pm UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/2 "2019-12-02T20:52:04Z")

</div>

You should make sure that Kong is actually seeing the public IP address of the end-user which is making the request to Kong.  
It is likely that you have a load-balancer in front of Kong and that is hiding the IP-address of the real request.  
You need to check Kong’s `trusted_ips` setting and also check if you need to enable proxy\_protocol or not. These will depend on the cloud provider you’re using.

---

<div class="post-metadata">

**Author:** ![samsja](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/samsja/32/1381_2.png) [@samsja](https://discuss.konghq.com/u/samsja)\
**Post date:** [December 3, 2019, 6:27am UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/3 "2019-12-03T06:27:20Z")

</div>

Thanks for your answer, so it is link with this [topic](https://discuss.konghq.com/t/how-to-forward-clients-request-ip/384/2) ? I will try to set thoses parameters.

We are running our k8s cluster on the google cloud platform, I thought that by using kong as our main loadbalancer we did not used the google one’s anymore ? What other google services can hide the IP from kong ?

Any advice on running kong in gcp in order to enable IP restriction ?

---

<div class="post-metadata">

**Author:** ![samsja](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/samsja/32/1381_2.png) [@samsja](https://discuss.konghq.com/u/samsja)\
**Post date:** [December 3, 2019, 8:45am UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/4 "2019-12-03T08:45:36Z")

</div>

I have expose a simple API that show me the header that come in http request, and I see than when I put the api behind kong, the X-Forwarded-For and the X-Forwarded-For header don’t point to my IP but an other one ( I am trying to determine it sources).

The ip-restriction plugin look at the X-real-IP isn’t it ?So I have to config kong so that I have the good value in this header ?

---

<div class="post-metadata">

**Author:** ![hbagdi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/hbagdi/32/562_2.png) [@hbagdi](https://discuss.konghq.com/u/hbagdi)\
**Post date:** [December 3, 2019, 9:58pm UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/5 "2019-12-03T21:58:16Z")

</div>

> [@samsja](#):
>
> I have expose a simple API that show me the header that come in http request, and I see than when I put the api behind kong, the X-Forwarded-For and the X-Forwarded-For header don’t point to my IP but an other one ( I am trying to determine it sources).

It most likely is the LoadBalancer IP address that Kong is seeing.

As I said in my previous comment, you want to set `trusted_ips` setting in Kong so that Kong respects the correct IP address that is forward from Google’s Load Balancer (if you are using L7 LB form Google).

You can also set the traffic policy in GKE to preserve the client IP address:

> **[Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip)**
>
> This page shows how to create an external load balancer.
> When creating a Service, you have the option of automatically creating a cloud load balancer. This provides an externally-accessible IP address that sends traffic to the correct port on your...

---

<div class="post-metadata">

**Author:** ![samsja](https://yyz2.discourse-cdn.com/flex036/user_avatar/discuss.konghq.com/samsja/32/1381_2.png) [@samsja](https://discuss.konghq.com/u/samsja)\
**Post date:** [December 4, 2019, 9:18am UTC](https://discuss.konghq.com/t/white-list-ip-restriction-nor-working-anymore/5048/6 "2019-12-04T09:18:52Z")

</div>

I finaly found the solution, I simply add :

```auto
proxy:
  externalTrafficPolicy: Local

```

to my values.yaml (for helm installation) It was previously set to Cluster: and the client IP was not forwarding correctly.
