From owner-freebsd-questions@FreeBSD.ORG Thu Aug 9 09:13:21 2007 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D899816A417 for ; Thu, 9 Aug 2007 09:13:21 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from smtp.teledomenet.gr (smtp.teledomenet.gr [213.142.128.2]) by mx1.freebsd.org (Postfix) with ESMTP id 57CE313C457 for ; Thu, 9 Aug 2007 09:13:21 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from iris (unknown [192.168.1.71]) by smtp.teledomenet.gr (Postfix) with ESMTP id 82B2F143E6F; Thu, 9 Aug 2007 12:13:20 +0300 (EEST) From: Nikos Vassiliadis To: freebsd-questions@freebsd.org Date: Thu, 9 Aug 2007 12:13:47 +0300 User-Agent: KMail/1.9.1 References: <200708091025.43912.bramschoenmakers@xs4all.nl> In-Reply-To: <200708091025.43912.bramschoenmakers@xs4all.nl> X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200708091213.47740.nvass@teledomenet.gr> Cc: Bram Schoenmakers Subject: Re: Problem with dump over SSH: Operation timed out X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2007 09:13:21 -0000 On Thursday 09 August 2007 11:25, Bram Schoenmakers wrote: > Dear list, > > There is a problem with performing a dump from our webserver at the data > centre to a backup machine at the office. Everytime we try to perform a > dump, the SSH tunnel dies: > > # /sbin/dump -0uan -L -h 0 -f - / | /usr/bin/bzip2 | /usr/bin/ssh > backup@office.example.com \ > dd of=/backup/webserver/root.0.bz2 > > DUMP: Date of this level 0 dump: Wed Aug 8 20:58:51 2007 > DUMP: Date of last level 0 dump: the epoch > DUMP: Dumping snapshot of /dev/da0s1a (/) to standard output > DUMP: mapping (Pass I) [regular files] > DUMP: mapping (Pass II) [directories] > DUMP: estimated 60746 tape blocks. > DUMP: dumping (Pass III) [directories] > DUMP: dumping (Pass IV) [regular files] > Read from remote host office.example.com: Operation timed out > DUMP: Broken pipe > DUMP: The ENTIRE dump is aborted. > > Here are some facts about the situation: > > * The client (where the dup takes place) runs FreeBSD 6.2-RELEASE-p4 > * The server (at the office) runs FreeBSD 6.1-RELEASE > * Both hosts have ipf installed > * Some IPF rules from the client: > > pass out quick on bge0 proto tcp from any to any flags S keep state > pass out quick on bge0 proto udp from any to any keep state > pass out quick on bge0 proto icmp from any to any keep state > pass out quick on bge0 proto gre from any to any keep state > pass out quick on bge0 proto esp from any to any keep state > pass out quick on bge0 proto ah from any to any keep state > > block out quick on bge0 all > pass in quick on bge0 proto tcp from any to any port = 22 flags S keep > state > > block return-rst in log quick on bge0 proto tcp from any to any > block in quick on bge0 proto tcp all flags S > block return-icmp-as-dest(port-unr) in log quick on bge0 proto udp from > any to any > block in log quick on bge0 all > > * Some IPF rules from the server: > > pass out quick on re0 proto tcp from any to any flags S keep state > pass out quick on re0 proto udp from any to any keep state > pass out quick on re0 proto icmp from any to any keep state > pass out quick on re0 proto gre from any to any keep state > pass out quick on re0 proto esp from any to any keep state > pass out quick on re0 proto ah from any to any keep state > > pass out quick on re0 proto tcp from any to any port = 22 keep state > > pass in quick on re0 proto tcp from any to any port = 22 flags S keep > state > > block return-rst in quick on re0 proto tcp all flags S > block in quick on re0 proto tcp all flags S > block return-icmp-as-dest(port-unr) in log quick on re0 proto udp from > any to any > block in log quick on re0 all > These rules deny incoming ICMP in general, Path MTU discovery will be broken. [snip] > * Maybe the MTU value was the cause, but setting them to 1472 on both > sides didn't improve the situation as well. Try using a much lower MTU, something like 1400 or perhaps lower, just for testing. You should configure this, on both client and server. I'm not familiar with ipf to give the exact rule, but I would allow ALL ICMP traffic, at least for testing purposes. I think this is correct: pass out quick proto icmp from any to any pass in quick proto icmp from any to any somewhere above the "block in log quick on re0 all" rule. Hope this helps a bit Nikos