At this point it's probably best to do something like:
and watch, packet by packet, to confirm what's missing, and from which
end. For sniffing, I use Ethereal pretty much exclusively these days;
it's supported on many platforms, including MS Windows.
Elijah: you say that pings across the tunnel work. Can you confirm
that they *don't* work if you use the "-l NNNN" option to send larger
than normal ping packets?
Regarding the lack of log information on the endpoints: you should be
able to activate VPN debugging on the Cisco side at least. I haven't
played with that particular subset of the debugging functionality, but
for PPP, ISDN, etc., Cisco's detailed debugging messages have saved me
several times. Just remember to do "no debug all" when you're done,
or your logs will grow pretty quickly :-)
Silly question: have you tried these tests with traffic shaping on the
m0n0wall disabled? I took a quick look at your earlier messages and
didn't see an answer...
** For the less experienced people following this discussion: it's
important to use a true hub in the pictured configuration, not a
dual-speed hub unless you're sure all three devices are communicating
at the same speed, and definitely not a switch. Otherwise, the
sniffer PC won't see the traffic between the m0n0wall and the
On Wed, 2 Mar 2005 07:25:59 -0500, Elijah Savage
<esavage at digitalrage dot org> wrote:
> The tunnel from the monowall is not being built to a pix, I replace
> monowall on my end with a pix sorry for the confusion. The tunnels are
> being built from monowall to a bunch of different Cisco routers 2600,
> 3600, and 831's. I see nothing on either end in the logs. I know it does
> not seem like a MTU issue but I truly believe it is and I think it has
> something to do with ICMP being blocked maybe, and the ICMP request
> telling the pc to fragment is not being sent possibly at least I never
> see it in the sniffer logs.