thebeardedone
New Around Here
G'day folks,
Quick (possibly) stupid (more possibly) question. Applies more to netfilter and general routing than AsusWRT-Merlin I suppose, but that's the system where I'm trying to pull this off.
I have a remote proxy that handles both HTTP and HTTPS - functionally, similar to tinyproxy.
I've set up DNAT/SNAT rules, and the requisite FORWARD rule for both 80 and 443 roughly like so:
iptables -t nat -A PREROUTING -i tun21 -s ! x.x.x.x -p tcp --dport 80 -j DNAT --to x.x.x.x:8080
//repeat for 443
iptables -t nat -A POSTROUTING -i tun21 -s 10.0.0.0/8 -d x.x.x.x -j SNAT --to 192.168.1.1
iptables -A FORWARD -s 10.0.0.0/8 -d x.x.x.x -i tun21 -o tun21 -p tcp --dport 8080 -j ACCEPT
...where x.x.x.x is the public IP address of the remote proxy. Of note, the remote proxy is directly connected to the internet, with a real public IP, not behind a firewall or any kind of NAT. Remote proxy is a linux system as well, so maybe netfilter on the remote side is dropping something (but I can't see it in my logs on the server side)
Now obviously HTTP works.
HTTPS does not - I've been aware it does not for some time, but every time I try to tackle this problem I wind up googling around and finding either a)"HTTPS doesn't work, give up!", or b)"obviously you're trying to use Squid, here's how you set up ssl_bump"
I don't need to do SSL inspection or anything of the sort. This is really a PoC for me more than anything. Either way, can anyone either provide a detailed explanation as for why "HTTPS doesn't work, give up!" is correct, or, alternatively, point me the direction of how to get this working?
I've seen the TPROXY netfilter target, not sure if that would make any difference. If it would, why?
I've also seen sparse doco for a proxy running on the same host as the netfilter box (in this case, AsusWRT-Merlin), but not a remote proxy. Would that work? I mean, running a proxy locally on the AsusWRT-Merlin box (an RT-N66U, fwiw) and chaining it to the upstream proxy? (assuming I can build a proxy binary that will run on the router successfully)
More detailed scenario - I have this rule in place for tun* so that those who VPN into my home network get routed to a remote proxy. With things set up as they are currently, HTTPS requests kinda sorta attempt to start, but ultimately time out. I can see the traffic hitting the remote proxy, but I've somewhat run out of ideas.
("those who VPN to my home network" == me firing up the OpenVPN client on my Android phone, and sending 80/443 to a proxy on our corporate network)
Any ideas or explanations, much appreciated, a bit lost in the weeds on this after a no-sleep-tried-again-and-failed all-nighter.
Quick (possibly) stupid (more possibly) question. Applies more to netfilter and general routing than AsusWRT-Merlin I suppose, but that's the system where I'm trying to pull this off.
I have a remote proxy that handles both HTTP and HTTPS - functionally, similar to tinyproxy.
I've set up DNAT/SNAT rules, and the requisite FORWARD rule for both 80 and 443 roughly like so:
iptables -t nat -A PREROUTING -i tun21 -s ! x.x.x.x -p tcp --dport 80 -j DNAT --to x.x.x.x:8080
//repeat for 443
iptables -t nat -A POSTROUTING -i tun21 -s 10.0.0.0/8 -d x.x.x.x -j SNAT --to 192.168.1.1
iptables -A FORWARD -s 10.0.0.0/8 -d x.x.x.x -i tun21 -o tun21 -p tcp --dport 8080 -j ACCEPT
...where x.x.x.x is the public IP address of the remote proxy. Of note, the remote proxy is directly connected to the internet, with a real public IP, not behind a firewall or any kind of NAT. Remote proxy is a linux system as well, so maybe netfilter on the remote side is dropping something (but I can't see it in my logs on the server side)
Now obviously HTTP works.
HTTPS does not - I've been aware it does not for some time, but every time I try to tackle this problem I wind up googling around and finding either a)"HTTPS doesn't work, give up!", or b)"obviously you're trying to use Squid, here's how you set up ssl_bump"
I don't need to do SSL inspection or anything of the sort. This is really a PoC for me more than anything. Either way, can anyone either provide a detailed explanation as for why "HTTPS doesn't work, give up!" is correct, or, alternatively, point me the direction of how to get this working?
I've seen the TPROXY netfilter target, not sure if that would make any difference. If it would, why?
I've also seen sparse doco for a proxy running on the same host as the netfilter box (in this case, AsusWRT-Merlin), but not a remote proxy. Would that work? I mean, running a proxy locally on the AsusWRT-Merlin box (an RT-N66U, fwiw) and chaining it to the upstream proxy? (assuming I can build a proxy binary that will run on the router successfully)
More detailed scenario - I have this rule in place for tun* so that those who VPN into my home network get routed to a remote proxy. With things set up as they are currently, HTTPS requests kinda sorta attempt to start, but ultimately time out. I can see the traffic hitting the remote proxy, but I've somewhat run out of ideas.
("those who VPN to my home network" == me firing up the OpenVPN client on my Android phone, and sending 80/443 to a proxy on our corporate network)
Any ideas or explanations, much appreciated, a bit lost in the weeds on this after a no-sleep-tried-again-and-failed all-nighter.