ip-restriction not working

[dingziran]

I am using kong 8.0 and the same problem was also found in kong7.0.
My configuration is

{
data: [
{
api_id: "b7456ca0-2986-47eb-9cd6-d698780eb809",
id: "b4740f5c-f96c-4f14-a8ba-086a1e9097ad",
created_at: 1459393992000,
enabled: true,
name: "ip-restriction",
config: {
whitelist: [
"182.60.124.75",
"127.0.0.1"
]
}
}
],
total: 1
}

And I can still query the api from other ips.

There is no error in error log.

Is there anything wrong with my configuration?

[subnetmarco]

@dingziran If I am not wrong in the previous issue the problem was happening when updating the plugin, is this still the case?

[dingziran]

I think it is not. I have tried create/update whitelist/blacklist with all customer/ specific customer. It just like there isn't any ip-restriction plugin installed.
Is there anyway to debug this problem?
I don't know how to turn on access log.

[joelfire]

I am having the same issue. It does not seem to be doing anything at all.

I have a simple 'test' API, it has basic-auth, acl, and ip-restriction.

As a simple test, whitelist is set to 1.1.1.1/32. (which definitely should not be allowed.)

My user has no problem hitting the API. I have also tried to blacklist 0.0.0.0/0, and combinations of both, the user is never restricted.

[subnetmarco]

@dingziran @joelfire I will look into this today and aim to release a fix into 0.8.0 RC2 if I can properly isolate the bug. You are invoking Kong directly without any load balancer in front of it, right?

[joelfire]

I am running it in AWS, I have tried both with and without a load balancer
in front of it; it does not work either way.

FYI in both cases my "x-forwarded-for" and "x-real-ip" headers were what I
would expect, so it should work with the load balancer.

thanks

-j

On Mon, Apr 4, 2016 at 3:41 PM Marco Palladino notifications@github.com
wrote:

@dingziran https://github.com/dingziran @joelfire
https://github.com/joelfire I will look into this today and aim to
release a fix into 0.8.0 RC2 if I can properly isolate the bug. You are
invoking Kong directly without any load balancer in front of it, right?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1115 (comment)

[joelfire]

Any update? This is a production blocker since I need to whitelist various APIs on a per customer basis.

[subnetmarco]

I have created a Kong instance to try to replicate the problem, and both try to:

• Set a whitelist with one or more IP addresses, like config.whitelist=52.90.220.31,127.0.0.1.
• Set a blacklist with one or more IP addresses, like config.blacklist=52.90.220.31,127.0.0.1

And they both worked. I have tried this with 0.8.0 RC2. Also, do you see any errors in the error.log file?

[joelfire]

I work with a docker image.
Steps I did to reproduce:

1. git clone https://github.com/Mashape/docker-kong.git
2. in Dockerfile, change ENV KONG_VERSION 0.8.0rc2, then build.
3. Run kong
4. Create a simple API that has ip-restriction whitelist 1.1.1.1, point to a local tomcat
5. Run a curl from localhost

ubuntu@ip-172-31-33-225:~/docker/docker-kong$ curl http://localhost:7000/foo/ -i
HTTP/1.1 200 OK
Date: Mon, 11 Apr 2016 20:09:15 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 247
Connection: keep-alive
Server: Apache-Coyote/1.1
Accept-Ranges: bytes
ETag: W/"247-1459532684000"
Last-Modified: Fri, 01 Apr 2016 17:44:44 GMT
X-Kong-Upstream-Latency: 11
X-Kong-Proxy-Latency: 0
Via: kong/0.8.0rc2

(omitted body)

So I'm not sure what else I should be doing. As isolated a test case I could find. You can see that it is version 0.8.0rc2. Also, I have attached a kongfig dump so you can see my config.

thanks

kongfig.txt

[subnetmarco]

I tried to run the following commands:

$ docker run -p 9042:9042 -d --name cassandra cassandra:2.2.5
$ docker run -d --name kong \
            --link cassandra:cassandra \
            -p 8000:8000 \
            -p 8443:8443 \
            -p 8001:8001 \
            -p 7946:7946 \
            -p 7946:7946/udp \
            --security-opt seccomp:unconfined \
            mashape/kong

$ curl -d "request_host=test.com&upstream_url=http://httpbin.org" 127.0.0.1:8001/apis
{"upstream_url":"http:\/\/httpbin.org","id":"9b318021-b09e-4aa9-b499-c25f4959f330","name":"test.com","created_at":1460416251000,"request_host":"test.com"}

$ curl -d "name=ip-restriction&config.whitelist=1.1.1.1" 127.0.0.1:8001/apis/test.com/plugins/
{"api_id":"9b318021-b09e-4aa9-b499-c25f4959f330","id":"b9bbecc3-d6fa-4a48-ac25-9d5e4d66bf75","created_at":1460416298000,"enabled":true,"name":"ip-restriction","config":{"_whitelist_cache":[[16843009,16843009]],"whitelist":["1.1.1.1"]}}

$ curl -H "host: test.com" 127.0.0.1:8000/get
{"message":"Your IP address is not allowed"}

I have also tried with an API that has a request_path, and it seems to work.

This is with 0.7.0, the current latest version on Docker.

[dingziran]

@thefosk with the same three line

$ curl -d "request_host=test.com&upstream_url=http://httpbin.org" 127.0.0.1:8001/apis
{"upstream_url":"http:\/\/httpbin.org","created_at":1460528545000,"id":"5bdc7c97-3c07-44aa-b463-4cdee5cef65e","name":"test.com","preserve_host":false,"strip_request_path":false,"request_host":"test.com"}

$ curl -d "name=ip-restriction&config.whitelist=1.1.1.1" 127.0.0.1:8001/apis/test.com/plugins/
{"api_id":"5bdc7c97-3c07-44aa-b463-4cdee5cef65e","id":"da4a4af7-90d6-416e-90a9-fe433fbaf3a1","created_at":1460528551000,"enabled":true,"name":"ip-restriction","config":{"whitelist":["1.1.1.1"]}}

$ curl -H "host: test.com" 127.0.0.1:80/get
An invalid response was received from the upstream server

for more info

$ curl -i -H "host: test.com" 127.0.0.1/get
HTTP/1.1 502 Bad Gateway
Date: Wed, 13 Apr 2016 06:26:04 GMT
Content-Type: text/plain; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Server: kong/0.8.0rc1

An invalid response was received from the upstream server

I will try to update from RC1 to RC2 and try again

[dingziran]

RC2 is working. maybe because of the missing {"_whitelist_cache":[[16843009,16843009]] in RC1?

[dingziran]

after add ip-restriction plugin, i have to reload kong(or reload before add each plugin). otherwise, the next ip-restriction plugin won't have _whitelist_cache. And if it doesn't have this property, it won't work.

@thefosk After install a new clean environment, you can add more ip-restriction after the test.com. And I think the bug will reproduce.

[joelfire]

@thefosk Ok I have found the same as above. If the cache value does not exist, it won't restrict. It seems as if, as @dingziran said, doing a reload prior to adding forces it to have the cache. Although I have had it also work without an immediate reload. But reload just prior seems to fix it. And it does not seem specific to version, I get the same with 7.0 and 8.0RC2

No cache

 curl http://localhost:8001/apis/test/plugins
{"data":[{"api_id":"1dcb31f2-934d-4228-ad36-96e58e91e9db","id":"b4b1e98c-a61d-4cfa-84da-28b7be4bb4a2","created_at":1460572688000,"enabled":true,"name":"ip-restriction","config":{"whitelist":["1.1.1.1"]}}],"total":1}

curl http://localhost:8000/test/
<!DOCTYPE html>
<html>
...
</html>

With cache

 curl http://localhost:8001/apis/test/plugins
{"data":[{"api_id":"1dcb31f2-934d-4228-ad36-96e58e91e9db","id":"01cc17df-3794-4106-8d43-55e82c910fb7","created_at":1460572774000,"enabled":true,"name":"ip-restriction","config":{"_whitelist_cache":[[16843009,16843009]],"whitelist":["1.1.1.1"]}}],"total":1}

 curl http://localhost:8000/test/
{"message":"Your IP address is not allowed"}

[subnetmarco]

Yes, I confirm that the _whitelist_cache and _blacklist_cache fields need to exist in order for the plugin to work. These fields are being created by Kong when the plugin is being added.

It seems like you are suggesting that those fields are not being added after the first time, I have tried to replicate this by executing:

$ curl -d "request_host=test.com&upstream_url=http://httpbin.org" 127.0.0.1:8001/apis
{"upstream_url":"http:\/\/httpbin.org","id":"a894b4ed-44b5-4bee-b367-a03c38717c3b","name":"test.com","created_at":1460584953000,"request_host":"test.com"}

$ curl -d "name=ip-restriction&config.whitelist=1.1.1.1" 127.0.0.1:8001/apis/test.com/plugins/
{"api_id":"a894b4ed-44b5-4bee-b367-a03c38717c3b","id":"0d386d45-eaaa-4d44-abb7-394e0e59b192","created_at":1460584962000,"enabled":true,"name":"ip-restriction","config":{"_whitelist_cache":[[16843009,16843009]],"whitelist":["1.1.1.1"]}}

$ curl -H "host: test.com" 127.0.0.1:8000/get
{"message":"Your IP address is not allowed"}

$ # Adding second API

$ curl -d "request_host=test2.com&upstream_url=http://httpbin.org" 127.0.0.1:8001/apis
{"upstream_url":"http:\/\/httpbin.org","id":"b76aa527-7196-460a-91bf-49b9be887b79","name":"test2.com","created_at":1460584973000,"request_host":"test2.com"}

$ curl -d "name=ip-restriction&config.whitelist=1.1.1.1" 127.0.0.1:8001/apis/test2.com/plugins/
{"api_id":"b76aa527-7196-460a-91bf-49b9be887b79","id":"41d53879-3bf3-45c4-9a00-756e25b0a0b5","created_at":1460584979000,"enabled":true,"name":"ip-restriction","config":{"_whitelist_cache":[[16843009,16843009]],"whitelist":["1.1.1.1"]}}

$ curl -H "host: test2.com" 127.0.0.1:8000/get
{"message":"Your IP address is not allowed"}

Which seems to be working. Could you give me the exact commands to replicate the issue?

[joelfire]

I can consistently reproduce it via the kong-dashboard UI, which does the following:

curl -X PUT http://localhost:7001/plugins --data '{"api_id":"0f1aefc8-b0ac-42c1-b99d-f8dfcbc51935","name":"ip-restriction","config":{"whitelist":"1.1.1.1"}}' -H 'Content-Type:application/json'

Oddly I can not consistently reproduce it from the command line (but often can). Also note that the URL used by dashboard does not include the full API path.

[subnetmarco]

Maybe it's a problem of the dashboard? We don't maintain or support any official GUI, so maybe it's an issue to be fixed by the creator of GUI.

Can anybody else replicate this issue just by using the API?

[joelfire]

See my comment, I did purely by API, but that's all the UI does anyway. It
does seem to use an undocumented way of creating the plugin as I noted, but
if that is not supported then perhaps you should not allow it, that will
force the UI maintainer to use it the documented way.

On Wed, Apr 20, 2016, 4:13 PM Marco Palladino notifications@github.com
wrote:

Maybe it's a problem of the dashboard? We don't maintain or support any
official GUI, so maybe it's an issue to be fixed by the creator of GUI.

Can anybody else replicate this issue just by using the API?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1115 (comment)

[subnetmarco]

I am confused by this line:

Oddly I can not consistently reproduce it from the command line (but often can)

Were you able to sometimes reproduce the error just by exclusively using the API?

[joelfire]

Yes, what I meant was calling the api using curl. After about 25 minutes of
trying different sequences of adding and deleting the plugin and reloading
Kong I was able to reproduce the bug a number of times but could not find a
repeatable way. So I gave up.

On Wed, Apr 20, 2016, 7:06 PM Marco Palladino notifications@github.com
wrote:

I am confused by this line:

Oddly I can not consistently reproduce it from the command line (but often
can)

You were able to sometimes reproduce the error just by exclusively using
the API?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1115 (comment)

[dingziran]

I can always reproduce this error with ubuntu 14, kong 0.8, postgres as db. Hoping this can be fixed in the next release. My install method is downloading the .deb and install with dpkg, then modified the kong.yml to use postgres. Add api and plugins with kong-dashboard

[jfirehammer-credibly]

Any update on this? I am using curl locally to add an ip-restriction (no dashboard), and it sometimes works and sometimes does not. I can tell right away because the _whitelist_cache is not returned if it failed. It's extremely frustrating especially since I am now in production. It seems that restarting kong and then adding it usually works, but I don't like doing this to a production server whenever I need to update the whitelist. Can you try to find the bug via code inspection? It's clearly about not creating the _whitelist_cache

[subnetmarco]

@jfirehammer-credibly I having an hard time trying to reproduce this problem, it seems to work every time for me. What values are you using to reproduce this issue?

[jfirehammer-credibly]

SImple, I just did this a second ago:

curl -X POST http://localhost:8001/apis/openscoring/plugins/ --data 'name=ip-restriction'  --data 'config.whitelist=0.0.0.0'
{"api_id":"bf18e932-3ccb-4a0f-a2f4-2362c34d2048","id":"fcba613c-c75d-4851-b68e-64ae2145f716","created_at":1464012850000,"enabled":true,"name":"ip-restriction","config":{"whitelist":["0.0.0.0"]}}

curl http://localhost:8001/apis/openscoring/plugins/fcba613c-c75d-4851-b68e-64ae2145f716
{"api_id":"bf18e932-3ccb-4a0f-a2f4-2362c34d2048","id":"fcba613c-c75d-4851-b68e-64ae2145f716","created_at":1464012850000,"enabled":true,"name":"ip-restriction","config":{"whitelist":["0.0.0.0"]}}

Note the lack of _whitelist_cache, which means that it failed. I can't tell you how to consistently reproduce this, but it fails more often than not for me. If I restart Kong and then do the POST, it is usually successful. You might have to just try to fix this via code inspection.

This is kong 0.8.0.

[subnetmarco]

The fix/ip-restriction branch has a fix proposal for this issue (which for some reason I cannot replicate on my environment, not even with the latest instructions).

Could you checkout that branch, [sudo] make install && kong restart, and see if this fixes the issue? If it does, happy to push it into 0.8.2.

[subnetmarco]

The PR has been merged and will be available in the next release - let me know if v0.8.2 fixes this problem.

[jfirehammer-credibly]

Excellent, thanks, I will upgrade to 0.8.2 as soon as 0.8.2 is released and I can get a chance, and let you know how it goes.

[subnetmarco]

The new version has been just released. Let me know if it works now. @jfirehammer-credibly

[jfirehammer-credibly]

nice, thanks. I won't get a chance before the long weekend but next week
I'll try it out in my integration environment and let you know

http://www.inc.com/profile/credibly
2014 | 2015
Joel Firehammer

Vice President of Software Engineering
O:646-612-7998 x3000
https://www.trustpilot.com/review/credibly.com
Some of the information contained within this email, if not all, may be
confidential and protected from disclosure. If you are not the intended
recipient please delete immediately. All loans through RetailCapital, LLC
d/b/a Credibly are made by WebBank, a Utah industrial bank, Member FDIC.

On Thu, May 26, 2016 at 2:26 PM, Marco Palladino notifications@github.com
wrote:

The new version has been just released. Let me know if it works now.
@jfirehammer-credibly https://github.com/jfirehammer-credibly

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1115 (comment)

[subnetmarco]

Looking forward to hearing the status on this.

[jfirehammer-credibly]

I just updated to 0.8.2. Added, removed, edited blacklist and whitelist and everything seems to be working.

Much obliged!

[subnetmarco]

Perfect - I will close this issue now, please reopen it if it happens again.

[cvrabie]

in kong 0.8.3/aws linux, ip-restriction stopped working all together on my instance. it never adds the _whitelist_cache fields and whatever value I set in the whitelist it blocks all incoming requests. i tried removing/adding/updating the plugin. from what I can tell, there's no error in the logs.

[subnetmarco]

We don't have the _whitelist_cache fields anymore, we changed how it works.

[cvrabie]

I see. It still doesn't seem to work, but I'll retest as I dismissed some cases because of the assumption above.

I was relying on those fields to see if the config was set/updated correctly. Should I understand it now, that if it accepts the config, the IPS/CIDR blocks were validated and accepted, and that no further action is necessary (ex: reload/restart)?

[subnetmarco]

that if it accepts the config, the IPS/CIDR blocks were validated and accepted, and that no further action is necessary (ex: reload/restart)?

Yes. When adding/updating/deleting the plugin on an API no restart/reload is required on any Kong node.

[gigelu]

I have the same problem with kong 0.9.2 on Debian: ip-restriction doesn't work when updating IPs for customers without a full restart (reload doesn't work, a stop/start is needed).

Edit: updated to 0.9.3 and it seems to work OK.