From owner-freebsd-net@FreeBSD.ORG Mon Feb 13 12:31:38 2006 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6989C16A420 for ; Mon, 13 Feb 2006 12:31:38 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof.pobox.com (proof.pobox.com [207.106.133.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96DAE43D5E for ; Mon, 13 Feb 2006 12:31:36 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A6DA5616F6; Mon, 13 Feb 2006 07:31:35 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 63C8916712; Mon, 13 Feb 2006 07:31:34 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F8crc-0006HU-St; Mon, 13 Feb 2006 12:31:33 +0000 Date: Mon, 13 Feb 2006 12:31:32 +0000 From: Brian Candler To: GiZmen Message-ID: <20060213123132.GA24126@uk.tiscali.com> References: <20060211163533.GA87353@blurp.pl> <20060212125124.GA20369@uk.tiscali.com> <20060212205344.GA40941@blurp.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060212205344.GA40941@blurp.pl> User-Agent: Mutt/1.4.2.1i Cc: net@freebsd.org Subject: Re: fastforward problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2006 12:31:38 -0000 On Sun, Feb 12, 2006 at 09:53:44PM +0100, GiZmen wrote: > Yes, clients can ping google IPs. > > ping 64.233.187.99 > PING 64.233.187.99 (64.233.187.99): 56 data bytes > 64 bytes from 64.233.187.99: icmp_seq=0 ttl=238 time=155.613 ms > 64 bytes from 64.233.187.99: icmp_seq=1 ttl=238 time=152.681 ms > > PING 72.14.207.99 (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=0 ttl=237 time=142.530 ms > 64 bytes from 72.14.207.99: icmp_seq=1 ttl=237 time=143.632 ms > 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=143.517 ms > > > (3) what happens when I open a TCP/IP connection to port 80, and manually > > fetch a HTTP page? > > When i try connect by telnet i have smth like this. > > telnet 64.233.167.99 80 > Trying 64.233.167.99... > Connected to 64.233.167.99. > Escape character is '^]'. > GET / HTTP/1.0 > Host: google.com > > > Connection closed by foreign host. > > There is nothing happening after pressing enter couple times the connection > is closing by foreigh host. Next: in another window, do # tcpdump -i fxp0 -n -s1500 -X (replace fxp0 with your external interface name). Then at the same time, have one of the clients do the same test (3). If you see too much tcpdump output, then try # tcpdump -i fxp0 -n -s1500 -X host 64.233.167.99 or icmp What you're looking for is the connection being closed, and what device is closing it (Google? Perhaps some upstream device?) I can only guess at a few causes. (1) Broken DNS. Your IP address maps to host.example.com but host.example.com does not map back to the same IP address. Since you've not said your client's IP address, I can't check this for you. I'd expect the server to drop the connection immediately in this case, but it's still worth checking. (2) Upstream from you is some sort of transparent HTTP proxy/cache, which is broken. To test this theory, try # telnet 1.1.1.1 80 Does this connect? Or does it time out after 75 seconds? If it connects, there's almost certainly a transparent cache upstream. (3) You have some sort of path MTU issue. I don't know why. Perhaps your upstream link is running PPPoE or something which is not clear for 1500-byte packets. If so, it ought to work, but bad filtering of ICMP or bad use of NAT can cause problems. Try to run a tcpdump as far up the upstream path as possible, to see what's going on. Brian.