Closed Matthias-vdE closed 2 months ago
Adding my WAN IP to the Whitelist seems to work, but of course that is prone to changing.
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.
Running Version 3.0.4 Build Release as a Docker container.
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.
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?
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?
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.
When connecting to my VPN via a remote location, it DOES work with this LocalOnly access list for some reason.
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.
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.
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.
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.
@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 ππ»
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.
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.