Transparent proxy with squid in a jail

J

jahlives

Hello

I'm currently trying to move my proxy (SQUID) from my DEBIAN to a jail on FreeBSD 9-Release
The server has two network interfaces connected to 2 private subs:

em0: 192.168.200.2
em1: 192.168.199.7

I setup a jail which is connected to em0 with IP 192.168.200.202 and installed SQUID in there. SQUID works fine if I set it's IP address in the browsers as explicit proxy server. My client is 192.168.199.11 and if I set 192.168.200.202 as proxy everything works fine. So ip-forwarding on the server should not be the issue.

But I cannot access the web if I try SQUID as a transparent proxy. To do so I setup the following on the router in the sub connected on em1 (192.168.199.1) in IPTABLES
Code: 
iptables -t mangle -I PREROUTING -j ACCEPT -p tcp --dport 80 -s 192.168.199.1
iptables -t mangle -A PREROUTING -j MARK --set-mark 3 -p tcp --dport 80
#iptables -t mangle -A POSTROUTING -p tcp --dport 80 -d 192.168.199.7 -j SNAT --to 192.168.199.1
ip rule add fwmark 3 table 2
ip route add default via 192.168.199.7 dev br0 table 2
the 3rd rule is not-active at the moment, but it does not work either if the rule is active
On the FreeBSD server I setup a "port-forward"-rule in my IPNAT rules file /etc/ipnat.rules
Code: 
rdr em1 192.168.199.7/32 port 80 -> 192.168.200.202 port 3128 tcp
imho this should forward all traffic on port 80 to the ip of the jail with SQUID and port 3128.

SQUID is configured as transparent proxy by the following in /usr/local/etc/squid/squid.conf
Code: 
http_port 192.168.200.202:3128 transparent
and finally I have a rule on the router firewall (IPTABLES) of em0-sub to DROP all traffic on port 80 which is not originated by the SQUID ip address
Code: 
DROP       tcp  -- !192.168.200.202      0.0.0.0/0           tcp dpt:80
but if I check the state with $ iptables -L FORWARD -nv I can see that every http request via transparent proxy gets dropped
Code: 
[B]3478  181K[/B] DROP       tcp  --  *      *      !192.168.200.202      0.0.0.0/0           tcp dpt:80
for me it seems that the requests are not originated by 192.168.200.202, that should be the only reason for this rule to take action. But this only happens when I try transparent mode. If I set the proxy manually in the browser settings, then this rule seems not to take action as the requests to the web are successful. Otherwise I could not write this post ;)

does anyone have a clue what I could check or in which region the problem could be? I use IPF as firewall on the server but currently no rules are in place, so imho it should not be a firewall issue too.

Thanks for any hint

tobi
 
SOLVED: Wrong ipnat rules

Hello

I think I finally got it and my SQUID is properly running in transparent mode. I had to change the IPNAT-rule to the following
Code: 
rdr em1 0.0.0.0/0 port 80 -> 192.168.200.202 port 3128 tcp
and it works as it should
Can anyone explain to me why it did not work with explicit interface ipaddress? or why I have to use 0.0.0.0/0? sorry for these maybe-newbie questions, but I'm still quite new to FreeBSD :)
 
You are not going to know the destination addresses of the connections to port 80 in advance, that's why you have to use the catch-all address 0.0.0.0/0 in the rdr rule. Btw, ipf(8) is becoming more and more deprecated because there's no development happening on it and the situation is unlikely to change, consider changing to pf(4) (probably easier for you) or ipfw(4).
 
@kpa
thanks for the tip with another firewall, I think I will tryout with pf then. Or which one would you personally prefer?

But I still do not understand why the server should not know the destination address. Such packets are forwarded by the router firewall to IP 192.168.199.7 which is em1-interface of the FreeBSD-server. In that case the destination should be 192.168.199.7 or am I completly missunderstand my own construction? ;)
 
I use pf(4) because I know it lot better than ipfw(4).

Forwarding is done based on the gateway setting on the host but the destination addresses in IP packets themselves are already set to the address of the target host and won't be changed in the process.
 
"ipf(8) is becoming more and more deprecated because there's no development happening on it and the situation is unlikely to change"

This is a false statement. Both IPF and PF have current development but the FreeBSD development team has dropped the ball by not updating the FreeBSD release 9.x or 10.x to the current release level of these firewall applications as maintained by their upstream authors.
 
What that tells me is ipfw is maintained by Freebsd and pf is maintained by openbsd and ipf is maintained by an upstream author who has his own mailing list. So in the big picture it means nothing.
 
You must log in or register to reply here.
Back
Top