今回は、
というタイトルで、（いつもどおり、、、？）ハマった話をお送りします。
触っていたのはNSX-V（サポート切れますが）の分散FWなのですが、
気づけば単純、気づかないと、、、ということで、
おおよそ1か月間、色々なポイントを調査し、、、たどり着きました。
事象（結論？）としては、
「分散ファイアウォールでブロックされていた」
なんですが、、、
『勿論、普通に許可するポリシーを入れているのに』ブロックされていたので、
分散FWでブロックされていると断定できずに時間が掛かってしまった。。。というわけですね。
そんなわけで、分散FWの、、、というか、
NSXのService Composer？での処理のされ方？という部分で
そういうことか！と知っていれば引っかからない話が分かったので、
共有します。。。
「分散ファイアウォールのルールに仮想マシンオブジェクトを登録しても
想定通りの動作をしない！！」
いつも通り、（ピンポイントな）限定するキーワードを書いてますが、
通信を許可するセキュリティグループに動的に登録されるようにした仮想マシンが、Service Composerから見てもしっかり登録されているのに通信が行えないという不思議な事象が発生しまして、、、分かったことは、
ということです。
勿体ぶった言い回しになりましたが、
VMware Toolsが把握していないIPアドレスは、ESXi、vCenterでも認識されず、、
結果NSXでも「そんなどこの馬の骨だかわからない…」存在として認識されるわけで、
「分散ファイアウォール」くんとしては「聞いてないものは知らないよ」と、しっかりブロックしてくれるわけですねー。。
（暗黙のdenyが最後に入れてあるホワイトリスト方式で運用してる環境なので。。）
うーん、、「忖度」してほしい。。笑
ということで、今回のこの事象、、、
自分はCitrix社のADC（Application Delivery Controler：旧NetScaler）のVPX（Virtual Appliance版）で起こったわけですが、Sub InterfaceとかをLinuxで有効にしても発生するんじゃないですかね。。
↑ADCは管理用のNSIP（これはToolsに拾われる）の他にSNIP（Subnet IP）と
ADCの中の仮想サーバ（LBだったりICAのリバプロにしたり）が持つVIPがあり
このようなことが発生したというわけです。。。
ひとまず解決して良かった。。。
ということで、
ご参考まで。
