4. OpenVPN - Peer to Peer

OpenVPN - Peer to Peer

  • -

    Bonjour,

    Je rencontre des difficultés dans la configuration de mon tunnel VPN entre 2 sites.
    Mon tunnel se monte correctement, par contre je n'arrive pas connecter les machines des réseaux différents réseaux les unes avec les autres.

    Explications :

    VPN : PeerToPeer (SSL/TLS)

    –-- Site 1 - Server
    LAN : 172.16.1.254/24
    WAN : IP Public
    IP VPN : 10.0.10.1

    ---- pfSense - Site 2 : Client
    La WAN du site 2 est dans une DMZ, derrière un firewall.
    LAN : 192.168.10.10/23
    WAN : 192.168.40.200/24 (DMZ)
    IP VPN : 10.0.10.2
    ---- Firewall Site 2
    LAN : 192.168.40.254 (DMZ)
    WAN : IP Public

    ---- Les premiers tests :
    Le client pfsense fait un ping sur l'IP VPN du serveur (IP 10.0.10.1) ==> OK
    Le serveur pfsense fait un ping sur l'IP VPN du client (IP 10.0.10.2) ==> OK
    Le client pfsense fait un ping sur l'IP LAN du serveur (IP 172.16.1.254) ==> OK
    Le serveur pfsense fait un ping sur l'IP LAN du client (IP 192.168.10.10) ==> Erreur

    Merci d'avance pour l'aide que vous pourrez m'apporter.

    0
  • B

    Bonjour,

    1/ Vérifier que les routes qui vont bien ont bien été ajouter sur le poste client. On peut vérifier à la fin des logs sur le client mais aussi en affichant la table de routage locale.
    Il est fréquent que cela survienne car il faut des droits administrateur pour éditer la table de routage sur le client.

    2/ Sur le site 1, pf est-il la GW par défaut des postes du Lan ? Si plusieurs GW sur le site 1 cela peut être un problème de ''route retour'' , voir :
    => https://forum.pfsense.org/index.php?topic=117350.0

    3/ FW soft sur les postes du lan ?

    Cdt

    0
  • C

    La WAN du site 2 est dans une DMZ, derrière un firewall.

    Je ne comprend pas ce que cela signifie.
    Il est très probable que vos difficultés soient liées à une mauvaise configuration du routage. A titre personnel pour un VPN site à site, je préfère utiliser IPSec. Moyennant un routage correctement configuré tout cela est parfaitement neutre pour les utilisateurs. Ce qui ne signifie pas que votre solution ne finira pas par tomber en marche.
    Vérifiez aussi vos règles dans le tunnel.

    0
  • C

    @baalserv:

    1/ Vérifier que les routes qui vont bien ont bien été ajouter sur le poste client. On peut vérifier à la fin des logs sur le client mais aussi en affichant la table de routage locale.
    Il est fréquent que cela survienne car il faut des droits administrateur pour éditer la table de routage sur le client.

    A quel client fais-tu référence ?
    Nous sommes ici dans un mode peer-to-peer

    2/ Sur le site 1, pf est-il la GW par défaut des postes du Lan ? Si plusieurs GW sur le site 1 cela peut être un problème de ''route retour''

    Cette option me semble beaucoup plus probable.

    Il se peut également que le serveur VPN à une extrémité n'annonce pas bien sa route au serveur VPN de l'autre coté.
    Il faut donc vérifier les routes, comme tu le dis en "1", mais au niveau des serveurs VPN, AMHA

    0
  • -

    Ppur baalserv

    Voici les routes :

    Site 1 - Server

    Site 2 - Client

    Une machine du site 1

    Une machine du site 2

    Sur le site 1 je confirme bien que la GW est bien pf.
    Je n'ai qu'une seule GW.
    Il n'y a pas de FW soft sur les postes clients

    Pour ccnet :
    Ce que je veux dire c'est que pf est dans une DMZ derrière un FW. (1 port en DMZ / 1 port dans le LAN)

    0
  • C

    @-Sylvain-:

    Ce que je veux dire c'est que pf est dans une DMZ derrière un FW. (1 port en DMZ / 1 port dans le LAN)

    Vers le "LAN" qui est aussi le LAN du FW précédent ?
    Ce n'est pas très clair pour moi

    0
  • -

    Pour faciliter la compréhension de mon réseau

    0
  • C

    … un schéma serait le bienvenu
    j'intuite que tu as un pfSense derrière un autre FW (donc au final 2 FW en série) mais je n'en suis pas bien sûr, faute de schéma ou d’explication claire (ou alors je ne comprends pas)

    Si c'est bien le cas, quelles sont les règle sur le FW en frontal ?

    0
  • -

    Pour chris4916

    Tu ne vois pas mon schéma ?

    Oui j'ai 2 firewall en série.
    En quoi les règles du FW frontal impacte le tunnel VPN ?
    Concernant les regles du FW frontal

    Deny | DMZ ==> WAN | Any service
    Allow | DMZ ==> WAN | Port 1195(OpenVPN)

    Deny | WAN==> DMZ| Any service

    Veux tu des informations  sur les règles LAN <==> DMZ et/ou LAN <==> WAN ?

    0
  • C

    @-Sylvain-:

    Tu ne vois pas mon schéma ?

    non

    0
  • -

    Schema

    http://imgur.com/EVRVY3v

    0
  • C

    Dans ce que je vois (maintenant) de ton schéma et que je mets ça en regard de ta première explication, tu dis que pfSense sa propre interface LAN, c'est bien ça ???  :o
    J'avoue être un peu largué.
    Je vais essayer de relire tout ça.

    0
  • -

    Oui j'utilise 2 cartes 1 WAN et 1 LAN
    Si tu as une meilleure proposition je suis preneur.

    0
  • C

    @chris4916:

    Dans ce que je vois (maintenant) de ton schéma et que je mets ça en regard de ta première explication, tu dis que pfSense sa propre interface LAN, c'est bien ça

    En même temps, si je n'écris que la moitié des mots, ce n'est pas très compréhensible  ::)
    Désolé.
    Je voulais écrire que "pfSense ne ping pas sa propre interface"

    0
  • C

    Le plus simple serait de publier vos configurations "serveur" et " client".  Tout cela reste obscure.

    Lorsque le problème sera résolu, je suis intéressé par la motivation des firewalls en série ….

    0
  • -

    Pour chris4916

    Le client et le serveur ping leur propre IPs (LAN  + VPN), pas de problème de ce coté là.
    Le client ping l'interface du serveur (LAN + VPN)
    Le serveur ping uniquement l'interface VPN du client. L'interface LAN ne répond pas.

    Popur ccnet

    Suggères tu que je dois remplacer mon firewall existant (hardware) par pf ?

    0
  • C

    @-Sylvain-:

    Suggères tu que je dois remplacer mon firewall existant (hardware) par pf ?

    Non, je m'interroge juste sur la raison d'être de cette architecture.

    0

  • salut salut

    pf est un pare feu aussi, d'où la question/suggestion de ccnet je pense.

    Personnellement je en comprends pas trop le schéma
    si j'ai bien vu
    on a un pf en vert qui a 3 cartes , et dont une protège un réseau en 10.0.10.0/24
    on a un réseau en 10.0.10.0/24 a aussi deux  pf en mauve et en vert
    on a un pf en mauve a 3 cartes, dont une avec le réseau en 10.0.10.0/24
    on a un un pare feu hardware entre les deux pf qui sont eux des pare feu logiciel/os

    je ne comprend pas trop l’intérêt du montage ou il nous manque des info et pas qu'une.

    Cordialement.

    0
  • -

    Pour tatave

    Le réseau bleu (10.0.10.0/24) c'est le réseau VPN (les cartes sont virtuelles …)
    Le réseau vert c'est le serveur : il y 2 cartes une pour le WAN et une pour le LAN.
    Le réseau mauve (surement celui qui pose problème) c'etst le client avec le FW frontal en tête de ligne. Il ne gère pas les tunnel VPN, je suis donc obligé d'utiliser un second firewall en cascade, derrière le frontal. c'est pfSense. j'ai raccordé pfsense a la DMZ géré par le FW frontal. donc 2 cartes : une raccordé à la DMZ et une raccordé au LAN.

    j'espère être clair

    0
  • C

    @-Sylvain-:

    j'espère être clair

    Pas assez pour que je comprenne car tu écris

    Le serveur pfsense fait un ping sur l'IP LAN du client (IP 192.168.10.10) ==> Erreur

    et sur ton schéma, pour moi, 192.168.10.10, c'est précisément l'adresse LAN de pfSense

    il y a un typo quelque part ?
    Quelle est la passerelle par défaut des machines sur le réseau 192.168.10.0/23 ?

    0
  • -

    OK, je reformule

    Les pings du pfsense du site 1 en direction del' adresse IP LAN du pfsense du site 2 échoue

    La passerelle par défaut (et l'unique) est 192.168.10.10 (pfsense)

    0
  • C

    Maintenant, grâce a tes explications et tes commentaires, je commence à comprendre un peu mieux.

    Ce qui m'a "confusé" c'est que tu parles à la fois de mode "peer-to-peer" et de "client-serveur"

    En mode "site-à-site" (peer-to-peer), il n'y a pas de client-serveur à proprement parlé, même si une des 2 extrémités du tunnel va initier la connexion.
    Une fois la connexion établie, les 2 LAN vont "se voir".
    En mode client-serveur, ce n'est absolument pas vrai. Le client va voir le LAN exposé par le serveur mais les clients sur le LAN ne voient pas le client VPN comme un réseau accessible.

    Je partage l'avis de ccnet: si tu ne décris pas plus précisément tes config VPN de par et d'autre, il va être difficile d'aller plus loin. Le problème n'est peut-être pas le FW intermédiaire (je suppose que tu as mis en place à ce niveau les règles nécessaire) mais peut-être plus au niveau du VPN lui-même

    0
  • -

    Voici les exports XML de la config VPN et des règles de sécurité

    Site 1

    Config VPN
    <openvpn-server><vpnid>2</vpnid>
    <mode>p2p_tls</mode>
    <protocol>UDP</protocol>
    <dev_mode>tun</dev_mode>
    <ipaddr><interface>wan</interface>
    <local_port>1195</local_port>

    <custom_options><tls>XXXXX</tls>
    <caref>XXXXX</caref>
    <crlref><certref>XXXXX</certref>
    <dh_length>1024</dh_length>
    <cert_depth>1</cert_depth>
    <crypto>AES-256-CBC</crypto>
    <digest>SHA1</digest>
    <engine>none</engine>
    <tunnel_network>10.0.10.0/24</tunnel_network>
    <tunnel_networkv6><remote_network>192.168.10.0/23</remote_network>
    <remote_networkv6><gwredir><local_network>172.16.1.0/24</local_network>
    <local_networkv6><maxclients><compression><passtos><client2client><dynamic_ip>yes</dynamic_ip>
    <pool_enable>yes</pool_enable>
    <topology>subnet</topology>
    <serverbridge_dhcp><serverbridge_interface>none</serverbridge_interface>
    <serverbridge_dhcp_start><serverbridge_dhcp_end><netbios_enable><netbios_ntype>0</netbios_ntype>
    <netbios_scope><no_tun_ipv6>yes</no_tun_ipv6>
    <verbosity_level>1</verbosity_level></netbios_scope></netbios_enable></serverbridge_dhcp_end></serverbridge_dhcp_start></serverbridge_dhcp></client2client></passtos></compression></maxclients></local_networkv6></gwredir></remote_networkv6></tunnel_networkv6></crlref></custom_options></ipaddr></openvpn-server>

    Règles
    <rule><id><tracker>1472923908</tracker>
    <type>pass</type>
    <interface>wan</interface>
    <ipprotocol>inet</ipprotocol>
    <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>
    <os><protocol>udp</protocol>
    <source>
    <any><destination><network>wanip</network>
    <port>1195</port></destination>

    <updated><time>1472923908</time>
    <username>admin@10.0.8.2</username></updated>
    <created><time>1472923908</time>
    <username>admin@10.0.8.2</username></created></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>
    <rule><type>pass</type>
    <ipprotocol>inet</ipprotocol>

    <interface>lan</interface>
    <tracker>0100000101</tracker>
    <source>
    <network>lan</network>

    <destination><any></any></destination></rule>
    <rule><type>pass</type>
    <ipprotocol>inet6</ipprotocol>

    <interface>lan</interface>
    <tracker>0100000102</tracker>
    <source>
    <network>lan</network>

    <destination><any></any></destination></rule>
    <rule><id><tracker>1472923962</tracker>
    <type>pass</type>
    <interface>openvpn</interface>
    <ipprotocol>inet</ipprotocol>
    <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>
    <os><source>
    <any><destination><any></any></destination>
    <log><created><time>1472920588</time>
    <username>OpenVPN Wizard</username></created>
    <updated><time>1473110776</time>
    <username>admin@10.0.8.2</username></updated></log></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>

    Site 2

    Config VPN
    <openvpn-client><auth_user><auth_pass><vpnid>1</vpnid>
    <protocol>UDP</protocol>
    <dev_mode>tun</dev_mode>
    <ipaddr><interface>wan</interface>
    <local_port><server_addr>IP Public</server_addr>
    <server_port>1195</server_port>
    <resolve_retry><proxy_addr><proxy_port><proxy_authtype>none</proxy_authtype>
    <proxy_user><proxy_passwd><mode>p2p_tls</mode>
    <topology>subnet</topology>
    <custom_options><caref>XXXX</caref>
    <certref>XXXXX</certref>
    <tls>XXXX</tls>
    <crypto>AES-256-CBC</crypto>
    <digest>SHA1</digest>
    <engine>none</engine>
    <tunnel_network>10.0.10.0/24</tunnel_network>
    <tunnel_networkv6><remote_network>172.16.1.0/24</remote_network>
    <remote_networkv6><use_shaper><compression><passtos><no_tun_ipv6><route_no_pull><route_no_exec><verbosity_level>1</verbosity_level></route_no_exec></route_no_pull></no_tun_ipv6></passtos></compression></use_shaper></remote_networkv6></tunnel_networkv6></custom_options></proxy_passwd></proxy_user></proxy_port></proxy_addr></resolve_retry></local_port></ipaddr></auth_pass></auth_user></openvpn-client>

    Règles :
    <rule><type>pass</type>
    <ipprotocol>inet</ipprotocol>

    <interface>lan</interface>
    <tracker>0100000101</tracker>
    <source>
    <network>lan</network>

    <destination><any></any></destination></rule>
    <rule><type>pass</type>
    <ipprotocol>inet6</ipprotocol>

    <interface>lan</interface>
    <tracker>0100000102</tracker>
    <source>
    <network>lan</network>

    <destination><any></any></destination></rule>
    <rule><id><tracker>1472924613</tracker>
    <type>pass</type>
    <interface>openvpn</interface>
    <ipprotocol>inet</ipprotocol>
    <tag><tagged><max><max-src-nodes><max-src-conn><max-src-states><statetimeout><statetype>keep state</statetype>
    <os><source>
    <any><destination><any></any></destination>
    <log><created><time>1472924613</time>
    <username>admin@192.168.10.131</username></created>
    <updated><time>1473110789</time>
    <username>admin@192.168.10.133</username></updated></log></any></os></statetimeout></max-src-states></max-src-conn></max-src-nodes></max></tagged></tag></id></rule>

    0
  • C

    Je ne suis pas certain d'avoir la patience (ni le temps) de lire la config directement depuis le fichier XML. J'ai un peu de boulot en ce moment  :-) !
    Une remarque :

    <crypto>AES-256-CBC</crypto>
          <digest>SHA1</digest>

    AES c'est bien et en 128 bits çà ira aussi bien. Gardez le mode CBC c'est important. Par contre SHA-1 est compromis. Utilisez sha-256. Mettre de l'AES 256 avec du sha-1 n'est pas très cohérent. Si on parle de sécurité AES 128 CBC + SHA256 est préférable à AES 256 CBC + SHA1.

    0
  • -

    Ok je prends note, mais j'avoue que ma priorité c'était de faire fonctionner le tunnel.

    Pour les informations j'ai essayé d'en donner le maximum.
    Mais pour faire simple :
    J'ai une règle, sur les 2 sites, qui autorise tous les protocoles sur l'interface OpenVPN.
    J'ai une règle sur le site 1 qui ouvre le port 1195 sur l'interface WAN (Port 1194 utilisé pour un remote access)
    je n'ai pas d'autre règle hormis celle en standard créé par pfsense.

    0
  • C

    Avant de passer plus de temps sur les aspects "règles de FW", une fois le tunnel établi, peux-tu regarder quelles sont les routes sur chaque pfSense ?
    Si sur chaque pfSense il n'y a pas une route qui dit: "pour joindre le site distant, passer par le tunnel VPN", il est normal que ça ne marche pas.

    Et pour que cette route existe de chaque coté, il faut qu'elle soit annoncée au niveau de OpenVPN.

    0
  • -

    Voici les routes de chaque pfsense

    Site 1
    http://imgur.com/VEDQWLm

    Site 2
    http://imgur.com/Khc8tCr

    0
  • C

    Il y a 2 serveurs VPN configurés sur le serveur pfSense "de gauche" (sur ton schéma) ?

    Les routes ont l'air correct.

    Tu peux activer les log au niveau FW sur le pfSense cible pour voir quelle règle est appliquée lorsque tu fais un ping (on suppose bien sûr que ICMP est autorisée de bout en bout) car pour moi le tunnel à l'air OK et il s'agit probablement d'un problème de règle de FW (un truc qui n'autoriserait que TCP et pas ICMP ce qui empêcherait le ping)

    Tu devrait d’ailleurs, au lieu de faire des ping au niveau de pfSense, regarder ce qui se passe dans la communication entre clients et serveur "du LAN", sur des protocoles "TCP" ce qui te donnera une indication du niveau de fonctionnement et permettra sans doute de réduire le scope des investigations

    0
  • -

    Bonjour,

    J'ai régler le problème autrement.
    J'ai réinitialiser les 2 pf et remonter une configuration VPN basé sur une clé partagée.
    Et cela fonctionne très bien.

    Merci quand même de votre aide.

    0
 

Products

Applications

Support

Services

News

Resources

Company

Our Mission

As host of the pfSense open source firewall project, Netgate believes in enhancing network connectivity that maintains both security and privacy. We also believe everyone should be able to afford it.

Subscribe to our Newsletter

Product information, software announcements, and special offers. See our newsletter archive for past announcements.

© Copyright 2002 - 2019 Rubicon Communications, LLC | Privacy Policy