2.6: ping on established(!) VPN tunnel doesn't!

sundialsvcs · 12-07-2005, 06:11 PM

Here's a wierd-one for ya...

I am using IPSec-Tools .. actually a modified version which supports the XAUTH protocol. I am using that version right now, successfully on a 2.4 machine.

But, on a 2.6 machine on the same network, behind the same router, with the same configuration, I get something "vewy skwewy..." (to quote Elmer Fudd).

I start Racoon, issue the SetKey commands, ping 192.168.30.1 (this being a port within the range of addresses exposed on the other network through the tunnel.

In a few moments, the VPN tunnel is established, successfully.
Knowing that the first exchange is simply going to get Racoon to do its thing, I stop pinging, wait a few seconds, and try again.
Using ethereal I can see UCMP Echo Reply packets being sent back .. from 192.168.30.1 -> the address of my ethernet adapter, yes, on the 2.6 machine! The remote host is trying to respond properly! Yes, the received packet appears to Ethereal to be valid in every way!
But nothing comes out on the terminal. ping will say that so-many packets were transmitted and that there was "100% packet loss."
The output from setkey -DP on both machines is virtually the same. They both show an established tunnel, both show policies in place.
The 2.6 machine isn't even running a firewall.

When I, now very curious, do the same thing on the 2.4 machine, and using a somewhat older version of ethereal, I do not see exactly the same output (it is an older version...), but I do promptly see ping delivering output to the terminal.

So... what

dumb thing am I overlooking?

sundialsvcs · 12-09-2005, 05:09 PM

The problem turned out to be a difference between the 2.4 implementation of IPSEC and the 2.6. The new kernel applies the spdadd rules (setkey command) rules more stringently than 2.4 did.

Previously, I had only a rule which specified -P out. I did not have, nor did I need on 2.4, a second, reverse rule which specified -P in.

Apparently, kernel 2.6 does perform this check more stringently, as indeed it should. (And my 2.4 is quite old, so maybe they fixed it there, too.)

Without the rule, what happens is that (as I saw in ethereal or tcpdump...), the IPSec packet comes in, it gets decrypted, the payload gets re-injected into the stream, and ... because there is no matching rule, the packet is silently dropped.