Bonjour,
Nous testons actuellement BM, et rencontrons des soucis avec certains modèles de smartphones Android.
Nous souhaiterions savoir si certains membres de la communauté utilisent BM derrière un boitier VPN-SSL Juniper, car c’est ce dernier qui semble poser problème.
Par avance merci.
Quel genre de soucis rencontrez-vous ?
Quelle version de Blue Mind utilisez-vous et sur quelle distribution ?
Tout d’abord voici la topologie :
Internet – FW – Juniper (DMZ) – FW – BM (Interne)
Il s’agit d’une version BM 2.0.6 hebergée sur une Debian Squeeze
Sur le FW il y a un PAT vers le juniper sur le port 443, et le flux entre le Juniper et BM sur le port 443 est autorisé. Il n’y a aucun message d’alerte sur le FW tout au long des tests.
Nous avons utilisé 3 téléphones différents pour tester : 1 Galaxy ACE, 1 Galaxy S2 et 1 Nexus 4 sous Android.
Descriptif des tests : configurer un compte exchange / BM sur les téléphones, autoriser la synchro sur le smartphone dans BM, finir l’enregistrement du compte dans le smartphone.
Test 1 :
Le Juniper est configuré pour ne laisser passer QUE de l’Active Sync sur le port 443.
Résultats 1 :
Galaxy ACE : Apparait dans BM mais impossible de finir la configuration.
Galaxy S2 : Ok.
Nexus 4 : Apparait dans BM mais impossible de finir la configuration.
Test 2 :
Le Juniper est configuré pour laisser passer tout le trafic sur le port 443.
Résultats 2 :
Galaxy ACE : Apparait dans BM mais impossible de finir la configuration.
Galaxy S2 : Ok.
Nexus 4 : Apparait dans BM mais impossible de finir la configuration.
Test 3 :
Changement de Topologie → Internet – FW – BM (Interne)
Résultat 3 :
Galaxy ACE : Ok.
Galaxy S2 : Ok.
Nexus 4 : Ok.
Nous sommes perplexes 
C’est assez étonnant. Avez-vous quelque chose de particulier dans un des fichier de logs de BM-eas /var/log/bm-eas/* ?
Bonjour,
Il y a donc en effet un problème avec vos FW ou reverseproxy. Vos FW doivent surement avoir des timeout plus petits que celui utilisé par Blue Mind sur les connexions HTTP ce qui doit induire ces problèmes.
Vous pouvez régler les timeout de connexion du service de synchronisation mobile en admin0 dans:
Gextion du système, configuration système onglet serveur EAS.
Il faut savoir à combien sont réglés vos firewall pour les régler à la même valeur ou plus petits.
@Toony : Nous pouvons vous fournir des tars du répertoire bm-eas (1 user.log, anonymous.log et eas.log) pour un test qui fonctionne et celui qui ne fonctionne pas pour voir les différences.
@Sylvain : Nous avons bien trouvé l’onglet, par contre, nous ne comprenons pas bien les intitulés des variables… Délais minimum et maximum pour le push … ?? Auriez vous quelques explications sur les mécanismes mettant en œuvre ces variables, et les changements induit par la modification de leur valeur? Merci par avance 
Pour éviter de passer par le Juniper pour la synchro nous souhaiterions savoir si il était simplement possible de changer de port pour l’active sync Je suppose que les modifications apportées au nginx.conf seront écrasées à la prochaine mise à jour ?
Vous pouvez créer un fichier /etc/nginx/conf.d/aes-redirector.conf, contenant:
server {
listen 4443;
server_name bluejob-build.apr-vmnet.loc;
ssl on;
ssl_certificate /etc/ssl/certs/bm_cert.pem;
ssl_certificate_key /etc/ssl/certs/bm_cert.pem;
ssl_session_timeout 5m;
location / {
proxy_pass https://127.0.0.1/;
}
}Puis recharger NGinx:
/etc/init.d/nginx reloadBien que ceci puisse vous permettre de continuer vos tests, nous déconseillons cependant cette solution.
Quel est votre modèle de Juniper ? Avez-vous la possibilité de voir des logs sur celui-ci ? Ne serait-il pas possible de faire de la simple translation d’adresse, il semblerait qu’il analyse le traffic passant sur le port 443 actuellement.
Concernant les timeout réglés au niveau de la console d’administration, il s’agit de définir une plage acceptable pour la durée de vie d’une requête de push. Cette durée de vie est négociée avec le téléphone, et celui-ci renouvelera la requête une fois cette durée atteinte.
Il faut donc s’assurer que vous n’ayez pas un proxy (le Juniper par exemple) qui ait un temps de inférieur au maximum défini dans la console d’administration, car celui-ci pourrait du coups mettre fin à une requête de push à l’insu du téléphone. Dans la configuration de NGinx, ceci correspond à la directive proxy_read_timeout.
Les paramètres proposés par défaut ont été définis en tenant compte des durée maximales acceptées par les opérateurs télépĥoniques, et correspondent bien généralement. Il n’est donc pas nécessaire de toucher aux valeurs de la console d’administration. Par contre il faut vérifier que le Juniper accepte bien des connexions > 1200s.
Merci tout d’abord pour les explications.
Notre modèle de Juniper est un MAG2600, il n’y a aucune erreur dans les logs de ce dernier, autre précision ce boitier ne sert que de VPN-SSL, notre Firewall est un autre boitier d’une autre marque. Nous avons testé de faire une simple translation d’adresse sans l’analyse de protocole Active Sync sur le Juniper, cela ne change pas les résultats. Le pire est que cela marche sur un S2 mais pas sur les autres modèles…
Le PAT sur eas nous évite d’exposer directement le webmail sur Internet, nous passerons toujours via le Juniper pour cela via une autre addresse IP. Nous faisons donc reposer la sécurité de la synchro active sync sur l’enrolement manuel des smartphones, et l’analyse protocolaire de notre Firewall. Après il nous reste la possibilité du VPN entre le smartphone et notre Firewall, mais cela nous semble un peu lourd à gérer, et risque d’être un gouffre en énergie pour les batteries.