tobychui / zoraxy

A general purpose HTTP reverse proxy and forwarding tool. Now written in Go!
https://zoraxy.arozos.com
GNU Affero General Public License v3.0
2.72k stars 163 forks source link

[BUG] Local LAN IP Whitelist gives 403 Access Denied error when connecting from the local network #170

Closed Matthias-vdE closed 2 months ago

Matthias-vdE commented 4 months ago

Describe the bug When creating an Access Control rule where you specify, for example, 192.168.0.0/16 in the whitelist, and then accessing a host with that rule applied from the local LAN, you still get a 403 access denied error.

To Reproduce Steps to reproduce the behavior: Create an Access Control Rule, "LocalOnly". Enable the Whitelist, and allow only 192.168.0.0/16. Apply this rule to a Proxy Host. Accessing the host from a local computer with IP 192.168.10.20/24 gives 403 Access Denied.

Expected behavior This should be allowed, considering I'm matching the whitelist.

Browser (if it is a bug appears on the UI section of the system):

Host Environment (please complete the following information):

Additional context An Access Rule where I specify a specific country does work. But I want to create an access rule where I can only reach certain host from within my own local network.

Matthias-vdE commented 4 months ago

Adding my WAN IP to the Whitelist seems to work, but of course that is prone to changing.

yeungalan commented 4 months ago

Hi, may I confirm your Zoraxy version? We recently made some changes to the allow/disallow list, and this problem should have already been resolved in a recent release.

Matthias-vdE commented 4 months ago

Running Version 3.0.4 Build Release as a Docker container.

tobychui commented 4 months ago

Cannot reproduce issue. Whitelist CIDR resolver seems working perfectly on my system. This is mostly cause by you have an invalid configuration in your docker network. Will be closing this issue if no network capture is provided for further debugging.

Matthias-vdE commented 4 months ago

The container is running in Bridged mode, with ports 80, 443, and 8005 mapped to the same outside ports. Using ARGS '-noauth=false -fastgeoip=true -mdns=false -version=true'.

I'd be happy to check some logs to see why it's failing. Where would be the best way to check this?

tobychui commented 4 months ago

The container is running in Bridged mode, with ports 80, 443, and 8005 mapped to the same outside ports. Using ARGS '-noauth=false -fastgeoip=true -mdns=false -version=true'.

I'd be happy to check some logs to see why it's failing. Where would be the best way to check this?

It is not a Zoraxy issue but an inbound networking one, so log is not helpful in this case. Are you accessing your zoraxy via public IP address of your host or your domain name?

Matthias-vdE commented 4 months ago

The container is running in Bridged mode, with ports 80, 443, and 8005 mapped to the same outside ports. Using ARGS '-noauth=false -fastgeoip=true -mdns=false -version=true'. I'd be happy to check some logs to see why it's failing. Where would be the best way to check this?

It is not a Zoraxy issue but an inbound networking one, so log is not helpful in this case. Are you accessing your zoraxy via public IP address of your host or your domain name?

All my HTTP proxies are configured as

service1.mydomain.com service2.mydomain.com service3.mydomain.com etc.

On my internal DNS server, .mydomain.com resolves to the local LAN IP of Zoraxy. For all external DNS, .mydomain.com resolves to my public WAN which forwards ports 80 and 443 to Zoraxy.

So when accessing service1.mydomain.com from my internal network, it gets correctly resolved to 192.168.0.2 (example) which is the IP of the server on which Zoraxy runs. https://192.168.0.2:8005/ is reachable. I can even navigate to service1.mydomain.com:8005 and up on the Zoraxy page. So everything appears to work just fine, but even when accessing my services from within my local network, Zoraxy seems to think it's coming from my WAN IP.

Looking at the piechart of Visitor Countries, almost nothing is coming from LAN. (17 LAN vs 7000 from my country).

The contents of /etc/resolv.conf on the docker host point to my local DNS server.

Matthias-vdE commented 4 months ago

When connecting to my VPN via a remote location, it DOES work with this LocalOnly access list for some reason.

tobychui commented 4 months ago

I see, feel free to tag me and let me know if you discover anything new. There are nothing I can help as it seems to be a networking issues in your docker environment.

Matthias-vdE commented 4 months ago

Is there any way in finding out from which IP address connections are coming in, and whether or not they are being blocked/allowed and why? Some kind of debug log for Zoraxy?

Because I frequently have issues with geoblocking as well. My home country is whitelisted, but often I still get 403 access denied when coming from an IP that is by multiple sites correctly identified as being from here.

tobychui commented 3 months ago

You can take a look at the IPv4 map (in csv files) in the geodb module to see if the db needs update.

But if you are sure it is not a docker network setting problem and the geodb files are correct (i.e. your IP is in a range described in the CSV file, matching your whitelisted country code), the only last thing you can try is to migrate the access control to Cloudflare instead. The Zoraxy build-in geodb is a lightweight implementation that based on (usually) outdated IP to country code data collected by the open source community. Accuracy wise, it will not be on par to commercial solutions like the one from CF.

klisza1993 commented 3 months ago

If you set up acl for only few IPs whoch not includes private range then its normal that you being blocked. You'll have to have HarpiNAT to advertise to your proxy with public IP. Otherwise you'll have to setup proper ACL.

tobychui commented 3 months ago

@klisza1993 Seems you mentioned something important but I don't quite understand it as I never encounter similar issues. Feel free to contribute to the wiki page if you want to πŸ‘πŸ»

tobychui commented 2 months ago

A new request logging system has been introduced in v3.0.8 where you can check where the request IP is coming from with the build in log viewer. I guess from here you can debug the problem yourself and I am closing this as this is mostly a user networking issues.

εœ–η‰‡