fastforward problem

[Brian Candler]

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.