[strongSwan] [strongSwan-users] When Tunnel mode Becomes Transport Mode

Martin Willi martin at strongswan.org
Fri Feb 20 14:52:40 CET 2015

Hi Daniel,

> [...] think of a typical Site-to-Site scenario where Subnets are
> protected by their respective gateways.
> However, the expert told me that it is possible to use Transport Mode
> instead of Tunnel Mode for this scenario a well.

As the endpoints that communicate from within the subnets are different
from the gateways that apply encryption, usually tunnel mode is used.
This allows the gateways to communicate with their addresses, and hide
the endpoint addresses in encrypted tunnel mode packets.

> For this Use Case to happen, the gateways must not encapsulate the entire
> IP packets (as Tunnel Mode does) but just need to do the routing task and
> cipher the data. It means that the gateways cipher the L4-7 data without
> changing the original IP header.

Theoretically this could work, where each gateway intercepts packets and
en/decrypts them as a man in the middle. So this would be some kind of
transparent inline encryption; if routing your subnets works outside of
these subnets, that could work.

With IKE(v2), however, the ESP packet addresses (both in tunnel and
transport mode) are implicitly the same addresses used for IKE
negotiation. This implies that you can't actually negotiate SAs from
your gateway for your inner subnet addresses, unless you mangle IKE
addresses as well (or do other tricks).

> 1. Have anyone seen this Use Case working before? If yes, How/Which
> implementation/hardware does so?

I didn't.

> 2. I know that Transport Mode is used for End-Point to End-Point
> communications where data plane is generated from/to end-points. But, Does
> StrongSwan support this kind of Site-to-Site communications in Transport
> Mode?

What we support in strongSwan is a transport-proxy mode for Mobile IPv6,
refer to the ipsec.conf manpage type keyword. It basically allows the
IKE daemon to use the Care-of-Address, but negotiate SAs for the Home
Address. Policy installation is up to a Mobile IP daemon, though. From
our NEWS:

> - Basic Mobile IPv6 support has been introduced, securing Binding Update
>   messages as well as tunneled traffic between Mobile Node and Home Agent.
>   The installpolicy=no option allows peaceful cooperation with a dominant
>   mip6d daemon and the new type=transport_proxy implements the special MIPv6
>   IPsec transport proxy mode where the IKEv2 daemon uses the Care-of-Address
>   but the IPsec SA is set up for the Home Address.


More information about the Users mailing list