Debugging dropped shell connections over a VPN

[Paul Keusemann]

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 at visi.com
4266 Joppa Court		                      (952) 894-7805
Savage, MN  55378