0

I have employed strongSwan U5.5.1 for installing an IPsec tunnel between two Debian hosts with a firewall in between. My ipsec.conf specifies authby=secret but not ah=. The firewall currently permits ESP (protocol 50) and UDP/500 (ISAKMP), UDP/4500 (NAT-T), but not yet AH (protocol 51).

My question is this: if I want to prevent men-in-the-middle attacks, does authby=secret suffice or do I have to activate AH is well? In other words: do authby= and ah= address the same or different kinds of authentication in the IPsec protocol stack?

1

These options serve a different purpose.

authby specifies an authentication method that is used during IKE. secret sets it to pre-shared keys (PSK), which need to be strong to be secure (they are otherwise vulnerable to active attackers). IKE security associations (SAs) are used to negotiate ESP or AH SAs between the two authenticated peers.

ah causes the negotiation of an Authentication Header (AH) SA, which can be used to integrity protect and authenticate actual IP traffic. However, the AH protocol does not provide confidentiality, i.e. traffic won't be encrypted, and it won't work over NATs because the addresses in the IP header are included in the Integrity Check Value (ICV).

For both confidentiality and integrity protection/authentication use the Encapsulating Security Payload (ESP), which is the default in strongSwan (specific algorithms can be configured using the esp option). It doesn't protect the outer IP header, like AH does, but it works over NATs.

Note that strongSwan does not support the combination of the two protocols, that is, the ah and esp options are mutually exclusive.

  • Yes, as I explained, one controls an aspect of IKE, the other enables AH (you might want to read up on how IKE and IPsec work). Not sure what you are getting at with that question about redirection (AH packets can be redirected too). Not sure if racoon supports the combination of both (but it only supports IKEv1 and is unmaintained anyway). Libreswan doesn't support it, as that mode of operation is not recommended anymore per RFC 8221, section 4. – ecdsa Sep 3 at 12:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.