VPN Client bekommt keinen Verbindung aus dem LAN zum externen VPN Server

[modi]

Hallo Zusammen,

bin ganz frisch dabei (Neuinstallation Version 23.7) und die OPNsense läuft soweit.

Zugriff auf das Internet funktioniert, DHCP, DNS läuft.

Lauft (default) installierter Regel sollten die Clients im LAN alles nach "draußen" dürfen.
HTTPS und Mail geht; aber der L2TP-Client bekommt keine Verbindung zu einem externen Server.
Ist dies so gewollt, oder muß ich doch noch etwas an den Regeln ändern?

viele Grüße 

[Monviech (Cedrik)]

Ist es denn nur L2TP oder L2TP over IPsec?

Es sollten keine weiteren Regeln nötigt sein. Die Standardregeln erlauben jedes Protokoll ins Internet. Durch die Statefulness der Firewall werden die Antworten auch zurück zugelassen.

Ansonsten sollte der L2TP (over IPSec) Client NAT-T beherrschen, weil die OPNsense die Pakete NATed.

Wenn es einfach nicht geht, dann ist es höchstwahrscheinlich entweder das NAT oder die MTU. Vielleicht werden die Pakete fragmentiert.

Auch zu beachten, vielleicht erwartet die Gegenstelle von den Quellports 1701, 500, 4500 auf die Zielports 1701, 500, 4500 die Anfrage um den Verbindungsaufbau zu erlauben. In dem Fall, muss eine manuelle Outbound NAT Regel erstellt werden, die diesen Traffic abfängt und einen "static Port" verpasst.

[modi]

Hallo Monviech,

vielen Dank für die Antwort.

Im LAN sind mehrere PCs (regelmäßig drei) die parallel einen VPN Tunnel nach verschiedenen externen Servern herstellen. Im Einsatz sind der Standard Client (MAC L2TP über IPsec) bzw. der Cisco VPN Client.

Mein Aufbau sieht wie folgt aus:

Fritzbox 6490                              opnsense
Netz: 123.45.67.12/30                 192.168.23.4 <-----> LAN <-----> PC1-n   
feste IP V4  123.45.67.13 <-----> 123.45.67.14
(->Exposed Host: 123.45.67.14)

Bisher habe ich eine Sophos UTM 9.7 im Einsatz. Damit funktioniert es einwandfrei.
Sie macht kein NAT sondern nur Masquerading.

Da diese zum 30.06.26 abgekündigt ist und ich nicht weiss ob ich meine in 2024 ablaufende Home Lizenz nochmals verlängert bekomme, möchte ich mich frühzeitig um Ersatz kümmern.

siehe auch :
https://support.sophos.com/support/s/article/KB-000035279?language=en_US#sophosutmsoftware

 

[Monviech (Cedrik)]

Masquerading ist Source NAT. (In der OPNsense heißt es Outbound NAT)

Der richtige Begriff dafür ist NAT Overloading:
"'Overloading' means that the single public IP assigned to your router can be used by multiple internal hosts concurrently"

Ich tippe hier immer noch weiter auf MTU Problem, oder NAT Problem. Es wurde auch noch nicht erwähnt, welche Phase der IPsec Verbindung fehlschlägt. Gibt es denn Logs? Der genaue Fehler würde die Fehlersuche vereinfachen.

Ich gehe davon aus, dass es noch IKEv1 ist, und dass die Phase 1 fehlschlägt. Wahrscheinlich schon beim initiieren der Verbindung. Hier sollte mit tcpdump auf dem WAN Interface geschaut werden, ob überhaupt eine Antwort kommt, und auf welchem Port. Gerade IKEv1 ist hier sehr streng, und es kann z.B. erwartet werden, dass das Paket von 500 zu 500 geht, bevor mit NAT-T auf 4500 zu random upper port gegangen wird.

(Bei Cisco wird die Phase 1 das Main Mode, MM1 MM2 MM3 etc... genannt)
https://www.cisco.com/c/de_de/support/docs/security-vpn/ipsec-negotiation-ike-protocols/217432-understand-ipsec-ikev1-protocol.html

(Ich habe früher sehr viel UTM gemacht und mache heutzutage auch XG Firewall welche Müll ist xD)

[modi]

habe ein Log auf einem Mac gefunden:

Wed Nov 29 16:47:17 2023 : l2tp_get_router_address
Wed Nov 29 16:47:17 2023 : l2tp_get_router_address 172.nn.nn.4 from dict 0
Wed Nov 29 16:47:17 2023 : L2TP connecting to server 'xxx.xxx.de' (2nn.nnn.nnn.nnn)...
Wed Nov 29 16:47:17 2023 : IPSec connection started
Wed Nov 29 16:47:17 2023 : IPSec phase 1 client started
Wed Nov 29 16:47:17 2023 : IPSec phase 1 server replied
Wed Nov 29 16:47:47 2023 : IPSec connection failed

es bricht also schon direkt am Anfang ab.

Nutze ich die UTM wird die Verbindung aufgebaut:

Wed Nov 29 16:52:54 2023 : l2tp_get_router_address
Wed Nov 29 16:52:54 2023 : l2tp_get_router_address nn.nn.nn.5 from dict 1
Wed Nov 29 16:52:54 2023 : L2TP connecting to server 'xxx.xxx.de' (2nn.nnn.nnn.nnn)...
Wed Nov 29 16:52:54 2023 : IPSec connection started
Wed Nov 29 16:52:54 2023 : IPSec phase 1 client started
Wed Nov 29 16:52:54 2023 : IPSec phase 1 server replied
Wed Nov 29 16:52:55 2023 : IPSec phase 2 started
Wed Nov 29 16:52:55 2023 : IPSec phase 2 established
Wed Nov 29 16:52:55 2023 : IPSec connection established
Wed Nov 29 16:52:55 2023 : L2TP sent SCCRQ
Wed Nov 29 16:52:55 2023 : L2TP received SCCRP
Wed Nov 29 16:52:55 2023 : L2TP sent SCCCN
Wed Nov 29 16:52:55 2023 : L2TP sent ICRQ
Wed Nov 29 16:52:55 2023 : L2TP received ICRP
Wed Nov 29 16:52:55 2023 : L2TP sent ICCN
Wed Nov 29 16:52:55 2023 : L2TP connection established.
Wed Nov 29 16:52:55 2023 : L2TP set port-mapping for en12, interface: 24, protocol: 0, privatePort: 0
Wed Nov 29 16:52:55 2023 : using link 0
Wed Nov 29 16:52:55 2023 : Using interface ppp0
Wed Nov 29 16:52:55 2023 : Connect: ppp0 <--> socket[34:18]
Wed Nov 29 16:52:55 2023 : sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x24150a00> <pcomp> <accomp>]
Wed Nov 29 16:52:55 2023 : rcvd [LCP ConfReq id=0x1 <mru 1380> <asyncmap 0x0> <auth chap MS-v2> <magic 0x3f4c0dd3>]
Wed Nov 29 16:52:55 2023 : lcp_reqci: returning CONFACK.
Wed Nov 29 16:52:55 2023 : sent [LCP ConfAck id=0x1 <mru 1380> <asyncmap 0x0> <auth chap MS-v2> <magic 0x3f4c0dd3>]
Wed Nov 29 16:52:55 2023 : rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x24150a00> <pcomp> <accomp>]
Wed Nov 29 16:52:55 2023 : sent [LCP EchoReq id=0x0 magic=0x24150a00]
Wed Nov 29 16:52:55 2023 : rcvd [CHAP Challenge id=0x49 <d70ffd958211fe898fb55671e952b92f>, name = "xxx.yyy.de"]
Wed Nov 29 16:52:55 2023 : sent [CHAP Response id=0x49 <0282ade438d8b78c774992aa991c386700000000000000007c8a2b2a0920f56e6f2d74e76960c68066b59113de1fa93800>, name = "aaaa-bbbbbb"]
Wed Nov 29 16:52:55 2023 : rcvd [LCP EchoRep id=0x0 magic=0x3f4c0dd3]
Wed Nov 29 16:52:57 2023 : rcvd [CHAP Success id=0x49 "S=BD1A2B64BB9DAA3E6E93D6E8BF1421F64D18E1C1 M=Access granted"]
Wed Nov 29 16:52:57 2023 : sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Wed Nov 29 16:52:57 2023 : sent [IPV6CP ConfReq id=0x1 <addr fe80::f22f:4bff:fe01:3858>]
Wed Nov 29 16:52:57 2023 : rcvd [IPCP ConfReq id=0x1 <addr 172.24.0.1>]
Wed Nov 29 16:52:57 2023 : ipcp: returning Configure-ACK
Wed Nov 29 16:52:57 2023 : sent [IPCP ConfAck id=0x1 <addr 172.24.0.1>]
Wed Nov 29 16:52:57 2023 : rcvd [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a f2 2f 4b ff fe 01 38 58]
Wed Nov 29 16:52:57 2023 : rcvd [IPCP ConfNak id=0x1 <addr mmm.mm.1.1> <ms-dns1 bbb.bb.19.5> <ms-dns3 bbb.bb.19.1>]
Wed Nov 29 16:52:57 2023 : sent [IPCP ConfReq id=0x2 <addr mmm.mm.1.1> <ms-dns1 bbb.bb.19.5> <ms-dns3 bbb.bb.19.1>]
Wed Nov 29 16:52:57 2023 : rcvd [IPCP ConfAck id=0x2 <addr mmm.mm.1.1> <ms-dns1 bbb.bb.19.5> <ms-dns3 bbb.bb.19.1>]
Wed Nov 29 16:52:57 2023 : ipcp: up
Wed Nov 29 16:52:57 2023 : local  IP address mmm.mm.1.1
Wed Nov 29 16:52:57 2023 : remote IP address 172.24.0.1
Wed Nov 29 16:52:57 2023 : primary   DNS address bbb.bb.19.5
Wed Nov 29 16:52:57 2023 : secondary DNS address bbb.bb.19.1
Wed Nov 29 16:52:57 2023 : Received protocol dictionaries
Wed Nov 29 16:52:57 2023 : l2tp_wait_input: Address added. previous interface setting (name: en12, address: nn.nn.nn.209), current interface setting (name: ppp0, family: PPP, address: mmm.mm.1.1, subnet: 255.255.0.0, destination: 172.24.0.1).
Wed Nov 29 16:52:57 2023 : Committed PPP store on install command
Wed Nov 29 16:53:01 2023 : L2TP port-mapping update for en12 ignored: VPN is the Primary interface. Public Address: 0, Protocol: None, Private Port: 0, Public Port: 0
Wed Nov 29 16:53:01 2023 : L2TP clearing port-mapping for en12
Wed Nov 29 16:53:08 2023 : [TERMINATE]
Wed Nov 29 16:53:08 2023 : Terminating on signal 15.
Wed Nov 29 16:53:08 2023 : ipcp: down
Wed Nov 29 16:53:08 2023 : sent [LCP TermReq id=0x2 "User request"]
Wed Nov 29 16:53:08 2023 : Connection terminated.
Wed Nov 29 16:53:08 2023 : Connect time 0.3 minutes.
Wed Nov 29 16:53:08 2023 : Sent 21926 bytes, received 27291 bytes.
Wed Nov 29 16:53:08 2023 : L2TP disconnecting...
Wed Nov 29 16:53:08 2023 : L2TP sent CDN
Wed Nov 29 16:53:08 2023 : L2TP sent StopCCN
Wed Nov 29 16:53:08 2023 : L2TP clearing port-mapping for en12
Wed Nov 29 16:53:08 2023 : L2TP disconnected

[Monviech (Cedrik)]

Anhand der Logs kann man sehen dass die Phase1 fehlschlägt. Da ein Paket zurückkommt funktioniert Firewall technisch anscheinend alles.

Stell mal bei dem Client wo du es testest die MTU auf 1400 oder so und schaue ob die Verbindung dann klappt. Wenn ja, muss man auf der OPNsense eine "Normalization" Regel für diesen Verkehr anlegen.

Schade dass es kein besseres Log gibt was den "genauen" Fehler hergibt. "failed" ist etwas zu wenig leider.

[modi]

Habe nun auf meinem Rechnwer mit MTU Werten zw. 1280 und 1400 getestet.
Leider ist noch der gleiche Fehler da.

Ein Möglichkeit bei MacOS das ppp Log ausführlicher zu bekommen habe ich nicht gefunden.

Welche Logs wären noch interessant? Gibt es auf der opnsense etwas was ich ansehen kann?

[Monviech (Cedrik)]

Der Unterschied muss auf dem Client festgestellt werden. Installiere Wireshark auf dem MAC und schneide den Verbindungsaufbau mit wenn er funktioniert (hinter der UTM). Und danach wenn er nicht funktioniert (hinter der OPNsense). Anhand der PCAP Dateien kann man dann Unterschiede analysieren. (ISAKMP auf Port 500/4500).

So eine Analyse kann etwas Zeitaufwendig sein. Aber irgendwas passiert mit den Paketen auf Netzwerkebene was man anders nicht feststellen kann.

[modi]

in der Zwischenzeit habe ich Wireshark auf dem Mac installiert.
Da bin ich doch etwas überfordert.

 Es strömt soviel über das LAN Interface da kann ich nichts erkennen.
Das "Interface ppp0" wird leider auch erst nach dem erfolgreichen Aufbau
in Wireshark sichtbar.

Ich habe im LAN noch einen Debian Rechner. Werde versuchen dort einen
L2TP Client zu installieren. Vielleicht kann man dann mehr erkennen.

 

[Monviech (Cedrik)]

Du benutzt Wireshark falsch.

Bei Wireshark startet man das Mitschneiden auf dem Ethernet (LAN) Interface und beendet es wenn man fertig ist. In deinem Fall würde das Mitschneiden angemacht werden, bevor du die VPN Verbindung aufbaust, und dann nach ein paar Sekunden beendet nachdem es failed ist, oder nachdem die andere Verbindung erfolgreich war. Jedes mal speichert man dann die Datei.

Daraus hat man dann 2 PCAP Dateien, eine wo es funktioniert, und eine wo es nicht funktioniert.

In diesen Dateien kann man dann Filtern. z.B. nach

Code: [Select]

udp.port == 500 || udp.port == 4500
Dadurch sieht man dann alles was zum IPsec Verbindungsaufbau gehört und kann dann in beiden Dateien vergleichen wo der Fehler liegt.

[modi]

Ist das erste mal das ich mit Wireshark gearbeit habe.
Hat aber geholfen. Ohne in die einzelnen Bits zu gehen sieht man
schon das es anscheinend an der lokalen Firewall des Mac gelegen hat.

vielen Dank für die Unterstützung / Augen öffnen.

[Monviech (Cedrik)]

Hast du super gemacht. Freut mich dass du das Problem gefunden hast.