IPsec Hilfe - Verbindung steht, aber keine Kommunikation

Started by kosta, July 20, 2021, 11:37:49 PM

Previous topic - Next topic
Hallo Leute,

benötige ein bisschen Hilfe zum Aufbau eines IPsec Tunnels.
Grundsätzlich so:


      .-----+-----.  Site A
      | OPNsense| LAN: 192.168.11.0/24, GW: 192.168.11.254
      '-----+-----'  WAN: 80.1.1.1
            |
            |
      .-----+------.
      |  WAN       |
      '-----+------' 
            |
            |
      .-----+------.  Site B
      | OPNsense | WAN: 200.1.1.1
      '-----+------'  LAN: 10.146.32.0/24, GW: 10.146.32.254
       



Log ist sauber.
Die Verbindung kommt zustande.
Aber, ich kann nichts erreichen. Kein Ping, keine Verbindung, mein Remote, SMB, nix.
Firewall blockt nix.
Die Einstellungen in beiden Firewalls sind gleich und nach OPNsense Anleitung gemacht.

Aus dem Log ziehe ich das mal raus:
2021-07-20T23:23:31   charon[55884]   15[IKE] <con1|4> CHILD_SA con1{4} established with SPIs c744b7d9_i c4c97c7b_o and TS 10.146.32.0/24 === 192.168.11.0/24
...
2021-07-20T23:23:31   charon[55884]   15[IKE] <con1|4> received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding

Drinnen sieht man auch PSK auth successful.

Paar Konfig-Screenshots.

Bisher hatte ich Sophos-OPNsense IKEv1 laufen, problemlos. Die schwarze OPNsense ist Site B, weiße OPNsense ist Site A.



Wie sollen wir prüfen, ob das alles passt, wenn Du die IP-Adressen löschst? Wieso denkst Du, die sind irgendwie kritisch? Wenn Deine Systeme am öffentlichen Internet per IPv4 hängen, werden sie 24x7 gescannt. Tatsache. Die Adressen sind kein Geheimnis.

Vorteil IPv6: jedes LAN hat ein /64 und damit die Größe des gesamten Legacy Internet im Quadrat. Für Server würfelt man darin die statischen Adressen einfach zufällig aus. Scannen mit nmap und Konsorten unmöglich ;)
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Warum muss/soll ich meine Domains auf dem Forum veröffentlichen? Was bringt's für das Troubleshooting?
Rest ist eh offen.

Dem IPsec interface hast Du aber schon eine allow rule zum LAN verpasst?

Siehe: https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html#firewall-rules-site-a-site-b-part-2

Gesendet von meinem ONEPLUS A5000 mit Tapatalk


July 21, 2021, 04:48:21 AM #6 Last Edit: July 21, 2021, 05:55:22 AM by kosta
Ja, habe ich, klar.
Im Live View sah ich nichts, aber ich filtriere WAN Intf raus. Dort dürfte nix sein, die Rules stimmen und Tunnel baut auf. Mehr soll am WAN nicht passieren.

Was mir aber aufgefallen ist:
Wenn ich unter Status Overview gucke, steht unter Remote subnets nicht der Remote Subnet.
Hier die Status Screenshots. Weiß zeigt ja nur wie üblich das SiteB Netzwerk, und schwarz zeigt aber Remote Subnet 10.146.32.0/24 anstatt 10.10.11.0/24, obwohl ich 10.146.32.0 deaktiviert habe.
IPsec schon neugestartet...

Und im Log sehe ich jetzt:
2021-07-21T05:44:44   charon[85574]   06[IKE] <con2|1> failed to establish CHILD_SA, keeping IKE_SA   
2021-07-21T05:44:44   charon[85574]   06[IKE] <con2|1> received TS_UNACCEPTABLE notify, no CHILD_SA built   
2021-07-21T05:44:44   charon[85574]   06[ENC] <con2|1> parsed CREATE_CHILD_SA response 3 [ N(TS_UNACCEPT) ]   
2021-07-21T05:44:44   charon[85574]   06[NET] <con2|1> received packet: from 212.232.x.x[4500] to 84.112.x.x[4500] (96 bytes)   
2021-07-21T05:44:44   charon[85574]   06[NET] <con2|1> sending packet: from 84.112.x.x[4500] to 212.232.x.x[4500] (496 bytes)   
2021-07-21T05:44:44   charon[85574]   06[ENC] <con2|1> generating CREATE_CHILD_SA request 3 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]   
2021-07-21T05:44:44   charon[85574]   06[IKE] <con2|1> establishing CHILD_SA con2{3}

Bin paar Schritte weiter. Ich habe bei IKEv2 nen Gedankenfehler bei Netzkonfigurationen gehabt. Bei IKEv1 war das, bilde ich mir ein, anders. Aber egal... jetzt sind die Logs sauber und alle Netze geroutet.

Aber: ich kann noch immer nix zugreifen! Schon alleine der Ping auf die Remote Firewall müsste klappen. Aber nein, aus keiner Richtung.
Ich habe keine Erfahrung mit IKEv2, aber am Routing kann es ja nicht liegen?

Noch ein Update:
Hab dann noch Routed IPsec eingerichtet und festgestellt, überraschenderweise, dass es funktioniert.
Ich vermute es liegt hier an dem zusätzlichen Routing, den man bestimmen kann/muss.

Was fehlt denn beim Tunneling dass die Pakete nicht richtig und automatisch geroutet werden?

Hallo kosta,

ich erinnere mich dunkel, dass ich bei den ersten Versuchen die gleichen Probleme hatte. Auf Grund eines Tutorials bin ich auf Route-based VPN umgestiegen. Damit wird der VPN-Tunnel aufgebaut, beide Seiten haben eine explizite Endpunkt-Tunnel-Adresse und über diese Adressen wird dann normal geroutet. Man muss sich nur manuell ein entferntes Gateway anlegen

Das funktioniert bei super (Testaufbau) und verbindet sich nach Ausfällen automtatisch wieder.

Viele Grüße
Ulf

Quote from: kosta on July 21, 2021, 11:10:13 PM
Was fehlt denn beim Tunneling dass die Pakete nicht richtig und automatisch geroutet werden?
Entweder ich habe es übersehen oder Du hast nicht beide Seiten gepostet. Sind die phase 2 SAs denn auf beiden Seiten wirklich identisch, nur mit vertauschten Rollen für local und remote?
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)