VPN Lancom <-> OpnSense

[MartinN]

Hallo,

ich kämpfe im Moment mit einem Tunnel zwischen einer OpnSense "Firewall" und einem Lancom 1783VAW. Wäre toll wenn jemand ne Idee hätte ...

Aufbau ist folgender

Lancom (10.6.42.0/24) --->TelekomVDSL ----> KD (Vodafon ) ---> FritzBox ----> OpnSense (10.6.1.0/24)

Der IKEv2 Tunnel wird aufgebaut und ich kann durch den Tunnel vom Lancom in das Netzwerk der OpnSense pingen ... aber leider nicht umgekehrt.
Der IPSec der OpnSense basiert auf dem StrongSwan. Im Trace des Lancom sehe ich folgenden Fehler:

IKE info: Phase-1 negotiation failed: no configuration found for incoming peer
und daraus folgt dann glaube ich auch der Fehler
no sa available: give up [2], should be retransmitted: 10.6.42.232->192.168.179.250

die 192.168.179.250 ist die IP der OpnSense an der FritzBox NAT-T ist aber aktiviert

.... und da hänge ich jetzt und komm nicht weiter Ich hab mich irgendwo in der Konfiguration verhauen ... habe aber im Moment keine Ahnung wo ich suchen soll.

Wäre toll wenn einer von euch ne Idee hätte ... ich sehe glaube ich den Wald vor lauter Bäumen nicht mehr

Danke für eure Mühe

[GrandDixence]

Die Android App "strongSwan VPN Client" basiert auf strongSwan:
fragen-zum-thema-vpn-f14/strongswan-vpn ... 16965.html

Somit kann die Anleitung unter:
viewtopic.php?f=41&t=16074&p=90462#p90462

und

fragen-zum-thema-vpn-f14/sitetosite-vpn ... tml#p91268

verwendet werden.

Zum Thema "SA" und IPv4-Regeln siehe bitte:

fragen-zum-thema-vpn-f14/frage-zu-vorde ... 17087.html

viewtopic.php?f=14&t=17091&p=96922&hili ... gel#p96922


Viel Glück!

Falls hier Hilfe erwünscht ist, sind mindestens die Trace-Ausgaben von vpn-ike und vpn-status hier zu veröffentlichen.

[MariusP]

Hi,
Du kannst dir auf dem Lancom mit show vpn sadb immer anschauen was genau am Ende ausgehandelt wurde.
Wenn also OpenSense Packete schickt die nicht den ausgehandelten Regen der SAs entsprechen, wird das Packet vom IPsec abgelehnt.

Und auch IPSec ist nicht gleich IKE.
Das eine bezeichnet, wie ausgehandelte SAs verwendet werden sollen um Daten zu übertragen, das andere ist ein Protokoll, dass die SAs aushandelt.
Unter Linux macht Strongswan kein IPSec, das macht dann ein Teil des Linux Kernels. Ich würde mal annehmen das selbiges auch für Android gilt.

Kleiner Funfakt, wenn man unter Linux ESP Fehler tracen will, muss man dafür den Kernel selber mit speziellen Flags bauen.
Gruß

[MartinN]

Hallo Marius,

erst mal Danke für die Antwort .... ich stehe vielleicht gedanklich gerade etwas auf dem Schlauch .... vielleicht kannst Du mir ja helfen meinen gedanklichen Knoten zu entknoten ...
ich vermute mein Problem liegt darin das ich versuche die Verbindung über ein NAT-T herzustellen ... d.h. ich sehe das die Pakete im Lancom versucht werden zu der IP des FritzBox Netzwerkes weitergeleitet zu werden .... das geht schief da keine SA für das Netz vorhanden ... kann ich das so zusammenfassen ??

IP internes lan 1: 192.168.101.0/24
IP internes lan 2: 10.6.1.0/24
IP Fritz LAN an Opnsense WAN: 192.168.179.0/24 mit 192.168.179.250 als WAN Schnittstelle der Opnsense

show vpn sadb:
src: öffentliche IP1 dst: öffentliche IP2
192.168.101.0/24 <-> 10.6.1.0/24
proposal 1 protocol IPSEC_ESP Encryption AES-CBC-256 Integrity AUTH-HMAC-SHA1 PFS-DH-Group None ESN None
spi[outgoing] 0xcd85cd8c
spi[incoming] 0xc952c399


Ergebniss des Trace:

[VPN-Packet] 2018/10/15 22:16:55,521 Devicetime: 2018/10/15 22:16:58,703
no policy found for: 192.168.101.254->192.168.179.250 60 ICMP ECHOREPLY
-->IPv4 Header

[GrandDixence]

Gemäss "show vpn sadb" lassen die VPN-Endpunkte durch den VPN-Tunnel nur IP-Pakete mit Quell-IP-Adresse im Bereich von 192.168.101.0/24 und Ziel-IP-Adresse im Bereich von 10.6.1.0/24 durch in Richtung vom LANCOM-Router zum OpnSense.

Gemäss "show vpn sadb" lassen die VPN-Endpunkte durch den VPN-Tunnel nur IP-Pakete mit Quell-IP-Adresse im Bereich von 10.6.1.0/24 und Ziel-IP-Adresse im Bereich von 192.168.101.0/24 durch in Richtung vom OpnSense zum LANCOM.

Ein "PONG" (ICMP ECHOREPLY) von einem Ping-Kommando von der IP-Adresse 192.168.101.254 mit Ziel 192.168.179.250 wird vor dem Betreten oder des Verlassen des VPN-Tunnels logischerweise aus Sicherheitsgründen herausgefiltert (no policy found).

Gemäss Beitrag Nr. 1 müsste "show vpn sadb" oder "show vpn long" eine SA für:
10.6.42.0/24 <-> 10.6.1.0/24
auflisten?! => IPv4-Regeln im LANCOM-Router und OpnSense korrekt für die internen Netzwerke konfigurieren?!

Mit NAT muss das "PONG"-IP-Paket eine Quell-IP-Adressänderung von 192.168.101.254 auf 10.6.42.0/24 (im OpenSense?) erhalten, bevor es den VPN-Tunnel betritt. Bitte mal den IP-Header studieren (Quell-IP => Source Address; Ziel-IP => Destination Address):
https://de.wikipedia.org/wiki/IP-Paket

[vinet]

Hi,
ich betreibe aktuell eine Site to Site Verbindung von einer OPNSense zu einem Lancom.
Das funktioniert soweit sehr gut, leider sind nach kürzerer Zeit immer die weiteren Ipv4 Netze die propagiert werden von der OPNSense seite aus nicht mehr am Lancom zu erreichen. Erst nach Neuinitialisierung angestoßen durch die OPNSense geht der ICMP Ping dann wieder durch.
Lancom baut auf, OPNSense wartet auf Anfragen und baut nicht aktiv auf.
Ping ist in der OPNSense gestzt um den Tunnel aktiv zu halten.

Das IPv4 Netz 192.168.30.0/24 ist immer erreichbar
nur das 192.168.31.0/24 wird nach einiger zeit nicht mehr erreicht. Nur nach reconnect wieder verfügbar
Lancom hat die Version 10.42

[vinet]

hier noch die weiteren settings der opnSense

[GrandDixence]

Auf dem LANCOM-Router wie auf dem OpnSense-Router die Lifetime zu Testzwecken temporär auf einen einstelligen Minutenwert heruntersetzen. Dann mit dem IKE-VPN-Trace beobachten, ob das Rekeying von Steuerkanal (IKE) und das Rekeying vom Datenkanal (IPSEC -> ESP) erfolgreich durchgeführt werden.

Werden beidseitig alle 30 Sekunden DPD-Datenpakete über den Steuerkanal versendet und immer ordnungsgemäss vom anderen VPN-Endpunkt beantwortet? => Im IKE-VPN-Trace beobachten!

[vinet]

Screenshot_20230207_085454.png

hier mal paar Performance vergleiche
die OPN Sense hat 5 CPUs a 2.6GHz teilweise zu 70-80% beansprucht um die 250Mbit im Download bei 12 IpSec IKev2 Tunneln

[vinet]

hier die Lancom Auslatung eines 1900EF
ein 1783VAW hatte fast 90% CPU Auslastung

[GrandDixence]

Wenn die CPU-Auslastung bei VPN-Tunnelverkehr hochschnellt, muss die CPU entweder zuviel Rechenarbeit für die Zerteilung (Fragmentierung) und Zusammenbauen (Defragmentierung) der IP-Datenpakete aufwenden oder der VPN-Endpunkt unterstützt keine hardwaremässige Beschleunigung der Verschlüsselung und Entschlüsselung der VPN-Datenpakete. Siehe dazu:
fragen-zum-thema-vpn-f14/7100-ikev2-aes-gcm-t17361.html

fragen-zur-lancom-systems-routern-und-g ... ml#p112809

Und gemäss der aktuellsten Fassung von BSI TR-02102-3 sollte aus Sicherheitsgründen kein DH14 und kein SHA-1 mehr eingesetzt werden.
https://www.bsi.bund.de/DE/Themen/Unter ... _node.html

[Hagen2000]

Hi,
ich betreibe aktuell eine Site to Site Verbindung von einer OPNSense zu einem Lancom.
Das funktioniert soweit sehr gut, leider sind nach kürzerer Zeit immer die weiteren Ipv4 Netze die propagiert werden von der OPNSense seite aus nicht mehr am Lancom zu erreichen. Erst nach Neuinitialisierung angestoßen durch die OPNSense geht der ICMP Ping dann wieder durch.
Lancom baut auf, OPNSense wartet auf Anfragen und baut nicht aktiv auf.
Ping ist in der OPNSense gestzt um den Tunnel aktiv zu halten.

Das IPv4 Netz 192.168.30.0/24 ist immer erreichbar
nur das 192.168.31.0/24 wird nach einiger zeit nicht mehr erreicht. Nur nach reconnect wieder verfügbar
Lancom hat die Version 10.42

Guten Morgen @vinet,
darf ich fragen, ob sich das Problem irgendwie lösen ließ?

[savakova]

...das Gleiche wollte ich auch wissen....