Exchange reverse proxy Ko (OWA TCP_DENIED/403)

cyrcocq

Bonjour,

Je n'arrive pas à faire fonctionner mon owa, ni outlook à travers mon pf sense avec squid et la publication exchange via le reverse proxy.

Contexte : milieu pro, administrateur pro système, mais profane pfsense, age de la solution firewall: nouveau pourtest pour remplacement solution TMG hors d'age...

Besoin : Le but est de publier exchange en utilisant le reverse proxy squid

Schéma plateforme de test::
exchange de prod <-> pfsense <-> PC de test

Sur exchange route statique vers pc de test à travers pfsense
Sur PC de test route statique vers exchange à travers pfsense
Sur PC de test IP résolution IP fixée par fichier hosts vers les noms utilisés (exch2013, autodiscover, owa)
Sur squid DNS paramétré vers DNS internes résolvant ces noms en IP

WAN (modem/routeur/box) : 1. type réseau. 1 IP publique sur pf sense (192.168.87.11)

LAN : 1 (172.17.0.2 le tmg étant en .1) dhcp non concernés, dns local (utilisé par pf sense)

Règles NAT : RAS coté accès messagerie pour owa, autodiscover et rcp/https ou activesync (443 et 80)

Règles Firewall : règles principales:
les régles à prendre en comptes sont celles dfinies par les pages https://www.itwriting.com/blog/9592-publishing-exchange-with-pfsense.html et http://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense.
En gros, des regles autorisant le 443 et le 80 depuis le wan vers pf sense (ici vers tout pour faciliter le réglage) et les régles de publication reverse proxy squid

Packages ajoutés : squid et son reverse proxy

Autres fonctions assignées au pfSense : RAS pour le moment

(Et là je sors un peu du formalisme)

Question : impossible de faire fonctionner owa, autodiscover, client outlook déjà configuré, client exchange sur telephone mobile...
pour le OWA qui est celui sur lequel j'ai le plus creusé, Le client ne se connecte pas avec "accès interdit" ou si la case "If checked, the reverse proxy will reset the TCP connection if the request is unauthorized" est cochée alors "La connexion avec le serveur a été réinitialisée" .
Dans les logs de squid erreur 192.168.87.187 TCP_DENIED/403 https://exch2013.mustinformatique.fr/owa
Dans les journaux du pare feu j'ai bien des autorisations pour des trames sur le ports 443

Pistes imaginées: nombreuses recherches sur le net ayant fait choux blanc (j'ai beaucoup cherché avant de choisir de poster ici et de me plier à la demande de formalisme que je trouve trop contraignante mais j'avoue donner ainsi toutes les infos)

J'ai tenté de m'adresser directement à l'adresse du serveur exchange. Cela fonctionne mais ne passe par par le squid.

J'ai tenté de changer Compatibility mode de modern à intermediaite (et j'ai l'impression que parfois cela a fonctionné pendans quelques secondes suis à ce changement bien que je ne l'ai pas revu lors de mes derniers essais)

Je me demande si le problème vient:

du certificat que j'aurais mal enregistré. J'utilise sur mon exchange un certificat multi-hotes (dont le nom principal est exch2013.mondomaine.fr) fourni par globalsign. Il m'a été fourni avec un certificat intermédiaire. il m'a fallu me battre pour transformer mon certificat sous forme de pfx vers le format voulu... Mais ma dernière tentative (je l'ai fait plusieurs fois) correspond à ce qui est sur la procédure de http://www.moh10ly.com/blog/pfsense/publishing-exchange-on-pfsense. passant par Digicert's tool.
Pour ce qui est du certificat intermédiaire, j'ai tenté de le mettre au niveau ACs (de système/gestionnaire de certificats ou au niveau Intermediate CA Certificate (If Needed)) ou de PaquetReverse Proxy Server: GeneralGeneral sans plus de succès.
du fait que je ne renseigne nulle part que le reverse proxy exchange doit s'appuyer sur le nom exch2013 et non sur mail comme je l'ai vu sur la plupart des sujets que j'ai pu trouver sur ce problème.
D'un réglage de mon exchange non conforme avec ce que veut pf sense qui serait différent de ce que veux TMG
Quand au log, je me demande si ce 192.168.87.187 TCP_DENIED/403 https://exch2013.mustinformatique.fr/owa m'indique bien que c'est squid lui même qui a réfusé ( avec wireshark je ne vois d'ailleurs pas de trames 443 arriver sur mon exchange pendant mes tentative par contre, de temps à autre, je vois arriver des trames venant du pfsense mais non synchronisées avec mes demandes... Squid établirait il le contact avec le serveur indépendamment des demandes qu'on lui fait... ou peut être ai-je mal interprété quelques trames)

Voila, je suis perdu.
Qu'en pensez vous?
J’espère que quelqu'un va m'apporter une réponse... J'ai mon boss qui m'allume parce que cela fait plusieurs mois que je dois mettre cela en place...

Merci de m'avoir lu déjà...

ccnet

Tous nos remerciement pour avoir fourni le niveau d'information nécessaire à la compréhension de votre problème.

Sur le point 3, il semble en effet que Squid refuse cette connexion.

Il y a quelques années j'ai été confronté à un problème similaire : proxifier les services d'Exchange.
Comme Microsoft ne fait rien comme tout le monde et notamment ne respecte pas certains standard, les choses ne sont pas toujours simple.
La solution que j'envisageai à l'époque était différente sur le plan architecturale dans le sens où à mon sens il est exclu de concentrer tous ces services sur une machine unique, qui plus est le firewall de l'entreprise. C'est contraire au principe de défense en profondeur. Et il y a de bonne raisons pour cela (ce principe). La solution envisagée reposait sur Vulture. Celui-ci n'a pas donné satisfaction, en particulier à cause de la difficulté à réécrire des urls pour faire fonctionner les services Exchange au travers d'un reverse. Non pas que Vulture ne sache pas le faire, mais à cause du manque de documentation.
J'ai donc fini par utiliser autre chose : Kemp. La solution existe en apliance physique, en VM et en apliance cloud. Et, cerise sur le gâteau, il existe une version gratuite. Sa limitation réside dans la bande passante wan à 20 Mbits/sec.
La mise en œuvre prend moins de deux heures quand on ne connait pas le produit. La config nécessaire pour proxifier les services Exchange est disponible, comme beaucoup d'autres, sous la forme d'un fichier à importer.
Pour vous mettre sur la piste :
https://support.kemptechnologies.com/hc/en-us/articles/207896256-Microsoft-Exchange-2016

cyrcocq

Bonjour,

Merci pour cette réponse.
Donc nous sommes d'accord, ce serait Squid lui même qui refuse la connexion...
Mais pourquoi?
Parce que j'ai un problème de certificat? Comment pourrais-je le tester?
Parce que je ne passe pas par un nom qui lui plait? Comment le vérifier?

jdh

Sur ce forum, il y a (plus qu')un expert qui répond, c'est ccnet. Je recommande de suivre ses conseils, parce qu'ils sont bons, sages, et adaptés.

Ici ccnet répond sur

la position du reverse proxy : il ne FAUT PAS imaginer utiliser le package Squid de pfSense, c'est une erreur ou une voie sans issue !
il propose une solution fonctionnelle 'mise en place en 2h par quelqu'un qui ne connait pas' (c'est dire la complexité).

Squid est un package, c'est à dire un module ajoutable à pfSense, mais qui ne fait pas partie de pfsense car développé par un/des tiers.
C'est un produit complexe (proxy ou reverse proxy), qui demande une certaine expertise quand on utilise des fonctions pointues (reverse p.e.). Alors utiliser un package tel Squid est une gageure.

Reverse proxy pour Exchange est en plus une difficulté (même Vulture n'y parvient pas aisément !). Alors une solution opérationnelle, ça s'essaye ...

cyrcocq

Bonjour,
Déjà, j'ai trouvé...
Squid/pfsense est effectivement mal foutu:
Les URL qu'il autorise sont celles qui commencent par ce qui est dans le champ external FQDN!!! (+ autodiscover)

Ensuite, je me range à vos arguments...
Mais Point de version gratuite chez Kemp... Et je ne peux déclencher cet achat avant quelques mois...
J'ai lu
que exchange était désormais suffisamment robuste pour recevoir lui mème les requetes sans qu'elle passent par un proxy.
que IIS pouvait faire du reverse proxy lui meme.

Que préconiseriez vous dans mon cas?

Merci.
Qu'on pouvait utiliser squid/Linux...

jdh

Je m'occupe de l'infra d'un groupe muti-sites (en cours d'intégration).
Ainsi j'ai une certaine variété de firewall, de messagerie, de ...

J'ai plusieurs Exchange : certains avec relais mail, d'autre non, et tous sans reverse proxy pour la partie HTTPS. Donc je sais que c'est mal.

Le minimum c'est d'avoir un relais mail, et ça c'est assez facile : une debian avec Amavis/SpamAssassin/Clamav (ou, mieux, RSpamd).
Ensuite, il faudrait un reverseproxy pour https (OWA et ActiveSync alias EAS pour les smartphone). Mais à partir d'Outlook 2013, il y a possibilité d'utiliser EAS aussi quand on n'a pas d'accès direct par réseau local ou presque, il ne faut pas l'oublier !

IIS en reverse proxy, oui bien sûr, mais quel contrôle ? Je ne vois aucun contrôle possible avec IIS, mais je ne suis pas spécialiste.

A minima, essayer avec un Squid en reverse proxy sur une bête Debian. Mais autant c'est simple en http, autant le problème de certificat complique le problème en https. L'idéal serait de savoir si Exchange peut faire OWA et EAS sans https, parce que le problème du certificat serait ainsi limité au reverse proxy.

C'est hors scope, mais je préconise fortement un relais mail.
Rien que pour tracer les mails entrants et sortants, parce que voir quelque chose sur le serveur Exchange, bon courage ...