[BUG] New Access Control feature returns error on Default rule about zoraxy HOT 9 CLOSED

Just to add up on the closure, since I didn't feel confident enough to build outside and push it to container, I just set up a new VM for Zoraxy for testing purposes. I could reproduce the issue with the latest 3.0.3 version, but as I was trying to diagnose it further (with tcpdump) I realized that despite having my local DNS returning the local IP address for the test FQDN the traffic incoming on the VM actually came from OUTSIDE the LAN, so my IPs were effectively not the one I was expecting on the Zoraxy instance... I am currently investingating why that's the case but it means it is outside of Zoraxy's scope.

from zoraxy.

Wrapping it up as I finally found the culprit, since it might be useful to anyone encountering the same issue.
Basically the problem came from Chrome. By default I had "Secure" DNS enabled, effectively bypassing my own local DNS so instead of having test.yangi.re being redirected to 192.168.20.XXX, I had Chrome ask a public DNS about it, returning my public IP instead. This resulted in my request going through the local router, going outside (to my external router) and going back in, effectively coming back with my external router IP instead of mine.

tl;dr, if you use Chrome, go to chrome://settings, search for "DNS" and check if this thing is disabled:

Edit: it apparently doesn't care about the "OS Default", my local DNS is supposedly the "OS Default" but that wasn't good enough for Chrome I guess...

from zoraxy.

Found the following workaround: deactivating the white list seems to make it work

from zoraxy.

Hi @Mereck13579 , thanks for the issue report. I will try to figure out what is the issue this weekend.

from zoraxy.

Unsure if it's related or not but it seems like the whitelist rules are not working properly as well at times...

I have a rule to limit some proxies to local addresses only (192.168.20.0/24 in the whitelist, my PC IP is 192.168.20.42) but I get a 403 forbidden when trying to access it. Disabling the white list makes it work.

Tell me if you want me to open another ticket instead for this.

from zoraxy.

@Mereck13579 Interesting, as I cannot reproduce this in my Zoraxy test environment, can you help me try out something?

Edit src/mod/access/whitelist.go and recompile zoraxy using go mod tidy and go build

//Line 3
import (
	"fmt" //Add this line to import fmt
	"strings"

	"imuslab.com/zoraxy/mod/netutils"
)

func (s *AccessRule) IsIPWhitelisted(ipAddr string) bool {
	//Check for IP wildcard and CIRD rules
	WhitelistedIP := *s.WhiteListIP
	for ipOrCIDR, _ := range WhitelistedIP {
		wildcardMatch := netutils.MatchIpWildcard(ipAddr, ipOrCIDR)
		if wildcardMatch {
			return true
		}

		cidrMatch := netutils.MatchIpCIDR(ipAddr, ipOrCIDR)
		fmt.Println(ipAddr, cidrMatch) //Add this line after line 91
		if cidrMatch {
			return true
		}
	}

	return false
}

Then we will know if your rule is set correctly or there are issue with the CIDR matching logic (which is rare as it is golang's build in function)

from zoraxy.

I modified the files accordingly in my Zoraxy container image and recreated the image but I'm unsure on where I should execute the go mod tidy and go build commands, is that inside of the container itself afterwards?

from zoraxy.

@Mereck13579 Oh uh you running Zoraxy in container. In that case, you will need a go compiler inside the container or you build it outside of your container and use SFTP to replace the running binary file in the container.

from zoraxy.

Fixed in v3.0.3

from zoraxy.