Messages

Re,

J'ai finalement trouvé la solution à mon problème, qui venait du vRack OVH.

Le souci provenait de l'option "port security", activée par défaut sur les interfaces réseau du vRack. OVH applique alors des règles anti-spoofing qui peuvent bloquer certaines communications réseau — notamment si vous utilisez du routage ou des ponts (ce qui était mon cas).

En théorie, il suffit de désactiver l'option "port security" sur l'interface LAN d'OPNSense. Dans le doute j'ai désactivé l'option aussi sur le serveur Rocky.

Cependant, le bouton prévu à cet effet dans l'interface OpenStack d'OVH semble ne pas fonctionner. Il faut donc passer par la CLI OpenStack pour effectuer les modifications :

# Supprime les "security groups" associés au port
openstack port set --no-security-group <port_id>

# Désactive l'option "port security" sur le port
openstack port set --disable-port-security <port_id>

Après avoir appliqué ces deux commandes, le ping vers 8.8.8.8 fonctionne, et la résolution DNS également.

En espérant que cela pourra aider d'autres personnes confrontées au même problème !

[25.1.11]

Bonjour,

Pour le contexte, je rencontre un problème de connexion du réseau LAN vers Internet via OPNsense, déployé sur des instances Public Cloud OVH.

La version d'OPNsense utilisée est : 25.1.11

Le schéma réseau est le suivant :

                                INTERNET
                                      |
                                      |
                      [WAN] 141.95.174.9
                            +-----------+
                            |  OPNsense |
                            +-----------+
                      [LAN] 172.8.0.1 (Passerelle)
                                      |
                                      |
                          +---------------+
                          | Serveur_Rocky |
                          |  IP: 172.8.0.244 |
                          +---------------+

Le réseau OVH utilisé est un réseau vRack ( Le terme désactivé concerne le DHCP du vRack):

You cannot view this attachment.

Les interfaces sont configurées comme suit :

You cannot view this attachment.

Les Règles du pare-feu sont les suivantes :

WAN : in IPv4 *  *  *  *  *  *  *
      out IPv4 *  *  *  *  *  *  *

LAN : in IPv4 *  *  *  *  *  *  *
      out IPv4 *  *  *  *  *  *  *

Le Outbound NAT est configuré en mode "Hybrid outbound NAT rule generation".

Je teste la connectivité via ICMP (j'ai aussi testé en TCP avec curl, et dans les états, je vois un CLOSED:SYN_SENT).

WAN adresse <-> 8.8.8.8 : OK
LAN adresse <-> Serveur Rocky : OK

Dans le Live View, je vois bien le NAT s'effectuer :

You cannot view this attachment.

Pour aller plus loin, j'ai réalisé une capture de flux sur les interfaces LAN (vtnet1) et WAN (vtnet0) :

You cannot view this attachment.

Ce que je constate :

    Le trafic sortant est bien visible :
    Serveur_Rocky → OPNsense (WAN) → 8.8.8.8

    En revanche, le retour semble bloqué quelque part :
    8.8.8.8 → OPNsense (WAN) → ??? → Le serveur ne reçoit rien

Si quelqu'un a déjà rencontré ce genre de problème ou a une idée d'où cela pourrait venir, je suis preneur de toute aide 🙏


NB :

J'ai déjà testé en mode Outbound manuel, ainsi qu'en activant les options suivantes dans :

Firewall > Settings > Advanced :

    Reflection for port forwards

    Reflection for 1:1

    Automatic outbound NAT for Reflection

... mais sans succès.

Merci d'avance pour votre aide !