VPN fonctionnel : but no connection has been authorized

[nl]

Hello,

Désolé de relancer un post au sujet des vpn, mais après moultes recherches sur "but no connection has been authorized". Il apparaît qu'aucune solution n'ait été trouvée.

Mon VPN fonctionne, mais il souffre de déconnexions fréquentes et ne se relance pas bien malgré le script de reconnexion. (car j'ai IPsec SA established, les scripts ne détectent pas le problème)

Après analyse de mes logs, j'ai décelé

Code: Tout sélectionner

initial Main Mode message received on 192.168.1.2 :4500 but no connection has been authorized with policy=RSASIG

qui est le seul problème.

A première vue, c'était un bug de freeswan http://bugs.xelerance.com/view.php?id=194, dont voici l'explication .http://www.freeswan.org/freeswan_trees/CURRENT-TREE/doc/faq.html#noconn.auth: Un problème de Right / Left.

Malheureusement, je ne comprends pas pourquoi mon vpn fonctionne avec ma configuration actuelle si c'est un problème de Right/ Left. Car j'ai bien

Code: Tout sélectionner

IPsec SA established

sur tous mes sites.

Cela pourrait-il venir du fait que j'ai

Code: Tout sélectionner

auto=start

dans tous mes ipsec.conf ?(Que la connexion essaye de s'établir de tous les côtés à la fois, cela engendrant le refus des connexions redondantes ?)

J'avoue être dépassé. Quelqu'un aurait-il déjà résolu le problème ?

Je tourne avec 4 ipcop 1.4.10 tous derrière des nat et voici mes fichiers de config (je post uniquement 2 configuration par simplification) :

Ipcop 1 :

Code: Tout sélectionner

config setup
   interfaces=%defaultroute
   klipsdebug=none
   plutodebug=none
   plutoload=%search
   plutostart=%search
   uniqueids=yes
   nat_traversal=yes
   virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.0.0.0/255.255.255.0,%v4:!10.0.2.0/255.255.255.0,%v4:!10.0.3.0/255.255.255.0,%v4:!10.0.1.0/255.255.255.0

conn %default
   keyingtries=0
   disablearrivalcheck=no


conn vpnfribourg
   left=192.168.1.2
   leftnexthop=%defaultroute
   leftsubnet=10.0.0.0/255.255.255.0
   leftcert=/var/ipcop/certs/hostcert.pem
   right=vpnfribourg.dyndns.org
   rightsubnet=10.0.1.0/255.255.255.0
   rightnexthop=%defaultroute
   rightcert=/var/ipcop/certs/vpnfribourgcert.pem
   dpddelay=30
   dpdtimeout=120
   dpdaction=hold
   pfs=yes
   authby=rsasig
   auto=start



Ipcop 2 :

Code: Tout sélectionner


config setup
   interfaces=%defaultroute
   klipsdebug=none
   plutodebug="none"
   plutoload=%search
   plutostart=%search
   uniqueids=yes
   nat_traversal=yes
   virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.0.1.0/255.255.255.0,%v4:!10.0.0.0/255.255.255.0

conn %default
   keyingtries=0
   disablearrivalcheck=no

conn vpnchatel
   right=192.168.2.3
   rightsubnet=10.0.1.0/255.255.255.0
   rightnexthop=%defaultroute
   rightcert=/var/ipcop/certs/hostcert.pem
   left=vpnchatel.dyndns.org
   leftsubnet=10.0.0.0/255.255.255.0
   leftnexthop=%defaultroute
   leftcert=/var/ipcop/certs/vpnchatelcert.pem
   ike=3des-sha-modp1536,3des-sha-modp1024,3des-sha-modp768,3des-md5-modp1536,3des-md5-modp1024,3des-md5-modp768
   esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
   ikelifetime=1h
   keylife=8h
   dpddelay=30
   dpdtimeout=120
   dpdaction=hold
   pfs=yes
   authby=rsasig
   auto=start


Merci

[nl]

Apparemment, il n'y a pas de solutions, cela serait dans la liste des améliorations d'ipsec.

Issue #1: Both hosts need to know that there is a NAT in the middle,
but currently IKE/IPsec do not provide such method. Only indication
of NAT presence is the fact that all IPsec SA packets, if they
arrive, will be dropped as invalid if AH is in use.


Issue #2: It is obvious that programs residing on an IKE responder
that is behind a basic NAT cannot know about the existence of the
NAT or about the specific address mappings configured there.
Therefore the IKE responder implementation should have advance
knowledge about the address mappings.

Issue #3: If NATs are employed along the route, there may be
addressing conflicts in tunnel mode (and there WILL be conflicts in
transport mode). From the IKE responder point of view, the IKE
initiators' addresses may conflict if they are in private networks
(such as the IANA-assigned 10.0.0.0 subnet).

source : draft-stenberg-ipsec-nat-traversal-02.txt : http://mirrors.isc.org/pub/www.waterspr ... sal-02.txt

[nl]

En fait ce bug est corrigé depuis la version 2.2 d'Openswan

this is a well-know bug occuring with NAT-Traversal when the receipient
has defined a connection with a static IP address instead of left=%any.

Ipcop 1.4.10 tourne avec Linux Openswan 1.0.10rc2 !!! A quand une mise à jour ???
J'ai fini mon monologue ..