bintec Router RXL-Serie und Rxxx2 Serie - Beispiel für das Prinzip einer VPN-Verbindung LAN-zu-LAN mit einem IPSec-Tunnel durch einen GRE-Tunnel: Unterschied zwischen den Versionen

Version vom 18. April 2018, 09:25 Uhr

bintec Router-Serien - Beispiel für das Prinzip einer VPN-Verbindung LAN-zu-LAN mit einem IPSec-Tunnel durch einen GRE-Tunnel

Vorbemerkungen

• Durch einen VPN-Tunnel sollen zwei örtlich getrennt liegende LANs mittels IPSec in einem GRE-Tunnel (Generic Routing Encapsulation) routingtechnisch miteinander verbunden werden.
• Im vorliegenden Beispiel soll diese "LAN-zu-LAN"-Verbindung zwischen einem bintec R1202 in der Filiale und einem bintec RXL12100
  in der Zentrale hergestellt werden, beide mit einem Firmware Release Version 10.1.27 Patch 5.
• Andere Geräte der bintec Router RXL-Serie und der Rxxx2-Serie mit vergleichbaren Software-Versionen sind teilweise identisch bzw.
  analog zu konfigurieren.
• Auf beiden bintec Routern soll im Beispiel von initial unkonfiguriertem VPN (GRE/IPSec) ausgegangen werden (entspr. Auslieferungszustand).
• Die Konfiguration erfolgt generell mittels GUI, im Wesentlichen aber im GUI Menü "VPN" unter "GRE" bzw. "IPSec".
• Die individuellen Einstellparameterbeschreibungen findet man im Kontext-Menü der Online-Hilfe und im Manual.
• Zum Zeitpunkt der Erstellung dieses Beispiels ist es wegen aktiviertem "DPD" nicht direkt übertragbar auf Geräte der RSxx3-Serie.
• Exportieren Sie Ihre aktive Konfiguration in eine externe Datei, bevor Sie mit Änderungen an der Konfiguration beginnen.

Achtung:
Die nachfolgende Beschreibung gilt nur für den Fall, dass sowohl der bintec R1202 in der Filiale als auch der bintec RXL12100 in der Zentrale über
eine feste "öffentliche" IP-Adresse verfügen. Die GRE-Verbindung selbst ist nicht verschlüsselt, für die Verschlüsselung sorgt hier der IPSec-Tunnel.

Vorgehensweise

Im vorliegenden Beispiel soll das LAN "192.168.17.0/24" eines bintec R1202 in der Filiale durch einen IPSec-Tunnel mit dem LAN "192.168.0.0/24" eines bintec RXL12100 in der Zentrale verbunden werden. Hierbei soll der IPSec-Tunnel innerhalb eines GRE-Tunnels bis zu seinem Ziel-Router (dem Tunnelendpunkt) geleitet werden. Die IP-Adresse "212.0.0.1" soll hierbei als "öffentliche" WAN-IP-Adresse des bintec RXL12100 in der Zentrale fungieren und "212.0.0.2" als "öffentliche" WAN-IP-Adresse des bintec R1202 in der Filiale.

Die Konfiguration erfolgt in drei wesentlichen Schritten:

1. GRE-Tunnel einrichten in der Filiale (R1202) und in der Zentrale (RXL12100)
2. IPSec-Tunnel einrichten in der Filiale (R1202) und in der Zentrale (RXL12100)
3. NAT-Freigabe einrichten in der Zentrale (RXL12100, Responder)

GRE-Tunnel einrichten in der Filiale (R1202) und in der Zentrale (RXL12100)

Das Anlegen des GRE-Tunnels erfolgt auf beiden bintec Routern im GUI Menü "VPN" unter "GRE" auf dem Tab "GRE-Tunnel" mit Klick auf "NEU".

Beispiel für das GUI-Menü des bintec R1202 in der Filiale mit Beispielwerten zur Konfiguration des GRE-Tunnels:

Bild 1: GUI-Menü des bintec R1202 in der Filiale mit den Beispielwerten des neuen GRE-Tunnels

Beispiel für das GUI-Menü des bintec RXL12100 in der Zentrale mit Beispielwerten zur Konfiguration des GRE-Tunnels:

Bild 2: GUI-Menü des bintec RXL12100 in der Zentrale mit den Beispielwerten des neuen GRE-Tunnels

Hinweis:
Die beiden im Beispiel verwendeten lokalen IP-Adressen "10.0.0.1" und "10.0.0.2" der beiden GRE-Interfaces sollen im Folgenden vom IPSec-Tunnel als Tunnelendpunkte (Peer-Adressen) verwendet werden. Dadurch wird auf einfache Weise erreicht, dass der IPSec-Tunnel duch den GRE-Tunnel geleitet wird.

IPSec-Tunnel einrichten in der Filiale (R1202) und in der Zentrale (RXL12100)

Das Anlegen des IPSec-Tunnels erfolgt auf beiden bintec Routern im GUI Menü "VPN" unter "IPSec" auf dem Tab "IPSec-Peers" mit Klick auf "NEU".

Beispiel für das GUI-Menü des bintec R1202 in der Filiale mit Beispielwerten zur Konfiguration des IPSec-Tunnels:

Bild 3: GUI-Menü des bintec R1202 in der Filiale mit den Beispielwerten des neuen IPSec-Tunnels

Beispiel für das GUI-Menü des bintec RXL12100 in der Zentrale mit Beispielwerten zur Konfiguration des IPSec-Tunnels:

Bild 4: GUI-Menü des bintec RXL12100 in der Zentrale mit den Beispielwerten des neuen IPSec-Tunnels

Weisen Sie dem IPSec-Tunnel in beiden Routern jeweils geeignete Profile zu für Phase-1 und Phase-2 (ggf. neu erstellen). Das Beispiel arbeitet erfolgreich mit dem Proposal AES-256/SHA1 für Phasen 1 und 2, bei Phase 1 mit PSK Aggressiv, DH-Gruppe 5 und Erreichbarkeitsprüfung "Dead Peer Detection (Idle)", bei Phase 2 mit PFS-Gruppe 5 und Erreichbarkeitsprüfung "Inaktiv". Achten Sie beim IPSec auch besonders auf korrekte Peer-IDs, Lokale IDs und die zugehörigen ID-Typen.

NAT-Freigabe einrichten in der Zentrale (RXL12100, Responder)

Im bintec RXL12100 in der Zentrale, der im Beispiel als Responder fungieren soll, ist bei aktiviertem NAT auf der WAN-Schnittstelle (hier en1-5) eine NAT-Freigabe für das Protokoll "GRE" einzurichten. Das Anlegen der NAT-Freigabe erfolgt im GUI Menü "Netzwerk" unter "NAT" auf dem Tab "NAT-Konfiguration" mit Klick auf "NEU".

Beispiel für das GUI-Menü des bintec RXL12100 in der Zentrale für die NAT-Freigabe für das Protokoll "GRE":

Bild 5: GUI-Menü des bintec RXL12100 in der Zentrale mit der NAT-Freigabe für das Protokoll "GRE"

Kontrolle der Funktion des neu konfigurierten VPN-Tunnels

• Eine gute Kontrolle des Verbindungsaufbaus ermöglicht das Kommando "debug all&" auf der Router-Konsole (Telnet, SSH oder seriell).

Beispielmeldungen auf der Konsole des Initiators bintec R1202 der Filiale beim erfolgreichen VPN-Verbindungsaufbau zum bintec RXL12100 in der Zentrale:

r1202_ks:> debug all&
08:31:15 INFO/INET: dialup if 100001 prot 1 192.168.17.30:2048->192.168.0.20:24296
08:31:15 DEBUG/INET: NAT: new outgoing session on ifc 1400 prot 47 212.0.0.2:0/212.0.0.2:0 -> 212.0.0.1:0
08:31:15 DEBUG/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): identified ip 10.0.0.2 -> ip 10.0.0.1
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'BINTECELMEG'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'RFC XXXX'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'draft-ietf-ipsec-nat-t-ike-03'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'draft-ietf-ipsec-nat-t-ike-02'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'draft-ietf-ipsec-nat-t-ike-02'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'draft-ietf-ipsec-nat-t-ike-00'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'draft-ietf-ipsra-isakmp-xauth-06'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): Vendor ID: 10.0.0.1:500 (fqdn(any:0,[0..7]=zentrale)) is 'Dead Peer Detection (DPD, RFC 3706)'
08:31:15 INFO/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): done id fqdn(any:0,[0..6]=filiale) -> id fqdn(any:0,[0..7]=zentrale) AG[8ef8b866 7d560a85 : c0161620 731c5f6f]
08:31:15 INFO/IPSEC: Trigger Bundle -1 (Peer 1 Traffic -1) prot 1 192.168.17.30:0->192.168.0.20:0
08:31:15 INFO/IPSEC: P2: peer 1 (IPSec_zur_Zentrale) traf 0 bundle -1 (I): created 192.168.17.0/24:0 < any > 192.168.0.0/24:0 rekeyed 0
08:31:15 DEBUG/IPSEC: P2: peer 1 (IPSec_zur_Zentrale) traf 0 bundle -1 (I): SA 3 established ESP[622a1faa] in[0] Mode tunnel enc aes-cbc (256 bit) auth sha (160 bit)
08:31:15 DEBUG/IPSEC: P2: peer 1 (IPSec_zur_Zentrale) traf 0 bundle -1 (I): SA 4 established ESP[45cb994e] out[0] Mode tunnel enc aes-cbc (256 bit) auth sha (160 bit)
08:31:15 INFO/IPSEC: Activate Bundle -1 (Peer 1 Traffic -1)
08:31:15 INFO/IPSEC: P2: peer 1 (IPSec_zur_Zentrale) traf 0 bundle -1 (I): established  (10.0.0.2<->10.0.0.1) with 2 SAs life 7200 Sec/0 Kb rekey 5760 Sec/0 Kb Hb none PMTU
08:31:45 DEBUG/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 0 (-): DPD: start checking 3 retries/2 seconds
08:31:45 DEBUG/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): DPD: sent request sequence 236026997
08:31:45 DEBUG/IPSEC: P1: peer 1 (IPSec_zur_Zentrale) sa 2 (I): DPD: received response sequence 236026997
r1202_ks:>

Beispielmeldungen auf der Konsole des Responders bintec RXL12100 in der Zentrale bei erfolgreicher VPN-Einwahl des bintec R1202 der Filiale:

rxl12100_ks:> debug all&
08:30:18 DEBUG/INET: NAT: new incoming session on ifc 1050000 prot 47 212.0.0.1:0/212.0.0.1:0 <- 212.0.0.2:0
08:30:18 DEBUG/IPSEC: P1: peer 0 () sa 2 (R): new ip 10.0.0.1 <- ip 10.0.0.2
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'BINTECELMEG'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'BINTECELMEG Heartbeats Version 1'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'RFC XXXX'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'draft-ietf-ipsec-nat-t-ike-03'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'draft-ietf-ipsec-nat-t-ike-02'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'draft-ietf-ipsec-nat-t-ike-02'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'draft-ietf-ipsec-nat-t-ike-00'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'draft-ietf-ipsra-isakmp-xauth-06'
08:30:18 INFO/IPSEC: P1: peer 0 () sa 2 (R): Vendor ID: 10.0.0.2:500 (No Id) is 'Dead Peer Detection (DPD, RFC 3706)'
08:30:18 DEBUG/IPSEC: P1: peer 1 (IPSec_von_Filiale) sa 2 (R): identified ip 10.0.0.1 <- ip 10.0.0.2
08:30:18 DEBUG/IPSEC: P1: peer 1 (IPSec_von_Filiale) sa 2 (R): notify id fqdn(any:0,[0..7]=zentrale) <- id fqdn(any:0,[0..6]=filiale) (unencrypted): Initial contact notification proto 1 spi(16) = [8ef8b866 7d560a85 : c0161620 731c5f6f]
08:30:18 INFO/IPSEC: P1: peer 1 (IPSec_von_Filiale) sa 2 (R): done id fqdn(any:0,[0..7]=zentrale) <- id fqdn(any:0,[0..6]=filiale) AG[8ef8b866 7d560a85 : c0161620 731c5f6f]
08:30:18 INFO/IPSEC: P2: peer 1 (IPSec_von_Filiale) traf 0 bundle 1 (R): created 192.168.0.0/24:0 < any > 192.168.17.0/24:0 rekeyed 0
08:30:18 DEBUG/IPSEC: P2: peer 1 (IPSec_von_Filiale) traf 0 bundle 1 (R): SA 3 established ESP[45cb994e] in[0] Mode tunnel enc aes-cbc (256 bit) auth sha (160 bit)
08:30:18 DEBUG/IPSEC: P2: peer 1 (IPSec_von_Filiale) traf 0 bundle 1 (R): SA 4 established ESP[622a1faa] out[0] Mode tunnel enc aes-cbc (256 bit) auth sha (160 bit)
08:30:18 INFO/IPSEC: Activate Bundle 1 (Peer 1 Traffic -1)
08:30:18 INFO/IPSEC: P2: peer 1 (IPSec_von_Filiale) traf 0 bundle 1 (R): established  (10.0.0.1<->10.0.0.2) with 2 SAs life 7200 Sec/0 Kb rekey 6480 Sec/0 Kb Hb none PMTU
08:30:48 DEBUG/IPSEC: P1: peer 1 (IPSec_von_Filiale) sa 2 (R): DPD: received request sequence 236026997
08:30:48 DEBUG/IPSEC: P1: peer 1 (IPSec_von_Filiale) sa 2 (R): DPD: sent response sequence 236026997
rxl12100_ks:>

Abschließend noch testweises Ping vom Host im LAN des R1202 der Filiale durch den VPN-Tunnel zu einem Host im LAN des RXL12100 in der Zentrale:

rs232bw_ks:> ping -c 3 192.168.0.20
PING 192.168.0.20: 64 data bytes
64 bytes from 192.168.0.20: icmp_seq=0. time=1.598 ms
64 bytes from 192.168.0.20: icmp_seq=1. time=1.043 ms
64 bytes from 192.168.0.20: icmp_seq=2. time=1.056 ms
----192.168.0.20 PING Statistics----
3 packets transmitted, 3 packets received, 0% packet loss

Abschlußbemerkung

Vergessen Sie nicht Ihre gewünschte Einstellung bootfest zu speichern und Ihre aktiven Konfigurationen regelmäßg in externe Dateien zu exportieren.

Basis

Erstellt: 12.+13.12.2018
Produkt: bintec Router der RXL-Serie und Rxxx2-Serie
Release: 10.1.27 Patch 5
KW: 04/2018
kst