Probleme de VPN 1.4.21/2.14

[fab]

Contexte :
2 reseaux distants en VPN
Site A : Ipcop 1.4.21
Site B : Ipcop 2.1.4
La connexion VPN (PSK avec les valeurs par defaut proposées)
Certaines communications entre les 2 reseaux sont OK , d'autres KO.... ou semi KO (tout le probleme est là)

Besoin :
Trouver des pistes vers lesquelles chercher, arriver à trouver une logique.

Schéma :
Site A (ipcop 1.4.21) <->SDSL ipfixe <---------->SDSL2 (ipcop2.1.4) Site B

Firewall/Serveur-passerelle multifonctions :

Adressages :
Site A 192.168.150.0
Site B 192.168.10.0

Question :
- Le trafic entre les 2 GREEN de chaque VPN est il ouvert

Pistes imaginées :


Historique :
Je me suis permis de transformé cette rubrique en Historique car il me parait important de savoir certaines choses.
Avant d'etre dans la config avec l'IPCOP 2.14, le VPN etait geré entre les 2 sites par ce bon vieux ipcop1.4.21 coté siteA et par un Syswan sur siteB. Les utilisateurs de siteB avait acces sans probleme aux ressources de siteA. Malheureusement ce Syswan ne s'entendait pas toujours avec l'IPcop et le VPN tombait regulierement. Je suis donc passé à un Ipcop sur le siteB. Et là plus de probleme de coupure de VPN mais d'autres problemes sont apparus....

Logs et tests :
Voici les tests dejà effectués :
- les ping entre differentes machines de site A et site B sont OK.

Ce qui ne marche pas :
- PC1 du siteB essaye de joindre https://192.168.150.6:10000 (webmin)par exemple, Firefox affiche alors la page "Cette connexion n'est pas certifiée" avec l'ajout d'une exception.. j'ajoute l'exception, et ensuite ça tourne et n'affiche jamais rien de plus
- du meme PC, je vais sur http://192.168.150.4, service web interne, j'ai une page d'authentication qui s'affiche je m'authentifie passe à la page suivante.. mais qui ne s'affichera jamais
- par contre de ce PC1 siteB je suis connecté en SSH sur un serveur siteA sans probleme.

J'ai bien sur fait ces differents tests sur plusieurs machines et le resultat est le meme.
Un autre probleme :
- de ma machine (LAN siteA) je n'accede pas l'interface d'IPCOP du siteB. J'ai pourtant ajouté un règle Acces IPcop Source:
Interface: IPsec-Red Adresse: Any
Destination: Acces IPCop : IPCop https
(j'ai fait des transferts de ports qui fonctionnent par contre...)

======
Comme quoi le fait d'en parler fait du bien. En remplissant la partie "Pistes" et ayant lu d'autres topics j'ai pensé à la partie route...
ROUTE :
Destination Gateway Genmask Flags Metric Ref Use Iface
default 193.xx.bb.65 0.0.0.0 UG 0 0 0 wan-1
192.168.10.0 * 255.255.255.0 U 0 0 0 lan-1
192.168.200.0 192.168.200.2 255.255.255.0 UG 0 0 0 tun0
192.168.200.2 * 255.255.255.255 UH 0 0 0 tun0
193.95.44.0 * 255.255.255.0 U 0 0 0 wan-1
rien qui ne concerne ipsec-red !!! est ce normal ??
Quand je fais un ifconfig, pas de trace de ipsec-red non plus !!
J'ai regardé sur mon IPCOP 1.4 et a bien des routes et cartes concernant ipsec0

Tout ceci me parait bien louche du coup ! Mon long topic va donc se résumer à 2 premieres questions :
- est ce normal de ne pas avoir de ipsec-red en faisant un ifconfig
- est ce normal de ne pas avoir de route concernant mon reseau distant siteA
(a priori non mais comme on arrive quand meme à pinguer.... le doute est là)

Merci d'avance.

[jdh]

(Je ne suis pas spécialiste ipcop.)

2 réflexions :
- ne serait-il pas judicieux d'avoir des ipcop au même niveau ?
- quid du routage des clients (plutôt que ceux des ipcop) ?

Il faut éviter de tester d'ipcop à ipcop car ce n'est pas suffisant : test de green à green mais éventuellement tcpdump au niveau d'ipcop !

Si des ping entre pc des 2 green fonctionnent c'est plutôt bon signe ! (et le routage des clients serait bon)
Il serait intéressant de tester des ping avec des tailles de paquets de plus en plus élevés car le lien via vpn peut empêcher les paquets longs et il faut s'assurer que les ipcop contrôle la fragmentation : sous windows, commande ping -l (size)

[fab]

Merci jdh.

Bien sur qu'avoir 2 IPCOP de meme niveau serait plus judicieux, mais le 1.4.21 est sur le site principal, il a une config plutot "complexe" enfin beaucoup de choses (pas mal transferts ports, une 20aine d'Openvpn RW, des alias, ....) pas mal de taf donc, sans savoir si ça peut changer quelquechose. De plus je ne suis pas encore familiarisé avec le IPcop2 et je ne peux pas me permettre de mettre en prod un IPcop qui ne ferait pas au moins ce que fait l'actuel.
Routage des clients ? Les clients de chaque GREEN ont comme passerelle leur Ipcop respectifs..

Je n'ai pas fait que des tests d'Ipcop à Ipcop, justement (aucun de mes tests ne parle de tests du'un à l'autre). Je teste plutot d'une machine du siteB vers un serveur du siteA. Je precise que les choses qui ne marche pas dans mes tests etaient des choses fonctionnelles avant le changement Syswan=>Ipcop2.

Je vais voir cette idée de ping -l (j'avais déjà pensé à modifier le MTU dans la config VPN de chaque IPcop, un test en 1500 n'avait pas porté ses fruits), je dois me renseigner sur tout ça...
Idem pour tcpdump que je connais plus de nom qu'à l'utilisation... je vais m'y pencher dessus.

Est ce que quelqu'un qui utilise un IPCOP 2.14 + VPN ipsec pourrait verifier svp :
- si une carte ipsec-red apparait lors d'un "ifconfig"
- si il y a une route pour le reseau ipsec-red en faisant un "route"

En vous remerciant d'avance.

[Franck78]

Hello,
Dans le kernel 2.6 + strongSwan, il n'y a plus d'interface ipsecN.
Note que je n'ai pas été voir comment était implémenté ipsec dans IPCop 2. Ce n'est donc pas anormal.....

Ensuite, si ton client trouve bien son chemin à l'autre bout du VPN pour afficher une page de n'importe quoi, c'est qu'il est établit, dans les deux sens....

La page qui ne s'affiche pas, c'est peut être applicatif. Parce qu'en gros, le tube vpn n'est pas regardant sur ce qu'il transporte.

Par contre il peut tomber. Sans raison évidente mais le log est la ESTABLISHED ... DOWN....

Donc des tests simples. Si pendant des heures tu fais du ftp entre sites, le vpn est probablement bon. Si tu consultes un serveur web (sans proxy of course), le vpn est probablement bon. Si ta session ssh tient trois heures, le vpn est probablement bon. Si xyz plante systématiquement, c'est qu'il n'arrive pas jusqu'au VPN, ou n'en sort pas à l'autre bout !

[fab]

Merci pour l'info ipsec Franck.
Je n'ai pas d'interface ipsecN, mais je m'attendais quand meme à trouver quelquechose correspondant au VPN dans ipconfig ou route.

Tu as en fait résumé mon probleme c'est qu'à priori tout semble OK, puisque des pings ou connexion SSH entre machines siteA et siteB se font, des pages web s'affichent.

Je ne pense pas que mon VPN tombe car je lance des ping -t (ping continu) afin de voir si ça coupe ou si le temps de reponse en prend un coup... mais non rien..
Il faudra que je verifie plus precisement le log Ipsec au cas où. Je suis aussi de ton avis une fois le tuyau etabli, sans regle spéciale, tout devrait passer d'un GREEN à l'autre.

Les services qui "coupent", ça ressemble un peu à un timeout (avec un temps plus court et assez variable), c'est ce que je constate sur la page web et avec le logiciel Filemaker (base de données qui fonctionne en mode connecté). Par exemple avec Filemaker qui permet vite de savoir si il y a une coupure ou non du fait du mode connecté, si je fais rien ça ne coupe pas, et si par exemple je mets à jour un enregistrement, ça mouline un peu et puis me dit que la connexion est perdu, mais pas dans tous les cas, (comme si j'avais eu une rupture de lien) mais mon ping à coté ou un autre utilisateur ne sont pas coupés.
Et comme je l'ai precisé précedemment tout ceci marchait tres bien avec le routeur Syswan (à la place du IPcop2).

Un truc qui ne marche pas non plus c'est l'accés à IPCOP2 (https) depuis le GREEN de siteA ... j'ai fait l'acces dans les regles (j'en ai fait d'autres pour un acces externe par le RED depuis mon domicile et c'est OK, je n'ai pas donc du me tromper en créant l'acces..) et c'est un peu pareil, je pingue, quand j'accede à la page il semble la trouver (pas de 404) mais tourne sans jamais rien afficher.

Je vais continuer à plancher dessus, et je reste ouvert à toute idée ou reflexion.

[Franck78]

Essaie des ping avec un payload gros puis plus gros puis très très gros... 1000 10000 100000 (pas sur pour le 100k )

[fab]

Bonjour,
Tu parles d'un ping -s (sous linux)?
ah ben tiens je viens de voir que pour Windows ça correspond à un ping -l ...... pratique !!

SI c'est le cas voici ce que ça donne :

ping -s 1000 => OK
ping -s 2000 => KO

Par dichotomie j'ai essayé de trouver la valeur max pour laquelle ça passe : 1362 => OK ; 1363 => KO

J'ai fait des ping d'un serveur Linux siteA vers server linux siteB et inversement, et de ma machine siteA vers le meme serveur siteB, je retrouve les memes valeurs...

Lors d'un ping depuis le serveur siteB vers siteA j'ai eu ça :

[root@servSIteB~]# ping 192.168.150.235 -s 1400
PING 192.168.150.235 (192.168.150.235) 1400(1428) bytes of data.
From 192.168.10.99 icmp_seq=0 Frag needed and DF set (mtu = 1422)

Le ping inverse ne donne pas l'info (mais ne passe pas quand meme), et l'info "Frag...." ne s'affiche que pour la valeur 1400....

Comment interpreter cela ? le MTU serait trop bas par rapport à la taille des paquets envoyés ?
Sur Ipcop dans la config du VPN je sais qu'on peut modifier la valeur du MTU.. mais que mettre ? 1422 ? 1400 ? 1362 ?

[fab]

Le chiffre du jour sera : 1390

En fixant le MTU à 1390 (1362 + 28 du ping) sur chaque config VPN ça marche !!

Je comprends toujours pas trop pourquoi avant ça marchait avec le Syswan et pas avec l'IPCOP. Et d'où vient cette valeur de MTU (la liaison SDSL qui le fixe ?)

En tout cas merci à vous pour vos interventions.

[jdh]

Les problème de MTU sont difficiles à identifier.
Mais on a souvent un ping et un ssh qui fonctionne, tandis que ftp ou http ne fonctionne pas.
Forcément puisque ces derniers protocoles tentent d'utiliser la totalité de la taille du paquet.
D'où le test du "ping -l" (ping -s sous linux) (mais avec des tailles raisonnables : pas 10000, comme Franck78 : l'erreur pédagogique pour voir si on suit !).
(Attention à bien tester depuis et vers un autre point que les firewall !).

Quand le MTU se réduit, on peut tenter la fragmentation, qui est loin d'être toujours autorisée : c'est un choix de firewall à fare, généralement c'est sans fragmentation !
(Pourquoi : le firewall doit déjà suivre les paquets dans une session, alors ça se complique s'il faut, en plus, suivre les fragments de paquets !).
(Et c'était une vielle technique pour "casser" les premiers firewall "statefull" !)