PfSense 2.3 en VM Xen - Autre VM Xen Accès Internet ICMP OK - Pas en TCP ni UDP
-
Bonjour,
j'ai installé PfSense 2.3 sur un Linux Alpine en VM Xen dans une appliance Beronet 2.0 PfSense est le routeur FW et dispose d'une interface pour le WAN une seconde pour le LAN. Une seconde VM est configurée, le PfSense étant sa GW. Dans le même temps, un PC est connecté au réseau local géré par ce même PfSense.
La VM Router/FW n'a aucun problème pour sortir sur Internet, le PC sur le LAN PfSense non plus. Parcontre, la seconde VM ne peut sortir qu'en ICMP !
J'ai modifié le réseau de l'Appliance en connectant son port WAN non pas à Internet mais à un réseau local qui fait office d'Internet en autorisant les réseaux privés sur le port WAN du PfSense. Le résultat est le même, le Routeur/FW et le PC peuvent sortir alors que neni pour la VM.
C'est alors que j'ai fait une capture pcap des trames sortantes de la passerelle du réseau faisont office dÍnternet et ai découvert que les paquets venant du PfSense ayant pour origine la VM n'était pas masqueradés par la passerelle et quittait donc le réseau avec comme IP source la WAN du PfSense ! Pas étonnant qu'il n'y ai pas de réponse.
J'ai alors installé une 3ème VM avec zeroshell comme distribution afin de remplacer le PfSense et vérifier l'origine du problème: effectivement, tout rentre dans l'ordre, la VM sort.
En fouillant sur le net je suis tombé sur https://forum.pfsense.org/index.php?topic=88467.0 mais cela n'a aidé en rien.
Il est à noter que les paquets sortants du PfSense sont bien masqueradés car le problème disparait lorsque la VM en erreur tente de se connecter à des machines du réseau privé faisant office d'Internet.
Si quelqu'un a une idée d'ou peut venir le problème et veut partager, qu'il en soit remercié :-)
Daniel
-
Merci d'utiliser le formulaire (A LIRE EN PREMIER) et notamment fournir un schéma avec adressages, les choix en matière de réseau concernant la virtualisation, les règles configurées…
NB : La virtualisation peut compliquer la perception des phénomènes ...Incompréhensible donc pas de réponse ...
NB : le flux sortant (par WAN) d'un firewall pfSense est logiquement masqueradé = ip source = ip WAN, par défaut.
-
Désolé si la description est incompréhensible. Voici le schéma
1er test
Internet <-> VM PfSense WAN (IP publique) <-> PfSense LAN 192.168.2.101 <-> VM #2 192.168.2.210 ;cette VM est celle en défaut.
Second test:
Internet <-> Router/FW WAN (IP publique) <-> LAN #1 192.168.10.1 <> VM PfSense WAN 192.168.10.78 <-> PfSense LAN #2 192.168.2.101 <-> VM #2 192.168.2.210
Dans ce second cas je peux analyser le traffic sortant sur Internet à partir du Routeur/FW du LAN #1. C'est à ce moment que j'ai découvert que les paquets partant sur Internet avaient toujours comme IP source 192.168.10.78, donc même le Routeur/FW du réseau 192.168.10.0/24 ne masquerade pas les paquets venant du PfSense.
Si dans ces deux configurations je remplace 1 pour 1 la VM PfSense par une VM zeronet, tout fonctionne. Je suppute fortement un problème PfSense/Xen
J'espère que c'est plus clair :)
Daniel
-
J'espère que c'est plus clair
Beh non ! Le formulaire donne des idées pour aider à présenter un problème, et j'ai listé 3 infos qui me semblent très minimales. Par ailleurs, je ne dois pas être seul à ne pas connaitre Beronet … (j'assimile ce beronet à un serveur xen à plusieurs interfaces physiques mais j'ignore les définitions d'interface et donc liens entre VM.)
C'est à ce moment que j'ai découvert que …
Ce que vous découvrez est le fonctionnement (parfaitement) 'normal' d'un firewall : le flux sortant par WAN utilise (forcément) l'ip source de WAN, et ce doit être aussi le cas de zeroshell.
Dans le même temps, un PC est connecté au réseau local géré par ce même PfSense.
Je ne vois pas ce PC sur vos schémas, mais je suppose qu'il se positionnerait comme VM #2 (et via une interface physique spécifique).
Si ce PC fonctionne correctement (et donc via pfSense), pourquoi incriminer pfFense et non une mauvaise config de VM #2 ?
NB : les adresses ip induisent des 'zones' mais il faut surtout que les interfaces soit réellement/virtuellement reliées, et c'est souvent ce qui n'est pas sûr avec la virtualisation (et dont nous n'avons aucune info/certitude).
La méthode usuelle de test est le test des 3 ping :
- ping de l'ip de la gateway
- ping de 8.8.8.8
- ping de google.fr
Quels sont les résultats pour chaque machine (pfSense, vm #2, et pc) ?
-
Par ailleurs, je ne dois pas être seul à ne pas connaitre Beronet … (j'assimile ce beronet à un serveur xen à plusieurs interfaces physiques mais j'ignore les définitions d'interface et donc liens entre VM.)
Dans mon message d'origine je précise qu'il s'agit d'une appliance qui tourne sous Linux Alpine et qui embarque Xen
Ce que vous découvrez est le fonctionnement (parfaitement) 'normal' d'un firewall : le flux sortant par WAN utilise (forcément) l'ip source de WAN
Dans mon second message je précise que les paquets sortent vers Internet avec l'IP source d'un réseau privé, la 192.168.10.78 du PfSense et non celle de l'interface WAN (IP publique du Routeur/FW du LAN #1), c'est bien là le problème!
Je ne vois pas ce PC sur vos schémas, mais je suppose qu'il se positionnerait comme VM #2 (et via une interface physique spécifique).
Je précise: les liens xDSL entrent dans un serveur sur lequel tourne Sophos UTM en VM (Routeur/FW du LAN#1). Il s'agit d'une Debian avec KVM. Deux VLAN 1001 et 1002 sont dédiés respectivement aux liens #1 et #2. Je peux donc vérifier le traffic sortant vers Internet à partir de cette Debian en capturant les paquets des VLAN
Si ce PC fonctionne correctement (et donc via pfSense)
Comme dit plus haut, ce n'est pas du PfSense, Sophos UTM
La méthode usuelle de test est le test des 3 ping :
- ping de l'ip de la gateway
- ping de 8.8.8.8
- ping de google.fr
Quels sont les résultats pour chaque machine (pfSense, vm #2, et pc) ?
Comme précisé dans mon message d'origine -et voir le titre de ce thread ;-)- l'ICMP passe, pas le TCP ni l'UDP.
Pourquoi je pense à un problème PfSense sur Xen ?
- avec zeroshell cela fonctionne
- avec UTM Sophos cela fonctionne
- un PC connecté au réseau local #2 (celui géré par le PfSense) fonctionne
- vu le problème de PfSense 2.2 sur Xen (voir le lien donné dans le message d'origine) et dont j'ai tenté les solutions sans résultat probant
En court: uniquement les VM derrière le PfSense ne fonctionnent pas. C'est la que je me dis que …
Daniel
-
Problème résolu. Il s'agit bien du bug https://forum.pfsense.org/index.php?topic=88467.0 qui est toujours présent en version 2.3.1_1 (j'avais du ne pas être concentré lorsque j'avais tenté la manipulation hier :-))
Résolution:
- dans l'hyperviseur 'sudo ethtool -K vifxx tx off' ou vifxx est l'interface WAN du PfSense (à refaire à chaque redémarrage du host si pas dans un script ou conf Xen)
- dans PfSense désactiver (cocher) dans System -> Advanced -> Networking (tab) "Disable hardware checksum offload"
IMPORTANT: redémarrer la VM PfSense
Merci pour votre support
Daniel
-
Bonjour,
- dans PfSense désactiver (cocher) dans System -> Advanced -> Networking (tab) "Disable hardware checksum offload"
Cela est écris dans la doc de pF, à faire quelque soit l'hyperviseur utilisé ;)
Cdt
-
Il y a un sérieux problème d'explication/compréhension :
Par ailleurs, je ne dois pas être seul à ne pas connaitre Beronet … (j'assimile ce beronet à un serveur xen à plusieurs interfaces physiques mais j'ignore les définitions d'interface et donc liens entre VM.)
Dans mon message d'origine je précise qu'il s'agit d'une appliance qui tourne sous Linux Alpine et qui embarque Xen
Je fais donc une assimilation correcte : le lecteur qui recherche 'Beronet', qui tombe sur une appliance hardware, ne se représente pas instantanément un serveur Xen !
Ce que vous découvrez est le fonctionnement (parfaitement) 'normal' d'un firewall : le flux sortant par WAN utilise (forcément) l'ip source de WAN.
Dans mon second message je précise que les paquets sortent vers Internet avec l'IP source d'un réseau privé, la 192.168.10.78 du PfSense et non celle de l'interface WAN (IP publique du Routeur/FW du LAN #1), c'est bien là le problème!
Désolé, les flux sortants de pfSense DOIVENT sortir et SORTENT avec l'ip WAN de pfSense, c'est une certitude ! Dans le schéma 2, vous indiquez 192.168.10.78 pour WAN, ils sortent avec cette ip; et Il ne peut y avoir d'accès Internet avec une ip privée (regardez le schéma 2 : vous placez le firewall entre Internet et WAN, donc le WAN est le LAN du firewall !
Je ne vois pas ce PC sur vos schémas, mais je suppose qu'il se positionnerait comme VM #2 (et via une interface physique spécifique).
Si ce PC fonctionne correctement (et donc via pfSense)Je précise: les liens xDSL entrent dans un serveur sur lequel tourne Sophos UTM en VM (Routeur/FW du LAN#1). Il s'agit d'une Debian avec KVM. Deux VLAN 1001 et 1002 sont dédiés respectivement aux liens #1 et #2. Je peux donc vérifier le traffic sortant vers Internet à partir de cette Debian en capturant les paquets des VLAN
Comme dit plus haut, ce n'est pas du PfSense, Sophos UTM
Vos explications indiquent que le PC, non rappelé dans le schéma est situé côté LAN de pfSense : il DOIT traverser pfSense avant d'aller vers Internet. Dans les 2 réponses, on comprend que le PC est en fait une Debian virtualisée placé avant ou après pfSense, ce qui ne correspond pas à l'explication initiale 'Dans le même temps, un PC est connecté au réseau local géré par ce même PfSense.'.
Il est très difficile de comprendre votre problème car vous n'avez pas compris ma demande 'les choix en matière de réseau concernant la virtualisation'.
Etant devant votre installation, il est nécessaire de vous relire car les lecteurs ne sont pas devant, et ne peuvent deviner vos réglages et le schéma !Clairement, ce qu'on comprend, en final,
- Xen (ou KVM), par défaut, active une option 'tcp checksum offloading' qui joue un rôle important dans le cadre de la virtualisation, spécifiquement avec les drivers 'VirtIO' (sensés être les plus performants).
- l'explication du fil indiqué est particulièrement explicative du problème et donc de la solution.
NB : à OFF dans ESXi 5.5 et 6.0
Le mécanisme de 'tcp checksum offloading' est connu, notamment soit par du hardware soit par des réglages bios. Il est sage, quand on balaye une installation de mettre ce genre de mécanisme à OFF …
De plus pfSense sait aussi s'y adapter ...Une fois de plus, on voit la pertinence à utiliser un formulaire dans lequel on fournit dès le départ des informations plus complètes ...
Je ne répondrai pas à une demande aussi incomplète ...