<div dir="ltr"><div><div><div>Hello Martin,<br><br></div>Thank you very much for your reply. <br></div>I think is an interesting scenario, even though Transport mode is not made to act as Tunnel mode. <br></div><div>Also,  is good to know that StrongSwan supports transport-proxy mode for Mobile IPv6. <br></div><div><br></div>Regards<br><div><div><div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Daniel Palomares<br><br></div></div></div>
<br><div class="gmail_quote">2015-02-20 14:52 GMT+01:00 Martin Willi <span dir="ltr"><<a href="mailto:martin@strongswan.org" target="_blank">martin@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>
<br>
> [...] think of a typical Site-to-Site scenario where Subnets are<br>
<span class="">> protected by their respective gateways.<br>
><br>
> However, the expert told me that it is possible to use Transport Mode<br>
> instead of Tunnel Mode for this scenario a well.<br>
<br>
</span>As the endpoints that communicate from within the subnets are different<br>
from the gateways that apply encryption, usually tunnel mode is used.<br>
This allows the gateways to communicate with their addresses, and hide<br>
the endpoint addresses in encrypted tunnel mode packets.<br>
<span class=""><br>
> For this Use Case to happen, the gateways must not encapsulate the entire<br>
> IP packets (as Tunnel Mode does) but just need to do the routing task and<br>
> cipher the data. It means that the gateways cipher the L4-7 data without<br>
> changing the original IP header.<br>
<br>
</span>Theoretically this could work, where each gateway intercepts packets and<br>
en/decrypts them as a man in the middle. So this would be some kind of<br>
transparent inline encryption; if routing your subnets works outside of<br>
these subnets, that could work.<br>
<br>
With IKE(v2), however, the ESP packet addresses (both in tunnel and<br>
transport mode) are implicitly the same addresses used for IKE<br>
negotiation. This implies that you can't actually negotiate SAs from<br>
your gateway for your inner subnet addresses, unless you mangle IKE<br>
addresses as well (or do other tricks).<br>
<span class=""><br>
> 1. Have anyone seen this Use Case working before? If yes, How/Which<br>
> implementation/hardware does so?<br>
<br>
</span>I didn't.<br>
<span class=""><br>
> 2. I know that Transport Mode is used for End-Point to End-Point<br>
> communications where data plane is generated from/to end-points. But, Does<br>
> StrongSwan support this kind of Site-to-Site communications in Transport<br>
> Mode?<br>
<br>
</span>What we support in strongSwan is a transport-proxy mode for Mobile IPv6,<br>
refer to the ipsec.conf manpage type keyword. It basically allows the<br>
IKE daemon to use the Care-of-Address, but negotiate SAs for the Home<br>
Address. Policy installation is up to a Mobile IP daemon, though. From<br>
our NEWS:<br>
<br>
> - Basic Mobile IPv6 support has been introduced, securing Binding Update<br>
>   messages as well as tunneled traffic between Mobile Node and Home Agent.<br>
>   The installpolicy=no option allows peaceful cooperation with a dominant<br>
>   mip6d daemon and the new type=transport_proxy implements the special MIPv6<br>
>   IPsec transport proxy mode where the IKEv2 daemon uses the Care-of-Address<br>
>   but the IPsec SA is set up for the Home Address.<br>
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888">Martin<br>
<br>
</font></span></blockquote></div><br></div></div>