[Openswan Users] Problem of ping

[Jérémie Wetzler]

Now it's ok ! with this configuration. However, when I test this over
Internet it doesn't work...
I have a NAT server. It always says "Negotiating IP policy" but never pings.

Roadwarrior     <---> Internet <--->       Nat Server        <---> LAN 
Ip of the FAI				 public IP	    LAN IP
Random IP                            a.b.c.d       e.f.g.h     192.1.0.0/24


Do I have to specify something like nexthop ? I juste have specified
nat_transversal=yes.

Jérémie


-----Message d'origine-----
De : Paul Wouters [mailto:paul at xelerance.com] 
Envoyé : mercredi 11 août 2004 10:06
À : Jérémie Wetzler
Cc : users at lists.openswan.org
Objet : Re: [Openswan Users] Problem of ping

On Wed, 11 Aug 2004, Jérémie Wetzler wrote:

> I’m actually working on Opoenswan for my Companie. Openswan doesn’t work
in
> a LAN (with a router with 2 interfaces). Negociating Security IP and when
I
> sniff the network, I can see “Isa KMP phase 1, IKE PHASE 2 ” and “frag
IP”.
> I retried the how to of Nate Carlson with certificates but it doesn’t
work


btw. whatever your mail client is doing, it is VERY hard for me to read
through it.
 
> config setup
>         interfaces=%defaultroute
>         #interfaces="ipsec0=eth0"
>         klipsdebug=none
>         plutodebug=none
>         uniqueids=yes
>         nat_traversal=yes
>         virtual_private=%v4:192.1.0.0/24,%v4:192.168.0.0/24

Note you are adding 192.1.0.0/24 as a virtual private network. This means
openswan will expect
this network to be a valid private network at the roadwarrior end.

> conn roadwarrior-net
>         # leftsubnet <=> reseau interne derriere le windows
>         leftsubnet=192.1.0.0/24

And that conflicts with having that subnet on the server end. Perhaps you
meant to use 192.168.0.0/24?

You mean to say something like :

         virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,!%v4:192.1.0.0/24

This means that valid ranges for addresses behind NAT is anything in the
10.* range
and the 192.168.* range, and explicitely excludes 192.1.0.0/24 (even though
that is
technically not needed, since it doesnt overlap with the previous entries)

> conn roadwarrior
>       # left <=> mon ip du windows client derrière un eventuel LAN
>       left=%any
>       # Ip du serveur du coté du client windows
>       right=192.1.0.142
>       # Contenu du certificat: openssl x509 -in demoCA/cacert.pem -noout
-subject
>       rightca="C=FR, S=France, L=Montreuil, O=RXBURO, CN=jeremie,
Email=jwetzler at reseaux-bureautique.com"
>       network=auto
>       auto=start
>       pfs=yes

The right cannot be part of the left subnet. That would mean that the IP
192.1.0.142 is both
on the left and right side. You need to think of having two "public" ip
addresses, one on each
end, and possible have two "private" subnets behind either one of them.
Don't mix them. If you
are not using more then two machines, and the machines are therefor in the
same local network,
then you cannot put that network into a subnet= line. If this is a test
network, then add a third
machines pretending to be "the internet", so you don't run into this
problem.

> conn roadwarrior-net
>       # left <=> mon ip personnel du windows derrière un eventuel LAN
>       left=%any
>       # right <=> ip publique du firewall
>       right=192.1.0.142
>       rightsubnet=192.168.0.0/24

Same here.
 
>       rightca="C=FR, S=France, L=Montreuil, O=RXBURO, CN=jeremie,
> Email=jwetzler at reseaux-bureautique.com"
>       network=auto
>       auto=start
>       pfs=yes

> When I try a ipsec barf everything is ok however it says ipsec.secrets
> [FAILED

ipsec barf just dumps all debug info. It does not say "ok" or "not ok". You
probably meant 'ipsec verify'. You can ignore the error in ipsec.secrets for
that entry, since you are using certificates and not raw rsa keys. This 
warning should not happen on modern openswan-2 releases, but I am not
entirely sure where this got fixed. 

Paul