Differences

This shows you the differences between two versions of the page.

--- doc:appunti:linux:sa:ipsec_strongswan [2021/02/05 16:49] – [File di configurazione] niccolo
+++ doc:appunti:linux:sa:ipsec_strongswan [2024/05/06 16:02] (current) – [Host remoto (right) dietro NAT] niccolo
@@ Line 65: / Line 65: @@
         dpdtimeout=120s
         dpdaction=restart
+        closeaction=restart
+</file>
+L'opzione ''closeaction=restart'' dovrebbe servire a far ripartire la connessione nel caso in cui il remote invii un segnale **DELETE**, altrimenti si rischia che la connessione termini con questo log e non riparta più:
+<file>
+charon: 07[IKE] received DELETE for IKE_SA office1-office2[5]
+charon: 07[IKE] deleting IKE_SA office1-office2[5]
+                between 132.82.168.98[213.182.68.98]...134.191.21.5[134.191.21.5]
+ipsec[30830]: 07[IKE] received DELETE for IKE_SA office1-office2[5]
+ipsec[30830]: 07[IKE] deleting IKE_SA office1-office2[5]
+              between 132.82.168.98[213.182.68.98]...134.191.21.5[134.191.21.5]
 </file>
@@ Line 76: / Line 88: @@
 .191.21.5 132.82.168.98 : PSK "de66979eaa77587d6b0e74d5bf871565"
 </file>
+===== Host remoto (right) dietro NAT =====
+Se l'host remoto è dietro NAT è necessario cambiare la configurazione, altrimenti la SA non si stabilisce e nei log si trova qualcosa del genere:
+<code>
+ipsec[21090]: 05[NET] received packet: from 134.191.21.5[4500] to 213.182.68.98[4500] (224 bytes)
+ipsec[21090]: 05[ENC] parsed IKE_AUTH response 1 [ IDr AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]
+ipsec[21090]: 05[IKE] authentication of '10.151.252.18' with pre-shared key successful
+ipsec[21090]: 05[CFG] constraint check failed: identity '134.191.21.5' required
+ipsec[21090]: 05[CFG] selected peer config 'office1-office2' unacceptable: constraint checking failed
+ipsec[21090]: 05[CFG] no alternative config found
+</code>
+Si vede che l'host remoto ha indirizzo IP 10.151.252.18, ma si presenta dietro NAT dall'IP 134.191.21.5. Nonostante la pre-shared key sia corretta, il controllo di identità dell'host remoto viene considerato fallito.
+Anche questo messaggio è esplicativo: il match dell'host remoto con **IP_pubblico[IP_privato]** fallisce:
+<code>
+ipsec[21090]: 09[CFG] looking for peer configs matching 132.82.168.98[%any]...134.191.21.5[10.151.252.18]
+ipsec[21090]: 09[CFG] no matching peer config found
+</code>
+Nel file di configurazione **office1-office2.conf** va aggiunta l'opzione **rightid** per identificare l'host remoto con il suo IP privato:
+<file>
+    ...
+    right=134.191.21.5
+    rightid=10.151.252.18
+    ...
+</file>
+e quindi nel file delle PSK si deve identificare l'host remoto con il suo IP privato:
+<file>
+# ------- Site 1 Gateway (office1-office2) -------
+.82.168.98 10.151.252.18 : PSK "de66979eaa77587d6b0e74d5bf871565"
+# ------- Site 2 Gateway (office2-office1) -------
+.151.252.18 132.82.168.98 : PSK "de66979eaa77587d6b0e74d5bf871565"5"
+</file>
+In alternativa si dovrebbe poter specificare **%%rightid=%any%%** in modo che un qualunque IP privato venga accettato. La PSK dovrebbe potersi selezionare in quel caso tramite l'IP pubblico.
 ===== Configurazione Shorewall =====
@@ Line 86: / Line 141: @@
 ACCEPT   net:134.191.21.5    $FW    udp     4500
 </file>
+**ATTENZIONE**: In effetti la porta **4500/UDP** viene usata solo se il traffico IPsec deve attraversare qualche apparato che fa **NAT** e che non potrebbe trasportare il protocollo ESP (che non ha porte). In tal caso il traffico ESP viene incapsulato in pacchetti UDP con la porta 4500.
 **/etc/shorewall/tunnels**