[Openswan Users] 2.4.0 trouble

[Paul Wouters]

On Wed, 5 Oct 2005, Ethy H. Brito wrote:

> I say 'kind a work' because the misleading error message '...could not start
> conn "cressem"' make me believe that there was something very very wrong. I
> then set plutodebug=all and klipsdebug=all and after one hour or two browsing thru
> the most incoomprehensive lines I've ever read (PERL not included :) ) I could
> NOT find anything that looked like an error. :-0

You should not set those debug flags, since those are to debug code, not debug
connections. It just adds a truckload of irrelevant messages.

> So why does _plutoload say it 'could not start conn "cressem" if I can see ESP

It could be for instance because your initiation to the remote fails, but it
triggers the remote to initiate to you which succeeds. As I said before, I am
not seeing all your logentries, so I cannot say more

> Why is this message so inconclusive?

Because you're not giving me the entire message.

> Another question: if I run 'ipsec auto --up --asynchronous cressem'
> ( _plutoload line 123) from console it gives me no error ($?=0). Why???

This might be related to this bug:

http://bugs.xelerance.com/view.php?id=198

> Did you know that net/xfrmudp.h is not found whem compiling 2.4.0
> modobj26/ipsec_init.c line 95 (missing link?)? I had to replace the #include
> with the full path. I was giving KLIPS a try when I found this.

That usually means you are trying to build KLIPS as a module with nat-t
support on a kernel that has no KLIPS nat-t support. In other words, you
did not apply the nat-t patch to the kernel, yet you are trying to build
a KLIPS module with CONFIG_IPSEC_NAT_TRAVERSAL=y

Paul