echec vpn / routage assymetrique
-
(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.
-
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
-
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 ?
-
@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.
-
This post is deleted! -
@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.
-
-
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.
-
This post is deleted! -
@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. -
@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 ...
