zoraxy icon indicating copy to clipboard operation
zoraxy copied to clipboard

[HELP] ACL Not Working

Open imlezz opened this issue 11 months ago • 4 comments

What happened? I have configured ACL for Zoraxy and everything works as long as the ip belong to local LAN but breaks when I am using VPN(wireguard). It looks like the ip address of the client isn't working correctly and Zoraxy is seeing the VPN server ip instead, hence blocking all access since VPN server ip isn't part of the ACL.

Describe what have you tried If I try to add the VPN server ip to the ACL, most of the proxy resource works via VPN but then this is not what I am looking for as setting things up this way would defeat the purpose of creating ACL.

Describe the networking setup you are using ==> Zoraxy is installed on a LXC container. ==> PiHole is handling my DNS(only ad-blocking). ==> PiHole forwards the DNS query to Pfsense which is running unbound. ==> DNS resolver on Pfsense has all the mappings for the FQDN for the services I am running and they are all pointed to the ip address of the Zoraxy server. ==> Wireguard is installed on a LXC container. ==> My network comprises of different VALNS such as 20, 30, 40 etc. There is RFC1918 rule in place for all VLANS and no one can talk to each other unless I manually create a firewall rule in my Pfsense router.

Additional context I read some of the closed issues that people reported here abt more or less the issue I am facing and referred to using "X-Forwarded-For" which I have absolutely no clue where and what to add. I did try editing on of the proxy resource and went into advance settings>>customer headers>>Header key and Header value section but this is as far I could get. Beyond this it was all Latin and Greek for me.

I did check the snippet/logview portal and found that there were references of 403 error in there with the ip address of my Wireguard server. Here is a quick extract of what I saw in the logview(here client 10.0.xx.xx] is the actual the ip address of my Wireguard server).

[2025-03-28 04:29:24.453623] [router:whitelist] [origin:] [client 10.0.xx.xx] GET / 403 [2025-03-28 04:29:24.543463] [router:whitelist] [origin:] [client 10.0.xx.xx] GET /favicon.ico 403

So in short Zoraxy is not picking the VPN ip address mentioned in the ACL to either grant or allow access to the proxy resource it is handling. Please let me know if you need any additional info in order to help me get this fixed.

Thanks!

imlezz avatar Mar 28 '25 04:03 imlezz

@imlezz Here is how Zoraxy get the request origin IP from an incoming request.

https://github.com/tobychui/zoraxy/blob/549e492ffd081df6032d9f1003917c1e63d1a1b1/src/mod/netutils/ipmatch.go#L16-L62

If there are no matching fields in your HTTP request, Zoraxy fall backs to Golang's net/http package's r.RemoteAddr for providing the remote address information. Sometime it might not be the IP you are expecting but it is the best Zoraxy can guess from a request.

Regarding X-Forwarded-For, it is a HTTP header that the HTTP proxy / forwarder should be appending to the HTTP request header so the next node in the route can know where the request has passed through and the respective IP address of the nodes.

Since you are forwarding the HTTP data in the transport layer (TCP/IP) instead of application layer, there are no ways Zoraxy can knows where the request come from except from reading from the TCP/IP packet which, you guessed it, sent from your wireguard node with that node's IP. That is why Zoraxy have no choice but to use that IP address for access control instead.

tobychui avatar Mar 28 '25 14:03 tobychui

Thank you for your response. So there is no way to fix this is what I understand. Am I correct?

imlezz avatar Mar 28 '25 14:03 imlezz

@imlezz You need to adjust your network architecture to support what you wanna do.

Something like adding a reverse proxy before the request entering your wireguard ingress node to append the required client ip headers to the HTTP request, so after it leave the VPN exit node, Zoraxy can still sniff where your request originally came from. Another approach is move the access control system before the request entering the VPN.

tobychui avatar Mar 29 '25 00:03 tobychui

Alright thank you for tips. I was able to get it to work. Enjoying your app to the fullest. Love its simplicity no frills and unwanted strings attached. Is there a roadmap I can take a look at and see what's coming? Do you plan to create a Discord server for your app where all community members can meet and discuss stuff?

Have a nice day.

imlezz avatar Mar 29 '25 11:03 imlezz