As of this writing I have placed across several devices running on a LAN:
one server as a VNC + Pidgin (chat client) combo
one server Squid Proxy + Wireguard (VPN) combo
The way this works is that every device wanting to use the VPN can do so by accessing the Squid proxy server. Mainly this is to allow simple access to the VPN via a browser, such as Firefox. As there is an extension to toggle whether the browser will use the proxy server or not the implementation is quite simple. Moreover, a private window in Firefox has VPN access disabled by default.
Likewise the VNC + Pidgin chat client server accomplishes two functions. Allowing for browser access and the use of a chat client through a remote desktop setup on that same server. Not the fastest nor can you watch videos, but handy for other things.
But as noted this requires TWO different servers to accomplish this. What I am trying to do is combine all of those functions into one server only.
Everything works except the Pidgin chat client. It does not connect with the chat server. The chat server and pihole DNS server reside on the LAN on a separate device of course. There are no problems with other devices accessing the chat server be it on the LAN or WAN. But the all in one combo server, Squid Proxy + Wireguard (VPN) + VNC + Pidgin (chat client) never connects to the chat server.
I am also left with the weakness that using the browser on the VNC being stuck using the global network settings on the server, which means VPN only, unless I kill Wireguard. But killing Wireguard kills the VPN access for other devices connecting to the internet via Squid on that same server.
Would some kind soul here point to the error(s) of my ways with this experiment?
The two servers are simple SBCs. Combining all of that functionality into one server would be nice, but am I on a fools errand?
If I understand your setup correctly then you could probably use policy routing.
You can have multiple routing tables and define rules that tells the kernel which one to use, based on “selectors” (man ip-rule).
Example:
# Create default route using the Wireguard wg0 interface in a new table with ID 10
ip route add 0/0 dev wg0 table 10
# All traffic from user 1000 (e.g. your Squid user) uses table 10
ip rule add uidrange 1000-1000 table 10
Now if you run as root ip route get 8.8.8.8 you should see your normal default route and ethernet interface show.
If you run that as user 1000, it’ll show it’s using table 10 and interface wg0.
So if you run each service as a different uid, you can easily have a different routing table per service.
The key there is to make sure the Wireguard tunnel comes up with a point-to-point route (the default, if you don’t specify anything fancy) and not a default route or a low priority “fake” default route like 0.0.0.0/1 + 128.0.0.0/1.
If you want more fine-grained selectors, you can use the iptables mangle table to select packets, and set the MARK target, which gets picked up from the fwmark selector in iproute2.
Another option is to put the services in different network namespaces, which also can get a per-namespace route table, but then you need to get the traffic into that namespace too, which I think makes it more complex than needed.
Thanks for the reply, all of this is a bit messy and complicated to me. I can see myself getting this wrong through a few iterations before I get iti working. It is not clear if your solution includes that both squid and wireguard are being used simultaneously, as they are right now. A user uses this proxy with the idea of ALSO using wireguard to access the WAN.
Otherwise, if this is above my pay grade then the idea of two SBC’s is the fall back, no way around it, as I know it works deterministically.
Your issue likely stems from DNS, firewall rules, or routing conflicts with WireGuard. Check if the all-in-one server resolves the chat server correctly (nslookup/dig). Ensure firewall rules allow Pidgin’s ports and that it’s not using Squid proxy. If WireGuard is forcing all traffic through VPN, try policy-based routing (iptables -t mangle + ip rule add fwmark 1 table main). Alternatively, use a separate user/network namespace for VNC or a SOCKS5 proxy for selective VPN use. Your setup isn’t a fool’s errand—just requires fine-tuning to handle network segregation properly. Let me know if you need specifics!
I did something similar and had to be careful with routing rules so that VNC and chat didn’t leak outside the VPN or proxy. Policy-based routing helped keep stuff separate.
