more transparent proxy problems (long)
David Bandel
david.bandel
Sun Oct 3 12:11:20 PDT 2004
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.
>
> The iptables setting that does this is:
> Chain OUTPUT (policy ACCEPT)
> target prot opt source destination
> REDIRECT tcp -- anywhere anywhere tcp dpt:http
> OWNER GID match john redir ports 3129
> REDIRECT tcp -- anywhere anywhere tcp dpt:http
> OWNER GID match tom redir ports 3129
> REDIRECT tcp -- anywhere anywhere tcp dpt:squid
> OWNER GID match john redir ports 3129
> REDIRECT tcp -- anywhere anywhere tcp dpt:squid
> OWNER GID match tom redir ports 3129
>
> I've installed a new ethernet card, with the IP address of 10.0.0.1 and it
> appears to be working fine:
> # route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
> 0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0 eth0
>
> I've enable dhcpd and have configured it to give out ip addresses between
> 10.0.0.100 and 10.0.0.110 and it also seems to be working just fine.
> # cat /etc/dhcpd.conf
> default-lease-time 86400;
> max-lease-time 86400;
> option subnet-mask 255.255.255.0;
> option broadcast-address 10.255.255.255;
> option routers 10.0.0.1;
> option domain-name-servers 68.34.76.5, 68.34.76.6;
> option domain-name "thewunders.org";
> ddns-update-style ad-hoc;
>
> subnet 10.0.0.0 netmask 255.255.255.0 {
> range 10.0.0.100 10.0.0.110;
> }
>
> I have an IBM R40 laptop running Fedora Core 2 with a wireless card that is
> configured to get its IP address via DHCP and it's gotten 10.0.0.109. My son
> has a Toshiba laptop running WinXP Home and it also gets its IP via DHCP and
> is assigned 10.0.0.110. It is hardwired to the linksys cable router.
>
> 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.
>
> 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).
> 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?
>
> 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.
>
> Thanks for listening...
>
> Tim
>
> --
> Fedora Core 2, Kernel 2.6.7-1.494.2.2, KDE 3.3.0, Xorg 6.7.0
> 10:30:00 up 1 day, 13:12, 3 users, load average: 0.14, 0.37, 0.32
> Against all odds, honey, we're the big door prize -- John Prine
> _______________________________________________
> Linux-users mailing list
> Linux-users at linux-sxs.org
> http://mail.linux-sxs.org/cgi-bin/mailman/listinfo/linux-users
>
David A. Bandel
--
Focus on the dream, not the competition.
- Nemesis Air Racing Team motto
More information about the Linux-users
mailing list