Hi Amos, I do not have a "intercept" with http_port. Here is my config: maximum_object_size 10240 KB http_port 80 accel defaultsite=cona-server vhost cache_peer 192.168.122.11 parent 80 0 no-query originserver name=myAccel acl our_sites dstdomain cona-server http_access allow our_sites cache_peer_access myAccel allow our_sites cache_peer_access myAccel deny all acl manager proto cache_object acl localhost src 127.0.0.1/32 ::1 acl to_localhost dst 127.0.0.0/8 0.0.0.0/32 ::1 acl SSL_ports port 443 acl Safe_ports port 80 # http acl Safe_ports port 21 # ftp acl Safe_ports port 443 # https acl Safe_ports port 70 # gopher acl Safe_ports port 210 # wais acl Safe_ports port 1025-65535 # unregistered ports acl Safe_ports port 280 # http-mgmt acl Safe_ports port 488 # gss-http acl Safe_ports port 591 # filemaker acl Safe_ports port 777 # multiling http acl CONNECT method CONNECT http_access allow manager localhost http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports http_access allow localhost http_access deny all http_port 3128 coredump_dir /var/spool/squid3 refresh_pattern ^ftp: 1440 20% 10080 refresh_pattern ^gopher: 1440 0% 1440 refresh_pattern -i (/cgi-bin/|\?) 0 0% 0 refresh_pattern (Release|Packages(.gz)*)$ 0 20% 2880 refresh_pattern . I am still not sure why Squid needs the original source. Here is what I understand: given a topology like this, (Squid is in transparent mode) Client ------- Squid --------- Server there will be an iptable rule at Client to do a DNAT and change destination address to that of Squid. When Squid receives the packets, it can do its lookups and send the packets back to Client (it can get Client's address from the packets). If a lookup fails, it will get the server's address from config and get content from the server. So, I expected, if I have a OpenFlow flow to re-write IP addresses (and not use iptable rule) it will work in the same way. The controller cannot change NAT table at the Squid box. When the client tries to contact the server, the traffic is re-directed to Squid using a flow. At this point nothing happens at the client. Once the flow times out and is deleted, the client gets the content from the server. I am not sure why would Squid relay the request to itself and loop (though, that seems to be the case here!). Can you please explain? Thanks On Wed, Jul 25, 2012 at 11:19 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 26/07/2012 4:50 p.m., Abhishek Chanda wrote: >> >> Hi Amos, >> >> Thanks for the reply. >> My Squid is 3.1.19. I am trying to use OpenFlow to automate the >> deployment of Squid in my organization. When the OpenFlow controller >> sees a new HTTP packet, it modifies it's destination IP and port to >> that of Squid and sends it back. Thus, I expected I will not need >> iptable rules here. >> >> I am a bit confused about how Squid does DNAT. Can you point me to >> some document? > > > There is no document but the code. > > Squid accept()'s a TCP connection. If the http_port is marked with > "intercept" it then performs a call to getsockopt(SO_ORIGINAL_DST) asking > the kernel for the NAT table record of that connections original > destination. That is all Squid-3.1 does, later series 3.2 has extra security > that validates that the HTTP details match the TCP ones and ensures > destination it is actually delivered to was the clients intended > destination. > > Does OpenFlow controller update the Squid box kernel NAT tables so the above > can work? if not, how can Squid receive that original destination info? > > The behaviour you described in your first email hints that Squid is > receiving a connection which is addressed to itself on port 3128. Which > could very easily be relayed on to .. itself on port 3128... etc > > I'm not clear what you meant by "register a MISS or HIT". I assume you meant > "log a MISS or HIT"? logging is not done on a transaction until it has been > completed and all timing details are known. In the case where Squid forwards > to itself, the request might never finish looping... > > Amos
