It manifests itself as communication originating from the remote tunnel
endpoint being ignored. Traffic from hosts other than the remote endpoint
that is routed over the tunnel IS seen and acted on.
In this log, 10.1.1.1 is the remote endpoint, 10.1.1.2 is tunneled, and
10.1.1.3 is another machine on the remote endpoints network. These are
tcpdumps of traffic as seen by the 10.1.1.2 system.
With kernel 2.2.5 (same results with 2.2.6)
20:00:39.041879 10.1.1.3 > 10.1.1.2: icmp: echo request (ipip)
20:00:39.041979 10.1.1.2 > 10.1.1.3: icmp: echo reply (ipip)
20:02:36.712234 10.1.1.1 > 10.1.1.2: icmp: echo request (ipip)
20:02:37.712373 10.1.1.1 > 10.1.1.2: icmp: echo request (ipip)
With kernel 2.2.3
20:20:43.066396 10.1.1.3 > 10.1.1.2: icmp: echo request (ipip)
20:20:43.066493 10.1.1.2 > 10.1.1.3: icmp: echo reply (ipip)
20:21:14.144984 10.1.1.1 > 10.1.1.2: icmp: echo request (ipip)
20:21:14.145081 10.1.1.2 > 10.1.1.1: icmp: echo reply
Of course, in the log from 2.2.3, the fact that the icmp reply is not
(ipip) shows that there is an asymmetrical route for that traffic, but
that doesn't seem to cause problems with 2.2.3. Maybe the problem is
stricter checking of interfaces traffic is recieved/sent on in the later
kernels, and that is the cause of the problem? If so, is there a
workaround?
I would be happy to provide any further information that is needed to
track down the problem.
Evan
-- | Evan Harris - Consultant, Harris Enterprises - eharris@puremagic.com | | Custom Solutions for your Software, Networking, and Telephony Needs
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/