From owner-freebsd-net@FreeBSD.ORG Tue Jul 26 11:52:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD24D106564A for ; Tue, 26 Jul 2011 11:52:19 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by mx1.freebsd.org (Postfix) with ESMTP id 6D4F48FC1F for ; Tue, 26 Jul 2011 11:52:19 +0000 (UTC) Received: from [173.30.51.17] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 21892118; Tue, 26 Jul 2011 06:52:18 -0500 Message-ID: <4E2EAA70.2020708@visi.com> Date: Tue, 26 Jul 2011 06:52:16 -0500 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Chuck Swiger References: <4E159C5A.5090702@visi.com> <13D65A4C-F874-4970-A070-AA0392416680@mac.com> <4E1C9FEA.2080608@visi.com> <5458975C-9FA3-4AB6-9535-3D7BD152378B@mac.com> In-Reply-To: <5458975C-9FA3-4AB6-9535-3D7BD152378B@mac.com> X-Is-From-Me: yes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Debugging dropped shell connections over a VPN 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: Tue, 26 Jul 2011 11:52:19 -0000 Once again, apologies for my sluggish response. The VPN problem is a background job worked on when I can or when I'm too annoyed by it to do anything else. On 07/12/11 17:42, Chuck Swiger wrote: > On Jul 12, 2011, at 12:26 PM, Paul Keusemann wrote: >> So, any other ideas on how to debug this? > Gather data with tcpdump. If you do it on one of the VPN endpoints, you ought to see the VPN contents rather than just packets going by in the encrypted tunnel. > I assume by endpoint, you are talking about the target of the remote shell. Unfortunately, running tcpdump on the endpoint shows only the initial negotiation (and any interactive keyboard traffic) but nothing to indicate the connection has been dropped or timed out. If I can get some time when I don't actually need to use the VPN for work, I'm going to try to run tcpdump on the tunnel to see if there's anything going across it that might shed some light on the cause of the dropped connections. >> Anybody know how to get racoon to log everything to one file? Right now, depending on the log level, I am getting messages in racoon.log (specified with -l at startup), messages and debug.log. It would really be nice to have just one log to look at. > This is likely governed by /etc/syslog.conf, but if you specify -l then racoon shouldn't use syslog logging. My syslog.conf foo is not good but it seems that some stuff from racoon always ends up in the messages file, even when the -l option to racoon is specified. Thanks again for the tips. -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378