more transparent proxy problems (long)

Sun Oct 3 12:34:01 PDT 2004

Thanks for the reply, David. But as my e-mail from yesterday states (which I 
guess you haven't gotten to yet. The problem was the normal firewall rules on 
the FC2 box (not the -t nat rules), which blocked everything coming in that 
wasn't explicitly enabled. Port 53 was not explicitly allowed in, hence DNS 
would not work. 

I've added some more repies below, if you;re curoius as to what my answers 
would be...

Regards, 
Tim

On Sunday 03 October 2004 10:57 am, someone claiming to be David Bandel wrote:
> On Fri, 1 Oct 2004 12:06:51 -0400, Tim Wunder <tim at thewunders.org> wrote:
> > I'm still fighting with this transparent proxy problem, and I must be
> > missing something obvious, so I'll start at the beginning and descibe my
> > network and what I'm trying to do...
> >
> > I have a linksys cable router that is currently used as a firewall/nat
> > box. Its internal facing IP address is 192.168.1.254, It only allows
> > traffic from 192.168.1.2 to go to the internet. It also forwards ports
> > 21,22,25,80,443,995 and 8000 to 192.168.1.2 for ssh, smtp, http, https,
> > pop3s, and gnump3d.
> >
> > 192.168.1.2 belongs to an FC2 box that serves webpages, e-mail, music
> > streaming and is our main desktop PC for the four people in the house.
> > traffic for GID's belonging to my two sons gets forwarded through
> > dansguardian/squidGuard and squid transparently.
>
> Unless your sons are on the FC2 box (which it sounds like they're
> not), then your GID rules are a no-go.  The only way the FC2 box can
> know that a process (and it? GID) belong to your sons is if that
> process is running on that box.  It knows nothing of the owner of a
> process on another box.
>

One gets access from the only the FC2 box, the other can access both from his 
laptop and from the FC2 box.

<snip>
> >
> > My wireless access point has a configuration ID of 192.168.1.251 and I
> > can access it from anywhere on the network. It is also hardwired to the
> > cable router.
>
> You have a mess.
>
> An access point is a bridge.  It doesn't even need an IP except for
> management purposes.  Think of an AP like a switch that talks both
> wired and wireless.
>

Understood. I configure it from the aforementioned IP, and it works fine. Just 
wanted to be clear about what I have connected. I don't think I actually HAVE 
a mess, but I'll agree that my *mind* was a mess...

> > I can ping the DNS server, 68.34.76.5, from my R40, and from the WinXP
> > laptop, and can see the traffic coming thru eth1 on the server/proxy via
> > tcpdump.
> >
> > If I try to connect to a web page from my R40 laptop, this is what I see
> > via tcpdump -i eth1:
> > # tcpdump -i eth1 -n
> > tcpdump: verbose output suppressed, use -v or -vv for full protocol
> > decode listening on eth1, link-type EN10MB (Ethernet), capture size 96
> > bytes 11:19:10.768253 IP 10.0.0.109.32790 > 68.34.76.5.domain:  27115+
> > AAAA? www.gnu.org. (29)
> > 11:19:10.768623 IP 10.0.0.1 > 10.0.0.109: icmp 65: host 68.34.76.5
> > unreachable - admin prohibited
>
> well, is your 10.0.0.1 box nat'ing?  sounds like not (that or your
> Linksys is not accepting port 80 from 192.168.2.1).
>

Yes, it was nat'ing fine, as evidenced from doing a tcpdump on eht0 and eth1, 
and pinging IP addresses and not domain names.

> > 11:19:10.770495 IP 10.0.0.109.32790 > 68.34.76.6.domain:  27115+ AAAA?
> > www.gnu.org. (29)
> > 11:19:10.770620 IP 10.0.0.1 > 10.0.0.109: icmp 65: host 68.34.76.6
> > unreachable - admin prohibited
> > 11:19:10.772592 IP 10.0.0.109.32790 > 68.34.76.5.domain:  27115+ AAAA?
> > www.gnu.org. (29)
> > 11:19:10.772702 IP 10.0.0.1 > 10.0.0.109: icmp 65: host 68.34.76.5
> > unreachable - admin prohibited
> > 11:19:10.774522 IP 10.0.0.109.32790 > 68.34.76.6.domain:  27115+ AAAA?
> > www.gnu.org. (29)
> > 11:19:10.774632 IP 10.0.0.1 > 10.0.0.109: icmp 65: host 68.34.76.6
> > unreachable - admin prohibited
> > 11:19:10.776490 IP 10.0.0.109.32790 > 68.34.76.5.domain:  27116+ AAAA?
> > www.gnu.org.localdomain. (41)
> > 11:19:10.776600 IP 10.0.0.1 > 10.0.0.109: icmp 77: host 68.34.76.5
> > unreachable - admin prohibited
> >
> > And there is no traffic going trough eth0 seen by tcpdump -i eth0 -n
>
> eth0 on what system?  If it's the same system, is forwarding turned on?
>

The FC2 box and yes, forwarding is (was) turned on.

> > I've enabled ip forwarding:
> > # cat  /proc/sys/net/ipv4/ip_forward
> > 1
> >
> > And I also have these firewall rules:
> > # iptables -t nat -L
> > Chain PREROUTING (policy ACCEPT)
> > target     prot opt source               destination
> >
> > Chain POSTROUTING (policy ACCEPT)
> > target     prot opt source               destination
> > SNAT       all  --  10.0.0.0/24          anywhere           
> > to:192.168.1.2
> >
> > When I ping 68.34.76.5 from the laptop, I see this traffic on eth0 via
> > tcpdump:
> > 11:24:07.658365 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 1
> > 11:24:07.668527 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 1
> > 11:24:08.659175 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 2
> > 11:24:08.670433 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 2
> > 11:24:09.660027 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 3
> > 11:24:09.670130 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 3
> > 11:24:10.660886 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 4
> > 11:24:10.671438 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 4
> > 11:24:11.661732 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 5
> > 11:24:11.673050 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 5
> > 11:24:12.662602 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 6
> > 11:24:12.671956 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 6
> > 11:24:13.663443 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 7
> > 11:24:13.673915 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 7
> > 11:24:14.664311 IP 192.168.1.2 > 68.34.76.5: icmp 64: echo request seq 8
> > 11:24:14.675373 IP 68.34.76.5 > 192.168.1.2: icmp 64: echo reply seq 8
> >
> > So it looks like the SNAT rule is working for ping...
>
> try running a traceroute (using the ICMP option, -I), then a normal
> traceroute (which uses UDP).
> report results
> then run tcptraceroute
> report results
>
> > What am I missing?
>
> the above should tell me, but I believe it's your rules (and the GID
> part only works if the process is local, not over a network).
>
> > Could it be that DNS is blocked somehow? Maybe I'll try to set up bind to
> > handle DNS locally and see if that works...
>
> I don't think so.
>

Yep. firewall rules was the problem, but not the -t nat rules. 

I've now learned more than I care to learn about iptables, nat'ing, bind and 
my own foibles...

Thanks, again, for your help, it was greatly appreciated.

Tim

-- 
Fedora Core 2, Kernel 2.6.7-1.494.2.2,  KDE 3.3.0, Xorg 6.7.0
 13:50:00 up 3 days, 16:32,  4 users,  load average: 0.27, 0.29, 0.14
It's what you learn after you know it all that counts