3

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)

ecdsa
  • 1,354
  • 7
  • 10
Jens Moser
  • 33
  • 2
  • https://pdfs.semanticscholar.org/7f3f/1177caf0946d4be8b1fa5e59dd63b9e9213a.pdf -- Enjoy –  Jul 14 '18 at 21:55
  • @Joshua. J Thanks for the link to the paper. I know how NAT-T works for IPsec, but nevertheless read this paper. As far as I could see, the paper doesn't mention any special security risks with NAT-T Transport Mode. Which section of the paper are you referring to? – Jens Moser Jul 15 '18 at 01:50
  • Have a look at [section 5.2 of RFC 3948](https://tools.ietf.org/html/rfc3948#section-5.2). – ecdsa Jul 16 '18 at 08:37
  • @ecdsa Thank you. I'm aware of Transport Mode Conflict, but I don't think this is what the strongSwan FAQ actually is referring to. If it was, they could just as well have warned against the use of NAT-T with Tunnel Mode (because of Tunnel Mode Conflict, which is similar, albeit not identical). – Jens Moser Jul 16 '18 at 14:37
  • I think it is, what else would it refer to? The FAQ entry is based on a quote from an email from 2009 (not even available in the mailing list archives anymore), but you see some of it if you go back in the history of the page. The answered question is also specifically about transport mode with Windows and older strongSwan versions, so why would it mention tunnel mode? (The tunnel mode conflict is similar but due to virtual IPs way less common and easily avoidable.) – ecdsa Jul 16 '18 at 15:07
  • @ecdsa Maybe you're right. The FAQ's answer sounds a lot more general than its corresponding question (as if NAT-Traversal with IPsec transport mode had some real security flaws itself). I also was unable to find any research papers in this regard. Would you mind creating an answer based on your comments? Thank you. – Jens Moser Jul 16 '18 at 15:25

1 Answers1

0

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).

Community
  • 1
ecdsa
  • 1,354
  • 7
  • 10
  • Very well explained and a really useful answer. One additional problem with IPsec Transport Mode and NAT-T arises, if there are two or more clients behind the same NAT, talking to the same server, one of them communicating via IPsec, the other communicating in clear text. In many cases this is difficult to impossible to configure, because the server sees both clients coming from the same IP address (the NAT's external IP) and setting up different policies for the same traffic descriptor is impossible. – Jens Moser Jul 17 '18 at 13:06
  • Yes, I didn't explicitly point to that issue (which is also described in section 5.2 of the RFC). But it is illustrated in the mentioned test scenario. – ecdsa Jul 17 '18 at 13:15
  • Btw., I didn't know you are a strongSwan contributor. Thank you for amending the FAQ. I think the FAQ's answer in its original form was indeed a little confusing. Your revised version is a lot clearer now and provides useful additional information on the subject. – Jens Moser Jul 17 '18 at 13:15