OpenVPN - ne pas forcer trafic internet local dans le VPN

Nackir

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Tout détail a son importance ! Et c'est le défaut de débutants de ne pas fournir assez d'informations : ça ne doit pas être utile, et non !

Je dirais plutôt que c'est la difficulté à cerner ce qui peut être utile ou non dans mon cas et c'est là que ça va fuser de tous les cotés la machine est un serveur dédié donc un seule interface réseau possible...
Pour différentes raison, j'ai laissé tomber la config à la maison, 2 onduleurs HS en peu de temps et depuis qq temps des coupures elec incessantes ajouté à cela que le seul opérateur qui m'ait relié à la fibre ne propose pas d'IP fixe

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Je note la ligne 'client-config-dir /var/etc/openvpn/server1/csc' : y a-t-il quelque chose dans ce dossier : il peut contenir un dossier par utilisateur et les réglages spécifiques à cet utilisateur, y compris un 'redirect-gateway' ! (C'est un peu lié avec votre choix 'Remote Acess + User Auth'.)

le dossier csc est vide donc pas de réglages spécifiques ?

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

MAIS, jamais au grand jamais, Proxmox fait des transferts de flux : ça c'est folie.
Proxmox n'a PAS à connaitre le réseau OpenVPN de pfSense ! Jamais !

même dans ce cas de figure, un serveur dédié avec une seule interface réseau?

le temps passant et les connaissances étant limitées, je me suis dit que si je n'aboutissait pas, je monterai une VM dans mon PC, VM dédiée à "l'admin de mon serveur"
Je vais reprendre la config à zéro d'OpenVPN comme suggéré plus tôt

edit: au cas où, la finalité de tout ça est de me permettre d'avoir un serveur nextcloud "protégé" et accessible en tout temps derrière un reverse proxy avec Haproxy...

jdh

Commençons dans l'ordre :

un pfSense doit, nécessairement, avoir 2 interfaces WAN et LAN bien distinctes = un n° de réseau distinct est le minimum
le réseau WAN est entre la box et WAN de pfSense, disons 192.168.1.x/24,
le réseau LAN est entre le LAN de pfSense et les PC ou VM internes, reliés en ethernet ou wifi, disons 192.168.10.x/24

Si vous avez un Proxmox avec UNE seule interface ethernet, vous avez créé 2 interfaces (WAN et LAN) bridgées sur cette seule interface. De facto le DHCP de la BOX rentre en conflit avec le DHCP du LAN de pfSense. (En outre, vous devrez avoir un point d'accès wifi sur le réseau LAN !)

Un serveur 'tour' comme hôte de virtualisation peut toujours avoir une interface ethernet supplémentaire (et ça coute <15 €). Mon ami a un NUC : on a donc ajouté un adaptateur USB3/Ethernet, et ça fonctionne ...

Les redirections sont réalisées au niveau de la Box et renvoient vers l'IP WAN de (la VM) pfSense. Les PC internes voient l'ip LAN de (la VM) pfSense comme leur gateway, ce qui va bien pour un PC connecté par (Open)VPN. Bref AUCUN réglage réseau au niveau de l'hôte (Penser à lui fournir une ip côté LAN !).

Nackir

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Commençons dans l'ordre :

un pfSense doit, nécessairement, avoir 2 interfaces WAN et LAN bien distinctes = un n° de réseau distinct est le minimum

le réseau WAN est entre la box et WAN de pfSense, disons 192.168.1.x/24,

le réseau LAN est entre le LAN de pfSense et les PC ou VM internes, reliés en ethernet ou wifi, disons 192.168.10.x/24

Si vous avez un Proxmox avec UNE seule interface ethernet, vous avez créé 2 interfaces (WAN et LAN) bridgées sur cette seule interface. De facto le DHCP de la BOX rentre en conflit avec le DHCP du LAN de pfSense. (En outre, vous devrez avoir un point d'accès wifi sur le réseau LAN !)

Un serveur 'tour' comme hôte de virtualisation peut toujours avoir une interface ethernet supplémentaire (et ça coute <15 €). Mon ami a un NUC : on a donc ajouté un adaptateur USB3/Ethernet, et ça fonctionne ...

Les redirections sont réalisées au niveau de la Box et renvoient vers l'IP WAN de (la VM) pfSense. Les PC internes voient l'ip LAN de (la VM) pfSense comme leur gateway, ce qui va bien pour un PC connecté par (Open)VPN. Bref AUCUN réglage réseau au niveau de l'hôte (Penser à lui fournir une ip côté LAN !).

Je suis d'accord avec tout ça mais quand je disais serveur dédié cela sous entendait loué auprès d'OVH en l’occurrence donc je n'ai pas la main sur le matériel...

jdh

Le serveur est un serveur dédié OVH : voilà une info à fournir dès le début !

Avec un serveur dédié chez un hébergeur, il faut

2 adresses ip : une pour l'hôte de virtualisation (Proxmox), et une pour WAN de pfSense,
on installe avec un Proxmox accédé en ssh avec son adresse ip,
l'interface ethernet du serveur est bridgé sous le nom 'vmbr0' avec l'ip de l'hôte,
une interface bridgée reliée à aucune interface réelle sera 'vmbr1' et sera l'interface des VM internes avec un réseau privé 192.168.x.0/24,
une seule VM aura 2 interfaces : l'une sur 'vmbr0' avec l'ip WAN, l'autre sur 'vmbr1' qui sera la passerelle par défaut des autres VM,
ce qui compte c'est de bien configurer le WAN en statique avec l'ip WAN distincte de l'ip de l'hôte (je ne sais pas comment on fait chez OVH mais je suppose que cela se fait avec une ip failover).

Je comprends que, ayant attribué une adresse ip dans le réseau interne à votre hôte, vous ayez besoin d'une route spécifique au réseau des clients VPN.

Nackir

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Le serveur est un serveur dédié OVH : voilà une info à fournir dès le début !

Vraiment merci pour la patience et l'aide apportée.

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Avec un serveur dédié chez un hébergeur, il faut

2 adresses ip : une pour l'hôte de virtualisation (Proxmox), et une pour WAN de pfSense,
on installe avec un Proxmox accédé en ssh avec son adresse ip,
l'interface ethernet du serveur est bridgé sous le nom 'vmbr0' avec l'ip de l'hôte,
une interface bridgée reliée à aucune interface réelle sera 'vmbr1' et sera l'interface des VM internes avec un réseau privé 192.168.x.0/24,
une seule VM aura 2 interfaces : l'une sur 'vmbr0' avec l'ip WAN, l'autre sur 'vmbr1' qui sera la passerelle par défaut des autres VM,
ce qui compte c'est de bien configurer le WAN en statique avec l'ip WAN distincte de l'ip de l'hôte (je ne sais pas comment on fait chez OVH mais je suppose que cela se fait avec une ip failover).

Du coup, je n'ai plus besoin d'aucune des deux règles de routage sur l'hôte (?)

Ainsi que l'ensemble de règles iptables sur l'hôte pourrait se résumer à tout bloquer en entrant hormis les ports qui m'intéressent soit celui de SSH et celui d l'interface de proxmox ?
Ceci déleste vraiment tout le travail à la VM PFSense.

J'ai fait un schéma, histoire de mieux m'imprégner des conseils promulgués, même s'il n'est pas conventionnel, est-il compréhensible et correct?

J'ai commandé l'@IP FailOver et je vais la mettre en place pour Proxmox (IP FO), l'@IP déjà fournie sera celle qui sera attribuée à vmbr0 (IP WAN).

jdh

Le schéma est presque correct.

'vmbr0' est un bridge sur l'interface physique 'enp3s00'
Proxmox a une adresse ip (publique) sur cette interface (et pas sur l'interface physique)
La VM pfSense a une interface connectée à ce bridge 'vmbr0', avec une adresse ip (publique) : l'ip FailOver ?

NB : il ne faut pas activer le 'ip_forwarding' sur Proxmox, et il faut activer un firewall : ne permettre que ssh sur l'interface 'vmbr0', avec une limitation du nombre de connection !

Nackir

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Le schéma est presque correct.
'vmbr0' est un bridge sur l'interface physique 'enp3s00'
Proxmox a une adresse ip (publique) sur cette interface (et pas sur l'interface physique)
La VM pfSense a une interface connectée à ce bridge 'vmbr0', avec une adresse ip (publique) : l'ip FailOver ?

Voilà le schéma modifié

J'ai mis en place l'@IP failover sur l'interface WAN de PFSense, avec une VM connectée à vmbr1, j'ai bien accès à internet et je vois bien que cela passe par PFSense (IP failOver)

J'ai accès à l'interface de Proxmox ainsi qu'à SSH par l'IP Publique

En ajustant la config client du VPN avec la bonne IP (failover), je récupère l'accès et ait accès à l'interface web de PFSense.
Cela n'a pas réglé le problème de l'accès à internet qui veut toujours passer par le VPN mais je vais y venir en reprenant la config à zéro comme vous l'avez suggéré.

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

NB : il ne faut pas activer le 'ip_forwarding' sur Proxmox, et il faut activer un firewall : ne permettre que ssh sur l'interface 'vmbr0', avec une limitation du nombre de connexion !

L'ip forwarding est bien désactivé et pour le moment, j'ai juste mis en place le firewall proposé par OVH qui bloque en entrée de son réseau les ports inutiles. J'ai vu une baisse significative des tentatives de connexion en regardant les logs de fail2ban. La config du firewall sur l'hôte est en cours...

Encore une fois merci, je ressens une grande satisfaction (d'avoir compris vos directives) même si cela est basique pour un grand nombre...

jdh

Je pense qu'il faut regarder, au niveau du Proxmox, les règles de firewall !
Côté public entrant (=vmbr0), seul ssh doit être ouvert mais aussi limité

'iptables ---state new -limit' permet de limiter le nombre de sessions (initiales) ssh à un nombre à définir par secondes, minutes : par exemple 6 sessions ssh par minute (soit 1 tout les 10 secondes) est un bon moyen de limiter les effets d'une attaque 'brut force'.

(Voire utiliser du 'port knocking' ... exemple https://www.linuxbabe.com/security/secure-ssh-service-port-knocking-debian-ubuntu NB : à essayer sur une autre machine avant d'appliquer à Proxmox !)

Nackir

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

Je pense qu'il faut regarder, au niveau du Proxmox, les règles de firewall !
Côté public entrant (=vmbr0), seul ssh doit être ouvert mais aussi limité

Faisant de la sorte je vais me bloquer l'accès à l'interface web de Proxmox (?)
Ce que j'en ai compris, Proxmox n'a qu'une IP qui est l'ip publique donc je ne vois pas comment faire dans cette nouvelle configuration pour y accéder si le port est fermé.

@jdh said in OpenVPN - ne pas forcer trafic internet local dans le VPN:

(Voire utiliser du 'port knocking' ... exemple https://www.linuxbabe.com/security/secure-ssh-service-port-knocking-debian-ubuntu NB : à essayer sur une autre machine avant d'appliquer à Proxmox !)

Merci pour la ressource, c'est en effet intéressant. Du coup je me dis que c'est peut-être la solution à ma précédente interrogation pour accéder à l'interface web de proxmox.

Avec cette configuration (2 adresses IP) je me rend compte à l'usage que je n'ai plus de demande de vérification que je ne suis pas un robot lorsque je me connecte à divers sites même une simple recherche google par exemple...

jdh

Le proxmox devrait être

accessible en ssh depuis l'extérieur (et depuis le VPN),
administrable en web (sur le port 8006/tcp) depuis le VPN (et pas depuis l'extérieur).

En sus, le port knocking permet d'éviter franchement les attaques brut-force (au contraire de le limiter avec '--limit' : avec --limit le port est ouvert en permanence).

(L'article indiqué est le premier que je trouve à être très complet sur le sujet ... car le port knocking est une technique assez ancienne.)

NB : si la VM pfSense est tombée et que le VPN ne fonctionne pas, il est possible en ssh de redémarrer la VM en ligne de commande !

Nackir

@jdh

En attendant de mieux maîtriser la situation, j'ai mis en place le pare-feu empêchant toute connexion et je gère l'ouverture des accès avec le KVM IP.
Une fois arrivé à ce point, je me lancerai dans le port-knocking.

Dans toutes mes tentatives de bloquer l'accès au port 8006 depuis internet et le permettre depuis le VPN, je me retrouve bloqué dehors.

J'ai refait la config d'openVPN en m'assurant que le fichier de conf ne soit plus présent après un reboot de la VM, rien n'y fait... le trafic internet passe toujours par la le VPN.
Sur un autre serveur dédié hébergé, j'ai eu le même problème...

Je vais reprendre l'installation de ce dernier avec les indications que m'avez données, une seule interface réseau physique et 2 adresses IP. Il me servira de "labo"...

Merci du temps que vous avez accordé à me fournir les éléments qui m'ont permis d'avancer.
je reviendrai poster les résultats de mes tests