Clients OpenVPN ne peuvent pas joindre les clients LAN, et vice versa.
-
Je fais tourner pfSense dans une virtualbox, sur une machine windows. Cette machine windows est connectée a mon réseau wifi. J'ai configué pfSense en suivant ce tutoriel:
http://resources.infosecinstitute.com/setting-up-a-vpn-based-penetration-testing-lab/Mon but est de créer un environement de pentest. J'ai donc d'autres machines virtuelles (windows xp, windows 7, metasploitable, etc) qui tournent sur mon PC, leur carte réseaux configurées sur "réseau interne", comme le dit le tutoriel. Avec un autre ordinateur, je peux me connecter a pfSense par OpenVPN, tout marche niquel, l'IP est correctement assignée, j'ai accès a internet. Pareil pour les machines virtuelles. Les machines virtuelles peuvent communiquer entre elles, j'ai essayé de ping l'une avec l'autre, ça marche. Mais mon ordi extérieur, connecté par OpenVPN, ne peux que joindre la machine pfSense, pas les machines virtuelles connectées en LAN, et pareil dans l'autre sens. Comment je peux résoudre ça?
-
Comment je peux résoudre ça?
En expliquant ce que tu as configuré ;)
Je ne suis pas allé voir le tuto que tu as suivi (j'avoue) mais si ton client se connecte correctement au serveur VPN, ce n'est peut-être qu'une simple question de FW sur l'interface OpenVPN.
en revanche, avant que les machines sur le LAN se connectent à ton client OpenVPN, il va falloir travailler un peu car en mode client-serveur, il n'y a pas de route qui annonce, coté pfSense, la direction du client. Mais quel est l'intérêt ici ?
-
Comment je peux résoudre ça?
En expliquant ce que tu as configuré ;)
Je ne suis pas allé voir le tuto que tu as suivi (j'avoue) mais si ton client se connecte correctement au serveur VPN, ce n'est peut-être qu'une simple question de FW sur l'interface OpenVPN.
en revanche, avant que les machines sur le LAN se connectent à ton client OpenVPN, il va falloir travailler un peu car en mode client-serveur, il n'y a pas de route qui annonce, coté pfSense, la direction du client. Mais quel est l'intérêt ici ?
L'intéret est de créer un environnement de test de pénétration légal, donc sans connection avec les cibles, c'est difficile de les hacker haha.
Je suis nouveau à pfSense, tout ça est plutôt flou pour moi.
Tu as des informations précises à demander sur ma configuration? Je sais pas vraiment quoi te serais utile…
C'est surement une question de pare feu oui, mais je comprends pas vraiment laquelle, j'ai essayé de tout paramétrer de manière a autoriser le plus de choses possibles, mais toujours rien... Le plus bizarre c'est qu'ils en parent pas une seconde dans le tuto.. -
L'intéret est de créer un environnement de test de pénétration légal, donc sans connection avec les cibles, c'est difficile de les hacker haha.
Oops, non mas question n'est pas "quel est l'intérêt d'un pentest ?"
mais plutôt
"quel est l'intérêt de vouloir joindre depuis le LAN un client qui se connecte en VPN dans un mode client-serveur ?"Coté pentest, je vois bien l'intérêt :P
quelles sont tes règles de FW sur l'interface OpenVPN ?
Quid du log du FW ? -
Eh bien, l'intérêt de ce labo, c'est de pouvoir y accéder à en WAN en fait. Si je voulais me faire un labo perso j'aurais pu juste installer une VM Kali Linux et la connecter au réseau interne. Mais le but la est que mes amis puissent se connecter à ce réseau aussi, pour pouvoir faire comme une compétition ^^. Celui qui compromet toutes les machines en premier gagne :3, bien sûr en se désavantageant mutuellement c: .
Donc voilà, mes amis et moi somment les clients OpenVPN (les attaquants) et les machines en LAN sont les cibles à attaquer. Donc pour pouvoir les exploiter, il faut bien pouvoir les atteindre avant ^^. Et il faut bien que le LAN puisse communiquer avec nous aussi, dans le cas où l'on utilise des virus à connexion inversée (qui est exécutée sur la cible et se connecte à l'attaquant (je précise juste au cas où ^^))
Enfin bref mon but c'est qu'au niveau du réseau, les clients OpenVPN se comportent comme n'importe quelle autre machine en LAN, donc qui puisse être contacté par tout le monde, et qui peut contacter tout le monde.Niveau config du FW etc je te dirais demain, j'ai pas accès à mon ordi la tout de suite. Merci beaucoup pour ta réponse en tout cas ^^
-
Décidément, tu te focalises sur l'explication de ce qu'est le pentest sans expliquer plus en détail l'intérêt qu'à une machine du LAN à se connecter à un client OpenVPN.
Ma manière de formler la quesiton ne doit pas être claire.Tu sembles en plus mélanger allègrement le fait que tu arrives, d'un point de vue FW, via OpenVPN avec l'idée que vous arriveriez du WAN.
C'est pour pfsense totalement différent.Mais je commence cependant à comprendre ce que tu vises, je pense.
Et donc l'objectif n'est pas que les machines du LAN sachent trouver une route vers des clients OpenVPN mais que les clients OpenVPN accèdent au LAN (c'est le service standard de ce genre de configuration) mais en plus se voient entre eux.As-tu seulement remarqué, dans la configuration du serveur OpenVPN, dans la section "tunnel settings", l'option qui dit:
Inter-client communication: Allow communication between clients connected to this serverça devrait répondre à ton besoin non ?
-
Effectivement, j'ai vu cette option, je me suis dit "Aaah, bah voilà où était le problème !", je l'ai cochée, redémarré pfSense… Mais ça ne change rien... Le ping ne répond toujours pas, dans un sens comme dans l'autre...
Et effectivement, c'est ce dont j'ai besoin, que les clients OpenVPN puissent accéder au LAN et se voir entre eux... Mais j'ai besoin que ça marche dans les deux sens. Qu'une machine en LAN puissent également joindre un client OpenVPN.
Parce que si, je te l'ai expliqué en détail ^^. J'ai besoin que le LAN puisse également joindre les clients OpenVPN, car certaines attaques le nécessitent, c'est tout, pas de raison particulière en plus...Tu sembles en plus mélanger allègrement le fait que tu arrives, d'un point de vue FW, via OpenVPN avec l'idée que vous arriveriez du WAN.
C'est pour pfsense totalement différent.Ah, alors pour ça… Aucune idée ^^... Pour moi à partir du moment où on fait pas partie du LAN interne, alors on arrive du WAN... C'est pas le cas? C'est confus dans ma tête ^^"
-
Mauvaise compréhension du fonctionnement de OpenVPN, AMHA, ce qui explique ta demande.
Dans un mode client-serveur, se connecter en OpenVPN à un LAN distant ne change pas l'adresse IP du client. Celui-ci accède au LAN, mais il n'en fait absolument pas partie ;)
Hormis le fait que la communication entre le client et le serveur se fait dans un tunnel encrypté, tout est histoire de règles de FW et de route.Ton client n'a pas une adresse IP sur le LAN. la machine du LAN ne connait pas son adresse IP. D'où ma question
"quel est l'intérêt pour une machine du LAN de se connecter à un client OpenVPN dont elle ne connait pas l'adresse IP et dont elle ne sait même pas si ce client est connecté ?"Seul le serveur OpenVPN (en l’occurrence pfSense) sait quel client est connecté et quelle est sont adresse IP, et encore, dans ce cas, si le client se pointe via, par exemple, un lien ADSL, le serveur OpenVPN connait l'IP publique du client.
Est-ce que OpenVPN est la bonne solution ?
As-tu réfléchi au type de VPN en fonction de l'usage ?
IPsec peut-être…? 8)Je peux me tromper mais il me semble essentiel de bien maitriser cet aspect avant de se lancer dans le pentest. Car dans tous les cas, tu auras besoin en plus de gérer des règles de FW, donc de comprendre se qui se passe et de quoi tu as besoin en terme de flux.
Un petit point supplémentaire: il n'est pas nécessaire, et fort heureusement, de redémarrer pfSense à chaque fois que tu modifies les caractéristiques d'un service. Ce n'est pas Windows ;D ;D ;D
-
I think you should try to set up firewall rule to allow traffic from the external computer on your LAN virtual clients.Hope that will work
Also as you are setting up this environment for the pentesting i would like you to introduce one platform which is offering training courses on Network Penetration testing, Web App penetration testing, malware analysis and many more at very minimal cost on Infosecaddicts.
please do visit us.
Thanks -
1. This is not a place for advertising.
2. Maybe you can consider a clean setup of your server at infosecaddicts.com. Http links in an https session is not really a good practice.