Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    echec vpn / routage assymetrique

    Français
    2
    16
    2.0k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      adhame95
      last edited by adhame95

      Bonjour
      j'ai un problème avec le vpn, je n'arrive pas a accéder a certaines machines du réseau local (par ex elles repondent pas au ping mais un serveur web fonctionne et je n'ai pas accès au nas synology)
      j'ai vu que cela pouvait être du au routage asymétrique.

      https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html
      ce document explique 2 methode
      l'automatique n'a pas fonctionée et je ne trouve pas l'option manuelle sur mon pfsense
      pouvez vous m'aider Merci !
      pfsense.png

      1 Reply Last reply Reply Quote 0
      • J
        jdh
        last edited by jdh

        Voilà des hypothèses ! Et vous semblez suivre celles-ci, mais sont elles des bonnes pistes ? A priori vous ne le savez pas ...

        Commencez donc par décrire votre contexte (à l'aide de A LIRE EN PREMIER). (Ne soyez pas timide : décrivez le maximum de choses, ne vous restreignez pas !)

        Parce qu'actuellement il n'y a aucune info utile pour vous dire quoi que ce soit d'autres !

        NB : si vous n'avez qu'une seule machine qui est l'intermédiaire avec Internet, il ne saurait y avoir de routage asymétrique ! Votre schéma doit faire apparaitre 2 firewall ou routeurs ...

        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

        A 2 Replies Last reply Reply Quote 0
        • A
          adhame95
          last edited by

          This post is deleted!
          1 Reply Last reply Reply Quote 0
          • A
            adhame95 @jdh
            last edited by

            This post is deleted!
            1 Reply Last reply Reply Quote 0
            • A
              adhame95 @jdh
              last edited by adhame95

              @jdh Bonjour
              voici la composition du reseau

              box operateur 192.168.0.0/24
              UNIFI dream machine pro qui possede actuellement 3 lan
              pf sense sur un esxi
              wan du pfsense qui est connecte au lan du unifi en 192.168.1.0/24
              lan du pf sense en 192.168.42.0/24
              depuis le vpn j'arrive a me connecter sur un serveur web de test d'un des pc sur le lan mais il ne reponds pas au ping
              j'arrive a faire des requetes dns sur le serveur windows server egalement connecté au lan, mais je n'arrive pas a acceder au nas synology (c'est ce point precis le plus handicapant)reseau.png firewall wan.png firewall vpn.png firewall lan.png

              1 Reply Last reply Reply Quote 0
              • J
                jdh
                last edited by

                (Ca n'est pas très précis, et c'est dommage car plus vous serez précis plus vous pourrez maitriser ce qui se passe ...)

                Premier point : il n'y a aucune raison d'avoir un problème de routage asymétrique puisque vous avez des réseaux définis avec UNE et UNE SEULE gateway.

                Deuxième point : en sus de la box, vous avez 2 firewall successifs (chacun effectuant du NAT) : c'est un problème MAJEUR pour bien maîtriser !

                Cet empilement box + 2 firewalls implique 3 emplacements pour créer une règle d'accès : ce ne simplifie pas la gestion ou la configuration !

                Sauf à avoir des matériels UNIFY à piloter, vous gagneriez à utiliser juste pfSense (avec suffisamment d'interfaces ethernet probablement). Avec cet unique pfSense, vous n'auriez plus que cet endroit pour contrôler les flux entre réseaux et entre les réseaux et Internet, sous réserver d'avoir une règle de 'DMZ' au niveau de la box = tous ports en tcp et udp redirigés vers le WAN de pfSense.

                Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                1 Reply Last reply Reply Quote 0
                • J
                  jdh
                  last edited by jdh

                  Vous fournissez des images, c'est bien. Bien les cadrer, serait mieux ! Elles ne sont pas faciles à lire ...

                  Pourquoi 2 lignes identiques dans Rules > WAN ?

                  Je n'écris aucune règle sans préciser : dans Rules > WAN, vous pouvez écrire des règles avec des alias pour Source et Destination puisque c'est connu !

                  Dans Rules > LAN, on peut laisser la règle par défaut, mais il vaut bien mieux écrire des règles précises.

                  Je ne pense pas que, avec des règles 'open bar', on peut bien comprendre les choses. Il faut, au contraire, écrire des règles idoines, activer le log, et vérifier ce qui se passe dans les logs, et identifier quelles règles s'activent ...

                  Un situation de routage asymétrique est lié à un réseau avec 2 accès Internet : si un paquet arrive d'un firewall vers un serveur, ce serveur doit répondre en passant par le même firewall. Ce ne doit pas être votre cas

                  Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                  1 Reply Last reply Reply Quote 0
                  • A
                    adhame95
                    last edited by

                    Nous avons 2 NAT pour des raisons de sécurité, le unify gère une dmz séparée du reste des machines de l'entreprise. Si nous utilisons uniquement le pfsense, la dmz ne sera plus isolée et protégée par le NAT.

                    En effet, il y avait 2 règles similaires crées par le wizard open vpn, je les ai supprimées
                    je me sers des règles par défaut car c'est plus simple a gérer pour les tests, une fois que tout sera en prod, on utilisera des règles spécifiques.

                    De plus, le souci semble venir du pfsense car le traffic ne transite pas par le unifi (c'est le pfsense qui gère le vpn ainsi que le réseau local auquel je n'ai pas totalement accès).

                    si cela ne vient pas du routage asymétrique, selon vous pourquoi je n'arrive pas à accéder au lan depuis le vpn ?

                    J 1 Reply Last reply Reply Quote 0
                    • J
                      jdh @adhame95
                      last edited by jdh

                      @adhame95 said in echec vpn / routage assymetrique:

                      Si nous utilisons uniquement le pfsense, la dmz ne sera plus isolée et protégée par le NAT

                      Non. Ce boitier et pfSense sont des firewall : ils sont 'sui generi' fonctionnellement équivalents !
                      Avec suffisamment d'interface ethernet, vous pouvez parfaitement n'avoir qu'un seul et unique firewall. A priori, je fais plus confiance à un administrateur expérimenté avec le firewall qu'il maitrise, à un schéma à 2 firewall différents avec une expérience moyenne sur les 2 ! L'idée de placer 2 firewall différents pour augmenter la sécurité s'oppose à l'expertise nécessaire sur 2 firewalls. (C'est comme l'idée d'avoir sur les serveurs un autre antivirus que celui des postes, ça n'a jamais fait la preuve d'apporter plus de sécurité ...)

                      Je persiste pour que vous écriviez 2 règles précises :

                      • dans Rules > LAN : de LAN net vers OpenVPN net
                      • dans Rules > OpenVpn : de OpenVPN net vers LAN net

                      Des règles avec * dans Source et Destination ne sont pas acceptables.

                      Enfin les machines situées dans le LAN ont elles TOUT ce qu'il faut : adresse ip, masque, passerelle : c'est la base.

                      Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                      A 1 Reply Last reply Reply Quote 0
                      • A
                        adhame95 @jdh
                        last edited by

                        This post is deleted!
                        1 Reply Last reply Reply Quote 0
                        • A
                          adhame95
                          last edited by

                          @jdh Je ne suis pas d'accord avec les éléments que vous avancez.
                          prenons un exemple avec un firewall (cf première image), si l'on veut contacter un des serveurs dans la dmz depuis le lan :
                          le pc va envoyer la requête au serveur (tcp syn sur le port 80, pour HTTP) en passant par le firewall, si le firewall est configuré pour accepter le port 80 alors le paquet arrivera jusqu'au serveur.
                          mais on va se heurter au problème suivant : le serveur va répondre sur un port dynamique (et aléatoire) qui sera logiquement bloqué par le firewall.
                          Si on autorise la plage de port dynamique (entre 49152 et 65535) alors c'est une importante baisse de niveau de sécurité.
                          en cas de piratage du serveur, il pourrait attaquer notre lan.

                          dans le cas avec 2 firewalls (2eme image)
                          le pc (n°3 sur le schéma) va envoyer la requête au serveur (tcp syn sur le port 80) en passant par le firewall interne (pf sense n°2) qui va alors autoriser le serveur a répondre en tcp ack sur un port dynamique aléatoire.
                          en cas de piratage sur le serveur web (n°4) le pfsense protègera les machines sur le lan grâce au NAT, si le serveur initie une connexion tcp syn vers une machine elle sera bloquée.
                          simple_dmz_network_v2a.png

                          A 1 Reply Last reply Reply Quote 0
                          • A
                            adhame95 @adhame95
                            last edited by

                            @adhame95 Traditional_Single_Layer_DMZ_with_two_flanking_firewalls.png

                            1 Reply Last reply Reply Quote 0
                            • J
                              jdh
                              last edited by jdh

                              Votre conception du firewall date d'avant 2000 !

                              Au milieu des années 90, CheckPoint a innové avec le mode 'statefull'.
                              Sous Linux, c'était l'époque de 'Ipchains', et en français on parlait de 'bastion'.

                              Puis est arrivé Netfilter (intégré à Linux depuis 2.4) et PF/Packet Filter (dispo depuis OpenBSD 3.0) au début 2000.

                              Netfilter a appelé 'Connection Tracking' le mode 'Statefull' de CheckPoint. PF est dans la même lignée. (Je ne suis pas sûr que ce soit une invention de CheckPoint puisque Netfilter a été commencé en 1989 !)

                              Le mode 'Statefull' et le firewalling de Netfilter et PF, contrôle les 'sessions' (TCP) et plus les paquets un par un (aller et/ou retour) : il suffit d'autoriser ou interdire la session, symbolisée par le premier paquet qui en donne le sens, il n'y a pas besoin d'écrire de règle pour les paquets retour (pour cela, une seule règle suffit pour TOUTES les règles, elle n'est d'ailleurs pas décrite dans pfSense).

                              C'est au niveau du noyau que sont identifiés les paquets par rapport à une session : sous Linux, on parle de '--state NEW, RELATED, ESTABLISHED' : quand le 'state' est 'RELATED' ou 'ESTABLISHED', la paquet est automatiquement autorisé (si la session existe dans la table crée avec les 'state NEW autorisé'). La table de session avec ip source, ip destination, (port source + port destination) pour la machine source et la machine destination. De plus il y a, dans TCP, le n° de séquence qui peut aider à identifier si le paquet est RELATED/ESTABLISHED.

                              Votre exemple est d'ailleurs incorrect ('le serveur va répondre sur un port dynamique (et aléatoire)' : faux) : si le PC sur Internet (source) appelle votre serveur web (en DMZ), il le fait par exemple avec port source = 2345 et port destination = 80 (forcément), le paquet retour aura les ports inversés. (Je passe sur le changement d'adresse ip destination, dans le sens extérieur -> interne, qui passe à un changement d'adresse source, dans le sens inverse). Le firewall n'aura aucune difficulté à identifier un paquet retour faisant partie de la session.

                              (Toutefois, certains protocoles compliqués, comme FTP, peuvent avoir un changement de port ... mais il existe des 'helper' pour aider le firewall à traiter ces protocoles ... NB : le helper FTP est disable par défaut dans pfSense !)

                              Il faut que vous lisiez, même s'il s'agit de Linux / Netfilter, http://irp.nain-t.net/doku.php/130netfilter:start : la compréhension du mécanisme décrit par ses pages est essentielle !

                              Ce que vous décrivez est du firewalling 'ipchains', c'est dépassé ...

                              D'ailleurs, vous le voyez en configurant pfSense, on ne décrit que le premier paquet avec Accepté/Blocké.

                              Toutes les appliance de firewall (Fortinet, Stormshield, Watchguard, ...) utilise la même représentation ...

                              NB : j'ai eu la chance de travailler 2 jours en 2001 avec un développeur Debian qui m'a formé à Netfilter/Iptables pour créer un firewall très spécifique : c'était intense et très instructif, la dépense n'a pas été inutile. Après j'ai fait mes premiers scripts iptables, puis Shorewall, et j'ai décidé d'utiliser pfSense en refusant d'apprendre la syntaxe de pf afin de ne pas pouvoir faire autrement qu'avec l'interface. Dans l'entreprise où je travaille, chaque serveur Linux a ses propres script iptables : il y a 2 serveurs qui ont un script de plusieurs milliers de lignes ... Cela ne me pose aucun problème de lecture !

                              NB : Depuis déjà 2 versions Debian utilise nativement nftables, le remplacant de netfilter, et des 'wrapper' de traduction iptables vers nftables.

                              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                              A 2 Replies Last reply Reply Quote 0
                              • A
                                adhame95 @jdh
                                last edited by

                                This post is deleted!
                                1 Reply Last reply Reply Quote 0
                                • A
                                  adhame95 @jdh
                                  last edited by

                                  @jdh Bonjour, après des investigations il s'avère que le NAS était mal configuré, la passerelle par défaut n'a pas été changée.
                                  C'est pour cela que j'avais un message qui m'indiquait que la route n'était pas la bonne.

                                  J 1 Reply Last reply Reply Quote 0
                                  • J
                                    jdh @adhame95
                                    last edited by

                                    @adhame95 said in echec vpn / routage assymetrique:

                                    la passerelle par défaut n'a pas été changée

                                    Ouais ...
                                    En fait c'est parce que le pfSense a été ajouté (je présume), et que toutes les machines destinées à être derrière ce firewall supplémentaire n'ont pas été toutes ajustées en conséquence !

                                    Enfin un NAS propose en général un partage Windows = de type SMB. Ce type de partage n'est jamais proposé par firewall, par la difficulté du protocole (445/tcp puis 139/tcp ou udp plus ...). A ne jamais faire !

                                    D'ailleurs quand on cherche un peu autour de Synology, on aboutit à 'QuickConnect' qui est bati sur http/https, et qui donc peut bien être proposé par un firewall ('NAT Port Forward compatible' !).

                                    Bref, on est pas vraiment sur un projet bien préparé, ni avec l'expertise bien assurée ... Vous ferez des progrès ... Je vous ai expliqué des choses un peu nouvelles, sans doute, pour vous ...

                                    Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.