VPN Point to Site ICMP funktioniert, TCP nicht
-
@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:
Das ist alles was ich für WG an der FritzBox konfiguriert habe.
Das ist nicht korrekt, da der Assistent das macht. Wie gesagt, es ist der andere Button, der die Tunnel-Config auf Seite der Fritzbox anzeigt. Und da darf nur die IP der FB auftauchen, die musst Du nämlich in der Config von der anderen Seite schon dort eintragen.
-
Hier brauche ich glaube ich noch mal ein Auffrischung: Bisher dachte ich, wenn Ping funktioniert, dann ist zumindest bei dem Thema Routing/NAT alles passend konfiguriert und meine Probleme liegen eher bei Firewall, MTU Size etc. Irre ich mich da?
-
Ich hänge hier auch mal noch den die Packet Capture Ausgaben von den beiden Tunnelinterfaces auf der pfSense dran. Es wird vom VPN-Client (10.111.111.194) der Homeserver (192.168.178.40) erst gepingt und dann versucht eine https Verbindung zu Port 8096 aufzubauen.
Protokoll von "WGtoHome" das Interface der pfSense mit der Fritzbox auf der anderen Seite
10:18:29.528761 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1629, seq 1, length 64 10:18:29.544324 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1629, seq 1, length 64 10:18:30.641733 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1630, seq 1, length 64 10:18:30.657190 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1630, seq 1, length 64 10:18:31.769912 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1631, seq 1, length 64 10:18:31.785601 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1631, seq 1, length 64 10:18:38.241731 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0 10:18:38.248959 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0 10:18:38.257544 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0 10:18:38.264558 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0 10:18:39.249772 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0 10:18:39.249794 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0 10:18:39.262905 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0 10:18:39.278293 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0 10:18:41.242700 IP 10.111.111.194.42500 > 192.168.178.40.8096: tcp 0 10:18:41.242733 IP 10.111.111.194.42492 > 192.168.178.40.8096: tcp 0 10:18:41.278328 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0 10:18:41.293476 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0 10:18:45.293411 IP 10.111.111.18.8096 > 10.111.111.194.42500: tcp 0 10:18:45.293509 IP 10.111.111.18.8096 > 10.111.111.194.42492: tcp 0Protokoll von "WGfromInternet" das Interface der pfSense mit den Tunneln zu den Endgeräten irgendwo in freier Wildbahn
10:20:37.481752 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1665, seq 1, length 64 10:20:37.497618 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1665, seq 1, length 64 10:20:38.601706 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1666, seq 1, length 64 10:20:38.617664 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1666, seq 1, length 64 10:20:39.728646 IP 10.111.111.194 > 192.168.178.40: ICMP echo request, id 1667, seq 1, length 64 10:20:39.744584 IP 10.111.111.18 > 10.111.111.194: ICMP echo reply, id 1667, seq 1, length 64 10:20:44.848783 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0 10:20:44.848897 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0 10:20:45.841665 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0 10:20:45.849767 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0 10:20:48.041692 IP 10.111.111.194.47002 > 192.168.178.40.8096: tcp 0 10:20:48.041751 IP 10.111.111.194.47004 > 192.168.178.40.8096: tcp 0Die Firewallregeln sind momentan für die Wireguard Interfaces Any Any. Auch unter Firewall / Rules / WireGuard ist erstmal Any Any konfiguriert.
-
@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:
Bisher dachte ich, wenn Ping funktioniert, dann ist zumindest bei dem Thema Routing/NAT alles passend konfiguriert und meine Probleme liegen eher bei Firewall, MTU Size etc. Irre ich mich da?
Nicht so ganz. Wie du schon im Titel geschrieben hattest, sind das verschiedene Protokolle (ICMP und TCP). TCP ist anders als ICMP "stateful". D.h. die Pakete müssen den Router in einer bestimmten Abfolge passieren. Die Verbindung muss mit einem SYN Paket geöffnet werden, dann lässt der Router SYN-ACK aus der anderen Richtung durch, usw.
Bei ICMP ist das nicht relevant.So führt beispielsweise ein asymmetrisches Routing zu einem Nicht-funktionieren von TCP. ICMP beeinträchtigt das nicht.
Asymmetrisches Routing bedeutet, dass die Pakete in der einen Richtung (Request) einen anderen Weg nehmen als in der entgegengesetzten (Respond).
In der pfSense ist ein solches Problem im Firewall Log sichtbar, wenn TCP Pakete mit anderen Flags als S oder SEC blockiert werden.
Voraussetzung ist, dass das Logging der Default Block Rule aktiviert ist. -
Bei AVM Kisten muss man doch noch NetBios über VPN zulassen für SMB Zugriff.
Nicht das hier mal wieder mehr hinter steckt als der Name vermuten lässt.
Mal einschalten und den Tunnel neu aufbauen. -
Dein Tip war richtig, ich kann im Firewall Log die Blockaden der SYN ACK und wenig später der Resend Pakete.
x Aug 12 14:44:51 WGTOHOME 10.111.111.18:8096 10.111.111.194:38768 TCP:SA x Aug 12 14:44:51 WGTOHOME 10.111.111.18:8096 10.111.111.194:38766 TCP:SA . . . x Aug 12 14:44:57 WGTOHOME 10.111.111.18:8096 10.111.111.194:38768 TCP:R x Aug 12 14:44:57 WGTOHOME 10.111.111.18:8096 10.111.111.194:38766 TCP:RIch habe allerdings noch nicht verstanden wie ich das lösen kann. Mit Statischen Routen? Wenn ja wer ist in dem Fall der Gateway oder welchen müsste man hinzufügen?
-
@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:
TCP:SA
Das ist das SYN-ACK Paket, also die Antwort auf ein initiales SYN Paket.
Das bedeutet nun, das SYN Paket hat den Server erreicht, ansonsten würde er kein SYN-ACK schicken, jedoch hat es den Router nicht passiert, der dann das SYN-ACK blockiert.
Es muss also seinen Weg zum Server gefunden haben, jedoch nicht jenen, den das SYN-ACK Paket nimmt.Vielleicht hilft das, rauszufinden, wie es zu dem Problem kommt.
Ich habe mich nicht so weit mit deinem Setup geschäftig, dass ich da nun mehr sagen könnte.TCP:R ist wohl eher ein Reset.
-
@TheBlackOne said in VPN Point to Site ICMP funktioniert, TCP nicht:
Ich habe allerdings noch nicht verstanden wie ich das lösen kann. Mit Statischen Routen?
Ich frage mich gerade zu welchem Wireguard-Tunnel der Eintrag WGtoHOME aus deinem Bild (Status / Gateways) gehört. Bei mir sieht das ganz anders aus, Weder bei meinem Wireguard-Tunnel zur Fritz-Box noch dem WIreguard-Tunnel für mobile Geräte, wie Smartphone, Tablet und Notebooks sieht das Gateway so aus wie bei dir.
Stattdessen zeigt bei mir der Status / Gateways für das Gateway des Wireguard-Tunnels zwischen FritzBox und pfsense unter Gateway den Wert dynamic und unter Monitor keinen Eintrag.
Ich hatte dir ja bereits gestern diesen Hinweis geschickt:
https://v64.tech/t/anleitung-site2site-wireguard-verbindung-zwischen-pfsense-und-fritzbox/438/13
Mit dieser Anleitung und mit meiner Ergänzung in den Kommentaren am Ende hat es bei mir funktioniert und läuft seit Wochen fehlerfrei durch.
(pfsense bei mir Zuhause, FritzBox an entferntem Standort)Du scheinst einen komplett anderen Ansatz zu verfolgen und offenbar ein Transfernetz zwischen pfsense und fritzbox zu haben, sofern der Eintrag zur Verbindung Fritzbox pfsense gehört.
Fritzboxen unterstützen aber kein Transfernetz, oder wenn dann nur mit ziemlichen Verrenkungen. Vielleicht solltest du daher deinen bisherigen Ansatz verwerfen und den aus der oben verlinkten Anleitung auf v64.tech verfolgen. Bei mir klappt der Ansatz von v64.tech jedenfalls ganz wunderbar und läuft stabil.
-
Zudem fällt mir auf, dass du am WAN interface eine private, also nicht öffentlich routebare IPv4-Adresse anliegen hast. 172.31.1.1
Somit hast du vor der pfsense noch einen Router, was doppeltes NAT bei IPv4 bedeutet. Auch das kann natürlich zu Routingproblemem führen.
-
@eagle61 said in VPN Point to Site ICMP funktioniert, TCP nicht:
Zudem fällt mir auf, dass du am WAN interface eine private, also nicht öffentlich routebare IPv4-Adresse anliegen hast. 172.31.1.1
Sind schon ein paar Merkwürdigkeiten aufgefallen.
@eagle61 Hast Du denn mit deinem Ansatz überhaupt eine IP-Adresse? Ein WireGuard-Interface braucht zwar nicht zwingend eine IP, aber es hat doch Vorteile, wenn es eine hat. Z.B. kannst Du NATen, was Du vermutlich auch musst, wenn mehr als das eine Subnet mit der Fritzbox kommunizieren können soll. Also Dein Ansatz sieht auch eher suboptimal aus.
-
@Bob-Dig said in VPN Point to Site ICMP funktioniert, TCP nicht:
kannst Du NATen, was Du vermutlich auch musst, wenn mehr als das eine Subnet mit der Fritzbox kommunizieren können soll.
Mit mehr als das eine Subnet meinst du mehr als ein SUbnetz auf Seiten der pfsense, also neben dem LAN der pfsense noch andere Subnetze wie DMZ, IoT?
Ja, das geht, sogar ohne zu NATen. Das kann nur der Wireguard-Konfigurationsassist der FritzBox nicht. Manuell kann man das aber nachträglich einrichten. Wie das geht beschreibt "Biberbaer" auch in seiner Anleitung auf v64.tech. Unter Erweiterte Methode zum hinzufügen, bearbeiten oder ergänzen von Peers in der FritzBox. von Oktober 2023. WIchtig ist sein Hinweis "mindestens eine WireGuard Verbindung gespeichert zu haben" bevor man dann die Config-Datei per Hand editiert und dort die von z.B. AllowedIPs = 192.168.0.0/24 ändert auf AllowedIPs = 192.168.0.0/24,192.168.10.0/24
So habe ich es auch gemacht und kann nun alle Subnetze hinter meiner pfsense vom Netzwerk der FB aus erreichen und umgekehrt klappt es auch.
In der FB sieht das dann so aus:
Wobei der zweite Eintrag der ursprüngliche Eintrag aus dem Konfigurationsassistenten war. der erste Eintrag der von mir manuell editierte ist, über den ich nun die drei genannten Subnetze erreichen kann.Wie man auch sehen kann habe ich nicht nur die erreichbaren Netze ergänzt, sondern auch die DNS-Adresse der pfsense verändert. Geht auch.
-
@eagle61 Ok, etwas sehr frickelig für meinen Geschmack. Man kann aber auch eine Config im Voraus erstellen und dann an die Fritte übergeben, mit allen Netzen.
Was dir aber noch fehlt ist z.B. gateway-monitoring.
Dafür nutzt Du auf Seite der pfSense ein Transfernetz und musst dieses natürlich der Fritte auch noch als allowed IP verklickern. Dann machst Du auf das WG Interface einfach eine IP aus dem Transfernetz. Für das Gateway kannst Du dann die IP der Fritte nutzen (Use non-local gateway aktivieren). So sollte das sauber laufen.
Ich würde vermutlich nur ein Subnet bekannt machen, das Transfernetz, und dann NATen. -
@Bob-Dig said in VPN Point to Site ICMP funktioniert, TCP nicht:
Man kann aber auch eine Config im Voraus erstellen und dann an die Fritte übergeben, mit allen Netzen
Kann man das? WOher bekommt die Fritte dann den private Key? Soweit ich das verstehe muss man dazu mindestens einmal eine Wireguard-Verbindung per Konfigurationsassistenten erstellen. genau deswegen darf man ja auch nicht alle erstellten Verbindungen löschen, wenn man die Vrbindung nachträglich manuell editiert. Dann löscht die Fritte nämlich alle Keys umd man fängt wieder von vorn an.
-
@eagle61 said in VPN Point to Site ICMP funktioniert, TCP nicht:
Kann man das? WOher bekommt die Fritte dann den private Key?
So wie ich das gelesen habe, erstellt Du diese WG-Config mit privatem Key und allem wie sonst außer, dass Du keine Adresse mitgibst, die setzt die Fritte automatisch, auf ihre LAN-Adresse.
Ich hatte das so auch heute probiert und ging, allerdings habe ich die Verbindung nicht getestet, da ich keine Anwendungsfall dafür habe, also die Config war nur ausgedacht. Es wurde mir aber alles passend in der Fritte angezeigt. -
@TheBlackOne leider hast du mir die frage nicht beantwortet, warum stellst du dir nicht alternativ eine pfSense zuhause hin. Für mich war es die beste entscheidung meine Fritzbox (2015/2016) zu einer Sense zu wechseln.
Du hast so viel möglichkeiten, es macht für mich vieles einfacher als mit einer Fritzbox. Mir ist noch eine frage aufgefallen, warum hast du erst ein 0er netzt angebeben und später wird es doch ein 178er netz. was bezewckst du damit, private IP bereiche kannst du posten wie du willst, da sind keine geheimnisse?Wenn du der Anleitung von v64.tech abarbeitest, hast du einen wireguard tunnel der mit einer fritzbox funktioniert. ich habe ihn genau so konfiguriert und habe halt ein vpn zu dem 190er netz.
Internet: Willy.tel Down: 1Gbit/s, UP: 250Mbit/s Glasfaser |
Hardware: Netgate 6100
ALT Intel NUC BNUC11TNHV50L00 (32GB Ram, 512GB M.2 NVME SSD) -
@eagle61 Ich hab jetzt auch mal so eine Verbindung gebaut, aber mit Gateway und NAT. Habe selbst aber keinen Anwendungsfall dafür.
MTU habe ich einfach möglichst gering gesetzt, weil ich nicht weiß, was die Fritte nutzt.
Die Fritte selbst NATet übrigens nicht über den Tunnel. Eine Frage, die ich mir lange selbst gestellt habe, nun kenne ich die Antwort.
-
@Bob-Dig said in VPN Point to Site ICMP funktioniert, TCP nicht:
MTU habe ich einfach möglichst gering gesetzt, weil ich nicht weiß, was die Fritte nutzt.
1392 ist die voreingestellte MTU der Fritte für Wireguard-Tunnel.
Kannste dir aber anzeigen lassen. Linux tracepath zeigt die an.
-
@eagle61 Man kann doch relativ leicht Allowed IPs hinzufügen, habe ich gerade festgestellt.
- Einfach die "WireGuard
-Einstellungen" anzeigen und exportieren. - In der Datei die neuen Allowed IP hinzufügen und speichern.
- Die bestehende WireGuard-Verbindung in der Fritte löschen.
- Eine neue Verbindung anlegen, dabei auswählen, dass die WG-Verbindung bereits auf der Gegenstelle erstellt wurde.
- Einen Namen vergeben und die editierte Datei laden.
Solange die Fritte vor Ort gemanaget wird, ist das kein größeres Problem. Das läuft jedenfalls und damit würde ich natürlich auch kein NAT benutzen wollen bei der Site2Site-Verbindung.
- Einfach die "WireGuard
-
@Bob-Dig said in VPN Point to Site ICMP funktioniert, TCP nicht:
Man kann doch relativ leicht Allowed IPs hinzufügen, habe ich gerade festgestellt
Das ist ziemlich genau die Methode aus der von mir gestern verlinkten Anleitung bei v64.tech, nach der ich das auch gemacht habe. Wird dort in einem Kommentar von Oktober 2023 beschrieben.
-
@eagle61 Hab ich nicht gelesen, weil die wohl dem Interface und Gateway keine IP geben.
