NAT 1:1

[Holonsys]

Bonjour à tous,

L'arrivée de notre SDSL de chez completel nous permet d'utiliser 6 IPs publiques ; je souhaite en utiliser 2.
J'ai donc installé une nouvelle version (v2.0RC3) sur une nouvelle machine (Dell Poweredge 1600SC) afin de faire mes essais
J'ai bien déclaré mes interfaces pour mes deux FAIs (ORANGE et COMPLETEL) et en changeant manuellement la passerelle par défaut, j'accède bien à Internet.

Maintenant je veux lier deux de mes six IPs publiques à deux serveurs sur mon réseau local ; je crée la règle NAT 1:1

Interface   External IP Internal IP       Destination IP Description
COMPLETEL    92.x.y.154 192.168.90.112       *         NAT svr1
COMPLETEL    92.x.y.155 192.168.90.118       *         NAT svr2

Ensuite je déclare mes règles de NAT Port Forward pour que mes serveurs puissent dialoguer sur leur propre adresse. Je commence par le srv1 :
If               Proto Src. addr  Src. ports Dest. addr         Dest. ports  NAT IP       NAT Ports
COMPLETEL TCP *       8087         92.103.113.155 8087                  192.168.90.112 8087
COMPLETEL TCP * 3389 (MS RDP) 92.103.113.155 3389 (MS RDP) 192.168.90.112 3389 (MS RDP)
COMPLETEL TCP * 80 (HTTP)         92.103.113.155 80 (HTTP)         192.168.90.112 80 (HTTP)

Résultat, je vois bien dans les logs qu'il tente de se connecté, mais on dirait que mon serveur me reçoit rien comme information…

Pourriez-vous me dire d'où viendrait le problème ?

Amicalement,

Fabrice.

[ccnet]

Pour http et rdp le nat 1:1 est inutile. Un transfert de port suffit puisque ces serveurs n'ouvrent pas de connexion vers l'extérieur. Pour le 8087 je ne sais pas. Si 192.168.90.112 n'ouvre pas de connexion vers l'extérieur c'est inutile aussi. Par ailleurs les règles d'accès sur les Wan sont elles en place ?
dans vos règles "Nat port forward" je crains que la valeur dans port source, pour http et rdp, ne soit pas adaptée.
Lire : http://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense%3F

[Holonsys]

Bonjour ccnet, merci d'avoir pris le temps de me répondre.

Par ailleurs les règles d'accès sur les Wan sont elles en place ?
Là, j'avoue ne pas vous suivre…

dans vos règles "Nat port forward" je crains que la valeur dans port source, pour http et rdp, ne soit pas adaptée.
J'ai mis une plage d'adresse, rien n'y fait.

Je suis vraiment dans l'expectative ; comment pfSense saura-t'il qu'il doit associer l'une de mes six adresses publiques à l'IP du serveur de mon choix ?

Autant avec une seule connexion WAN, je n'ai pas de problème de redirection,mais là, j'ai du mal à comprendre.

Amicalement,

Fabrice.

[ccnet]

Là, j'avoue ne pas vous suivre…

Vous devez autoriser sur l'ip publique de destination les connexions vers les ports TCP 80, 3389, 8087.

J'ai mis une plage d'adresse, rien n'y fait.

Je vous parle de port source vous me répondez plage d'adresses …

Si j'en crois le document joint vous n'avez qu'une seule ip publique utilisable. Ou alors ce n'est pas la configuration actuelle.

[Holonsys]

Encore merci pour votre réponse…

J'ai donc décidé de reprendre tout depuis le début afin de mieux comprendre les tenants et las aboutissants.

Mes besoins :
Affectation d'une de nos six adresses publiques (92.x.y.152/29) de notre nouveau FAI Completel à l'un de nos serveurs via le port 80 et 3389 tout en gardant notre interface Orange. J'ai choisi l'adresse 92.x.y.155.
J'ai installé un second pfSense sur mon réseau pour faire mes tests sans interrompre le traffic du routeur de production sous pfSense v1.2.3 selon le schéma suivant :

J'ai donc repris les réglages suivants :

• Attribution des interfaces,
• Réglages des interfaces,
• NAT Outbound,
• Virtual IP ; j'ai laissé tombé le NAT 1:1 sur conseil de ccnet,
• Port forwarding,
• Firewall rules ; généré automatiquement avec la règle de port forwarding.

Je prends le controle d'un poste à distance (ip : 88.x.y.145) et je tente de me connecter à l'adresse publique 92.x.y.155 : demi-echec.
Je regarde le log de ma Firewall Rule pour voir que mon poste se connecte bien sur mon adresse, mais je n'ai que le SYN.

Pas de SYN-ACK ni de ACK.

Une capture de paquet depuis pfSense sur 92.x.y.155 me donne ceci :

07:43:08.277337 IP 88.x.y.145.60704 > 92.x.y.155: tcp 0
07:43:11.205182 IP 88.x.y.145.60704 > 92.x.y.155: tcp 0
07:43:17.241929 IP 88.x.y.145.60704 > 92.x.y.155: tcp 0

Apparemment, mon client peut accéder à mon serveur, mais ce dernier, pour une obscure raison, ne lui répond pas !

Juste pour information, sur le routeur de production, mes règles fonctionnent bien puisque je peux me connecter  à mon serveur avec mon IP Orange.

Toute remarque pertinente serait le bienvenue !

Amicalement,

Fabrice.

[ccnet]

Pardonnez moi, je vous lis rapidement. Prouvez vous observer ce qui se passe sur l'interface du serveur 192.168.90.112 ?
La première chose est de vérifier que le Syn lui parvient bien et voir ce qu'il répond et vers où.
Je ne comprend pas l'utilité du Nat Outbound .
Le serveur 192.168.90.112 devrait être dans une dmz.

[Holonsys]

Encore merci de votre réponse !

Pardonnez moi, je vous lis rapidement. Prouvez vous observer ce qui se passe sur l'interface du serveur 192.168.90.112 ?
La première chose est de vérifier que le Syn lui parvient bien et voir ce qu'il répond et vers où.

Voici la capture réseau effectuée sur le serveur via wireshark portable :

Je ne comprend pas l'utilité du Nat Outbound .

Humm… J'avais vu dans un tuto qu'il était préférable de l'écrire manuellement dans le cas de plusieurs FAIs... Je me trompe peut-être.

Le serveur 192.168.90.112 devrait être dans une dmz.

Je la crée tout de suite. Comme ce serveur est utilisé aussi bien sur le Lan qu'à l'extérieur et que nous n'avons pas de DNS en interne, cela m'évitait de créer des règles supplémentaires… Tant pis !

Fabrice.

[ccnet]

D'après la capture le serveur web répond correctement. Pouvez vous vérifier que cette réponse parvient au client et localiser le 3eme segment segment du handshake TCP ?

Sur ce point :

nous n'avons pas de DNS en interne

Utilisez le DNS Forwarder de Pfsense pour régler le problème. Vous ferez du "DNS split horizon". Le sujet a été abordé plusieurs fois ici.

Humm… J'avais vu dans un tuto qu'il était préférable de l'écrire manuellement dans le cas de plusieurs FAIs... Je me trompe peut-être.

A priori je pense que Pfsense devrait s'en tirez tout seul puisque cette machine n'ouvre pas de connexion sortante mais ne fait que répondre.

[Holonsys]

Bonjour à tous.

Tout d'abord, je tiens à remercier ccnet de la patience qu'il a eu à mon égard et à mes petits problèmes ;) .

Comme je l'avais indiqué auparavant, j'ai installé sur mon réseau de production un second routeur avec pfSense v2.0RC3 pour faire mes tests sur un serveur. Ce dernier était en production sur le réseau local et faisait l'objet d'un accès extérieur avec le routeur de production sous pfSense v1.2.3RC3.
Le serveur possède sa propre adresse statique… Et je n'avais pas pensé à la passerelle !
Je pensais naïvement que l'adresse IP locale du routeur se substituerait  à l'adresse IP publique, mais les captures de paquets montrent qu'il n'en est rien !
Le serveur tentait donc de répondre sur la passerelle qui était écrit en statique, c'est-à-dire, sur le routeur de production et non par le routeur de test...

Dès que l'adresse de passerelle fut changée, tout est revenu dans l'ordre...

J'espère que mon fil de discussion pourra être utile à ceux dont le problème se pose !

Encore un grand merci à ccnet !

Amicalement,

Fabrice.