Reply To: Direct transparent proxy traffic to a peer?

Home Page Forums Network Management Transparent Proxy Direct transparent proxy traffic to a peer? Reply To: Direct transparent proxy traffic to a peer?

#50419

roden
Member

I changed things around a bit (and disabled Zeroshell’s built-in transparent proxy, which removed this line: -A PREROUTING -p tcp -m tcp –dport 80 -j Proxy) and got a slightly better scenario. So now my rules look like:

-A PREROUTING -i ETH00 -p tcp -m tcp –dport 80 -j DNAT –to-destination 67.219.254.22:3128
-A PREROUTING -i ETH01 -p tcp -m tcp –dport 80 -j REDIRECT –to-ports 3128

And I get traffic to the upstream proxy:

17:14:50.952063 10.102.132.38.3088 > .3128: R 187842165:187842165(0) ack 2449923915 win 0 (DF)
17:14:52.364742 10.102.132.38.3092 > .3128: S 1325328404:1325328404(0) win 64240 (DF)
17:14:52.366500 .3128 > 10.102.132.38.3092: S 3955775135:3955775135(0) ack 1325328405 win 65535 (DF)
17:14:52.366713 10.102.132.38.3092 > .3128: . ack 1 win 64240 (DF)
17:14:52.367808 10.102.132.38.3092 > .3128: P 1:696(695) ack 1 win 64240 (DF)
17:14:52.368737 .3128 > 10.102.132.38.3092: . ack 696 win 65535 (DF)

Note that once again I removed the actual IP and replaced it with “IP”, since this is a public IP. Anyway, the problem now is that the request shows up in my upstream proxy logs as http://:3128/morestuff. So you can see for some reason it’s inserting the :3128 into the forwarding request. Note that this upstream proxy forwards to yet another upstream proxy.

At least that’s how it forwarding the request. When I look at packet captures from this upstream proxy I notice that when I’m not using transparent proxy for my Zeroshell, and point my browser directly to the upstream proxy, then it will send a correct absolute URI: http:///morestuff. But when I transparently proxy, with no proxy set in the browser, then I see an absolute path sent: /morestuff

I’m nit sure if this plays a part in the problem. I’m pretty sure that when you specify a proxy in your browser, it then sends requests in absolute URI instead of absolute path. But it may be unrelated to the problem with the :3128 being stuck into my request. Any ideas?