PfSense 2.0.1 virtualisé affectant la connectivité de l'hôte Hyper-V? arp?


8

La mise en place

J'ai configuré pfSense 2.0.1 (image 64 bits-amd) en tant qu'hôte dans Hyper-V. Comme décrit dans d'autres blogs, j'ai dû faire le "ifconfig down deX", "ifconfig up deX" pour que le réseau soit opérationnel.

Le serveur (HP exécutant Windows 2008 R2) est équipé de deux cartes réseau physiques.

  • Le premier NIC physique (port 1) n'est pas configuré dans l'hôte (uniquement en tant que commutateur Hyper-V, voir plus loin).

  • Le deuxième NIC physique (port 2) est configuré avec un réseau pour la gestion à distance (réseau standard de classe C). Je pense que les deux cartes réseau sont connectées au même commutateur et VLAN = par défaut (le câblage physique a été effectué par mon fournisseur de colocalisation).

Dans Hyper-V, les réseaux virtuels suivants sont définis:

  • internal : réseau interne de machine virtuelle utilisé pour la communication inter VM («LAN» connectant les serveurs Windows).

  • Internet : réseau virtuel utilisé comme connexion WAN pour pfSense. Ce réseau est affecté au premier NIC physique (port 1) du serveur. Le réseau virtuel est dédié à Hyper-V et n'est pas partagé avec l'hôte.

Dans ma configuration, j'utilise pfSense comme pare-feu face à Internet pour quelques machines virtuelles (serveurs Windows) fonctionnant également sur le même hôte Hyper-V.

Les boîtes Windows utilisent pfSense comme passerelle par défaut et j'ai réussi à télécharger les mises à jour Windows sur toutes les machines virtuelles via le pare-feu pfSense - en douceur.

Pour rediriger les services entrants, le pfSense est configuré avec 1-1 NAT pour mapper les adresses IP des FAI aux adresses 172.16.0.0/16 internes sur les boîtes Windows.

Le problème

Le problème que j'avais était qu'après avoir travaillé avec succès avec une connexion RDP sur le réseau de gestion (port 2), la connexion s'éteignait et toute la connectivité réseau était perdue pour le serveur et les machines virtuelles. Avant le problème, j'ai fait deux changements de configuration.

  1. Déplacement de l'adresse IP de gestion du port 1 vers le port 2. Cette modification a été vérifiée avec succès en reconnectant RDP une heure plus tard sur la nouvelle interface (port 2 comme décrit ci-dessus).

  2. A fait quelques configurations sur les IP virtuelles dans pfSense (nécessaires pour le NAT 1-1).

Quelques minutes plus tard, la connectivité à la machine a été perdue.

La chose qui me laisse perplexe est que la connexion réseau de gestion (port 2) est censée être intacte par Hyper-V car elle n'est pas intégrée à Hyper-V. Cependant, il semble y avoir une propagation d'erreur à partir de pfSense (en utilisant la carte réseau sur le port 1).

Plus tôt dans la journée, nous avons rencontré un problème similaire lors de l'utilisation d'une seule carte réseau (port 1 partagé entre Hyper-V / pfSense et l'hôte). Le problème que nous avons eu alors était que lorsque pfSense était arrêté, nous pouvions cingler l'hôte et quand il était redémarré, le ping cessait de fonctionner (pas de conflit IP ce que nous savons).

Le pfSense est installé à partir de l'ISO et «l'usurpation d'adresse MAC» est par défaut = désactivé.

Étant donné que le problème semble se propager entre les deux ports physiques, je suppose que cela pourrait avoir quelque chose à voir avec ARP ne fonctionnant pas correctement.

Tous les commentaires sur ce point sont très appréciés.

/ J


Vous avez fait un travail divin pour expliquer le problème. Mais vous ne dites pas quelles modifications vous avez apportées. Pouvez-vous répertorier les adresses IP réelles (ou obscurcies) utilisées comme IP virtuelle et de gestion et les modifications réelles apportées aux parties # 1 et # 2?
Andy Shinn

Déboguez-vous cela localement (même commutateur pour le serveur et votre client)? Je demande parce que vous pourriez supposer que pfSense / Hyper-V sont la source du problème alors qu'en fait, il pourrait y avoir un pare-feu / proxy expirant quelque part vos connexions avec état. Essayez d'être le plus près possible de cet hôte et laissez tcpdump et Wireshark s'exécuter respectivement sur pfSense et Windows, puis vérifiez ce qui se passe. De plus, puisque vous avez échangé les interfaces, vérifiez tout dans le commutateur virtuel d'Hyper-V.
Giovanni Tirloni

Avez-vous activé le mode promiscuité sur l'interface virtuelle? vous devrez l'activer pour les pare-feu: par défaut, la carte réseau virtuelle d'un système d'exploitation invité ne reçoit que les trames qui lui sont destinées. Placer la carte réseau de l'invité en mode promiscuous le fait recevoir toutes les trames passées sur le commutateur virtuel qui sont autorisées sous la stratégie VLAN pour le groupe de ports associé. Cela peut être utile pour la surveillance de la détection d'intrusions ou si un renifleur doit analyser tout le trafic sur le segment de réseau.
MrLightBulp

Réponses:


1

Avez-vous vérifié l'Observateur d'événements sur le W2008R2?

Peut être dû au nombre maximal de connexions TCP autorisées par Windows: https://technet.microsoft.com/en-us/library/cc759700%28WS.10%29.aspx

pfSense en tant que routeur logiciel utilise de nombreuses connexions qui peuvent être ouvertes mais pas fermées, en attente, etc. Ce type d'utilisation du réseau peut atteindre les limites par défaut de la pile TCP et les fenêtres pourraient se fermer ou ne pas autoriser plus de connexions de ce type. La première chose à faire dans ce cas est de vérifier l'Observateur d'événements pour voir si quelque chose y est signalé.


Pouvez-vous développer cette réponse?
BE77Y

pfSense en tant que routeur logiciel utilise de nombreuses connexions qui peuvent être ouvertes mais pas fermées, en attente, etc. Ce type d'utilisation du réseau peut atteindre les limites par défaut de la pile TCP et les fenêtres pourraient se fermer ou ne pas autoriser plus de connexions de ce type. La première chose à faire dans ce cas est de vérifier l'Observateur d'événements pour voir si quelque chose y est signalé.
NetVicious

Apprécié - mais ce serait très utile pour compléter votre réponse ci-dessus. :)
BE77Y

0

Cela ressemble plus à un problème de routage entre pfSense et les autres appareils ...

Si vous utilisez les machines virtuelles derrière le pFSense comme pare-feu, cependant vous en avez besoin sur un sous-réseau différent de celui des PC sur le réseau local. Vous devrez peut-être activer une interface supplémentaire sur pfSense (par exemple LAN2), puis mappez-la dans le VM Host à un VSwitch privé que les autres VM utilisent .. Ou même TAGUEZ le trafic dans le vSwitch et disposez d'un vlan séparé pour cela.

J'ai dû le faire plusieurs fois sur VMWare. Aussi pour votre 1: 1, vous devrez peut-être ajouter un mappage de route réseau statique pour ceux-ci comme exemple. J'ai vu pfSe nse obtenir son routage foiré.

De cette façon, vous avez ..

IINTERNET -> Wan0 -> pFSense -> PC LAN1 ..

                  pfSense -->LAN2 Virtual Machines.

Après cela, vous pouvez mieux contrôler les règles de routage et de pare-feu.

J'espère que cela vous aide, Cheers ...

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.