[BUG] IPv6 doesn't work in whitelist

[Nirostar]

First of all, thanks for this great piece of software and for your time maintaining it!

Describe the bug When I whitelist fe80::/10 Zoraxy still blocks fe80::705b:4974:22ce:288b which should be in this CIDR.

To Reproduce Steps to reproduce the behavior:

1. Whitelist fe80::/10
2. Try to connect to a proxied address behind that Access Control from a link local device using IPv6.
3. You get 403 - Forbidden Page

Expected behavior Requests from link local IPv6 should work when whitelisted.

Screenshots & Logs

2025/04/06 00:49:51 [2025-04-06 00:49:51.275838] [router:whitelist] [origin:] [client fe80::705b:4974:22ce:288b%eth0] GET /web/login.html 403

Host Environment (please complete following information, DO NOT REMOVE ANY FIELD(S)):

• Arch: x86_64
• Device: Intel(R) Xeon(R) CPU E5-2640 v4 @ 2.40GHz (Through Proxmox)
• OS: Debian GNU/Linux 12 (bookworm)
• Version: v.3.1.9
• Are you using Docker? (yes / no): no
• Docker Version (fill in "N/A" for native deployment): N/A

[tobychui]

Well I don't have any IPv6 devices to test or debug this, but maybe you can try using Zoraxy natively (without docker) to see if the same issue persists. That will help narrow down the issue a bit.

[Nirostar]

@tobychui I use it natively though. Shouldn't any Desktop be able to do connect to others via ipv6 locally? The connection actually seems to work, but the whitelist doesn't trigger right.

[tobychui]

@Nirostar Hmm, as I remember whitelist do works for IPV6, but it has never tested in a ipv6 based LAN environment. I am thinking the %eth0 might be the problem here. You got any more logs with different ips?

[Nirostar]

@tobychui Not atm, because I am at the office. I will come back to you later. What is the semantic difference between the globe and the screen next to the pattern in the UI? Maybe that is a hint?

[Nirostar]

@tobychui I connected home via my VPN and it seems that IPv6 has %eth0: 2025/04/06 00:23:28 [2025-04-06 00:23:28.656875] [router:whitelist] [origin:] [client fe80::705b:4974:22ce:288b%eth0] GET /web/login.html 403

while IPv4 doesn't have it:

2025/04/08 14:39:47 [2025-04-08 14:39:47.384459] [router:host-http] [origin:192.168.0.66] [client 192.168.0.202] GET /ocs/v2.php/apps/notifications/api/v2/notifications?format=json 304

[Nirostar]

https://github.com/tobychui/zoraxy/pull/631

I think this could fix the issue, no idea how to properly verify that though.

[tobychui]

@Nirostar

What is the semantic difference between the globe and the screen next to the pattern in the UI?

The globe means that Zoraxy can identify it as a public IP address, while the screen icon means it is LAN / unrecognizable address (and will be treated as LAN connections). It have no functional purpose in terms of whitelist routing, so I guess it might not be the issue here.

I think this could fix the issue, no idea how to properly verify that though.

The "check if the request IP is within the given CIDR ip range" part of the implementation is handled using golang native net.ParseCIDR and net.ParseIP. https://github.com/tobychui/zoraxy/blob/19d5695f1ae5e6b3968243b2938d765c4cf474ad/src/mod/netutils/ipmatch.go#L88C1-L101C2

And the ip address of the request is cast from net.Conn

https://github.com/tobychui/zoraxy/blob/19d5695f1ae5e6b3968243b2938d765c4cf474ad/src/mod/access/accessRule.go#L21C1-L27C1

So in theory I don't think trimming that part off in #631 is the "correct fix" for the issue.

Btw, the Version field in the bug report form is expected you to fill in the Zoraxy version that you are using. What Zoraxy version you are using? Have you tried the "AllowLocalAndLoopback" option?

[Nirostar]

Oops, of course it is. I fixed it. I am on v.3.1.9. Yeah maybe not in that function, but since you are also removing fluff like [], I thought it should be fine? Not sure where this is used elsewhere. But it should at least be removed before doing the CIDR checks, because they won't work with the scope id.

[tobychui]

Yeah ok, fair enough.

To be honest I think this is a bug / missing feature in golang's cidr.Contains function. But if it works, it works. Regarding the PR, I might need to change the merge target to the v3.2.1 dev branch so the docker will be correctly built later in the next release. Great job fixing it 👍🏻

[Nirostar]

Thanks a lot for the lightning-fast responses and the great product. I was mainly vibe-coding the fix, since I never worked with Go before. Any timeline on the next release?

[tobychui]

Probably next month, thought the coming few versions will all be pre release due to massive internal change recently.