SMPFR

Pour certains de mes clients, j'ai monté un VPN ipsec afin de faciliter la gestion de leur parc. Mais voilà ! me suis aperçu, que le VPN ne fonctionne que dans le "bon" sens! (flèche rouge)

Je m'explique :



Dans l'autre sens, je n'arrive à rien l'option NAT-T est bien activé dans la configuration des tunnels.

Une idée... du pourquoi ?

Vire le NAT-T ça fou la merde

Mais je comprends pas trop ton problème

lan client ping pas lan support ? ils sont sur le même réseau ? les routes sont bonnes ?

la freebox n'est pas transparente en NAT-T (coté serveur)
http://forum.pfsense.org/index.php?topic=14530.0

donc normal que tu puisse te connecter en tant que client mais pas en tant que serveur

Mais je comprends pas trop ton problème

A partir du LAN CLIENT aucun accès au LAN SUPPORT...

lan client ping pas lan support ?

non

ils sont sur le même réseau ?

Non, sinon le vpn ne monte pas...

les routes sont bonnes ?

Oui

la freebox n'est pas transparente en NAT-T (coté serveur)
http://forum.pfsense.org/index.php?topic=14530.0
donc normal que tu puisse te connecter en tant que client mais pas en tant que serveur

Ah d'accord... merci pour l'info.

donc en clair:
ping de support vers client OK
ping de client vers support KO

t'as une merde dans tes routes, j'en ai fait l'experience ya 15 jours

Ah! avais compris que c'était impossible à mettre en place vu que la Freebox ne gère pas le NAT-T

Bon bah reste à trouver les bonnes routes alors ?

S'agit de pfsense de chaque côté.

LAN SUPPORT / pfsense :

Virtualisé sous ESXi
Firewall off : Note: This converts pfSense into a routing only platform! Note: This will turn off NAT!

LAN CLIENT / pfsense :

Virtualisé sous VMware Server
Configuration classique...

mon precedent post signifiait que tu ne pouvais pas faire serveur IPsec coté freebox vu qu'elle n'est pas "transparente".

concernant ton problème:
si ça ping dans un sens, c'est que les routes sont en partie bonnes (les paquets vont bien dans un sens puis dans l'autre pour l'ACK)
ce qui doit te manquer ou que tu as de faux c'est uen route qui envoie vers la mauvaise gateway a partir de chez ton client.

faut pas oublier qu'un ping c'est uen trame qui part vers la destination et une qui repars vers toi avec la réponse

PS: wireshark est ton ami, perso ça m'a permis de savoir ou je buggais (trame ICMP qui passe mais pas le ACK dans mon cas car je routais vers internet au lieu de laisser passer dans le tunnel)

Bon bah c'est parti! Wireshark en cours d'installation...

De plus en plus étrange...

Source : LAN CLIENT / Serveur
Destination : LAN SUPPORT / Poste de travail

Réponse de ... ok

Mais erreur dans Wireshark
Source : LAN CLIENT / Serveur
Destination : LAN SUPPORT / Serveur A

Délai d'attente de la demande dépassé.
Même erreur, mais pas le même résultat...

Edit : l'erreur "IP checksum offload" peut être supprimée en désactivant l'option "Checksum Offload" de votre carte réseau.

c'est quoi l'OS sur ta station et ton serveur ?
http://support.microsoft.com/kb/885407

Station : XP Pro SP3
Serveur : Serveur 2003 R2 SP2

Résolu !

Pour que les sites distants puisse accéder aux ressources du LAN SUPPORT, côté LAN SUPPORT serveur, station,etc... doit avoir le pfsense en passerelle et non la freebox.

Au départ pourque cela fonctionne dans le sens SUPPORT vers CLIENT, ajoutais la route manuellement (route add).

ah Bah oui, evidament

Pour ceux qui auraient aussi un soucis un jour, tracert ou traceroute sont très utiles

Sacré boulet te l'accorde [:akane:1]

Ah! avais compris que c'était impossible à mettre en place vu que la Freebox ne gère pas le NAT-T

Bon bah reste à trouver les bonnes routes alors ?

S'agit de pfsense de chaque côté.

LAN SUPPORT / pfsense :

Virtualisé sous ESXi
Firewall off : Note: This converts pfSense into a routing only platform! Note: This will turn off NAT!

LAN CLIENT / pfsense :

Virtualisé sous VMware Server
Configuration classique...

mince ta config des pfsense m'aurait intéressée du coup, mais sir firewall /off pas trop