基本的なところから入りますが、IPSecはGREやPPPoE、L2TPのような「普通」のトンネルではない、というところが重要です。「普通」とはどういうことかというと、例えばL2TPの場合、トンネルの終端デバイス上で、ppp0とかそういった名前の仮想インターフェースが立ち上がりますよね。その仮想インターフェースは、手動の場合もあればIPCP等の自動割り当ての場合もあるでしょうがIPアドレスを割り当てることができて、そのIPアドレスがデバイスのルーティングテーブルに乗るのであって、データの伝送にトンネルを使うかを決定するのはルーティングテーブルです。つまり、普通のインターフェースのように扱えます。
IPSecは違います。IPSecトンネルを使うかどうかを決めるのは、レイヤ的にはIPより上、処理順序としてはルーティングテーブル検索より前に発生するService Policy Database (SPD) の検索です。SPDは、対向IPアドレスごとにBYPASS（何もしない）、DISCARD（パケットを破棄）、SECURE（暗号化）の３つしか選択肢がないという素っ気ない表です。この表を検索して暗号化するかを決め、さらにSecurity Association Database (SAD) の鍵データを使って暗号化した後にやっとルーティングテーブルで検索して出方路が決まります。
そんなわけで、IPSecトンネルにはipsec0みたいな仮想インターフェースはないし、それ用にIPアドレスを割り当てることもないのです。今となっては、なんとまあ面倒なことをしてくれたと思いますが、RFC2401 (Google翻訳) が世に出た1998年当時としては、これが自然な発想だったのかもしれません。
NATトラバーサル
いちばん簡単な、IPSecトランスポートモードで一対一で通信するモデルで説明します。例えばこんな構成。
serverとIPSecを喋っているpc1と同じNATの下に、同じserverと普通のTCPを喋るpc2がいます。往路、つまりpc2からserverへのトラフィックはちゃんと通るのです。問題は復路、つまりserverからpc2への応答トラフィックがserverのSPDにヒットしてしまい、ESPに暗号化されて返ってくるのです。当然pc2との通信は成立しません。そんなわけでpc1とserverがIPSec通信している間だけpc2とserverの通信が途切れます。。。（イマココ）
参考文献
RFC3947
T. Kivinen, et al. (2005)
Negotiation of NAT-Traversal in the IKE
https://tools.ietf.org/html/rfc3947 (Google翻訳)