How can I make my users' browsers use my cache without configuring the browsers for proxying?
Getting transparent caching to work requires three distinct steps:
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
First, get and install the IP Filter package.
Put these lines in /etc/ipnat.rules:
# Redirect direct web traffic to local web server.
rdr de0 1.2.3.4/32 port 80 -> 1.2.3.4 port 80 tcp
# Redirect everything else to squid on port 8080
rdr de0 0.0.0.0/0 port 80 -> 1.2.3.4 port 8080 tcp
Modify your startup scripts to enable ipnat. For example, on FreeBSD it looks something like this:
/sbin/modload /lkm/if_ipl.o
/sbin/ipnat -f /etc/ipnat.rules
chgrp nobody /dev/ipnat
chmod 644 /dev/ipnat
Squid-2 (after version beta25) has IP filter support built in. Simple enable it when you run configure:
./configure --enable-ipf-transparent
Add these lines to your squid.conf file:
http_port 8080
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Note, you don't have to use port 8080, but it must match whatever you
used in the /etc/ipnat.rules file.
Patches for Squid-1.X are available from Quinton Dolan's Squid page. Add these lines to squid.conf:
http_port 8080
httpd_accel virtual 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Thanks to Quinton Dolan.
Note: Transparent proxying does NOT work with Linux 2.0.30! Linux 2.0.29 is known to work well.
Warning: this technique has some shortcomings.
If you can live with the side-effects, go ahead and compile your kernel with firewalling and redirection support. Here are the important parameters from /usr/src/linux/.config:
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Networking options
#
CONFIG_FIREWALL=y
# CONFIG_NET_ALIAS is not set
CONFIG_INET=y
CONFIG_IP_FORWARD=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_VERBOSE is not set
CONFIG_IP_MASQUERADE=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
# CONFIG_IP_ACCT is not set
CONFIG_IP_ROUTER=y
You may also need to enable IP Forwarding. One way to do it is to add this line to your startup scripts:
echo 1 > /proc/sys/net/ipv4/ip_forward
Go to the Linux IP Firewall and Accounting page, obtain the source distribution to ipfwadm and install it. Older versions of ipfwadm may not work. You might need at least version 2.3.0. You'll use ipfwadm to setup the redirection rules. I added this rule to the script that runs from /etc/rc.d/rc.inet1 (Slackware) which sets up the interfaces at boot-time. The redirection should be done before any other Input-accept rule. To really make sure it worked I disabled the forwarding (masquerading) I normally do.
/etc/rc.d/rc.firewall:
#!/bin/sh
# rc.firewall Linux kernel firewalling rules
FW=/sbin/ipfwadm
# Flush rules, for testing purposes
for i in I O F # A # If we enabled accounting too
do
${FW} -$i -f
done
# Default policies:
${FW} -I -p rej # Incoming policy: reject (quick error)
${FW} -O -p acc # Output policy: accept
${FW} -F -p den # Forwarding policy: deny
# Input Rules:
# Loopback-interface (local access, eg, to local nameserver):
${FW} -I -a acc -S localhost/32 -D localhost/32
# Local Ethernet-interface:
# Redirect to Squid proxy server:
${FW} -I -a acc -P tcp -D default/0 80 -r 8080
# Accept packets from local network:
${FW} -I -a acc -P all -S localnet/8 -D default/0 -W eth0
# Only required for other types of traffic (FTP, Telnet):
# Forward localnet with masquerading (udp and tcp, no icmp!):
${FW} -F -a m -P tcp -S localnet/8 -D default/0
${FW} -F -a m -P udp -S localnet/8 -D default/0
Here all traffic from the local LAN with any destination gets redirected to the local port 8080. Rules can be viewed like this:
IP firewall input rules, default policy: reject
type prot source destination ports
acc all 127.0.0.1 127.0.0.1 n/a
acc/r tcp 10.0.0.0/8 0.0.0.0/0 * -> 80 => 8080
acc all 10.0.0.0/8 0.0.0.0/0 n/a
acc tcp 0.0.0.0/0 0.0.0.0/0 * -> *
I did some testing on Windows 95 with both Microsoft Internet Explorer 3.01 and Netscape Communicator pre-release and it worked with both browsers with the proxy-settings disabled.
At one time squid seemed to get in a loop when I pointed the browser to the local port 80. But this could be avoided by adding a reject rule for client to this address:
${FW} -I -a rej -P tcp -S localnet/8 -D hostname/32 80
IP firewall input rules, default policy: reject
type prot source destination ports
acc all 127.0.0.1 127.0.0.1 n/a
rej tcp 10.0.0.0/8 10.0.0.1 * -> 80
acc/r tcp 10.0.0.0/8 0.0.0.0/0 * -> 80 => 8080
acc all 10.0.0.0/8 0.0.0.0/0 n/a
acc tcp 0.0.0.0/0 0.0.0.0/0 * -> *
NOTE on resolving names: Instead of just passing the URLs to the proxy server, the browser itself has to resolve the URLs. Make sure the workstations are setup to query a local nameserver, to minimize outgoing traffic.
If you're already running a nameserver at the firewall or proxy server (which is a good idea anyway IMHO) let the workstations use this nameserver.
Additional notes from Richard Ayres
I'm using such a setup. The only issues so far have been that:
- It's fairly useless to use my service providers parent caches (cache-?.www.demon.net) because by proxying squid only sees IP addresses, not host names and demon aren't generally asked for IP addresses by other users;
- Linux kernel 2.0.30 is a no-no as transparent proxying is broken (I use 2.0.29);
- Client browsers must do host name lookups themselves, as they don't know they're using a proxy;
- The Microsoft Network won't authorize its users through a proxy, so I have to specifically *not* redirect those packets (my company is a MSN content provider).
Aside from this, I get a 30-40% hit rate on a 50MB cache for 30-40 users and am quite pleased with the results.
See also Daniel Kiracofe's page.
This works with at least IOS 11.1 and later I guess. Possibly earlier, as I'm no CISCO expert I can't say for sure. If your router is doing anything more complicated that shuffling packets between an ethernet interface and either a serial port or BRI port, then you should work through if this will work for you.
First define a route map with a name of proxy-redirect (name doesn't matter) and specify the next hop to be the machine Squid runs on.
!
route-map proxy-redirect permit 10
match ip address 110
set ip next-hop 203.24.133.2
!
Define an access list to trap HTTP requests. The second line allows
the Squid host direct access so an routing loop is not formed.
By carefully writing your access list as show below, common
cases are found quickly and this can greatly reduce the load on your
router's processor.
!
access-list 110 deny tcp any any neq www
access-list 110 deny tcp host 203.24.133.2 any
access-list 110 permit tcp any any
!
Apply the route map to the ethernet interface.
!
interface Ethernet0
ip policy route-map proxy-redirect
!
Bruce Morgan notes that there is a Cisco bug relating to transparent proxying using IP policy route maps, that causes NFS and other applications to break. Apparently there are two bug reports raised in Cisco, but they are not available for public dissemination.
The problem occurs with o/s packets with more than 1472 data bytes. If you try to ping a host with more than 1472 data bytes across a Cisco interface with the access-lists and ip policy route map, the icmp request will fail. The packet will be fragmented, and the first fragment is checked against the access-list and rejected - it goes the "normal path" as it is an icmp packet - however when the second fragment is checked against the access-list it is accepted (it isn't regarded as an icmp packet), and goes to the action determined by the policy route map!
John notes that you may be able to get around this bug by carefully writing your access lists. If the last/default rule is to permit then this bug would be a problem, but if the last/default rule was to deny then it won't be a problem. I guess fragments, other than the first, don't have the information available to properly policy route them. Normally TCP packets should not be fragmented, at least my network runs an MTU of 1500 everywhere to avoid fragmentation. So this would affect UDP and ICMP traffic only.
Basically, you will have to pick between living with the bug or better performance. This set has better performance, but suffers from the bug:
access-list 110 deny tcp any any neq www
access-list 110 deny tcp host 10.1.2.3 any
access-list 110 permit tcp any any
Conversely, this set has worse performance, but works for all protocols:
access-list 110 deny tcp host 10.1.2.3 any
access-list 110 permit tcp any any eq www
access-list 110 deny tcp any any
Just for kicks, here's an email message posted to squid-users on how to make transparent proxying work with a Cisco router and Squid running on Linux.
by Brian Feeny
Here is how I have Transparent proxying working for me, in an environment where my router is a Cisco 2501 running IOS 11.1, and Squid machine is running Linux 2.0.33.
Many thanks to the following individuals and the squid-users list for helping me get redirection and transparent proxying working on my Cisco/Linux box.
First, here is what I added to my Cisco, which is running IOS 11.1. In IOS 11.1 the route-map command is "process switched" as opposed to the faster "fast-switched" route-map which is found in IOS 11.2 and later. You may wish to be running IOS 11.2. I am running 11.1, and have had no problems with my current load of about 150 simultaneous connections to squid.:
!
interface Ethernet0
description To Office Ethernet
ip address 208.206.76.1 255.255.255.0
no ip directed-broadcast
no ip mroute-cache
ip policy route-map proxy-redir
!
access-list 110 deny tcp host 208.206.76.44 any eq www
access-list 110 permit tcp any any eq www
route-map proxy-redir permit 10
match ip address 110
set ip next-hop 208.206.76.44
So basically from above you can see I added the "route-map" declaration, and an access-list, and then turned the route-map on under int e0 "ip policy route-map proxy-redir"
ok, so the Cisco is taken care of at this point. The host above: 208.206.76.44, is the ip number of my squid host.
My squid box runs Linux, so I had to do the following on it:
my kernel (2.0.33) config looks like this:
#
# Networking options
#
CONFIG_FIREWALL=y
# CONFIG_NET_ALIAS is not set
CONFIG_INET=y
CONFIG_IP_FORWARD=y
CONFIG_IP_MULTICAST=y
CONFIG_SYN_COOKIES=y
# CONFIG_RST_COOKIES is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_VERBOSE is not set
CONFIG_IP_MASQUERADE=y
# CONFIG_IP_MASQUERADE_IPAUTOFW is not set
CONFIG_IP_MASQUERADE_ICMP=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
# CONFIG_IP_ACCT is not set
CONFIG_IP_ROUTER=y
You will need Firewalling and Transparent Proxy turned on at a minimum.
Then some ipfwadm stuff:
# Accept all on loopback
ipfwadm -I -a accept -W lo
# Accept my own IP, to prevent loops (repeat for each interface/alias)
ipfwadm -I -a accept -P tcp -D 208.206.76.44 80
# Send all traffic destined to port 80 to Squid on port 3128
ipfwadm -I -a accept -P tcp -D 0/0 80 -r 3128
it accepts packets on port 80 (redirected from the Cisco), and redirects them to 3128 which is the port my squid process is sitting on. I put all this in /etc/rc.d/rc.local
I am using v1.1.20 of Squid with Henrik's patch installed. You will want to install this patch if using a setup similar to mine.
I think almost everyone who have tried to build a transparent proxy setup have been bitten by this one.
Measures you can take:
by Duane Wessels
I set out yesterday to make transparent caching work with Squid and FreeBSD. It was, uh, fun.
It was relatively easy to configure a cisco to divert port 80 packets to my FreeBSD box. Configuration goes something like this:
access-list 110 deny tcp host 10.0.3.22 any eq www access-list 110 permit tcp any any eq www route-map proxy-redirect permit 10 match ip address 110 set ip next-hop 10.0.3.22 int eth2/0 ip policy route-map proxy-redirectHere, 10.0.3.22 is the IP address of the FreeBSD cache machine.
Once I have packets going to the FreeBSD box, I need to get the kernel to deliver them to Squid. I started on FreeBSD-2.2.7, and then downloaded IPFilter. This was a dead end for me. The IPFilter distribution includes patches to the FreeBSD kernel sources, but many of these had conflicts. Then I noticed that the IPFilter page says ``It comes as a part of [FreeBSD-2.2 and later].'' Fair enough. Unfortunately, you can't hijack connections with the FreeBSD-2.2.X IPFIREWALL code (ipfw), and you can't (or at least I couldn't) do it with natd either.
FreeBSD-3.0 has much better support for connection hijacking, so I suggest you start with that. You need to build a kernel with the following options:
options IPFIREWALL
options IPFIREWALL_FORWARD
Next, its time to configure the IP firewall rules with ipfw. By default, there are no "allow" rules and all packets are denied. I added these commands to /etc/rc.local just to be able to use the machine on my network:
ipfw add 60000 allow tcp from any to any
ipfw add 60001 allow icmp from any to any
But we're still not hijacking connections. To accomplish that,
add these rules:
ipfw add 49 allow tcp from 10.0.3.22 to any
ipfw add 50 fwd 127.0.0.1 tcp from any to any 80
The second line (rule 50) is the one which hijacks the connection.
The first line makes sure we never hit rule 50 for traffic originated
by the local machine. This prevents forwarding loops.
Note that I am not changing the port number here. That is, port 80 packets are simply diverted to Squid on port 80. My Squid configuration is:
http_port 80
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
by Martin Lyons
The following shows important kernel features to include:
[*] Network firewalls
[ ] Socket Filtering
[*] Unix domain sockets
[*] TCP/IP networking
[ ] IP: multicasting
[ ] IP: advanced router
[ ] IP: kernel level autoconfiguration
[*] IP: firewalling
[ ] IP: firewall packet netlink device
[*] IP: always defragment (required for masquerading)
[*] IP: transparent proxy support
You must include the IP: always defragment, otherwise it prevents you from using the REDIRECT chain.
The following script is used to configure ipchains:
#Accept all on loopback
/sbin/ipchains -A input -j ACCEPT -i lo
#Accept my own IP, to prevent loops (repeat for each interface/alias)
/sbin/ipchains -A input -j ACCEPT -p tcp -d 10.0.3.22 80
#Send all traffic destined to port 80 to Squid on port 80
/sbin/ipchains -A input -j REDIRECT 80 -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 80
Also, Andrew Shipton notes that with 2.0.x kernels you don't need to enable packet forwarding, but with the 2.1.x and 2.2.x kernels using ipchains you do. Packet forwarding is enabled with the following command:
echo 1 > /proc/sys/net/ipv4/ip_forward
This is to do with configuring transparent proxy for an ACC Tigris digital access server (like a CISCO 5200/5300 or an Ascend MAX 4000). I've found that doing this in the NAS reduces traffic on the LAN and reduces processing load on the CISCO. The Tigris has ample CPU for filtering.
Step 1 is to create filters that allow local traffic to pass. Add as many as needed for all of your address ranges.
ADD PROFILE IP FILTER ENTRY local1 INPUT 10.0.3.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL
ADD PROFILE IP FILTER ENTRY local2 INPUT 10.0.4.0 255.255.255.0 0.0.0.0 0.0.0.0 NORMAL
Step 2 is to create a filter to trap port 80 traffic.
ADD PROFILE IP FILTER ENTRY http INPUT 0.0.0.0 0.0.0.0 0.0.0.0 0.0.0.0 = 0x6 D= 80 NORMAL
Step 3 is to set the "APPLICATION_ID" on port 80 traffic to 80. This causes all packets matching this filter to have ID 80 instead of the default ID of 0.
SET PROFILE IP FILTER APPLICATION_ID http 80
Step 4 is to create a special route that is used for packets with "APPLICATION_ID" set to 80. The routing engine uses the ID to select which routes to use.
ADD IP ROUTE ENTRY 0.0.0.0 0.0.0.0 PROXY-IP 1
SET IP ROUTE APPLICATION_ID 0.0.0.0 0.0.0.0 PROXY-IP 80
Step 5 is to bind everything to a filter ID called transproxy. List all local filters first and the http one last.
ADD PROFILE ENTRY transproxy local1 local2 http
With this in place use your RADIUS server to send back the ``Framed-Filter-Id = transproxy'' key/value pair to the NAS.
You can check if the filter is being assigned to logins with the following command:
display profile port table
Fyodor has tracked down the cause of unusual ``connection reset by peer'' messages when using Cisco policy routing to hijack HTTP requests.
When the network link between router and the cache goes down for just a moment, the packets that are supposed to be redirected are instead sent out the default route. If this happens, a TCP ACK from the client host may be sent to the origin server, instead of being diverted to the cache. The origin server, upon receiving an unexpected ACK packet, sends a TCP RESET back to the client, which aborts the client's request.
To work around this problem, you can install a static route to the null0 interface for the cache address with a higher metric (lower precedence), such as 250. Then, when the link goes down, packets from the client just get dropped instead of sent out the default route. For example, if 1.2.3.4 is the IP address of your Squid cache, you may add:
ip route 1.2.3.4 255.255.255.255 Null0 250
This appears to cause the correct behaviour.