OpenVPN - ne pas forcer trafic internet local dans le VPN

Nackir

@jdh
Bonjour,

merci pour la réponse et les pistes.

J'ai vérifié le fichier de configuration openvpn sur PFSense, aucune mention de 'redirect gateway...' ni 'push..'.

Coté client, j'ai procédé aux vérifications de la table de routage avant et après connexion au VPN, en effet après connexion je me retrouve avec deux lignes 'destination 0.0.0.0' l'une d'elle indiquant bien ~~la passerelle du VPN~~ l'@ IP de l'interface du serveur VPN en tant que passerelle.

Avant connexion

# route -n              
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3

Après connexion

# route -n
Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         10.2.2.1        0.0.0.0         UG    50     0        0 tun0
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
10.0.2.2        0.0.0.0         255.255.255.255 UH    100    0        0 enp0s3
10.2.2.0        0.0.0.0         255.255.255.0   U     50     0        0 tun0
IP publique     10.0.2.2        255.255.255.255 UGH   100    0        0 enp0s3
192.168.100.0    10.2.2.1        255.255.255.0   UG    50     0        0 tun0

Ceci est valable quelles que soient les options que j'ajoute au client, je pense notamment à

pull-filter ignore redirect-gateway

Voilà je me suis rendu compte, en consultant le lien suggéré sur openvpn.net que les mots clés choisi dans ma recherche précédant mon post n'était pas si pertinent.
Je continue...
Encore une fois merci

jdh

(Il faut avoir une approche 'pragmatique' pour comprendre ce qui se passe ...)

Le démarrage d'OpenVPN Client modifie la route par défaut, alors que le serveur ne l'impose pas. C'est difficile à comprendre !

Je supprimerai la config existante de serveur OpenVPN, et j'en recréérai une nouvelle (après un reboot de pfSense). Bien sûr avec vérification de la disparition et réapparition du fichier de conf.

Il va falloir afficher la config serveur ...

NB : en recréant une config, le certificat DH sera à remplacer ...

Nackir

merci pour l'intérêt porté à ma demande

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

(Il faut avoir une approche 'pragmatique' pour comprendre ce qui se passe ...)

Le message est passé, je crois

Avant de tout recommencer, je poste des détails en plus
Je ne sais pas si cela a de l'intérêt pour mieux comprendre (je ne maîtrise pas encore tous les tenants et aboutissants)
PFSense est une VM installée sur/dans proxmox

j'ai un script qui me permet de rediriger le trafic entrant vers PFSense, il est activé au boot par une directive post-up dans le fichier /etc/networtk/interface dans la partie qui correspond à la config de la carte réseau LAN.
Son contenu est le suivant :

echo 1 > /proc/sys/net/ipv4/ip_forward

ip route change 192.168.100.0/24 via 10.0.0.2 dev vmbr1
ip route add 10.2.2.0/24 via 10.0.0.2 dev vmbr1

vmbr0 porte l'@IP publique (bridge entre l'interface physique du serveur et celle de proxmox)
vmbr1 est la patte WAN
vmbr2 la patte LAN
le VPN est dans le réseau 10.2.2.0/24

le contenu de la config openvpn:

cat /var/etc/openvpn/server1/config.ovpn

dev ovpns1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_server1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh
local 10.0.0.2
tls-server
server 10.2.2.0 255.255.255.0
client-config-dir /var/etc/openvpn/server1/csc
plugin /usr/local/lib/openvpn/plugins/openvpn-plugin-auth-script.so /usr/local/sbin/ovpn_auth_verify_async user TG9jYWwgRGF0YWJhc2U= false server1 1194
tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'host.domain.tld' 1"
lport 1194
management /var/etc/openvpn/server1/sock unix
max-clients 3
push "route 192.168.100.0 255.255.255.0"
remote-cert-tls client
capath /var/etc/openvpn/server1/ca
cert /var/etc/openvpn/server1/cert 
key /var/etc/openvpn/server1/key 
dh /etc/dh-parameters.4096
tls-auth /var/etc/openvpn/server1/tls-auth 0
data-ciphers AES-256-GCM:AES-256-CBC
data-ciphers-fallback AES-256-CBC
allow-compression no
persist-remote-ip
float
topology subnet
explicit-exit-notify 1
inactive 300
--route-noexec

voilà, voilà...

jdh

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 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'.)

C'est ce qui est décrit dans 'Client Specific Overrides' : je préconise de n'avoir rien de spécifique par utilisateur, à vérifier ...

Moi aussi, j'ai un pfSense sur un Proxmox, le tout derrière une box.
Et la box renvoie le trafic 1194/udp sur l'ip WAN de la VM pfSense.
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 !

=> Votre architecture est à revoir (et simplifier) !! (Il vous faudra un routeur Wifi dédié car votre réseau interne sera distinct du réseau ethernet et wifi de la box !)

(NB : je préconise TRES FORTEMENT d'avoir un Proxmox avec 2 interfaces Ethernet, pour chacune d'utiliser des bridges 'vmbrX', et la VM PfSense sera la SEULE VM a disposer de 2 interfaces : l'une sur le bridge WAN = vers la box, l'autre vers le bridge LAN = vers le réseau interne. J'au un ami qui avait un Proxmox mono interface avec un script très compliqué de renvoi : je lui ai fait ajouter une interface et je lui ai montré que tout se simplifiait ensuite !)

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