Guten Abend allerseits,
ich möchte ein Site-2-Site mit VTI aufbauen. Baue ich den Tunnel manuell auf oder setze die Config auf "sofort starten" ist alles schick (also hab ich wohl keine grundsätzlichen Fehler gemacht), aber nur bis der Tunnel dann mal abgebaut wird. Der Tunnel wird nicht automatisch aufgebaut, Anbei die Meldungen dazu (zeitliche Abfolge von oben nach unten):
charon: 15[KNL] received an SADB_ACQUIRE with policy id 2 but no matching policy found
charon: 15[KNL] creating acquire job for policy a.b.c.d/32 === w.x.y.z/32 with reqid {0}
charon: 16[CFG] trap not found, unable to acquire reqid 0
Auf beiden Büchsen läuft 19.1.8, beide zeigen das gleiche Verhalten, Auf der einen ist das einzige Tunnel, auf der anderen laufen noch andere, bisher policy-basierte Tunnel.
Kennt jemand das Problem oder hat eine Idee, wo der Fehler liegt?
Danke vorab,
Siegfried
Sorry, für mich zum Verständnis, was ist ,,VTI"?
Gesendet von iPad mit Tapatalk Pro
0 ist komisch, eigentlich geht's ab 1000 los. Schau Mal in die ipsec.conf
Quote from: micneu on May 27, 2019, 08:49:04 PM
Sorry, für mich zum Verständnis, was ist ,,VTI"?
Gesendet von iPad mit Tapatalk Pro
VTI = virtual tunnel interface
Hier ist ein Howto dazu: https://github.com/opnsense/docs/blob/master/source/manual/how-tos/ipsec-s2s-route.rst
Moin minugmail,
in der ipsec.conf steht reqid = 1000
conn con1
aggressive = no
fragmentation = yes
keyexchange = ikev2
mobike = yes
reauth = yes
rekey = yes
forceencaps = no
installpolicy = no
dpdaction = none
left = x.x.x.x
right = y.y.y.y
leftid = xxx.yyy.de
ikelifetime = 28800s
lifetime = 28800s
ike = aes256-sha512-ecp521!
leftauth = pubkey
rightauth = pubkey
leftcert = /usr/local/etc/ipsec.d/certs/cert-1.crt
leftsendcert = always
rightca = "meineCA"
rightid = xxx.yyy.de
reqid = 1000
rightsubnet = 0.0.0.0/0
leftsubnet = 0.0.0.0/0
esp = aes256-sha512-ecp521!
auto = route
Hm, das würde ja eher auf einen Bug in strongswan selbst hinweisen.
Wenn du nur danach googlest kommt nix?
"creating acquire job for policy" "with reqid {0}"
Leider nichts, was mich weiterbringt. Was ich da finde ist z.T. mehrere Jahre alt...:-(
Gerade gefunden: wie es scheint gibt's dazu zwei Tickets.
https://github.com/opnsense/core/issues/2332
https://github.com/opnsense/core/issues/3443
Hab ich also morgen früh im Büro was zu lesen ;-)
Nachdem ich das Thema zwischendurch habe ruhen lassen, nun ein neuer Versuch mit 19.7.1 auf der einen Büchse. Leider immer noch dasselbe Verhalten. Hab auch schon die gesamte IPSec config geklöscht, die Kiste zurückgesetzt und das config-Backup wieder draufgenagelt und das VPN neu konfiguriert. Hat nix gebracht.
Ich hab den Fehler auch schon bei Policy based mit Checkpoint gesehen, ich glaub das heißt nicht viel. Stell doch mal alles auf bekannten Standard, also AES 256, SHA256, DH14 und PSK statt cert. Ist es dann besser?
Ich versuche gerade das routed IPSec howto nachzustellen und komme nicht weiter: bei der Einrichtung der Gateways habe ich nur meine selbst eingerichteten Interfaces zur Auswahl. Die generierte ipsec.conf beinhaltet kein 'reqid = ' aber ein 'type = tunnel'.
Habe ich irgendwas übersehen? (Ich habe es zigmal kontrolliert).
Die Verbindung ist 'up'
con1{11}: INSTALLED, TUNNEL, reqid 7, ESP SPIs: cf282e8b_i c874d2a8_o
con1{11}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 30 minutes
con1{11}: 10.111.1.1/32 === 10.111.1.2/32
ipsec.conf
# This file is automatically generated. Do not edit
config setup
uniqueids = yes
conn con1
aggressive = no
fragmentation = yes
keyexchange = ikev2
mobike = yes
reauth = yes
rekey = yes
forceencaps = no
installpolicy = no
type = tunnel
left = 1.2.3.4
right = 4.3.2.1
leftid = 1.2.3.4
ikelifetime = 86400s
lifetime = 3600s
ike = aes256-sha256-modp2048!
leftauth = psk
rightauth = psk
rightid = 4.3.2.1
rightsubnet = 10.111.1.1
leftsubnet = 10.111.1.2
esp = aes256-sha256!
auto = start
include ipsec.opnsense.d/*.conf
Screenshot Phase2 bitte ...
Bitte :-)
und Danke
Mode muss routed sein, nicht tunnel ... :o
Oh, mann.... Sorry, 'route-based'....
War das jetzt ne Frage oder ein alter Screenshot oder geht jetzt alles? ;)
Hallo,
ja ipsec1000 ist da, Danke, und sorry für meine Blindheit.
Letzte Frage: 'Manual SPD' macht hier wohl keinen Sinn. Habe ich eine chance ein src NAT hinzukriegen mit diesem setup?
Danke
manual spd müsste funktionieren, keine Ahnung auf welchem Interface. Ich glaub das hat mal einer zum Laufen gebracht.
Hallo,
ich krieg das im Moment nicht gebacken. Traffic geht in ipsec1000 (und enc0), aber das NAT greift nicht.
Vielleicht müsste mein NAT jetzt auf ipsec1000 arbeiten und nicht meht auf enc0.
Danke
Quote from: mimugmail on September 19, 2019, 04:22:29 PM
... keine Ahnung auf welchem Interface.
Einfach testen ...
Hallo,
in der NAT config kann ich als Interface ja nur 'IPsec' auswählen. Generiert wird dann 'enc0' in der config.xml. Auf der Gegenseite sehe ich dann nur original SRC Adressen auf enc0 und ipsec1000.
Wenn ich aber in der config.xml enc0 durch ipsec1000 ersetze und neu starte oder opnsense-shell reload mache passiert folgendes
- auf enc0 sowie auf ipsec1000 sehe ich geNATtete SRC Adressen :)
- das SPI ist das gleiche wie auf der Gegenseite :)
- auf der Gegenseite herrscht Stille auf enc0 und ipsec1000, obwohl ipsec neu aufbaut :-[
- es werden keinerlei Pakete mehr zwischen den beiden Gateways ausgetauscht :-[
Wenn ich in der Konfig wieder auf enc0 zurückwechsle beim NAT, dann kommen dir Pakete wieder drüben an, aber mit original SRC.
Bei Routed IPSec wird ein neues Interfaces angelegt, das kannst du assignen und dann kannst du das auch als NAT Interface auswählen. Steht das nicht in der Doku?
Ja stimmt. War mir gar nicht aufgefallen da es sogar automatischt assigned wird und den Namen aus der Description der Phase1 übernimmt.
Leider ändert es nichts an dem Verhalten:
wähle ich IPsec als interface im NAT, wird nicht geNATet, wähle ich ipsec1000, wird sieht es nach NAT aus, aber auf der Gegenseite kommt nichts mehr an, obwohl IPsec richtig verbindet, die route nach "192.168.2.0/24 10.111.1.2 UGS ipsec1000" da ist...
Hast du das mit dem NAT lösen können? Ich stehe nämlich vor genau dem gleichen Problem.
NAT und route-based IPsec ist momentan schwierig.
Du könntest mal die tuning parameter hier testen:
https://github.com/opnsense/docs/pull/279/files