<div dir="ltr">Thanks for the Answer Tobias,<div><br></div><div>I got it. </div><div><br></div><div>Daniel</div><div><br></div><div class="gmail_extra"><div class="gmail_quote">2015-07-23 19:35 GMT+02:00 Tobias Brunner <span dir="ltr"><<a href="mailto:tobias@strongswan.org" target="_blank">tobias@strongswan.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Daniel,<br>
<span class=""><br>
> I still have one question which is not very clear in my mind.<br>
><br>
> Does this patch allows Subnet-to-Subnet Transport Mode or Does it allows<br>
> Host-to-Subnet Transport Mode?<br>
<br>
</span>Neither.  This is to simplify configuration of fully-meshed VPNs between<br>
a number of peers.  IKE and IPsec SAs between the peers are established<br>
on demand based on the traffic between them.<br>
<span class=""><br>
> The scenario I want to test is the Following:<br>
><br>
> Subnet A  ------    Strongswan GW ---------------  WAN Netwroking<br>
> ---------------- Strongswan GW ---------------  Subnet B.<br>
><br>
> In this particular use case, is it possible to create a single Transport<br>
> Mode IKEv2/IPsec session between both Strongswan's Gateways so both<br>
> subnets can communicate securely?<br>
<br>
</span>No, that's currently not possible with strongSwan.  This scenario is<br>
just what tunnel mode is for (or GRE over a transport mode IPsec SA).<br>
<br>
IPsec SAs are usually identified by the Protocol, SPI and destination<br>
address (and often even the source address).  So to decrypt packets<br>
from/to all hosts transparently a gateway would have to install a whole<br>
bunch of duplicate SAs (same SPIs, same keys, but different addresses),<br>
at least as long as the OS' IPsec stack does not have support for this.<br>
 Not sure if that would even work, but I doubt it would scale well.<br>
<br>
Regards,<br>
Tobias<br>
<br>
</blockquote></div><br></div></div>