[Openswan Users] Don't ping to subnet.

[Paul Wouters]

On Sun, 21 Sep 2008, André João Telöcken wrote:

> conn roadwarrior
>         left=%defaultroute
>         leftcert=host.linuxcom.br.pem
>         right=%any

You cannot do this. openswan can now not find out if it is left
or right. If this is a server, then put the real ip in left= (assuming
you're left). If this is the client, then right= should be the ip of
the remote server (assuming right is the other end)

> 3)       Windows XP IPSec : ipsec.conf:

You should use lsipsectool (sourceforge.net) and not the old ebootis
tools. They're causing problems on some XP's

> conn roadwarrior
> 
>       left=%any

That should be %defaultroute

>       right=200.xxx.xxx.xxx
> 
>       rightca="C=BR, S=Santa Catarina, L=Chapeco, O=Transportes CoName
> Ltda, OU=CoName, CN=srvName, E={email}"
> 
>       network=auto
> 
>       auto=start
> 
>       pfs=yes

Windows does not support pfs I believe?

> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
> 
> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> byte 2 of ISAKMP Hash Payload must be zero, but is not
> 
> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> malformed payload in packet

Not sure why this happes, maybe because of the above errors?

> Sep 21 20:39:12 srvName pluto[14022]: | payload malformed after IV
> 
> Sep 21 20:39:12 srvName pluto[14022]: |   20 3a cd 09  23 5d 31 01
> 
> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> sending notification PAYLOAD_MALFORMED to 189.73.104.254:4500
> 
> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> 
> Sep 21 20:39:12 srvName pluto[14022]: "roadwarrior"[2] 189.73.104.254 #2:
> STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0xfca13310
> <0x2fe017a4 xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=189.73.104.254:4500
> DPD=none}

Though it seems to go on the second run? Though I am confused because
what are these logs if windows didnt negotiate yet:

> 5)       Ping to openswan server (200.xxx.xxx.xxx):
>  
> C:\Documentos\Desenvto\IPSec\IPSec>ping 200.xxx.xxx.xxx
> 
> Disparando contra 200.xxx.xxx.xxx com 32 bytes de dados:
> 
> Negociando segurança IP.

It's normal that a few packets won't work while the tunnel is
being setup, since windows does not do packet caching like Openswan
(when used with KLIPS)

> C:\Documentos\Desenvto\IPSec\IPSec>ping 200.xxx.xxx.xxx
> 
> Disparando contra 200.xxx.xxx.xxx com 32 bytes de dados:
> 
> Resposta de 200.xxx.xxx.xxx: bytes=32 tempo=60ms TTL=64

For you, since that first negotiation failed, it took a few more
lost packets before it worked.

> 6)       Ping to subnet on openswan Server (192.168.1.254):

Since we did not see logs for roadwarrior-subnet or roadwarrior-all,
there is no tunnel for that.

> 
> C:\Documentos\Desenvto\IPSec\IPSec>ping 192.168.1.254
> 
> Disparando contra 192.168.1.254 com 32 bytes de dados:
> 
> Esgotado o tempo limite do pedido.

And it looks like windows doesnot know which tunnel to use for this.

Paul