Hello, I am having trouble finding rules to redirect traffic to a squid transparent proxy running using shorewall. Here are the details: Shorewall 4.0.6 on Ubuntu 8.04 single interface squid 2.6 running in transparent mode on port 3128 on FW I have a Cisco Cat 6500 MSFC which redirects all port 80 traffic from a subnet (10.3.5.0/24) to the squid box using WCCP2. Here is a tcpdump of the traffic: 17:06:01.519659 IP 10.3.5.23.4011 > 74.125.155.104.80: S 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> 17:06:01.519905 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 3903948434 win 0 17:06:04.536350 IP 10.3.5.23.4011 > 74.125.155.104.80: S 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> 17:06:04.536408 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 1 win 0 I have tried using the rules shown in the Shorewall docs for squid trans proxy, but it does not work - squid does not see the traffic. Squid does work fine when used as manual proxy from same test client. I have tried: ACCEPT $FW net tcp www REDIRECT net 3128 tcp 80 - The squid/shorewall box has a single NIC only; it is NOT the gateway. The gateway to the net is on the same subnet as the squid/shorewall box. The client box is 10.3.5.23, and the squid/shorewall box is 72.2.0.4. Attached is a shorewall dump. Thanks. Shawn Wright I.T. Manager, Shawnigan Lake School http://www.shawnigan.ca ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
A bit more detail on this one, as I''m not sure my description is clear. Manually setting the client (10.3.5.23) to use proxy on (72.2.0.4:80) does work, so iptables is redirecting packets destined for the FW:80 to FW:3128. I need to intercept *all* packets destined for port 80 (except those with dest=local networks) and redirect to port 3128 on the firewall. I''ve also tried this with no luck: DNAT net:10.0.0.0/8 net:72.2.0.4:3128 tcp 80 Shawn Wright I.T. Manager, Shawnigan Lake School http://www.shawnigan.ca ----- "Shawn Wright" <swright@shawnigan.ca> wrote: Hello, I am having trouble finding rules to redirect traffic to a squid transparent proxy running using shorewall. Here are the details: Shorewall 4.0.6 on Ubuntu 8.04 single interface squid 2.6 running in transparent mode on port 3128 on FW I have a Cisco Cat 6500 MSFC which redirects all port 80 traffic from a subnet (10.3.5.0/24) to the squid box using WCCP2. Here is a tcpdump of the traffic: 17:06:01.519659 IP 10.3.5.23.4011 > 74.125.155.104.80: S 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> 17:06:01.519905 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 3903948434 win 0 17:06:04.536350 IP 10.3.5.23.4011 > 74.125.155.104.80: S 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> 17:06:04.536408 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 1 win 0 I have tried using the rules shown in the Shorewall docs for squid trans proxy, but it does not work - squid does not see the traffic. Squid does work fine when used as manual proxy from same test client. I have tried: ACCEPT $FW net tcp www REDIRECT net 3128 tcp 80 - The squid/shorewall box has a single NIC only; it is NOT the gateway. The gateway to the net is on the same subnet as the squid/shorewall box. The client box is 10.3.5.23, and the squid/shorewall box is 72.2.0.4. Attached is a shorewall dump. Thanks. Shawn Wright I.T. Manager, Shawnigan Lake School http://www.shawnigan.ca ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/24/10 3:26 PM, Shawn Wright wrote:> Hello, > > I am having trouble finding rules to redirect traffic to a squid > transparent proxy running using shorewall. Here are the details: > > Shorewall 4.0.6 on Ubuntu 8.04 > single interface > squid 2.6 running in transparent mode on port 3128 on FW > > I have a Cisco Cat 6500 MSFC which redirects all port 80 traffic from a > subnet (10.3.5.0/24) to the squid box using WCCP2. Here is a tcpdump of > the traffic:Sorry -- don''t know what WCCPv2 is and really don''t have the time or interest to read the Cisco docs and/or RFCs. What does it do (at the IP and link layers)? Also, I see that http://wiki.squid-cache.org/Features/Wccp2 seems to have quite a bit of information about configuring Squid to support this feature.> > 17:06:01.519659 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:01.519905 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack > 3903948434 win 0 > 17:06:04.536350 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:04.536408 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 1 win 0Sigh -- tcpdump output and no clue about which system the output was captured on. Client? Shorewall box? ??? Note that the connection requests are being rejected, wherever this was captured...> > I have tried using the rules shown in the Shorewall docs for squid trans > proxy, but it does not work - squid does not see the traffic. Squid does > work fine when used as manual proxy from same test client. > > I have tried: > > ACCEPT $FW net tcp www > REDIRECT net 3128 tcp 80 -The dump that you supplied shows that traffic is matching this rule.> > The squid/shorewall box has a single NIC only; it is NOT the gateway. > The gateway to the net is on the same subnet as the squid/shorewall box. > > The client box is 10.3.5.23, and the squid/shorewall box is 72.2.0.4. > Attached is a shorewall dump.Also, I see this in the conntrack table: tcp 6 56 SYN_RECV src=10.3.5.23 dst=74.125.155.105 sport=4039 dport=80 packets=1 bytes=48 src=72.2.0.4 dst=10.3.5.23 sport=3128 dport=4039 packets=5 bytes=240 mark=0 secmark=0 use=1 So the SYN from the client seems to be redirected to port 3128 as you expect. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
----- "Tom Eastep" <teastep@shorewall.net> wrote:> I have a Cisco Cat 6500 MSFC which redirects all port 80 traffic from a > subnet (10.3.5.0/24) to the squid box using WCCP2. Here is a tcpdump of > the traffic:Sorry -- don''t know what WCCPv2 is and really don''t have the time or interest to read the Cisco docs and/or RFCs. What does it do (at the IP and link layers)? In my case, it does this: WCCP L2 redirect rewrites packet MAC address to that of the local Engine (squid/shorewall box) Also, I see that http://wiki.squid-cache.org/Features/Wccp2 seems to have quite a bit of information about configuring Squid to support this feature. I am fairly certain squid is configured correctly, as it passes the test of using the proxy directly, which means traffic directed at the FW on port 80 is redirected to port 3128. The problem is catching traffic meant for other hosts on port 80 (regular www traffic) which arrives at the shorewall box by means of the L2 redirect of WCCP2.> > 17:06:01.519659 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:01.519905 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack > 3903948434 win 0 > 17:06:04.536350 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:04.536408 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 1 win 0Sigh -- tcpdump output and no clue about which system the output was captured on. Client? Shorewall box? ??? Note that the connection requests are being rejected, wherever this was captured... Sorry, this was done on the squid/shorewall box.> > I have tried using the rules shown in the Shorewall docs for squid trans > proxy, but it does not work - squid does not see the traffic. Squid does > work fine when used as manual proxy from same test client. > > I have tried: > > ACCEPT $FW net tcp www > REDIRECT net 3128 tcp 80 -The dump that you supplied shows that traffic is matching this rule. It is possible this traffic is not from the test client, as their are other clients on the subnet that may generate regular proxy requests. I will move to an isolated subnet for a better test.> > The squid/shorewall box has a single NIC only; it is NOT the gateway. > The gateway to the net is on the same subnet as the squid/shorewall box. > > The client box is 10.3.5.23, and the squid/shorewall box is 72.2.0.4. > Attached is a shorewall dump.Also, I see this in the conntrack table: tcp 6 56 SYN_RECV src=10.3.5.23 dst=74.125.155.105 sport=4039 dport=80 packets=1 bytes=48 src=72.2.0.4 dst=10.3.5.23 sport=3128 dport=4039 packets=5 bytes=240 mark=0 secmark=0 use=1 So the SYN from the client seems to be redirected to port 3128 as you expect. That''s odd. I see no evidence of requests in the squid log, so this needs more investigation. Thanks for the reply. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
----- "Tom Eastep" <teastep@shorewall.net> wrote:> 17:06:01.519659 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:01.519905 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack > 3903948434 win 0 > 17:06:04.536350 IP 10.3.5.23.4011 > 74.125.155.104.80: S > 3903948433:3903948433(0) win 65535 <mss 1460,nop,nop,sackOK> > 17:06:04.536408 IP 74.125.155.104.80 > 10.3.5.23.4011: R 0:0(0) ack 1 win 0Sigh -- tcpdump output and no clue about which system the output was captured on. Client? Shorewall box? ??? Note that the connection requests are being rejected, wherever this was captured... The dump is from the squid/shorewall box. If I''m reading this correctly, the rejection is from the remote host back to the client, which indicates the proxy redirect is not taking place. The remote host should have no knowledge of the client IP; it should see only the proxy IP (72.2.0.4) So what shorewall config do I need to redirect ALL packets with a DST port=80 and a SRC=10.0.0.0/8 received on an interface? ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/25/10 10:54 AM, Shawn Wright wrote:> > The dump is from the squid/shorewall box. If I''m reading this > correctly, the rejection is from the remote host back to the client, > which indicates the proxy redirect is not taking place. The remote > host should have no knowledge of the client IP; it should see only > the proxy IP (72.2.0.4)The Shorewall/squid box is returning the RST. It simply reverses the SRC and DST. If it used it''s own IP address, the client wouldn''t have a clue what it meant since it sent no SYN packet to 72.2.0.4.> > So what shorewall config do I need to redirect ALL packets with a > DST port=80 and a SRC=10.0.0.0/8 received on an interface? >You already have that and more with your REDIRECT rule but that exact entry would be: REDIRECT net:10.0.0.0/8 3128 tcp 80 -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/25/10 11:14 AM, Tom Eastep wrote:> On 8/25/10 10:54 AM, Shawn Wright wrote: > >> >> The dump is from the squid/shorewall box. If I''m reading this >> correctly, the rejection is from the remote host back to the client, >> which indicates the proxy redirect is not taking place. The remote >> host should have no knowledge of the client IP; it should see only >> the proxy IP (72.2.0.4) > > The Shorewall/squid box is returning the RST. It simply reverses the SRC > and DST. If it used it''s own IP address, the client wouldn''t have a clue > what it meant since it sent no SYN packet to 72.2.0.4. > >> >> So what shorewall config do I need to redirect ALL packets with a >> DST port=80 and a SRC=10.0.0.0/8 received on an interface? >> > > You already have that and more with your REDIRECT rule but that exact > entry would be: > > REDIRECT net:10.0.0.0/8 3128 tcp 80 >And by the way, the fact that it works when you configure it as a manual proxy does not mean that Squid is correctly configured for Transparent proxy. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
----- "Tom Eastep" <teastep@shorewall.net> wrote: On 8/25/10 11:14 AM, Tom Eastep wrote:> On 8/25/10 10:54 AM, Shawn Wright wrote: > >> >> The dump is from the squid/shorewall box. If I''m reading this >> correctly, the rejection is from the remote host back to the client, >> which indicates the proxy redirect is not taking place. The remote >> host should have no knowledge of the client IP; it should see only >> the proxy IP (72.2.0.4) > > The Shorewall/squid box is returning the RST. It simply reverses the SRC > and DST. If it used it''s own IP address, the client wouldn''t have a clue > what it meant since it sent no SYN packet to 72.2.0.4. > >> >> So what shorewall config do I need to redirect ALL packets with a >> DST port=80 and a SRC=10.0.0.0/8 received on an interface? >> > > You already have that and more with your REDIRECT rule but that exact > entry would be: > > REDIRECT net:10.0.0.0/8 3128 tcp 80 >And by the way, the fact that it works when you configure it as a manual proxy does not mean that Squid is correctly configured for Transparent proxy. Yes, but it confirms the proxy can access external sites. I think the only way I can confirm transparent proxy without iptables is to place the squid box into a router role for the client. I could do this, but the ultimate goal is to use WCCP2, so I do need to get iptables/shorewall working. I don''t wish to place the proxy load on our firewall, as there are 600 users on a 1Gb pipe, so the traffic is significant. Squid is returning this: "Accepting transparently proxied HTTP connections at 0.0.0.0, port 3128, FD 16." , so it appears to be set correctly. There are no hits in the squid access log for the transparent client. tcpdump on the shorewall/squid box now shows this, and I am not quite sure why I don''t see the rejections, but the packets still don''t reach squid on port 3128. I am clearly missing some critical piece, but I don''t know where to look. 11:57:46.823061 IP 10.3.5.23.2374 > 136.1.241.33.80: S 1396530295:1396530295(0) win 65535 <mss 1460,nop,nop,sackOK> 11:57:46.823117 IP 136.1.241.33.80 > 10.3.5.23.2374: S 146074113:146074113(0) ack 1396530296 win 5840 <mss 1460,nop,nop,sackOK> Thanks for any guidance you can offer. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/25/10 12:18 PM, Shawn Wright wrote:> > Yes, but it confirms the proxy can access external sites. I think the > only way I can confirm transparent proxy without iptables is to place > the squid box into a router role for the client. I could do this, but > the ultimate goal is to use WCCP2, so I do need to get > iptables/shorewall working.I frankly don''t believe that iptables/Shorewall has a anything to do with your problem.> I don''t wish to place the proxy load on our > firewall, as there are 600 users on a 1Gb pipe, so the traffic is > significant. > > Squid is returning this: "Accepting transparently proxied HTTP > connections at 0.0.0.0, port 3128, FD 16." , so it appears to be set > correctly. There are no hits in the squid access log for the transparent > client. > > tcpdump on the shorewall/squid box now shows this, and I am not quite > sure why I don''t see the rejections, but the packets still don''t reach > squid on port 3128. I am clearly missing some critical piece, but I > don''t know where to look. > > 11:57:46.823061 IP 10.3.5.23.2374 > 136.1.241.33.80: S > 1396530295:1396530295(0) win 65535 <mss 1460,nop,nop,sackOK> > 11:57:46.823117 IP 136.1.241.33.80 > 10.3.5.23.2374: S > 146074113:146074113(0) ack 1396530296 win 5840 <mss 1460,nop,nop,sackOK> >Squid is accepting the connection. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/25/10 1:00 PM, Tom Eastep wrote:> On 8/25/10 12:18 PM, Shawn Wright wrote: > >> >> Yes, but it confirms the proxy can access external sites. I think the >> only way I can confirm transparent proxy without iptables is to place >> the squid box into a router role for the client. I could do this, but >> the ultimate goal is to use WCCP2, so I do need to get >> iptables/shorewall working. > > I frankly don''t believe that iptables/Shorewall has a anything to do > with your problem. > >> I don''t wish to place the proxy load on our >> firewall, as there are 600 users on a 1Gb pipe, so the traffic is >> significant. >> >> Squid is returning this: "Accepting transparently proxied HTTP >> connections at 0.0.0.0, port 3128, FD 16." , so it appears to be set >> correctly. There are no hits in the squid access log for the transparent >> client. >> >> tcpdump on the shorewall/squid box now shows this, and I am not quite >> sure why I don''t see the rejections, but the packets still don''t reach >> squid on port 3128. I am clearly missing some critical piece, but I >> don''t know where to look. >> >> 11:57:46.823061 IP 10.3.5.23.2374 > 136.1.241.33.80: S >> 1396530295:1396530295(0) win 65535 <mss 1460,nop,nop,sackOK> >> 11:57:46.823117 IP 136.1.241.33.80 > 10.3.5.23.2374: S >> 146074113:146074113(0) ack 1396530296 win 5840 <mss 1460,nop,nop,sackOK> >> > > Squid is accepting the connection.I should say, rather, that the connection is being accepted. Because of listener backlog (second argument to listen(2)), a TCP connection can be acknowledged without the server actually calling accept(). The fact that we don''t see an ACK back from the client might indicate that it is not receiving (or doesn''t like) the SYN,ACK response. This is supported by the conntrack entry I pointed out to you last evening. Have you run tcpdump (or wireshark) on the client system? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
----- "Tom Eastep" <teastep@shorewall.net> wrote:> Squid is accepting the connection.I should say, rather, that the connection is being accepted. Because of listener backlog (second argument to listen(2)), a TCP connection can be acknowledged without the server actually calling accept(). The fact that we don''t see an ACK back from the client might indicate that it is not receiving (or doesn''t like) the SYN,ACK response. This is supported by the conntrack entry I pointed out to you last evening. Have you run tcpdump (or wireshark) on the client system? ==The client is not receiving the SYN,ACK response. A tcpdump on the client shows only the outgoing SYN and nothing else. So it appears the packets are being dropped on the shorewall box. What methods can I employ to trace these packets and determine where they are being dropped? Alternately, is there an "allow all" switch I can enable to get it working, then trace back what is required to make this work? (bearing in mind that I still need the REDIRECT from 80-3128 for all traffic). Thanks. Shawn Wright I.T. Manager, Shawnigan Lake School http://www.shawnigan.ca ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/26/10 9:33 AM, Shawn Wright wrote:> > > ----- "Tom Eastep" <teastep@shorewall.net> wrote: > > >> Squid is accepting the connection. > > I should say, rather, that the connection is being accepted. Because > of listener backlog (second argument to listen(2)), a TCP connection > can be acknowledged without the server actually calling accept(). > > The fact that we don''t see an ACK back from the client might indicate > that it is not receiving (or doesn''t like) the SYN,ACK response. > This is supported by the conntrack entry I pointed out to you last > evening. Have you run tcpdump (or wireshark) on the client system? > > === The client is not receiving the SYN,ACK response. A tcpdump on > the client shows only the outgoing SYN and nothing else. So it > appears the packets are being dropped on the shorewall box.Then how in $DEITY''s name is tcpdump seeing them leaving the Shorewall box?> What methods can I employ to trace these packets and determine where they > are being dropped? Alternately, is there an "allow all" switch I can > enable to get it working, then trace back what is required to make > this work? (bearing in mind that I still need the REDIRECT from > 80-3128 for all traffic).Let''s put the Shorewall configuration issue to bed once in for all: - shorewall clear - iptables -t nat -A PREROUTING -p 6 --dport 80 -j REDIRECT --to-port 3128 Now test -- does it work? If not, I would next use the -e options (e.g., tcpdump -nei eth0 ...) on the Shorewall-less box to see what the link layer destination address of the SYN,ACK is. Does it match that of the client? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
----- "Tom Eastep" <teastep@shorewall.net> wrote:> Then how in $DEITY''s name is tcpdump seeing them leaving the Shorewall > box? > > > What methods can I employ to trace these packets and determine where > they > > are being dropped? Alternately, is there an "allow all" switch I > can > > enable to get it working, then trace back what is required to make > > this work? (bearing in mind that I still need the REDIRECT from > > 80-3128 for all traffic). > > Let''s put the Shorewall configuration issue to bed once in for all: > > - shorewall clear > - iptables -t nat -A PREROUTING -p 6 --dport 80 -j REDIRECT --to-port > 3128 > > Now test -- does it work?Nope.> If not, I would next use the -e options (e.g., tcpdump -nei eth0 ...) > on > the Shorewall-less box to see what the link layer destination address > of > the SYN,ACK is. Does it match that of the client?Thank you. This was the info I needed to track it down. The DST address indicated a routing problem. Once I fixed this, it works. I did actually look at this output last night, but missed the incorrect DST MAC. ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/26/10 11:34 AM, Shawn Wright wrote:> Thank you. This was the info I needed to track it down. The DST > address indicated a routing problem. Once I fixed this, it works. I > did actually look at this output last night, but missed the incorrect > DST MAC.Glad to hear that is is resolved, Shawn -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d