The strongSwan FAQ states:
NAT-Traversal with IPsec transport mode has some inherent security risks.
What kind of security risks is the documentation referring to?
(links to other resources are welcome too)
The strongSwan FAQ states:
NAT-Traversal with IPsec transport mode has some inherent security risks.
What kind of security risks is the documentation referring to?
(links to other resources are welcome too)
I think the answer refers to the Transport Mode Conflict, which is described in section 5.2 of RFC 3948. If two clients behind the same NAT device connect to the same server using Transport Mode this might result in duplicate IPsec policies (i.e. between the NAT device's public IP and the server's IP). This means the server may only be able to send traffic to one of the clients (usually the one that connected last). If the traffic selectors include ports and protocols this issue might be avoided (unless they conflict) and in some cases it's possible to work around it (e.g. by using strongSwan's connmark plugin).
The term "inherent security risk" might be a bit harsh (note that I changed that on the FAQ page in the meantime), which is why newer strongSwan versions support NAT-T with Transport Mode. Although users should be aware of the potential caveats. The ikev2/host2host-transport-nat scenario in strongSwan's regression test suite illustrates two possible problems that could arise when using Transport Mode over NATs.
However, the developers of the FreeS/WAN project, on which strongSwan versions before 5.0.0 were originally based, had some very strict opinions about NAT Traversal with Transport Mode, which is why it had to be specifically enabled with a configure option (i.e. the code was not even compiled in), which is what the rest of the answer in the FAQ explains (if the option wasn't enabled, the error message clearly conveyed their opinion: "NAT-Traversal: Transport mode disabled due to security concerns").
By the way, the FAQ entry's answer is based on a quote form an email by Andreas Steffen (founder of the strongSwan project) from 2009, which, unfortunately, is not available in the mailing list archives anymore. But looking at old versions of the answer in the history of the FAQ page does point to this origin.
For completeness, there is a similar issue with Tunnel Mode over NATs (described in section 5.1 of RFC 3948) if two clients behind different NAT devices with the same private IP address connect to the same server. However, this can easily be avoided by assigning virtual IPs to the clients (which is what's usually done in roadwarrior scenarios).