Problème VPN avec NAT sur IPCOP 2.0

[dblogin]

Bonjour à tous,

Voici la description de mon besoin et du problème rencontré :

Besoin : portage d'une configuration VPN IPSEC d'IPCOP 1.4.21 vers IPCOP 2.0.6


Schéma (en pièce jointe) :

Schéma de la configuration réseau et IPCOP

Config VPN IPCOP 1.4.21.png (160.03 Kio) Consulté 2022 fois

Description :

Il s'agit d'une liaison VPN entre un site avec IPCOP et un site avec un CISCO ASA 5550.
La seule IP acceptée par le site distant étant 10.118.X.Y, j'avais donc été obligé de faire du NAT avec iptables pour que l'ensemble des postes sur le réseau VERT 10.10.10.0/24 soit vu du site distant avec cette IP :

iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -d E.F.G.68/32 -j SNAT --to 10.118.X.Y

La connexion que j'établie via VPN avec le serveur distant dont l'IP est E.F.G.68 est une simple connexion HTTP.

Cela fonctionnait très bien avec IPCOP 1.4.21 mais j'ai des soucis avec la nouvelle version d'IPCOP 2.0.6 dans laquelle la stack NETKEY a remplacé la stack KLIPS et ce principe de translation d'adresse ne fonctionne plus.


Question : quelle est la solution pour qu'une telle configuration fonctionne avec IPCOP 2.0.6 ?
Utilisation de iptables et comment ?
Configuration des "Règles du Pare-Feu" pour le trafic interne ?
Créer une interface réseau virtuelle ?

J'espère avoir été précis dans la description de ma demande
Merci pour toute l'aide que vous pourrez m'apportez

Cordialement,

Didier

[Franck78]

Hello,
une recherche de type 'google netkey iptables' t'éclairera...

En résumé, NETKEY ne fournit plus d'interface virtuelle ipsecX. Il devient donc impossible d'appliquer facilement des règles iptables.

La solution retenue est quelquechose comme
-policy mark vpn packet
-encrypt netkey
-policy match iptables à la sortie pour snat ou autres

Peut être l'heure de passer site A en 10.118 ou contacter l'admin site B.....

[dblogin]

Bonjour et merci Franck78 pour votre réponse.

Effectivement avec IPCOP V2 et donc netkey il n'y a plus d'interface ipsecX donc pas vraiment de routage possible.

Pas de possibilité de passer mon site 1 en 10.118 non plus, 10.118.X.Y est une adresse unique imposée et non un réseau et j'ai sur le réseau du site A plusieurs postes en 10.10.10.Z. Quand ces postes joignent le serveur E.F.G.68 via le VPN il faut qu'ils soient vus avec l'IP 10.118.X.Y.

Et je n'ai aucune maîtrise sur le site B, c'est l'admin de ce site qui m'impose d'ailleurs de les joindre avec l'IP 10.118.X.Y.

Votre solution m'intéresse mais je n'ai pas une grande maîtrise des iptables et ip rule, pourriez-vous être plus précis dans la description de votre solution ?

Merci

Didier

[Franck78]

Votre solution m'intéresse mais je n'ai pas une grande maîtrise des iptables et ip rule, pourriez-vous être plus précis dans la description de votre solution ?

Ce n'est pas 'ma' solution mais ce qui se dégage avec une recherche rapide comme indiqué. Je n'ai rien (matériel) pour travailler dessus qui plus est !

[dblogin]

Ok merci tout de même.

En fait, j'ai l'impression que mon souci n'est pas un souci de routage puisque le routage ne semble pas nécessaire avec netkey.

C'est vraiment comment pour les packets provenant du réseau vert (10.10.10.0/24) et à destination du VPN (serveur distant E.F.G.68) via le réseau rouge (ipsec-rouge), affecter l'adresse IP 10.118.X.Y attendue par le serveur VPN distant (site B) alors que ce n'est pas mon adresse de sortie, mon adresse publique A.B.C.D sur le site A ?

[Franck78]

Tu t'en sortirais peut être mieux avec pfsense. Si tu ne peux pas changer tout l'adressage local de A, tu peux néanmoins ajouter le réseau 10.118 en parallèle.
pFsense gère correctement plusieurs IP par interface si je ne m'abuse.

IPCop 2, je ne sais pas.

Envoie le http de tes clients vers un proxy local que tu gères; celui-ci saura orienter une simple connexion HTTP vers le VPN ou vers l'internet !

Peut être même que un simple proxy.pac peut faire l'aiguillage dès le départ, mais il faut étendre 10.118 à chaque client.

[dblogin]

Merci pour ce complément d'information.
Peut-être qu'il ne manque pas grand chose mais j'ai essayé de m'en sortir avec les mark mais je n'y suis pas parvenu. Je ne sais pas qu'elle est la mark qu'il faut mettre, ni à quel moment (PREROUTING, OUTPUT, ...) dans une table mangle, filter ? Et ensuite à quel moment je peux prendre en compte cette mark pour essayer de faire du SNAT (transformer toutes mes IP internes GREEN 10.10.10.0/24 vers l'IP unique 10.118.X.Y) comme je le faisais auparavant avec IPCOP 1.4 (avec KLIPS au lieu de NETKEY).
J'ai essayé ceci :
iptables -t mangle -A PREROUTING -s 10.10.10.0/24 -d E.F.G.68/32 -j MARK --set-mark 1
et ensuite
iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j SNAT --to-source 10.118.192.148

Et je ne sais pas ensuite s'il faut ajouter des règles supplémentaires pour que le trafic ne soit pas bloqué.

Au départ je suis parti sur IPCOP 2 car je changeais de matériel et la carte réseau n'était pas reconnue mais je viens de voir que tu mets à disposition une version 1.4.24 et que dans l'évolution 1.4.22/1.4.23, il y a eu une mise à jour des drivers réseau donc avant de passer à PfSense que je ne connais pas ou de compliquer mon réseau en ajoutant un proxy je vais déjà essayer cette dernière version d'IPCOP 1.4.
Merci pour ton aide.

[Franck78]

Ton snat postrouting s'appliquait très très très probablement sur ipsec0 qui n'existe plus.
Maintenant c'est sur RED et c'est trop tard. Il faut une IP publique comme source....(-j MASQUERADE)

Pas vérifié que cela fonctionne, tu dois cependant pouvoir insérer ta règle avant le masquerade final.
iptables -t nat -I POSTROUTING -m mark --mark 0x1 -j SNAT --to-source 10.118.192.148

[dblogin]

Bonjour Franck78

J'ai pu reprendre mes tests et essayer ta dernière proposition :
# iptables -t mangle -A PREROUTING -s 10.10.10.0/24 -d E.F.G.68/32 -j MARK --set-mark 0x66
# iptables -t nat -I POSTROUTING -m mark --mark 0x66 -j SNAT --to-source 10.118.192.148

J'ai utilisé la mark 0x66 car la mark 0x01 était déjà utilisée.

Mais ça n'a pas résolu mon problème.

[Franck78]

il faudrait posément faire un diagramme du chemin suivi par un paquet dans IPCop/iptables; et vérifier ce qui est possible et si ça marche comme attendu.
Ou imaginer d'utiliser BLUE pour ça ?!