How to setup a transparent http proxy system-wide?

My setup is one where I am connected to router 2 that routes all connections to a vpn, in this setup I have a EndeavourOS guest virtual machine, but I don’t want the traffic on this VM to go through the vpn. As a solution, router 1 doesn’t use a vpn and provides a proxy applications can connect to. When testing if the proxy works through Firefox (under general → scroll to bottom → network settings → fill out the fields), it was successful! Websites show my real ip instead of the vpn.
It is still possible for some applications to not offer the option of using a proxy, because of this I need a method that doesn’t rely on proxy settings being implemented. Here’s a little guide on how to do this.

  1. Install Redsocks
yay -S redsocks
  1. Write a configuration file in /etc/redsocks.conf
base {
        log_debug = on;
        log_info = on;
        log = "syslog:daemon";
        daemon = on;
        redirector = iptables;
}

redsocks {
        local_ip = 0.0.0.0;
        local_port = 31338;

        ip = 192.168.1.1;
        port = 8888;
        type = http-connect;
}
  1. Enable and start the systemctl service
sudo systemctl enable redsocks
sudo systemctl start redsocks
  1. Setup iptables, use the redsocks website as a guide
# Create new chain
sudo iptables -t nat -N REDSOCKS

# Ignore LANs and some other reserved addresses.
# See Wikipedia and RFC5735 for full list of reserved networks.
sudo iptables -t nat -A REDSOCKS -d 0.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 10.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 127.0.0.0/8 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 169.254.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 172.16.0.0/12 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 192.168.0.0/16 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 224.0.0.0/4 -j RETURN
sudo iptables -t nat -A REDSOCKS -d 240.0.0.0/4 -j RETURN

# Anything else should be redirected to port 31338
sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 31338

Now it should work, but it doesn’t. In another guide, I noticed someone also did

sudo iptables -t nat -A REDSOCKS -p tcp --dport 443 -j REDIRECT --to-ports 31338

sudo iptables -t nat -A REDSOCKS -p tcp -j REDIRECT --to-ports 31338

# Any tcp connection made should be redirected to the REDSOCKS CHAIN.
sudo iptables -t nat -A OUTPUT -p tcp -j REDSOCKS

So I tried. Now I don’t have internet connection. This is mainly due to the last line.

I believe I got this to work on OpenSUSE, but I didn’t write the steps I took or the resources I used to achieve this. Is anyone able to help me make this work? I had also tried to use NekoRay which was able to achieve this successfully, but it was using google’s dns instead of pi-hole and I can’t figure out how to change it. Github issue

I might be missing something here, but if you want the VM to only use the proxy why not just define the exports in /etc/environment?

http_proxy=[proxy info]
https_proxy=[proxy info]
HTTP_PROXY=[proxy info]
HTTPS_PROXY=[proxy info]

I run my entire system through a proxy and everything works, besides Steam which actively blocks proxies.

Steam which actively blocks proxies.

That is exactly why. I am sure not every app will respect your system proxy settings or will use those settings.

Edit: In my experience, Steam doesn’t “block” proxies. Even with tor, Steam only prevents you from logging in but you can still browse the website freely. If you are already logged in, you won’t get logged out, and you can still play games without getting banned (the games can still ban you). This was my experience using tor as a proxy years ago.
Steam simply ignores the proxy settings provided by your system, this is not always intentional since programs have to go out of their way to make the program recognize that the system wants every program to go through a proxy. Your system settings don’t intercept or redirect connections and it doesn’t do anything to dominate in this case like VPNs do, all it does is suggest some configurations (just like a dhcp server does)

In my experience over the years of writing /debugging ipchains/iptables/netfilter rules/firewalls in that even with a good understanding or ip networking things often don’t works the way you expect and can be perplexing, frustrating and really difficult to debug, even when they are happening right in front of me, and every time I do it I have to refresh my knowledge again.

So I really don’t want to get in to deep. That said. None of the red socks table rules will do anything without a rule on the ouput table send the packets to I the red socks rule, which when you got blocked. So you have to figure out what is happening to the packets and fix it for packets you don’t want to go to redsoocks, or maybe even packets from red socks. Usually the here would be other rules about related, established connections short circuiting the rules too.

Easiest way to debug is debug in a stripped down VM, so less complexity and less other things interfering . When you have predictable and non interfering in the VM you can try on the host,

Also, you said http proxy, which is port 80, and you are interviewing port 443 which is https, which usually requires a local certificate setup to decrypt an reencrypt, so you might want to read more doco and refund what you are doing.