Masquerade IP & Racoon

Support Debian
#1

Bonjour,

J’ai un soucis avec un vpn. J’utilise racoon et ipsec-tool pour créer mon tunnel.

Cela fonctionne très bien lorsque je n’ai pas de masquerade ip sur mes routeurs.

En fait j’ai 2 sites distants, avec une cinquantaine de personnes en IP privées cachées derriere mon masquerade.

De chaque coté, un sous réseau est definit pour etre celui utilisé sur le tunnel vpn, le 10.0.1.0 d’un coté et le 10.0.2.0 de l’autre.

J’ai fait mes tests sur une maquette et tout se passait très bien, les 2 sous reseaux arrivent à se pinguer, le partage de dossier se fait, jusqu’à ce que je teste avec un masquerade (comme cela est le cas sur l’architecture chez le client), a ce moment plus moyen de pinguer les hotes des sous réseaux distants.

Aucune autre modification n’a été réalisée, et dès que j’enlève le masquerade, le vpn refonctionne.

Malheureusement, j’ai besoin des 2 fonctionnalités…

Auriez-vous une idée la dessus ?

Merci d’avance

#2

Une petite aide ?

s’il vous plait… :cry: :cry:

#3

ne masquerade que ce qui vient du LAN (en rajoutant un -i ethLAN), en critère supplémentaire à tout ce qui sort par ton interface NET.
Comme ça, tout ce qui concerne les vpn (qui sont, j’imagine sur la passerelle elle même) sera non masqueradé.

#4

Marchera pas, le masquerading se fait dans POSTROUTING où l’option -i n’est pas valable. On peut contourner cette limitation en utilisant une marque posée dans la chaîne FORWARD :

iptables -t mangle -A FORWARD -i ethLAN -o ethNET -j MARK --set-mark 0x1 iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j MASQUERADE mais je ne suis pas convaincu que ça aide.

Bonne remarque, le tunnel IPSec est-il géré par les routeurs ou par des machines des LANs ? L’encapsulation est-elle native ou NAT-T (UDP port 500 ou 4500) ? Mode tunnel ou transport ?

Je connais très peu IPSec, néanmoins j’ai lu que :

  • l’encapsulation IPSec native supporte mal le passage à travers le NAT/masquerading, d’où la création de NAT-T ;
  • si c’est la même machine qui fait à la fois le masquerading et l’encapsulation IPSec, depuis qu’IPSec n’utilise plus des interfaces réseau virtuelles distinctes (comme c’était avec l’IPSec des noyaux 2.4, et comme d’autres types de VPN comme OpenVPN ou PPTP), les relations entre les deux peuvent être un peu compliquées pour savoir si le masquerading est appliqué avant ou après l’encapsulation IPSec.
#5

Bonjour, merci de vous interesser à mon soucis, je vais vous donner le contenu des differents fichiers de configuration, ça pourra surement aider un peu :

1er site :

[code]#/etc/racoon/racoon.conf
path pre_shared_key “/etc/racoon/psk.txt”;

listen
{
isakmp 95.167.199.218[500];
isakmp_natt 95.167.199.218[4500];
}
remote 202.99.97.26 {
exchange_mode main,aggressive;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
generate_policy off;
}

sainfo address 10.0.2.0/24[any] any address 10.0.1.0/24[any] any
{
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}

#/etc/racoon/psk.txt

202.99.97.26 bclva

#/etc/ipsec-tools.conf

spdadd 10.0.2.0/24 10.0.1.0/24 any -P out ipsec
esp/tunnel/95.167.199.218-202.99.97.26/require;

spdadd 10.0.1.0/24 10.0.2.0/24 any -P in ipsec
esp/tunnel/202.99.97.26-95.167.199.218/require;
[/code]

2nd site :

[code]#/etc/racoon/racoon.conf
path pre_shared_key “/etc/racoon/psk.txt”;
listen
{

isakmp 202.99.97.26[500];
isakmp_natt 202.99.97.26[4500];
}
remote 95.167.199.218 {
exchange_mode main,aggressive;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
generate_policy off;
}

sainfo address 10.0.1.0/24[any] any address 10.0.2.0/24[any] any {
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}

#/etc/racoon/psk.txt

95.167.199.218 bclva

#/etc/ipsec-tools.conf

spdadd 10.0.2.0/24 10.0.1.0/24 any -P in ipsec
esp/tunnel/95.167.199.218-202.99.97.26/require;

spdadd 10.0.1.0/24 10.0.2.0/24 any -P out ipsec
esp/tunnel/202.99.97.26-95.167.199.218/require;[/code]

Ensuite pour repondre aux questions, c’est en effet la même passerelle qui gère le masquerade ET le tunnel ipsec/racoon.

J’ai essayé d’ajouter “isakmp_natt xxx[4500];” et “nat_traversal on;” après avoir fait quelques recherches sur le sujet.

En ce qui concerne l’encapsulaiton, je pense que c’est ce dont je parle au dessus. Faut-il laisser isakmp ET isakmp_natt ou juste laisser le natt ?

Enfin, je suppose que c’est le mode tunnel, mais je ne vois pas vraiment ce qu’est le mode transport.

Auriez-vous une idée pour que les personnes placées sur le LAN puissent se connecter au vpn, tout en ayant la possibilité de sortir vers internet via le masquerade ?

Merci à vous.

bye

#6

La solution de marquage des trâmes proposée par PascalHambourg me parait avisée: au lieu de masquerader tout ce qui sort par l’interface NET, tu marques les paquets qui viennent de l’interface LAN dans l’INPUT, et tu ne masquerade que les paquets marqués qui sortent vers NET.
Ca permettra d’éviter de masquerader ce qui est issu de ta passerelle (c’est inutile de toutes les manières).

#7

dudu:
Comme c’est la même machine qui fait le masquerading et l’encapsulation IPsec, pas besoin de s’embêter avec le NAT-T (NAT Traversal) puisque les paquets IPsec n’ont pas à être NATés.

mattotop:
En fait comme je l’ai déjà dit je ne suis pas sûr que ça aide, car IPsec sur le noyau 2.6 ne fonctionne pas comme d’autres VPN.

Avec OpenVPN par exemple, une interface “virtuelle” spécifique au VPN (tun ou tap) est créée, les paquets envoyés par cette interface - par routage - sont récupérés par le démon OpenVPN qui l’encapsule dans un nouveau paquet généré localement envoyé par l’interface “réelle”. Il y a donc deux paquets indépendants du point de vue du noyau.

Avec IPsec, il n’y a pas d’interface virtuelle spécifique. Les paquets à encapsuler sont sélectionnés non par routage mais pas une politique IPsec. C’est le même paquet qui traverse certaines chaînes iptables tantôt sous sa forme originale et tantôt encapsulé, et qui garde la marque. Hélas il ne semble pas facile de trouver des détails à ce sujet.

Par conséquent, j’ai une suggestion : il faut exclure du masquerading, en plus des paquets émis localement par le routeur, les paquets concernés par la politique IPsec, c’est-à-dire destinés à la plage d’adresses de l’autre LAN.

#8

Superbe !! Ca fonctionne !!

Grace à vos differentes suggestions tout marche parfaitement.

J’ai ajouté les lignes suivante à mes passerelles, comme vous l’aviez pensé :

iptables -t mangle -A FORWARD -s Lan_source/24 -d ! Lan_destination/24 -j MARK --set-mark 0x1 iptables -t nat -A POSTROUTING -m mark --mark 0x1 -j MASQUERADE

En plus j’ai pu en apprendre un peu plus sur la table mangle que je ne connaissait que très peu.

Mille mercis à vous !! :smt007 :smt007

A la prochaine

#9

Bonjour ! ^^

Je reviens vous embeter une dernière petite fois, pour un petit conseil…

Comme je vous l’ai dit dans le post précedent, avec les règles mangle cela fonctionne, mais pour que mes utilisateurs dans les sous réseaux 10.0.[3-60].0 puisse avoir internet, je dois leur appliquer un masquerade aussi.

Dois-je faire un masquerade particulier pour chaque sous-réseau ? cela ne va t-il pas poser de soucis au niveau de la charge sur la passerelle ?

Aussi, le fait de marquer les trames ne pose pas de soucis de ralentissement dans le traitement des paquets ?

Merci encore pour votre aide

#10

Tu fais comme tu veux, du moment que les paquets destinés à passer dans le tunnel IPsec ne sont pas masqueradés. Pourquoi ne pas tout simplement supprimer l’option -s, ou élargir sa plage pour inclure tous les sous-réseaux ?

D’après mon expérience et mes lectures, la charge induite par iptables est faible même avec beaucoup de règles. Et quelques dizaines de règles, ce n’est pas beaucoup. Le chiffrement par IPsec est certainement beaucoup plus coûteux en proportion.

#11

quote=“PascalHambourg”
D’après mon expérience et mes lectures, la charge induite par iptables est faible même avec beaucoup de règles.
(…)[/quote] En fait, la manière dont c’est traité ne cause effectivement pas vraiment de dégradation des perfs sous la charge, mais par contre, avec des jeux de regles complexes (en centaines), c’est l’initialisation et la traduction des règles de pare feu en hook pour les modules lors de la mise en place ou l’ajout de règles qui peut commencer à prendre du temps. Des secondes entières, même… :mrgreen:

#12

Excusez-moi de vous embéter une nouvelle fois…

Est-ce qu’il n’y aurait pas possibilité de marquer tous les paquets à destination du vpn, pour ne pas appliquer de masquerade dessus (les paquets sont beaucoup moins nombreux) ?

Et sinon, étant donné que le réseau comporte environ 150 utilisateurs, pour 4méga de débit symétrique, le fait de marquer toutes les trames en provenance de leurs machines vers internet, ne va t-il pas ralentir mon réseau ?

Merci d’avance

#13

[quote=“dudu”]Excusez-moi de vous embéter une nouvelle fois…

Est-ce qu’il n’y aurait pas possibilité de marquer tous les paquets à destination du vpn, pour ne pas appliquer de masquerade dessus (les paquets sont beaucoup moins nombreux) ?[/quote]Non. Ce ne sont pas les paquets à destination du vpn qui sont à exclure du masquerading mais ceux du trafic ipsec qui partent de ton routeur pour aller atteindre l’autre machine du tunnel par son ip publique. Tu pourrais donc peut être ne rien marquer et dans le POSTROUTEING ACCEPTer les paquets qui -d <l’autremachine du vpn> avant le masq, mais ça concernerait aussi les paquets de ton lan qui tentent d’atteindre cette machine (avec son adresse publique, je veux dire). Alors tu pourrais restreindre ça à l’UDP 500, et aux protocoles AH et ESP, mais puisque tu as une solution qui marche pourquoi se compliquer la vie…[quote=“dudu”]Et sinon, étant donné que le réseau comporte environ 150 utilisateurs, pour 4méga de débit symétrique, le fait de marquer toutes les trames en provenance de leurs machines vers internet, ne va t-il pas ralentir mon réseau ?[/quote] Non. Il va ralentir le ping de manière négligeable, mais de toutes les manières, ton débit reste le même, avec ou sans iptables, et tu aurais un jeu de règles plus compliquées donc plus longues à recharger.
Et 150 machines sur 4Mb, c’est ridicule comme charge pour ipables :mrgreen:

#14

Bonjour à tous, je me permet de dépoussiérer ce topic… car j’ai une légère problèmatique dans la lignée de celle au dessus…

Depuis l’an dernier j’ai monté plusieurs vpn site à site, avec directement l’ip publique attribuée a la machine… cependant cela m’est impossible dans certains cas où je n’ai qu’une seule IP publique… dans ce cas je voudrais quand même pouvoir monter dans tunnels…

Pour ce faire, j’ai redirigé mes ports 500 et 4500 (tcp+udp) des routeurs passerelles de mes réseaux vers mes ‘serveurs’ linux (debian etch) qui servent de passerelles vpn… j’ai donc une configuration comme ceci…

[code]#/etc/racoon/racoon.conf
path pre_shared_key “/etc/racoon/psk.txt”;
listen {
isakmp 192.168.1.3[500];
isakmp_natt 192.168.1.3[4500];#ligne que j’ai ajouté par rapport a la configuration IP_pub-IP_pub
}
remote IP_pub_routeur_distant {
exchange_mode main,aggressive;
nat_traversal on;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group modp1024;
}
generate_policy off;
}

sainfo address 10.2.0.0/24[any] any address 172.17.0.0/24[any] any
{
pfs_group modp768;
encryption_algorithm 3des;
authentication_algorithm hmac_md5;
compression_algorithm deflate;
}
[/code]

[code]#/etc/ipsec-tools.conf
spdadd 10.2.0.0/24 172.17.0.0/24 any -P out ipsec
esp/tunnel/192.168.1.3-IP_pub_routeur_distant/require;

spdadd 172.17.0.0/24 10.2.0.0/24 any -P in ipsec
esp/tunnel/IP_pub_routeur_distant-192.168.1.3/require;[/code]

#/etc/racoon/psk.txt IP_pub_routeur_distant secret

Et le meme genre de config sur le 2eme serveur…

Dans les logs je retrouve ceci :

Mar 24 11:59:32 v2box racoon: INFO: Reading configuration from "/etc/racoon/racoon.conf" Mar 24 11:59:32 v2box racoon: INFO: Reading configuration from "/etc/racoon/racoon.conf" Mar 24 11:59:32 v2box racoon: INFO: Resize address pool from 0 to 255 Mar 24 11:59:32 v2box racoon: INFO: Resize address pool from 0 to 255 Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[4500] used as isakmp port (fd=7) Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[4500] used as isakmp port (fd=7) Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[4500] used for NAT-T Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[4500] used for NAT-T Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[500] used as isakmp port (fd=8) Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[500] used as isakmp port (fd=8) Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[500] used for NAT-T Mar 24 11:59:32 v2box racoon: INFO: 192.168.1.3[500] used for NAT-T Mar 24 11:59:53 v2box racoon: INFO: accept a request to establish IKE-SA: @IP_PUB2 Mar 24 11:59:53 v2box racoon: INFO: accept a request to establish IKE-SA: @IP_PUB2 Mar 24 11:59:53 v2box racoon: INFO: initiate new phase 1 negotiation: 192.168.1.3[500]<=>@IP_PUB2[500] Mar 24 11:59:53 v2box racoon: INFO: initiate new phase 1 negotiation: 192.168.1.3[500]<=>@IP_PUB2[500] Mar 24 11:59:53 v2box racoon: INFO: begin Identity Protection mode. Mar 24 11:59:53 v2box racoon: INFO: begin Identity Protection mode. Mar 24 11:59:53 v2box racoon: INFO: received Vendor ID: RFC 3947 Mar 24 11:59:53 v2box racoon: INFO: received Vendor ID: RFC 3947 Mar 24 11:59:53 v2box racoon: INFO: received Vendor ID: DPD Mar 24 11:59:53 v2box racoon: INFO: received Vendor ID: DPD Mar 24 11:59:53 v2box racoon: INFO: Selected NAT-T version: RFC 3947 Mar 24 11:59:53 v2box racoon: INFO: Selected NAT-T version: RFC 3947 Mar 24 11:59:53 v2box racoon: INFO: Hashing @IP_PUB2[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Hashing @IP_PUB2[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Hashing 192.168.1.3[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Hashing 192.168.1.3[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Adding remote and local NAT-D payloads. Mar 24 11:59:53 v2box racoon: INFO: Adding remote and local NAT-D payloads. Mar 24 11:59:53 v2box racoon: INFO: Hashing 192.168.1.3[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Hashing 192.168.1.3[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: NAT-D payload #0 doesn't match Mar 24 11:59:53 v2box racoon: INFO: NAT-D payload #0 doesn't match Mar 24 11:59:53 v2box racoon: INFO: Hashing @IP_PUB2[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: Hashing @IP_PUB2[500] with algo #2 Mar 24 11:59:53 v2box racoon: INFO: NAT-D payload #1 doesn't match Mar 24 11:59:53 v2box racoon: INFO: NAT-D payload #1 doesn't match Mar 24 11:59:53 v2box racoon: INFO: NAT detected: ME PEER Mar 24 11:59:53 v2box racoon: INFO: NAT detected: ME PEER Mar 24 11:59:53 v2box racoon: INFO: KA list add: 192.168.1.3[4500]->@IP_PUB2[4500] Mar 24 11:59:53 v2box racoon: INFO: KA list add: 192.168.1.3[4500]->@IP_PUB2[4500] Mar 24 11:59:53 v2box racoon: INFO: ISAKMP-SA established 192.168.1.3[4500]-@IP_PUB2[4500] spi:c9ac3fd1d268458d:444ccf0a58fcc9fb Mar 24 11:59:53 v2box racoon: INFO: ISAKMP-SA established 192.168.1.3[4500]-@IP_PUB2[4500] spi:c9ac3fd1d268458d:444ccf0a58fcc9fb

sur une machine et ceci sur l’autre…

Mar 24 12:13:12 v2box racoon: INFO: respond new phase 1 negotiation: 192.168.1.100[500]<=>@IP_PUB1[500] Mar 24 12:13:12 v2box racoon: INFO: respond new phase 1 negotiation: 192.168.1.100[500]<=>@IP_PUB1[500] Mar 24 12:13:12 v2box racoon: INFO: begin Identity Protection mode. Mar 24 12:13:12 v2box racoon: INFO: begin Identity Protection mode. Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: RFC 3947 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: RFC 3947 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00 Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: DPD Mar 24 12:13:12 v2box racoon: INFO: received Vendor ID: DPD Mar 24 12:13:12 v2box racoon: INFO: Selected NAT-T version: RFC 3947 Mar 24 12:13:12 v2box racoon: INFO: Selected NAT-T version: RFC 3947 Mar 24 12:13:13 v2box racoon: INFO: Hashing 192.168.1.100[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Hashing 192.168.1.100[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: NAT-D payload #0 doesn't match Mar 24 12:13:13 v2box racoon: INFO: NAT-D payload #0 doesn't match Mar 24 12:13:13 v2box racoon: INFO: Hashing @IP_PUB1[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Hashing @IP_PUB1[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: NAT-D payload #1 doesn't match Mar 24 12:13:13 v2box racoon: INFO: NAT-D payload #1 doesn't match Mar 24 12:13:13 v2box racoon: INFO: NAT detected: ME PEER Mar 24 12:13:13 v2box racoon: INFO: NAT detected: ME PEER Mar 24 12:13:13 v2box racoon: INFO: Hashing @IP_PUB1[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Hashing @IP_PUB1[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Hashing 192.168.1.100[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Hashing 192.168.1.100[500] with algo #2 Mar 24 12:13:13 v2box racoon: INFO: Adding remote and local NAT-D payloads. Mar 24 12:13:13 v2box racoon: INFO: Adding remote and local NAT-D payloads. Mar 24 12:13:13 v2box racoon: INFO: NAT-T: ports changed to: @IP_PUB1[4500]<->192.168.1.100[4500] Mar 24 12:13:13 v2box racoon: INFO: NAT-T: ports changed to: @IP_PUB1[4500]<->192.168.1.100[4500] Mar 24 12:13:13 v2box racoon: INFO: KA list add: 192.168.1.100[4500]->@IP_PUB1[4500] Mar 24 12:13:13 v2box racoon: INFO: KA list add: 192.168.1.100[4500]->@IP_PUB1[4500] Mar 24 12:13:13 v2box racoon: INFO: ISAKMP-SA established 192.168.1.100[4500]-@IP_PUB1[4500] spi:c9ac3fd1d268458d:444ccf0a58fcc9fb Mar 24 12:13:13 v2box racoon: INFO: ISAKMP-SA established 192.168.1.100[4500]-@IP_PUB1[4500] spi:c9ac3fd1d268458d:444ccf0a58fcc9fb

Le established a la fin des logs me parait encourageant… cependant aucun ping entre le réseau 10.2.0.0 et le reseau 172.17.0.0 ne passe.

Auriez-vous quelques idées par rapport a cela ? y’a t’il un soucis au niveau de la déclaration des ip publiques/privées ?

Merci d’avance !