Routenbasiertes und richtlinienbasiertes IPSec

Bei routenbasiertem IPSec konfigurieren Sie keine Verkehrsselektoren (auch als lokale und entfernte Präfixe bezeichnet) und konfigurieren stattdessen eine VTI-Schnittstelle. Darüber hinaus konfigurieren Sie manuell statische Routen für entfernte Subnetze, deren nächster Hop auf diese Schnittstelle gesetzt ist.

Für richtlinienbasiertes IPSec auf der Vyatta konfigurieren Sie lokale und entfernte Präfixe und konfigurieren keine routingfähige Schnittstelle für den Tunnel. Die VFP-Schnittstelle wurde als Funktion hinzugefügt, um eine routingfähige Schnittstelle zu richtlinienbasierten IPSec-Konfigurationen hinzuzufügen. Damit entfällt die Notwendigkeit, zu einer routenbasierten Konfiguration zu migrieren, um NAT und granularere Firewall-Regeln mit richtlinienbasierten Tunneln zu nutzen.

Um mehr über die Unterschiede zwischen routenbasiertem und richtlinienbasiertem IPSec zu erfahren, lesen Sie den Artikel IPsec site-to-site VPN Konfigurationsoptionen.

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
set security vpn ipsec site-to-site peer 159.8.98.213 authentication id 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 159.8.98.213 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 159.8.98.213 authentication remote-id 159.8.98.213
set security vpn ipsec site-to-site peer 159.8.98.213 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 159.8.98.213 local-address 169.50.194.197
set security vpn ipsec site-to-site peer 159.8.98.213 vti bind vti2
set security vpn ipsec site-to-site peer 159.8.98.213 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.5/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.127.132.128/26 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 2 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

#PHASE 1
set security vpn ipsec ike-group IKE-Fergie ike-version 2
set security vpn ipsec ike-group IKE-Fergie lifetime 28800
set security vpn ipsec ike-group IKE-Fergie proposal 1 dh-group 20
set security vpn ipsec ike-group IKE-Fergie proposal 1 encryption aes256
set security vpn ipsec ike-group IKE-Fergie proposal 1 hash sha2_256

#PHASE 2
set security vpn ipsec esp-group ESP-Fergie pfs dh-group20
set security vpn ipsec esp-group ESP-Fergie proposal 1 encryption aes128gcm128
set security vpn ipsec esp-group ESP-Fergie proposal 1 hash null
set security vpn ipsec esp-group ESP-Fergie lifetime 3600

#Tie it all together configuration
et security vpn ipsec site-to-site peer 169.50.194.197 authentication id 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 authentication mode pre-shared-secret
set security vpn ipsec site-to-site peer 169.50.194.197 authentication pre-shared-secret '*********'
set security vpn ipsec site-to-site peer 169.50.194.197 authentication remote-id 169.50.194.197
set security vpn ipsec site-to-site peer 169.50.194.197 ike-group IKE-Fergie
set security vpn ipsec site-to-site peer 169.50.194.197 local-address 159.8.98.213
set security vpn ipsec site-to-site peer 169.50.194.197 vti bind vti2
set security vpn ipsec site-to-site peer 169.50.194.197 vti esp-group ESP-Fergie

#VTI INTERFACE CREATION
set interfaces vti vti2 address 172.16.0.6/30

#STATIC ROUTE CREATION FOR REMOTE PREFIX
set protocols static interface-route 10.165.125.112/28 next-hop-interface vti2

#HA considerations - group number can be different on each Vyatta
set interfaces bonding dp0bond1 vrrp vrrp-group 1 notify 'ipsec'

#IKEv2 considerations
set security vpn ike make-before-break

Schnittstellenbasierte Firewalls mit routenbasiertem IPsec

Wenn Sie Firewall-Regelsätze auf Ihre Schnittstellen anwenden, sollten Sie sich darüber im Klaren sein, welche Quell- und Ziel-IPs ein Paket hat, wenn es an einer Schnittstelle ein- und ausgeht. Das folgende Diagramm veranschaulicht ein typisches Paket, das den Vyatta auf dem Hin- und Rückweg durch einen IPSec-Tunnel durchläuft.

Die OUT-Richtung für eine VTI ist die Richtung, in der das Paket verschlüsselt und aus dem Vyatta gesendet wird. Die IN-Richtung für eine VTI ist der Ort, an dem das Paket entschlüsselt und an den Server hinter dem Vyatta gesendet wird. Für die äußere Schnittstelle, dp0bond1, wird das Paket immer die IP-Adressen der Peer-Endpunkte enthalten. Die Ports/Protokolle sind ESP, UDP-Port 500 und UDP-Port 4500 (wenn Sie NAT-T verwenden).

Die Quell- und Ziel-IP in einem Paket für die IN-Richtung einer VLAN-Schnittstelle (VIF) sollte mit der OUT-Richtung für die VTI übereinstimmen.

Die folgenden Firewall-Regelprotokolle veranschaulichen den Ablauf:

May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond1 PASS fw rule PubIn:1 proto=(other/50) addr=198.11.194.155->159.8.98.214 macs=e4:c7:22:63:b5:41->0:0:5e:0:1:2 v4=(len:156,ttl:241,tos:00,ecn:Not,prot:50,hl:5)
May 25 05:34:07 gateway02 dataplane[4391]:  In:vti0 PASS fw rule INipsecvti0:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond0.1750 PASS fw rule OUTipsec1750:10 proto=(icmp/1) addr=10.90.72.203->10.126.19.174 v4=(len:84,ttl:62,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRq,type:8,code:0)
May 25 05:34:07 gateway02 dataplane[4391]:  In:dp0bond0.1750 PASS fw rule INipsec1750:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:64,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:vti0 PASS fw rule OUTipsecvti0:10 proto=(icmp/1) addr=10.126.19.174->10.90.72.203 v4=(len:84,ttl:63,tos:00,ecn:Not,prot:1,hl:5) icmp=(EchoRp,type:0,code:0)
May 25 05:34:07 gateway02 dataplane[4391]: Out:dp0bond1 PASS fw rule PubOut:1 proto=(other/50) addr=159.8.98.214->198.11.194.155 v4=(len:156,ttl:255,tos:00,ecn:Not,prot:50,hl:5)

Zonenbasierte Firewalls mit routenbasiertem IPSec

Bei zonenbasierten Firewalls sollten die von Ihnen definierten Richtlinien davon ausgehen, dass der Verkehr zwischen der VTI-Schnittstelle und dem lokalen privaten VLAN-Interface (VIF) des VRA fließt. Sie müssen keine Richtlinie zwischen der VTI und den dp0bond1 Zonen definieren.

Grundlegende Fehlersuche

Um Probleme mit der IPSec-Tunnelkonfiguration zu beheben, gehen Sie wie folgt vor:

1. Setzen Sie die Tunnel zurück und starten Sie das VPN neu.

   Tun Sie dies nach Möglichkeit zuerst, da dies bei einem Stromausfall Zeit sparen kann. Vergewissern Sie sich, dass Sie sich merken, was die einzelnen Befehle auslösen und welche Auswirkungen sie auf die übrigen Tunnel haben.

2. Prüfen Sie, ob eine durchgehende Netzwerkverbindung zwischen den Peers besteht.

   Stellen Sie sicher, dass die UDP-Ports 500 und 4500 (bei Verwendung von NAT-T) und das ESP-Protokoll an der äußeren Schnittstelle für beide Peers zugelassen sind.

3. Prüfen Sie den Status von Phase 1. Ein "Down"-Status könnte bedeuten:

   • Sie haben Schritt 2 nicht überprüft
   • Es gibt nicht übereinstimmende IKE-Versionen, Verschlüsselungsalgorithmen, Hash-Algorithmen oder IKE-Bezeichner
   • Es gibt Hersteller-Inkompatibilitäten

4. Überprüfen Sie den Status von Phase 2. Ein "Down"-Status (oder überhaupt kein Status) könnte bedeuten:

   • Phase 1 ist ausgefallen
   • Es gibt nicht übereinstimmende Verschlüsselungsalgorithmen, Hash-Algorithmen, Verkehrsselektoren oder dh-Gruppen
   • Es gibt Hersteller-Inkompatibilitäten

5. Durchsuchen Sie die verfügbaren IPsec-Protokolle nach Hinweisen auf das Problem. Die Protokolle können Ihnen genaue Informationen über Fehlanpassungen geben und Ihnen helfen, das Problem schnell zu lösen.

6. In den VRA-Software-Patches finden Sie Informationen zu häufigen Fehlern. Sie können auch eine umfassende PDF-Datei beim IBM Cloud Security Support anfordern.

show vpn ike sa
show vpn ike sa peer <Peer IP>

vyatta@siferguson-par01-02:~$ show vpn ike sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    State    Encrypt       Hash    D-H Grp  A-Time  L-Time IKEv
    -----  ------------  --------  -------  ------  ------ ----
    up     aes256        sha2_256  14       2154    3600    2

show vpn ipsec sa
show vpn ipsec sa peer <Peer IP>

vyatta@siferguson-par01-02:~$ show vpn ipsec sa peer 169.50.194.197
Peer ID / IP                            Local ID / IP
------------                            -------------
169.50.194.197                          159.8.98.213

    Tunnel  Id          State  Bytes Out/In   Encrypt       Hash      DH A-Time  L-Time
    ------  ----------  -----  -------------  ------------  --------  -- ------  ------
    vti     44          up     284.3M/27.2G   aes128gcm128  null      n/a 2131    300

show vpn debug peer <Peer IP>

vyatta@siferguson-par01-02:~$ show vpn debug peer 169.50.194.197
peer-169.50.194.197:  159.8.98.213...169.50.194.197  IKEv2
peer-169.50.194.197:   local:  [159.8.98.213] uses pre-shared key authentication
peer-169.50.194.197:   remote: [169.50.194.197] uses pre-shared key authentication
peer-169.50.194.197-tunnel-vti:   child:  0.0.0.0/0 === 0.0.0.0/0 TUNNEL
peer-169.50.194.197[48]: ESTABLISHED 38 minutes ago, 159.8.98.213[500][159.8.98.213]...169.50.194.197[500][169.50.194.197]
peer-169.50.194.197[48]: IKEv2 SPIs: 65967eb4beab8549_i 1eacdfa5f926b9a3_r*, pre-shared key reauthentication in 13 minutes
peer-169.50.194.197[48]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
peer-169.50.194.197-tunnel-vti{44}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: 9796e1b4_i db89cc43_o
peer-169.50.194.197-tunnel-vti{44}:  AES_GCM_16_128, 31436172664 bytes_i, 322001309 bytes_o, rekeying active
peer-169.50.194.197-tunnel-vti{44}:   0.0.0.0/0 === 0.0.0.0/0

show log vpn ipsec
show log vpn ipsec subsystem ike-sa site-to-site peer <Peer IP>
journalctl -f -u strongswan #This live follows the end of the journal logs for ipsec
journalctl -u strongswan > /home/vyatta/journalctl-ipsec-$(date +%Y%m%d) #this creates a file so that you can parse/grep through the logs without them rotating

 reset vpn ipsec-peer <Peer IP> #reset all tunnels/phase 2's on this peer
 reset vpn ipsec-peer <Peer IP> tunnel <tunnel id> #reset phase 2 tunnel for only the specified tunnel on the specified peer
 restart vpn #This restarts the entire IPSec VPN subsystem - this affects all tunnels on all peers

Gängige Probleme

Die folgende Liste enthält einige häufige Probleme, die bei IPSec-Tunneln auftreten können.

• Die Parameter der Phase 1 und der Phase 2 stimmen zwischen den beiden Peers nicht überein.
• Es gibt nicht übereinstimmende IKE-Versionen.
• Phase 1 schlägt mit einem Authentifizierungsfehler fehl, obwohl alles zu stimmen scheint.
  • Stellen Sie sicher, dass Sie die Authentifizierungs-ID und die Remote-ID auf die lokale und die Remote-IP-Adresse einstellen.
• ESP und die UDP-Ports 500 und 4500 sind auf externen Schnittstellen nicht erlaubt.
  • Stellen Sie sicher, dass ESP und Port 500 erlaubt sind. Wenn Sie NAT-T verwenden, stellen Sie sicher, dass UDP 4500 erlaubt ist.
• Ciena empfiehlt, dass Sie die Zeile set security vpn ike make-before-break verwenden, wenn Sie IKEv2 verwenden. Das Weglassen dieser Zeile kann zu Ausfällen führen.
• Der Durchsatz ist langsam.
  • Verwenden Sie entweder aes128gcm oder aes256gcm als Phase-2-Verschlüsselungsalgorithmus. Dies kann den Durchsatz erheblich steigern, wenn der vorherige Verschlüsselungsalgorithmus der Standard AES128 oder AES256 war.
  • Deaktivieren Sie die Protokollierung pro Paket, falls sie implementiert ist. Die paketweise Protokollierung der Firewall kann den Durchsatz verringern.
• IPSec-Tunnel funktionieren, aber bei einem erneuten Schlüsselabruf brechen sie zusammen.
  • Prüfen Sie, ob PFS und dh-groups auf beiden Peers übereinstimmen.
• Der Befehl show vpn ipsec sa zeigt Inkremente nur in einer Richtung an.
  • Dies wird in der Regel durch asymmetrisches Routing verursacht, bei dem die eine Seite Daten durch den Tunnel sendet und die andere nicht.
• Verwendung von run-transition-scripts für HA-Failover anstelle des Ersatzbefehls notify.
  • Weitere Informationen finden Sie unter VRA-Upgrade-Probleme.

Zusätzliche Ressourcen

Die folgende Liste enthält einige zusätzliche Ressourcen für die Konfiguration und Fehlerbehebung von IPSec-Tunneln:

• IPSec Standort-zu-Standort-VPN-Konfigurationsoptionen
• IPsec Site-to-Site VPN Configuration Guide, 17.2.0
• IPsec Site-to-Site VPN-Konfigurationsanleitung, Anhang 1801
• Internet Key Exchange Protocol Version 2(IKEv2)
• IP Encapsulating Security Payload(ESP)