Messages

Hi,

seitdem ich auf die neuste Version geupdatet hatte funktioniert der IPSec zum RoadWarrior nicht mehr.
Die alten Konfiguration wurden in das neue Format konvertiert und sind in der swanctl.conf verfügbar.

Ich hatte die Verbindung auch in der GUI unter Connections (new) angelegt und in der alten Konfig deaktiviert, auch hier ohne Erfolg. Ich hatte auch bereits die swanctl.conf kontrolliert und mit den Beispielen auf der StrongSwan Homepage verglichen. Dabei konnte ich keinen offensichtlichen Fehler erkennen. Und was aus den Daten aus der GUI generiert wird sah recht vernünftig aus.

Im Protokoll steht immer als letzter Eintrag:
parsed INFORMATIONAL request 2 [ N(AUTH_FAILED) ]

Leider habe ich zu dieser Fehlermeldung keine weiteren Infos gefunden. Der Rest sah eigentlich gut aus, Zertifikate wurden ausgetauscht und akzeptiert und nachdem man meint, die Verbindung müsste nun stehen, wird diese wieder mit dem oben genannten Fehler abgebaut.

Hat hier jemand einen Rat für mich ?

Danke

Hi,
Danke für die Antwort.

Was ich bereits schon probiert hatte:

Beim RoadWarrior Phase 2 habe ich aktuell drei Einträge
Lokales Subnetz   Fernes Subnetz
50.50.0.0/16        mobiler Client
30.30.30.0/24      mobiler Client
Internet               mobiler Client

Wobei hier der Eintrag Internet wohl eher falsch ist und der Zugang zum Internet, wie angedeutet, über NAT gehen sollte.
Bei NAT Ausgehend gibt es eine automatische Regel in der folgendes steht:
Schnittstelle Quellnetzwerk Quellport Ziel Zielport NAT Adresse NAT Port Statischer Port
Internet       10.0.0.0/24    *             *    *          Internet        *           NEIN

Ins Internet komme ich damit aber leider nicht mit dem RoadWarrior...

In der einen Site2Site Verbindung habe ich auch zwei Phase 2 Einträge definiert:
Lokales Subnetz   Fernes Subnetz
50.50.0.0/16        30.30.30.0/24
10.0.0.0/24          30.30.30.0/24
Entsprechend anders herum auf der Gegenseite.
Ahhhhh urgghhh, da ist mir doch glatt ein Fehler bei der IP-Adresse aufgefallen...
Korrigiert und nun komme ich zumindest mit dem RoadWarrior ins Site2Site Netzwerk. :)

Welche Firewall Regeln sollte dazu vorhanden sein, habe hier großzügig unter "Fließend" ein paar eingerichtet.
Vermute mal ich benötige da sowas für alle entsprechenden Netze:

Protokoll Quelle               Port Ziel                Port Gateway
IPv4 *    30.30.30.0/24   *     50.50.0.0/16  *     *               Bidirektional
IPv4 *    50.50.0.0/16     *     30.30.30.0/24*     *               Bidirektional

Für den RoadWarriior dann das selbe nochmal oder bin ich da irgendwo falsch abgebogen ?
Will natürlich auch nicht mehr zulassen als nötig.

Muss hier dann auch noch eine Regel für Internet hinterlegt werden oder muss ich bei NAT noch etwas ergänzen, damit der RoadWarrior auch ins Internet über VPN kommt ?

Danke.

Hi,

ich habe folgende VPN Konstellation, wie in beiliegenden Bild.
Die IP-Adressen sind symbolisch dargestellt, entsprechen aber von der Struktur her der Realität.

Nun habe ich das Problem, dass ich zwar zwischen den Site2Site Verbindungen kommunizieren kann, wenn ich mich aber über den Roadwarrior VPN einwähle komme ich nicht auf z.B. das Netzwerk 30.30.30.0/24 oder ins Internet. Ich hatte dazu schon mehrfach gesucht und auch div. Anleitungen abgearbeitet.
Habe hier auch schon entsprechende Phase 2 Verbindungen angelegt, die zwischen 50.50.0.0/16 und 30.30.30.0/24 sowie 10.0.0.0/16 und 30.30.30.0/24 sind.
Am NAT habe ich mich auch schon versucht, bislang hatte mich aber alles nicht auf einen grünen Zweig gebracht.
Ich nehme mal an, dass der Internetzugriff vom Roadwarrior VPN ausschliesslich über NAT geregelt werden muss, da kann ich ja keine zusätzliche Phase2-Route einfügen.

Hätte mir da jemand ein paar Schritt für Schritt Infos, wo ich was einstellen muss bezogen auf die angegebene Konfiguration ?

Vielen Dank schon mal im voraus !

Hi,
da ich mehrere Netzwerke miteinander verbinden wollte, habe ich mich an einem gerouteten VPN Tunnel nach dieser Anleitung versucht: https://docs.opnsense.org/manual/how-tos/ipsec-s2s-route.html

In der Phase 1 habe ich ein paar Änderungen vorgenommen, ich verwende Zertifikate und Site A ist mit fester öffentlicher IP, Site B allerdings mit dynamischer und nicht öffentlicher IP (10.x.y.z) vom Provider. Damit gab es aber erstmal keine Probleme. In Phase 2 hatte ich zuvor einen Tunnel IPv4 verwendet. Dieser hat auch soweit funktioniert und die jeweiligen Netze auf Site A (192.../16) und Site B (172.../24) verbunden.
Habe dann zum Umstieg nach routet VPN in Phase 1 "Install Policies" rausgenommen und NAT-T deaktiviert.
Phase 2 auf "Route-based" umgestellt und dort zwei IP Adressen aus einem unbenutzen Segment verwendet:
Site A: 10.200.1.1
Site B: 10.200.1.2
Die restlichen Einstellungen sind jeweils gleich geblieben.

Beim Anlegen der Gateways kommt es dann zu der ersten Abweichung, hier habe ich keine Schnittstelle mit dem Namen IPSEC1000, es wurde aber eine Schnittstelle angelgt die den Namen aus der Beschreibung der Phase 1 hat und diese ist mit ipsecX verknüpft. Ich bin davon ausgegangen, dass dies dann die Entsprechung zu IPSEC1000 ist und habe darauf das GW angelegt.
Die Routen habe ich entsprechend auch angelegt.

Der Tunnel wird auch soweit erfolgreich aufgebaut, es wird aber wohl nichts empfangen, in der Statistik sehe ich zwar ausgehenden Verkehr auf beiden Seiten aber nicht eingehendes:

Code Select Expand

Pakete eingehend 0
Pakete ausgehend 131.560
Bytes eingehend 0 bytes
Bytes ausgehend 3.52 MB
Fehler eingehend 0
Fehler ausgehend 317
Kollisionen         0

Auch der jeweilige GW wird mir als Offline angezeigt.
In den FW-Regeln habe ich schon jeweils alles zugelassen (IPSEC und Site X Schnittstelle).

Ein tcpdump auf enc0 zeigt folgendes:

Code Select Expand

tcpdump -n -i enc0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 262144 bytes
13:00:32.283232 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9227, length 8
13:00:33.286536 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9228, length 8
13:00:34.304797 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9229, length 8
13:00:35.367038 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9230, length 8
13:00:36.380112 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9231, length 8
13:00:37.387789 (authentic,confidential): SPI 0xXXXXXXX: IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9232, length 8


Auf der ipsec Schnittstelle vergleichbar:

Code Select Expand

tcpdump -n -i ipsec1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec1, link-type NULL (BSD loopback), capture size 262144 bytes
13:03:08.512792 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9378, length 8
13:03:09.516795 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9379, length 8
13:03:10.580297 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9380, length 8
13:03:11.583076 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9381, length 8
13:03:12.601792 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9382, length 8
13:03:13.625798 IP 10.200.1.2 > 10.200.1.1: ICMP echo request, id 64826, seq 9383, length 8


Im Log des Tunnels kommen eigentlich nur wiederholend folgende Meldungen:

Code Select Expand

2021-05-20T13:06:41 charon[43354] 11[IKE] <con1|9> sending keep alive to w.x.y.z[4500]
2021-05-20T13:06:41 charon[43354] 11[KNL] <con1|9> querying policy 0.0.0.0/0 === 0.0.0.0/0 out failed, not found

Hier habe ich mich schon gefragt, ob die nicht gefundene Policy etwas zu bedeuten hat, habe dazu aber nichts brauchbares in den weiten des Internets gefunden.

Habe auch schon einige Threads hier aus dem Forum durchgelesen und versucht damit weiter zu kommen, aber alles bisher ohne Erfolg. Hatte auch in älteren Beiträgen gelesen, dass irgendetwas aufgrund eines Bugs mit FreeBSD und den VTI devices nicht gehen soll. Konnte aber nicht nachvollziehen, ob dieser Bug nach wie vor besteht oder schon behoben wurde.
Folgende OPNsense Version setze ich ein und es werden aktuell keine Updates dazu gefunden, daher sollte es der letzte Stand sein:
OPNsense 21.1.5-amd64
FreeBSD 12.1-RELEASE-p16-HBSD

Kann mir hier jemand auf die Sprünge helfen ?

Viele Dank schon mal...