Dear Amos, Thanks for your great hint of "tcpdump gets packets before any of the iptables etc handling gets done to them" and " We have to rely on ebtables/iptables LOG functionality for those bits" Now I start debugging iptables, using sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG --log-prefix "TEST: " from node-s (sender), we run [node-s (sender), 10.0.1.1, node-r, 10.0.2.1 (receiver), the squid3 machine is 10.0.3.1] wget 10.0.2.1:8080 while we still see "19:20:09.439059 IP nodes-links.40520 > noder-linkr.http-alt: Flags [S], seq 4014254024, win 5840, options [mss 1460,sackOK,TS val 68449700 ecr 0,nop,wscale 6]," in tcpdump, we see nothing in the iptables log in contrast, if we run 'wget 10.0.3.1:8080' (directly connect to 8080 port of squid3 machine, although there is no service) we see information in both tcpdump "19:26:51.347175 IP nodes-links.41022 > nodec1-tblink-l9.http-alt: Flags [S], seq 1779139991, win 5840, options [mss 1460,sackOK,TS val 68550176 ecr 0,nop,wscale 6], length 0 19:26:51.347287 IP nodec1-tblink-l9.http-alt > nodes-links.41022: Flags [R.], seq 0, ack 1779139992, win 0, length 0 " and iptables log " Mar 5 19:24:09 nodec1 kernel: [28094.303462] TEST: IN=eth0 OUT= MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1 DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0 Mar 5 19:24:09 nodec1 kernel: [28094.303495] TEST: IN=eth0 OUT= MAC=00:04:23:ae:cc:38:00:0e:0c:68:a8:58:08:00 SRC=10.0.1.1 DST=10.0.3.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=62692 DF PROTO=TCP SPT=41021 DPT=8080 WINDOW=5840 RES=0x00 SYN URGP=0 " Can we conclude the error was happened due to sudo iptables -t nat -A PREROUTING -p tcp --dport 8080 -j LOG --log-prefix "TEST: " cannot pick up the 8080 packet forwarded by the switch? Can some packet loss happen before this step? I am sorry I am not very familiar with the linux kernel/system...and bother you so much trouble... Thanks a lo! On Mon, Mar 5, 2012 at 5:57 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 06.03.2012 11:09, pplive wrote: >> >> Dear Amos, >> >> To see whether there were some internal firewall in my system , I >> tried a simpler topology, i.e., >> >> Client (10.0.0.1) (eth0) -> (eth0) Squid3 (eth1) -> (eth0) Server >> (10.0.0.2) >> >> I just follow the setting in >> >> >> http://freecode.com/articles/configuring-a-transparent-proxywebcache-in-a-bridge-using-squid-and-ebtables >> >> brctl addbr br0 >> brctl addif br0 eth0 >> brctl addif br0 eth1 >> >> ebtables -t broute -A BROUTING -p IPv4 --ip-protocol 6 >> --ip-destination-port 8080 -j redirect --redirect-target ACCEPT > > > "ACCEPT" on the layer-2 bridging is to handle the packet entirely at that > low layer. > > It needs to be "DROP"ed out of the bridging layer into to iptables layer > handling before NAT can change the IP/port and routing can shift it to INPUT > path where Squid gets it. > > > >> >> iptables -t nat -A PREROUTING -i br0 -p tcp --dport 8080 -j REDIRECT >> --to-port 3128 >> >> According to tcpdump, we can see the packets are forwarded to port 3128 >> (I use wget 10.0.0.2:8080 at the client) >> >> 14:04:50.282381 IP 10.0.0.1.33088 > 10.0.0.10.3128: Flags [S], seq >> 388132433, win 5840, options [mss 1460,sackOK,TS val 1028407 ecr >> 0,nop,wscale 6], length 0 >> 14:04:53.212426 IP 10.0.0.1.33088 > 10.0.0.10.3128: Flags [S], seq >> 388132433, win 5840, options [mss 1460,sackOK,TS val 1029157 ecr >> 0,nop,wscale 6], length 0 >> >> Still, I am confusing of using one NIC, how can I redirect the packets >> to port 3128. > > > NAT is a special system which can change packets on both bridging and > routing layers but does not itself make them change layer. > > So what the above trace shows is that packets arriving are NAT/NAPT changed > as they flow through the bridge. But not anything else. > > > tcpdump gets packets before any of the iptables etc handling gets done to > them. So its useful to verify that the packets are arriving and/or leaving > the NIC as expected. but not much help deciphering what is happening to them > in the middle around where Squid sits. > We have to rely on ebtables/iptables LOG functionality for those bits. > > > I'm sorry I can't be of much more help. Beyond suggesting to try later > versions of the software including kernel I've run out of ideas. > > Amos
