Srongswan : Endpoint derrière un NAT
Dans ce court article, je décris les problèmes que j’ai rencontré (ainsi que des solutions) lors de la configuration du service Strongswan (hebergé sur un VPS) pour la création d’un tunnel IPsec (policy-based) avec un endpoint ASA derrière un NAT.
Configuration de Strongswan
ipsec.conf
conn centos-to-ftd
type=tunnel
auto=start
keyexchange=ikev2
authby=secret
left=10.10.10.10
leftsubnet=192.168.1.0/24
right=20.20.20.20
rightsubnet=10.32.0.0/16
ike=aes256-sha256-modp2048!
esp=aes256-sha256!
aggressive=no
keyingtries=%forever
ikelifetime=28800s
lifetime=3600s
dpddelay=30s
dpdtimeout=120s
dpdaction=restart
ipsec.secret
10.10.10.10 20.20.20.20 : PSK "0123456789ABCDEF"
Je ne publirai pas la configuration coté ASA, elle a peu d’interet pour cet article.
Tout semble prêt, mais lorsque je démarre le service strongswan, le tunnel ne monte pas (bien que l’instruction auto=start soit spécifiée). Il y a une erreure qui empèche la création du tunnel.
En regardant les logs, on peut constater ceci :
Jan 2 21:02:24 09[NET] sending packet: from 10.10.10.10[4500] to 20.20.20.20[4500] (320 bytes)
Jan 2 21:02:24 10[NET] received packet: from 20.20.20.20[4500] to 10.10.10.10[4500] (256 bytes)
Jan 2 21:02:24 10[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) N(MOBIKE_SUP) ]
Jan 2 21:02:24 10[IKE] authentication of '10.31.99.13' with pre-shared key successful
Jan 2 21:02:24 10[CFG] constraint check failed: identity '20.20.20.20' required
Jan 2 21:02:24 10[CFG] selected peer config 'centos-to-ftd' unacceptable: constraint checking failed
Jan 2 21:02:24 10[CFG] no alternative config found
Jan 2 21:02:24 10[ENC] generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
constraint check failed: identity ‘20.20.20.20’ required
Strongswan s’attend à trouver l’IP 10.31.99.13 (la véritable IP du endpoint) dans ipsec.conf mais on ne l’a pas renseigné.
On ne peut pas changer la valeur du champ right par 10.31.99.13, c’est une IP privé et elle sera injoignable depuis internet.
La solution (de contournement) est d’utiliser l’instruction rightid pour renseigner la véritable IP de l’interface servant de source pour le tunnel VPN coté ASA.
conn centos-to-ftd
<#TRUNCATED#>
left=10.10.10.10
leftsubnet=192.168.1.0/24
right=20.20.20.20
rightid=10.31.99.13 # NEW !
rightsubnet=10.32.0.0/16
<#TRUNCATED#>
Nous redemarrons le service strongswan et cette fois le tunnel monte automatiquement au démarage du daemon.
Jan 2 21:04:30 09[NET] sending packet: from 10.10.10.10[4500] to 20.20.20.20[4500] (320 bytes)
Jan 2 21:04:30 10[NET] received packet: from 20.20.20.20[4500] to 10.10.10.10[4500] (256 bytes)
Jan 2 21:04:30 10[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) N(MOBIKE_SUP) ]
Jan 2 21:04:30 10[IKE] authentication of '10.31.99.13' with pre-shared key successful
Jan 2 21:04:30 10[IKE] IKE_SA centos-to-ftd[1] established between 10.10.10.10[10.10.10.10]...20.20.20.20[10.31.99.13]
Jan 2 21:04:30 10[IKE] scheduling reauthentication in 28179s
Jan 2 21:04:30 10[IKE] maximum IKE_SA lifetime 28719s
Jan 2 21:04:30 10[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jan 2 21:04:30 10[CFG] selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
Jan 2 21:04:30 10[IKE] CHILD_SA centos-to-ftd{1} established with SPIs xxxxxx
[root@labfabear strongswan]# strongswan status
Security Associations (1 up, 0 connecting):
centos-to-ftd[3]: ESTABLISHED 2 minutes ago, 10.10.10.10[10.10.10.10]...20.20.20.20[10.31.99.13]
centos-to-ftd{3}: INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: cf879764_i 2fae57a3_o
centos-to-ftd{3}: 192.168.1.0/24 === 10.32.0.0/16
Avec ces résultats nous pourrions penser que tout est opérationnel mais en réalité le tunnel ne se montera correctement que s’il est initié depuis Stronswan.
Si c’est le firewall ASA qui initie le tunnel, cela ne fonctionnera pas et les logs de Strongwan indiqueront ceci :
Jan 2 21:08:45 11[ENC] parsed IKE_AUTH request 1 [ V IDi AUTH SA TSi TSr N(INIT_CONTACT) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Jan 2 21:08:45 11[CFG] looking for peer configs matching 10.10.10.10[%any]...20.20.20.20[10.31.99.13]
Jan 2 21:08:45 11[CFG] candidate "centos-to-ftd", match: 1/20/3100 (me/other/ike)
Jan 2 21:08:45 11[CFG] selected peer config 'centos-to-ftd'
Jan 2 21:08:45 11[IKE] no shared key found for '%any' - '10.31.99.13'
no shared key found for ‘%any’ - ‘10.31.99.13’
Les paquets IKE_AUTH se font jeter par Strongswan sous prétexte qu’il ne trouve pas la pre-shared key correspondant à l’endpoint 10.31.99.13 dans ipsec.secret.
C’est une erreure de ma part, j’ai mis l’adresse internet redirigée par le NAT en tant que remote endpoint alors que j’aurai du mettre la véritable adresse IP présente sur l’interface du firewall ASA.
Pour corriger le problème il suffit de modifier cette ligne:
10.10.10.10 20.20.20.20 : PSK "0123456789ABCDEF"
Comme ceci :
10.10.10.10 10.31.99.13 : PSK "0123456789ABCDEF"
Et plus de problème ! Le tunnel IPsec montera quelque soit le coté qui initie la connexion.