source address problem using transparent proxy

[awrightus]

I'm running DD-WRT on a Linksys WRT-160N router. I'm using iptables to create a transparent proxy, passing all port 80 traffic to another box running Squid. It's working fine, except that when I look at my Squid logs (access.log), the source address of all the traffic is the Linksys router, and not the actual originating client. My iptables rules are copied below. Am I doing something wrong? Any help appreciated. Thanks.

iptables -t nat -A PREROUTING -i br0 -s 192.168.101.0/24 -d 192.168.101.0/24 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -i br0 -s ! 192.168.101.3 -p tcp --dport 80 -j DNAT --to 192.168.101.3:3128
iptables -t nat -A POSTROUTING -o br0 -s 192.168.101.0/24 -p tcp -d 192.168.101.3 -j SNAT --to 192.168.101.1
iptables -t filter -I FORWARD -s 192.168.101.0/24 -d 192.168.101.3 -i br0 -o br0 -p tcp --dport 3128 -j ACCEPT

[Lazydog]

What does your entire firewall rules look like?

don't understand why you are doing this;

iptables -t nat -A PREROUTING -i br0 -s 192.168.101.0/24 -d 192.168.101.0/24 -p tcp --dport 80 -j ACCEPT

Also don't understand why you are doing this either;

iptables -t nat -A POSTROUTING -o br0 -s 192.168.101.0/24 -p tcp -d 192.168.101.3 -j SNAT --to 192.168.101.1

[syd05]

Hi,

The SNAT rule for IP tables replaces the original IP in the packet with the new SNAT packet. IMHO there is no way that the original IP is sort of encapsulated in the data packet and fetched later on.

Other option that might work ( though I've not tried it out ), would be to use the mangle table on the Linksys router, mark packets and re-route it to the squid server. Something on the lines of the following:
On router

iptables -t mangle -A PREROUTING -j ACCEPT -p tcp --dport 80 -s squid-box
iptables -t mangle -A PREROUTING -j MARK --set-mark 3 -p tcp --dport 80
ip rule add fwmark 3 table 2
ip route add default via squid-box dev eth1 table 2

On Squid server:

iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128

Your would need to create second routing table as well for the ip route / ip rule command to work.

--Syd

[awrightus]

I haven't yet tried anything with regard to the 'mangle' suggestion, but I have played around a bit more and gotten things working with just this one line:

iptables -t nat -A PREROUTING -i br0 -s ! 192.168.1.3 -p tcp --dport 80 -j DNAT --to 192.168.1.3:3128

So if the source is address is anything other than 1.3, forward all port 80 traffic to 1.3 on port 3128. I'm not doing anything with source address translation, yet the squid access.log (on 1.3) shows the linksys router (iptables box/ 1.1) as the source address. Here's a snippet from the squid access.log:

1259673516.405 36 192.168.1.1 TCP_MISS/200 394 HEAD <url here that linuxforums.org won't allow in my post> - DIRECT/208.111.185.136 application/octet-stream

Something going on with iptables and/or dd-wrt natively that I clearly don't understand. Any insight appreciated.

[awrightus]

iptables rule output if it's of any value. Stuff going on under the hood done automatically with dd-wrt that I'm not doing. The only command I've added is the one in the previous post.

root@linksys:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere udp dpt:route
DROP udp -- anywhere anywhere udp dpt:route
ACCEPT udp -- anywhere anywhere udp dpt:route
DROP icmp -- anywhere anywhere
DROP igmp -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state NEW
logaccept 0 -- anywhere anywhere state NEW
DROP 0 -- anywhere anywhere

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT gre -- 192.168.1.0/24 anywhere
ACCEPT tcp -- 192.168.1.0/24 anywhere tcp dpt:1723
ACCEPT 0 -- anywhere anywhere
TCPMSS tcp -- anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU
lan2wan 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere 192.168.1.3 tcp dpt:ssh
TRIGGER 0 -- anywhere anywhere TRIGGER type:in match:0 relate:0
trigger_out 0 -- anywhere anywhere
ACCEPT 0 -- anywhere anywhere state NEW
DROP 0 -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Chain advgrp_1 (0 references)
target prot opt source destination

Chain advgrp_10 (0 references)
target prot opt source destination

Chain advgrp_2 (0 references)
target prot opt source destination

Chain advgrp_3 (0 references)
target prot opt source destination

Chain advgrp_4 (0 references)
target prot opt source destination

Chain advgrp_5 (0 references)
target prot opt source destination

Chain advgrp_6 (0 references)
target prot opt source destination

Chain advgrp_7 (0 references)
target prot opt source destination

Chain advgrp_8 (0 references)
target prot opt source destination

Chain advgrp_9 (0 references)
target prot opt source destination

Chain grp_1 (1 references)
target prot opt source destination

Chain grp_10 (0 references)
target prot opt source destination

Chain grp_2 (0 references)
target prot opt source destination

Chain grp_3 (0 references)
target prot opt source destination

Chain grp_4 (0 references)
target prot opt source destination

Chain grp_5 (0 references)
target prot opt source destination

Chain grp_6 (0 references)
target prot opt source destination

Chain grp_7 (0 references)
target prot opt source destination

Chain grp_8 (0 references)
target prot opt source destination

Chain grp_9 (0 references)
target prot opt source destination

Chain lan2wan (1 references)
target prot opt source destination
grp_1 0 -- anywhere anywhere

Chain logaccept (1 references)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere

Chain logdrop (0 references)
target prot opt source destination
LOG 0 -- anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
LOG 0 -- anywhere anywhere state INVALID LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
DROP 0 -- anywhere anywhere

Chain logreject (0 references)
target prot opt source destination
LOG 0 -- anywhere anywhere LOG level warning tcp-sequence tcp-options ip-options prefix `WEBDROP '
REJECT tcp -- anywhere anywhere tcp reject-with tcp-reset

Chain trigger_out (1 references)
target prot opt source destination
root@linksys:~#

root@linksys:~# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT icmp -- anywhere adsl-178-20-245.chs.bellsouth.net to:192.168.1.1
DNAT tcp -- anywhere adsl-178-20-245.chs.bellsouth.net tcp dpt:ssh to:192.168.1.3:22
TRIGGER 0 -- anywhere adsl-178-20-245.chs.bellsouth.net TRIGGER type:dnat match:0 relate:0
DNAT tcp -- !192.168.1.3 anywhere tcp dpt:www to:192.168.1.3:3128

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT 0 -- anywhere anywhere to:74.178.20.245
RETURN 0 -- anywhere anywhere PKTTYPE = broadcast
MASQUERADE 0 -- 192.168.1.0/24 192.168.1.0/24

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

[awrightus]

Found this at linuxdevcenter.com. Seems to describe my problem. Any help with crafting the iptables rules to support what it's describing here appreciated.

"You can have proxies which aren't on the intercepting machine, but these are more awkward. First, the source address of the request is no longer available to the proxy -- it's lost in the process of redirection. You can solve this by using destination NAT (Network Address Translation), but you then have to route the proxy traffic back through the translating server. If you attempt to have the proxy pass the HTTP response back directly, the client will be confused and (quite correctly) refuse to speak to the proxy. The proxy is not the machine the client thinks it's talking to -- the client thinks it's making the request of the destination web server. The proxy must route back through the interceptor, so it can translate the addresses back, and let the client continue to believe it's speaking directly to the web server."