MultiWan PFSense, Perte WAN, arpresolve, arplookup: can't allocate route
-
Bonjour,
Mon problème est que je perd la connection WAN toutes les 30 secondes.
Après plusieurs jours de recherche, ne trouvant pas de pistes, je me tourne vers ce forum pour avoir d'autres points de vues.Cette configuration me sers de test. Le but final sera de remplacer l'IPCop.
Voici ma configuration de test:Internet –-- SDSL ---- (OPT1)PFSense(WAN) –-- IPCop ---- ADSL ---- Internet
| |
| |
| |
PC de test Swicht (réseau d'entreprise)PFSense (WAN): 192.168.37.91
IPCop: 192.168.37.1La connection SDSL fonctionne très bien.
La connection WAN est configurée en DHCP.Le multiwan est correctement configuré avec par exemples les routes statiques pour les DNS, le load balancer avec OPT1 et WAN (moniteur: les DNS), les règles de NAT et de firewall qui vont bien (HTTP sur le load balancer, HTTPS sur le SDSL par exemple).
Comme indiqué en introduction, mon souci vient de la connection WAN qui tombe. Pour la réactivé, un petit dhclient sur WAN et la connection repart pour un temps très court.
Les logs:
ping 192.168.37.1 #Sur PFSense, ping de l'IPCop #Résultat ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: No route to host #dhclient sur WAN 64 bytes from 192.168.37.1: icmp_seq=2262 ttl=64 time=53.633 ms 64 bytes from 192.168.37.1: icmp_seq=2263 ttl=64 time=0.749 ms 64 bytes from 192.168.37.1: icmp_seq=2264 ttl=64 time=0.748 ms 64 bytes from 192.168.37.1: icmp_seq=2265 ttl=64 time=0.750 ms 64 bytes from 192.168.37.1: icmp_seq=2271 ttl=64 time=0.693 ms 64 bytes from 192.168.37.1: icmp_seq=2276 ttl=64 time=1.116 ms 64 bytes from 192.168.37.1: icmp_seq=2277 ttl=64 time=1.000 ms 64 bytes from 192.168.37.1: icmp_seq=2278 ttl=64 time=0.999 ms ping: sendto: Network is unreachable #La connection tombe ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: Network is unreachable ping: sendto: Network is unreachable#Les logs system de PFSense (/var/log/system.log) Nov 30 15:58:05 pfsense kernel: arplookup 192.168.37.1 failed: host is not on local network Nov 30 15:58:05 pfsense kernel: arpresolve: can't allocate route for 192.168.37.1 Nov 30 15:58:06 pfsense kernel: arplookup 192.168.37.1 failed: host is not on local network Nov 30 15:58:06 pfsense kernel: arpresolve: can't allocate route for 192.168.37.1 Nov 30 15:58:37 pfsense kernel: arplookup 192.168.37.1 failed: host is not on local network Nov 30 15:58:37 pfsense kernel: arpresolve: can't allocate route for 192.168.37.1Avec ce problème, j'ai recherché des solutions sur les forums et les listes de diffusions. La seule information intéressante était de Chris qui indiquait que le problème venait des allias. Or je n'utilise aucun aliias. J'ai aussi testé d'ajouter manuellement l'entrée d'IPCop dans la table ARP de PFSense sans résultat probant.
Des suggestions ? Des idées ? (Idéalement^^) Des solutions ?
-
On peux savoir les champs renseigner sur l'interface WAN?
-
Je ne vois pas en quoi WAN aurait le rôle d'une carte WAN !
Le WAN normal serait plutôt relié à la SDSL. et non derrière un firewall et partant une lointaine ADSL.Il y a incohérence entre "WAN est en DHCP" et "un petit dhclient sur OPT1".
La plupart du temps, les opérateurs livrent une SDSL avec 1 routeur et une ip publique fixe, donc en statique (enfin pour Orange et SFR, pour moi c'est comme ça dans plusieurs sites et plusieurs entreprises). Donc nul besoin de dhcp.
Il est probable que si l'interface tombe, les routes portées sur cette interface tombent.
Le schéma ne me parait pas être un bon test.
(Sans compter qu'après avoir installé pfSense, et commencé à configurer règles et surtout alias, le rejet d'ipcop est très très rapide.)Perso, je ne vois pas du tout de cette façon le multiwan : j'ai des sites avec 1 SDSL et une ADSL : la SDSL est le WAN, et l'adsl est relié à une carte supplémentaire d'un proxy situé en DMZ. L'intérêt est de fournir une navigation en ADSL donc plus bien rapide que sur SDSL car la répartition des flux montant/descendant est conforme à l'ADSL. Inversement le serveur de mail (le relais mail) est situé en DMZ mais utilise la SDSL puisque les flux sont égaux approximativement en montants/descendants (et entre autre car l'ADSL est dynamique) …
-
On peux savoir les champs renseigner sur l'interface WAN ?
L'interface WAN est configuré en DHCP. Le serveur DHCP est le routeur IPCop.
Je ne vois pas en quoi WAN aurait le rôle d'une carte WAN !
Le WAN normal serait plutôt relié à la SDSL. et non derrière un firewall et partant une lointaine ADSL.Comme je l'indiquais, il s'agit d'un schéma permettant de tester PFSense en multiwan avec IPCop. Garder IPCop permet juste de pouvoir faire des tests sans déranger le réseau de l'entreprise. L'architecture finale sera sans IPCop, avec le réseau entreprise connecté directement à PFSense, et l'ADSL connecté au WAN en PPOE. (PFSense ne gère le PPOE uniquement sur le WAN)
Il y a incohérence entre "WAN est en DHCP" et "un petit dhclient sur OPT1".
Effectivement, il s'agit d'une erreur de ma part. Le dhclient s'effectue sur le WAN permettant à l'IPCop de délivrer une adresse IP à PFSense. Pour information, le SDSL est configuré en statique.
Il est probable que si l'interface tombe, les routes portées sur cette interface tombent.
La route menant à IPCop tombe effectivement avec la perte du WAN (et revient lors du dhclient), à mon sens, il s'agit d'une conséquence au problème que j'ai décrit et non l'origine du problème.
Le schéma ne me parait pas être un bon test.
Ce test permet de tester PFSense sans déranger les employés, de garder le VPN nomades et inter-sites. Mais surtout, la migration d'IPCop vers PFSense pourra se faire avec une interruption de service très court.
Perso, je ne vois pas du tout de cette façon le multiwan : j'ai des sites avec 1 SDSL et une ADSL : la SDSL est le WAN, et l'adsl est relié à une carte supplémentaire d'un proxy situé en DMZ. L'intérêt est de fournir une navigation en ADSL donc plus bien rapide que sur SDSL car la répartition des flux montant/descendant est conforme à l'ADSL. Inversement le serveur de mail (le relais mail) est situé en DMZ mais utilise la SDSL puisque les flux sont égaux approximativement en montants/descendants (et entre autre car l'ADSL est dynamique) …
Une fois PFSense et ses tests validés, IPCop serait remplacer par PFSense et son interface WAN serait directement relié au modem par PPOE. Le schéma simplifié ne montre pas tout, il y a une zone DMZ, plusieurs réseaux, qui n'interviennent pas pour le moment.
-
Le schéma simplifié ne montre pas tout, il y a une zone DMZ, plusieurs réseaux, qui n'interviennent pas pour le moment.
C'est toujours ce que l'on croit. L'expérience, cette semaine encore, m'a encore montré que c'est une erreur.
D'une façon plus général le schéma retenu pour le test n'est pas adapté. Il faut prendre en considération le routage par défaut de Pfsense et qui affecte le PC de test.
Ce test permet de tester PFSense sans déranger les employés, de garder le VPN nomades et inter-sites. Mais surtout, la migration d'IPCop vers PFSense pourra se faire avec une interruption de service très court.
Pour obtenir une interruption courte dans ce genre de migration, il faut une très bonne préparation. Ce qui implique par exemple des tests or des heures d'activités. Les conditions de tests ne me semblent pas satisfaisantes pour garantir une migration rapide et sans mauvaise surprise.
Mais vous êtes le maître à bord.
-
C'est toujours ce que l'on croit. L'expérience, cette semaine encore, m'a encore montré que c'est une erreur.
Pour le moment, vu que PFSense fonctionne mal, j'ai simplifié au maximum. Avec ou sans loadbalancer, le problème est le même. Sauf qu'en utilisant le loadbalancer, le PC de test n'est plus tributaire de la route par défaut de PFSense. Une fois que la connection WAN sera stable, d'autres éléments de tests interviendrons, comme les VLANs, la DMZ, et les VPNs. Quand il y a un problème, je simplifie un maximum pour déterminer, localiser et résoudre le problème. Je pense l'avoir bien localiser, par contre sa résolution …
D'une façon plus général le schéma retenu pour le test n'est pas adapté. Il faut prendre en considération le routage par défaut de Pfsense et qui affecte le PC de test.
Si tu entends routage par défaut, par la route par défaut, alors il s'agit de l'IPCop. J'ai aussi tester de mettre le SDSL sur le WAN pour avoir comme route par défaut la connexion SDSL, le problème est identique, c'est à dire que la connexion OPT1 (donc la connexion à l'IPCop dans cette configuration) tombe de la même manière avec les mêmes symptômes.
Par contre, je vois pas de rapport direct entre la route par défaut et le souci rencontré. Vu que j'utilise un loadbalancer, PFSense détecte que la connexion WAN est tombé et passe uniquement le traffic par défaut vers le SDSL. La route par défaut sert uniquement pour les services locales de PFSense.Pour obtenir une interruption courte dans ce genre de migration, il faut une très bonne préparation. Ce qui implique par exemple des tests or des heures d'activités. Les conditions de tests ne me semblent pas satisfaisantes pour garantir une migration rapide et sans mauvaise surprise.
Les tests hors heure d'activité sont prévus une fois tous les tests passés. Et le test présenté dans ce forum n'est que le premier d'une batterie.
-
"WAN" pourrait être stable en statique et non en DHCP dans ce schéma de test.
Une telle migration ne peut/doit se faire qu'en 2 temps :
- un, remplacement à iso-périmètre : même découpage réseaux, même adressage, même filtrage, …
- deux, ajout de nouvelles fonctionnalités : double accès Internet, ...
Faire 2 choses en même temps est le plus sûr moyen d'échouer ...
Objectivement, je vois mal qu'un pfSense ne puisse pas remplacer en "un instant" un Ipcop du fait d'une structure "bloquée" d'Ipcop (couleurs très strictes), de la puissance d'écriture des règles via les alias, des multiples fonctions vpn incluses, ... La supériorité de pfSense est due à sa souplesse. Mais il faut avoir compris qu'on filtre par interface d'arrivée.
-
"WAN" pourrait être stable en statique et non en DHCP dans ce schéma de test.
J'ai déjà tester ce cas, sans succès, au lieu de faire un dhclient, il suffit de désactiver puis réactiver l'interface WAN pour que ca refonctionne … 30sec.
Une telle migration ne peut/doit se faire qu'en 2 temps :
…
La supériorité de pfSense est due à sa souplesse. Mais il faut avoir compris qu'on filtre par interface d'arrivée.
PLe but des tests est justement d'être sur que les nouvelles fonctionnalités soient correctement gérer avec les fonctionnalités existantes. Après la réussite de ceux-ci, je mettrais en place la configuration par allias pour avoir une migration "très" rapide.
-
"WAN" pourrait être stable en statique et non en DHCP dans ce schéma de test.
J'ai déjà tester ce cas, sans succès, au lieu de faire un dhclient, il suffit de désactiver puis réactiver l'interface WAN pour que ca refonctionne … 30sec.
- Et d'intervertir les interfaces entre elles? WAN deviens SDSL et SDSL deviens WAN.
- changer de carte reseau,
- de port PCI,
- …
-
Une config d'interface en ip statique qui tombe toutes les 30 sec ?
=> le problème n'est pas dans pfSense, il est forcément ailleurs !
De toute façon, le problème est sûrement plus complexe que vous le présentez : plus de réseaux, des vlans, … ?
Quand on réalise des tests, il est impératif, à un moment, de cesser de croire à certains acquis : un dhcp qui fournit correctement une adresse à partir d'une adresse mac peut très bien se mettre à délirer ...
Et puis en dhcp, il FAUT regarder les baux : certains serveurs sont configurés pour des baux TROP courts.
(Il y a eu une époque où les Freeboites fournissaient des baux de 60 secondes !!).
Ce problème est GRAVE : il faut TOUT regarder, y compris les câbles, les switchs, les cartes réseaux, ...
Attention à la méthodologie des tests : pas 3 modifs à la fois : comment sait-on lequel bloque ?NB : j'ai cru que pfSense 2.0 Beta 4 supportait correctement des cartes Broadcom 5716 (des serveurs DELL récents) : et beh non, une carte Intel quad port et ça roule mieux ...
Les alias en 2me étapes ?
=> Il est possible que vous ne compreniez pas à quoi servent les Alias : c'est ABSOLUMENT indispensable d'utiliser le maximum d'Alias dans l'écriture des règles de filtrage.
Je ne vois même pas comment m'en passer : exemple : un alias 'srvdns' est défini pour un serveur dns, une règle pourra alors utiliser 'srvdns' pour autoriser un trafic sur udp/53, puis s'il y a un autre serveur, il suffit de modifier l'alias !
Les Alias ne sont pas une étape de config, c'est la base sur laquelle on s'appuie (en normant les noms d'Alias). -
- Et d'intervertir les interfaces entre elles? WAN deviens SDSL et SDSL deviens WAN.
- changer de carte reseau,
- de port PCI,
Tester sans résultat.
De toute façon, le problème est sûrement plus complexe que vous le présentez : plus de réseaux, des vlans, … ?
Pour mes premiers tests, non, je suis aller au plus simple et j'utilise bien le schéma donné lors de mon premier post.
Quand on réalise des tests, il est impératif, à un moment, de cesser de croire à certains acquis : un dhcp qui fournit correctement une adresse à partir d'une adresse mac peut très bien se mettre à délirer …
On est bien d'accord, cependant je n'ai jamais vu un DHCP merdé sur un seul poste et pas sur les autres.
Et puis en dhcp, il FAUT regarder les baux : certains serveurs sont configurés pour des baux TROP courts.
(Il y a eu une époque où les Freeboites fournissaient des baux de 60 secondes !!).Le baux DHCP d'IPCop est réglé à 1800sec.
Ce problème est GRAVE : il faut TOUT regarder, y compris les câbles, les switchs, les cartes réseaux, …
J'ai déjà regardé toute la partie physique sans trouvé de cause. J'ai l'habitude face à ce genre de situation de remonter un à un les couches du modèle OSI: physique, liaison …
Attention à la méthodologie des tests : pas 3 modifs à la fois : comment sait-on lequel bloque ?
Je teste bien mes modifications une par une, jamais plusieurs modifications à la fois.
=> Il est possible que vous ne compreniez pas à quoi servent les Alias : c'est ABSOLUMENT indispensable d'utiliser le maximum d'Alias dans l'écriture des règles de filtrage.
On est aussi tout à fait d'accord.
Pour information, j'ai renoncé à régler ce problème, vu que la liaison ADSL sera configuré au final en PPOE et plus en DHCP derrière un IPCop comme c'est le cas actuellement. J'ai testé cette liaison en PPOE et PFSense est opérationnel.