VMWare上のFedora9で、eth0(bridge)、eth1(NAT)設定をしているとき、DHCPでのIP取得を行おうとすると、eth0がDHCPに失敗する、という問題がでていた。

結論からいうと、下記許可ルールを追加すると解決する。

ローカル側：UDP 67-68ポート
リモート側：UDP 67-68ポート 信頼ゾーン

非常に気持ち悪いのだが、ひとまず解決策。

追記：
VMWareのIP幅を信頼ゾーンに加えてないと、失敗するかもしれない。未検証。

追追記：
サポートに推奨設定を問い合わせていたが、その返答がきた。曰く、

プロトコル：UDP
方向：内向き
アクション：許可
ローカルポート：68
リモートポート：67

を追加するようにとのこと。これで変なところで引っかからずきちんとファイアウォールを使うことができる。ありがたい。

　毎度毎度、VMWareとPersonal firewall製品との相性には泣かされる。bridgeとして設定したNICが、promiscuos modeで動作することと、(恐らく)Personal firewallが、自身の動作する宛先IP以外を宛先とするパケットを拒否してしまうからなのだが、理由がわかっても回避方法がないことが多い。

　今使っているのは、ESET Smart Security。その昔、NOD32があまり知られていなかった頃に価格.comでの問題を見つけて中の人に連絡したのが懐かしいが、そのNOD32を出しているところのFirewall込み製品だ。これまでは全体的に悪くないなと思って使っていたが、今回VMを外から叩く必要が出てきて問題が発覚した。これも駄目っぽい。
　昔、NOD32＋outpost(だったかSygate Personal firewallだったかどちらか)との組み合わせだとこの問題は回避できたように記憶している。やはり餅は餅屋、Firewall製品はFirewall製品屋で、ということなのだろうか。

　ひとまず今回はfirewall設定を切ることで対処した。やれやれ・・・。

参考サイト：Firewallと森で遊ぼう　このサイト、更新されていないのが本当に惜しい。

vmware workstation 5はずいぶん前にライセンスを購入してあったのだが、ついにVer 6が正式リリースとなったようだ。

それに伴い、これまでEvalutionで使っていたVer 6が使えなくなってしまうことになる。開発業務にかなり高い頻度で使っているのでアップグレードすることに。vmware.comから直接買っているのでUSD99也。

機能も色々増えているようなので追々評価していきたい。