32
PfSense, Wireguard und Routing
Hallo,
ich habe vor einiger Zeit in Azure eine pfSens als Firewall am laufen und habe diese per VPN mit 2 Lancom Routern verbunden.
Nun habe ich Wireguard installiert und zum laufen bekommen.
Aber es funktioniert nicht alles so wie ich es gerne hätte und mit meinem wenigen Wissen komme ich da nicht weiter.....
Azure
192.168.0.1/24
per NSG sind die für VPN notwendigen Ports freigegeben, alles Andere ist gesperrt
pfsense:
WAN 192.168.0.4/24 , Gateway 192.168.0.1
LAN 10.3.0.5/24
WGTUNNEL 10.3.1.1/24
1. IKEv2 tunnelt zu 10.0.0.1/24
2. IKEv2 tunnelt zu 10.2.0.1/24
Firewall:
NAT steht auf Automatic
WAN den Port für WG freigegeben
LAN hat alles freigegeben für IPv4
WG TUNNEL ist alles freigegeben für IPv4
IPsec ist alles freigegeben für IPv4
Ich hoffe das reicht im Ersten Schritt als Info, ich ergänze gerne.
Nun zu den Problemen:
Ich kann über alle VPN Zugänge das Netz 10.3.0.0/24 erreichen
Aus dem Netz hinter pfsense erreiche ich nur das Internet, nicht mal die pfsense
Das ist nicht tragisch aber sicher ein Fehler.
Im Dashboard der pfsense wird unter Gateways WAN_DHCP 192.168.0.1 als offline rot angezeigt.
Von der pfsense erreiche ich die mit Wirequard verbundenen Clients, nicht aber die Netze 10.0.0.0/24 und 10.2.0.0/24
Mit Wireguard würde ich nun auch noch gerne die Netze 10.0.0.0/24 und 10.2.0.0/24 erreichen.
Ich habe nun einiges versucht und probiert komme aber nicht weiter.
Wireguard macht evtl. Probleme in Verbindung mit meinen NAT Einstellungen (?)
Eventuell sind Rückrouten falsch oder gar nicht angelegt.
Würde mich freuen wenn da jemand helfen kann. Vermutlich sind es verschiedene Baustellen und sicher fehlen dazu noch Infos.
ich habe vor einiger Zeit in Azure eine pfSens als Firewall am laufen und habe diese per VPN mit 2 Lancom Routern verbunden.
Nun habe ich Wireguard installiert und zum laufen bekommen.
Aber es funktioniert nicht alles so wie ich es gerne hätte und mit meinem wenigen Wissen komme ich da nicht weiter.....
Azure
192.168.0.1/24
per NSG sind die für VPN notwendigen Ports freigegeben, alles Andere ist gesperrt
pfsense:
WAN 192.168.0.4/24 , Gateway 192.168.0.1
LAN 10.3.0.5/24
WGTUNNEL 10.3.1.1/24
1. IKEv2 tunnelt zu 10.0.0.1/24
2. IKEv2 tunnelt zu 10.2.0.1/24
Firewall:
NAT steht auf Automatic
WAN den Port für WG freigegeben
LAN hat alles freigegeben für IPv4
WG TUNNEL ist alles freigegeben für IPv4
IPsec ist alles freigegeben für IPv4
Ich hoffe das reicht im Ersten Schritt als Info, ich ergänze gerne.
Nun zu den Problemen:
Ich kann über alle VPN Zugänge das Netz 10.3.0.0/24 erreichen
Aus dem Netz hinter pfsense erreiche ich nur das Internet, nicht mal die pfsense
Das ist nicht tragisch aber sicher ein Fehler.
Im Dashboard der pfsense wird unter Gateways WAN_DHCP 192.168.0.1 als offline rot angezeigt.
Von der pfsense erreiche ich die mit Wirequard verbundenen Clients, nicht aber die Netze 10.0.0.0/24 und 10.2.0.0/24
Mit Wireguard würde ich nun auch noch gerne die Netze 10.0.0.0/24 und 10.2.0.0/24 erreichen.
Ich habe nun einiges versucht und probiert komme aber nicht weiter.
Wireguard macht evtl. Probleme in Verbindung mit meinen NAT Einstellungen (?)
Eventuell sind Rückrouten falsch oder gar nicht angelegt.
Würde mich freuen wenn da jemand helfen kann. Vermutlich sind es verschiedene Baustellen und sicher fehlen dazu noch Infos.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31298641422
Url: https://administrator.de/forum/pfsense-wireguard-und-routing-31298641422.html
Ausgedruckt am: 05.02.2025 um 18:02 Uhr
32 Kommentare
Neuester Kommentar
Das hiesige Wireguard Tutorial beschreibt das pfSense und OPNsense WG Setup im Detail. Besonders bei der pfSense ist hier etwas Sorgfalt geboten, weil es die Cryptokey Routings nicht automatisch in die Routing Tabelle übernimmt! Hier muss man also mit statischen Routen nachhelfen.
Das pfSense spezifische WG Tutorial erläutert die einzelnen Konfig Schritte.
Zusätzlich musst du natürlich daran denken das du im IPsec Setup deiner Lancom Peers das interne Wireguard IP Netz zusätzlich noch als 2te Phase 2 SA eintragen musst damit dieser Traffic auch in die IPsec Tunnel geforwardet wird!
Eins oder beides dieser Dinge hast du vermutlich vergessen?! Wegen fehlender Infos deines Setups kann man hier aber leider nur wieder Kristallkugeln...
Letztlich fragt sich warum du so eine, eigentlich überflüssige, Frickelei mit einem 2ten VPN Protokoll überhaupt machst?!
Wenn es dir nur um mobile Clients geht ist es deutlich besser diese ebenfalls mit IPsec IKEv2 anzubinden. Zusätzlich vereinfacht es erheblich das Management:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das hat den unschätzbaren Vorteil das du nicht mit einem 2ten Protokoll und überflüssiger VPN Client Software auf den Endgeräten rumfrickeln musst sondern kannst ein gemeinsames VPN Protokoll und vor allem die überall vorhandenen onboard VPN Clients nutzen! Win win also... 😉
Alternativ böte sich auch noch L2TP an:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Das pfSense spezifische WG Tutorial erläutert die einzelnen Konfig Schritte.
Zusätzlich musst du natürlich daran denken das du im IPsec Setup deiner Lancom Peers das interne Wireguard IP Netz zusätzlich noch als 2te Phase 2 SA eintragen musst damit dieser Traffic auch in die IPsec Tunnel geforwardet wird!
Eins oder beides dieser Dinge hast du vermutlich vergessen?! Wegen fehlender Infos deines Setups kann man hier aber leider nur wieder Kristallkugeln...
Letztlich fragt sich warum du so eine, eigentlich überflüssige, Frickelei mit einem 2ten VPN Protokoll überhaupt machst?!
Wenn es dir nur um mobile Clients geht ist es deutlich besser diese ebenfalls mit IPsec IKEv2 anzubinden. Zusätzlich vereinfacht es erheblich das Management:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten
Das hat den unschätzbaren Vorteil das du nicht mit einem 2ten Protokoll und überflüssiger VPN Client Software auf den Endgeräten rumfrickeln musst sondern kannst ein gemeinsames VPN Protokoll und vor allem die überall vorhandenen onboard VPN Clients nutzen! Win win also... 😉
Alternativ böte sich auch noch L2TP an:
PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer
Hallo und danke für die Rückmeldung, ich arbeite das Tutorial gerade noch mal durch.
IKEv2 habe ich gut mit den Lancom Devices ans Laufen bekommen, mit Windows hatte ich aber immer Probleme und habe aufgegeben. WG lief ja recht schnell und ist einfach zu konfigurieren.
Eine zusätzliche 2. Phase habe ich natürlich nicht eingetragen .... da bin ich auch gerade am schauen was da rein muss .....
Welche Angeben zu meinem Setup fehlen denn um hier die einzelnen Punkte abzuarbeiten ? Evtl. als erstes mal warum im Dashboard das Gateway rot angezeigt wird (?)
IKEv2 habe ich gut mit den Lancom Devices ans Laufen bekommen, mit Windows hatte ich aber immer Probleme und habe aufgegeben. WG lief ja recht schnell und ist einfach zu konfigurieren.
Eine zusätzliche 2. Phase habe ich natürlich nicht eingetragen .... da bin ich auch gerade am schauen was da rein muss .....
Welche Angeben zu meinem Setup fehlen denn um hier die einzelnen Punkte abzuarbeiten ? Evtl. als erstes mal warum im Dashboard das Gateway rot angezeigt wird (?)
mit Windows hatte ich aber immer Probleme und habe aufgegeben.
Warum?? Das ist sehr schade denn es funktioniert einwandfrei ohne jegliche Probleme wenn man das o.a. Tutorial und die weiterführenden Links genau beachtet und sich Schritt für Schritt daran hält! 
Eine zusätzliche 2. Phase habe ich natürlich nicht eingetragen
Böses Faul! Dann kann das logischerweise nicht klappen. Woher sollen denn die Lancom Netze sonst wissen das das interne WG Netz mit in den IPsec Tunnel muss wenn du ihnen das in der P2 SA nicht mitteilst? Sagt einem eigentlich schon der gesunde IT Verstand! Beispiele dazu findest du z.B. hier:
PFSense mit Fritzboxen verbinden
Routingprobleme über OpenVPN auf Fritzbox
Die sollten dir das Prinzip erklären.
Welche Angeben zu meinem Setup fehlen denn um hier die einzelnen Punkte abzuarbeiten
Vergleiche es erstmal mit dem o.a. WG Beispielsetup der pfSense ob das deinem entspricht und du alles umgesetzt hast! Hier müssen natürlich auch die beiden IP Netze 10.0.0.1/24 und 10.2.0.0/24 in die "AllowedIPs" bei den WG Clients! (Siehe Beispiel hier)Wie gesagt, diese ganze gruselige Frickelei kannst du dir mit einem IKEv2 Server für die mobilen Clients ersparen und wäre der deutlich bessere Weg...aber nundenn...
Die Wireguard Konfiguration bin ich durchgegangen, die ist richtig und funktioniert. Evtl. war da mein Kommentar zu dem rot markierten WAN Gateway verwirrend:
Ich hatte immer versucht, eine Verbindung von Windows auf die Lancom Router zu bekommen. Die Verbindung auf die pfsense habe ich nicht nicht versucht. - Das gehe ich mal an. Wobei Wireguard halt echt schnell und einfach ist.
Beispiele dazu findest du z.B. hier:
PFSense mit Fritzboxen verbinden
Routingprobleme über OpenVPN auf Fritzbox
Die sollten dir das Prinzip erklären.
in der pfsense habe ich nun eine 2. Phase eingetragen
Im Lancom Router muss ich suchen wo ich das eintrage
Wie oben geschrieben, Wireguard selbst funktioniert.
Wie gesagt, diese ganze gruselige Frickelei kannst du dir mit einem IKEv2 Server für die mobilen Clients ersparen und wäre der deutlich bessere Weg...aber nundenn...
Ich setze mich nachher mal dran, den Versuch zu starten, von Windows aus auf die pfsense zu kommen per IKEv2.
Was mir nach wie vor unklar ist, warum können meine Geräte im Netz hinter der pfsense (LAN, 10.3.0.0/24) nicht mal die pfsense erreichen?
Die 1. Regel würde ja genau den Zugriff sicherstellen.
Zitat von @aqui:
Tutorial und die weiterführenden Links genau beachtet und sich Schritt für Schritt daran hält! mit Windows hatte ich aber immer Probleme und habe aufgegeben.
Warum?? Das ist sehr schade denn es funktioniert einwandfrei ohne jegliche Probleme wenn man das o.a.Ich hatte immer versucht, eine Verbindung von Windows auf die Lancom Router zu bekommen. Die Verbindung auf die pfsense habe ich nicht nicht versucht. - Das gehe ich mal an. Wobei Wireguard halt echt schnell und einfach ist.
Eine zusätzliche 2. Phase habe ich natürlich nicht eingetragen
Böses Faul! Dann kann das logischerweise nicht klappen. Woher sollen denn die Lancom Netze sonst wissen das das interne WG Netz mit in den IPsec Tunnel muss wenn du ihnen das in der P2 SA nicht mitteilst? Sagt einem eigentlich schon der gesunde IT Verstand! Beispiele dazu findest du z.B. hier:
PFSense mit Fritzboxen verbinden
Routingprobleme über OpenVPN auf Fritzbox
Die sollten dir das Prinzip erklären.
in der pfsense habe ich nun eine 2. Phase eingetragen
Im Lancom Router muss ich suchen wo ich das eintrage
Welche Angeben zu meinem Setup fehlen denn um hier die einzelnen Punkte abzuarbeiten
Vergleiche es erstmal mit dem o.a. WG Beispielsetup der pfSense ob das deinem entspricht und du alles umgesetzt hast! Hier müssen natürlich auch die beiden IP Netze 10.0.0.1/24 und 10.2.0.0/24 in die "AllowedIPs" bei den WG Clients! (Siehe Beispiel hier)Wie gesagt, diese ganze gruselige Frickelei kannst du dir mit einem IKEv2 Server für die mobilen Clients ersparen und wäre der deutlich bessere Weg...aber nundenn...
Was mir nach wie vor unklar ist, warum können meine Geräte im Netz hinter der pfsense (LAN, 10.3.0.0/24) nicht mal die pfsense erreichen?
Die 1. Regel würde ja genau den Zugriff sicherstellen.
Das gehe ich mal an. Wobei Wireguard halt echt schnell und einfach ist.
Nicht immer. Zumal man dort dann immer die Fricklei mit zusätzlicher Client VPN Software hat die schlicht überflüssig ist.in der pfsense habe ich nun eine 2. Phase eingetragen
Die völliger Quatsch ist, denn sie definiert das gleiche Ziel IP Netz wie die erste SA. Sinnfrei...! von Windows aus auf die pfsense zu kommen per IKEv2.
Sicherlich die sinnvollere Aktion. 😉warum können meine Geräte im Netz hinter der pfsense (LAN, 10.3.0.0/24) nicht mal die pfsense erreichen?
Das ist eine gute Frage. Das o.a. Regelwerk dazu ist zwar unsinnig und überflüssig (Test) weil die Default Rule existiert, letztlich greift diese aber so das es am Regelwerk selber keinesfalls liegt weil dies schlicht und einfach nix blockt. Generell empfiehlt sich immer solche sinnfreien Regeln wieder zu löschen und das Regelwerk sauber zu halten weil darauf immer die Sicherheit einer Firewall basiert! 🧐Sehr wahrscheinlich hast du ein Layer 2 Problem das es gar keine L2 Connectivity mit dem FW LAN Interface und dem Device gibt wo deine LAN Clients angeschlossen sind.
Da die FW, wie du beschreibst, virtuell ist, hast du vermutlich einen Fehler zwischen dem LAN Port der Firewall VM und dem dazu korrespondierenden vSwitch deines Hypervisors.
Ein grober Kardinalsfehler der dir zu denken geben sollte. Wenn es an solchen grundsätzlichen Dingen schon scheitert sind gravierendere Probleme damit vorprogrammiert. Weisst du ja auch alles selber...?!
Beispiele aus Virtualisierungsumgebungen findest du z.B. hier und auch hier.
Hallo,
Du musst das implizite Routing von Azure mit einer Route-Table für das Subnet überschreiben. Für den Betrieb eines virtuellen Routers analog zu physischer Infrastruktur sind drei Azure-Routen erforderlich:
Eine Standardroute (0.0.0.0/0) mit Next-Hop-Typ "Virtual Appliance" und der IP des virtuellen Routers, die VNet-Range(s) ebenfalls mit Next-Hop-Typ "Virtual Appliance" und der Router-IP (denn 0.0.0.0/0 erfasst nicht die VNet-Range) und die Subnet-Range mit Next-Hop-Typ "Virtual Network". Letztere ist optional - ohne sie separiert aber die pfSense auch Traffic zwischen Hosts desselben Subnets.
In der pfSense einfach das Gateway-Monitoring ausschalten.
Grüße
Richard
Du musst das implizite Routing von Azure mit einer Route-Table für das Subnet überschreiben. Für den Betrieb eines virtuellen Routers analog zu physischer Infrastruktur sind drei Azure-Routen erforderlich:
Eine Standardroute (0.0.0.0/0) mit Next-Hop-Typ "Virtual Appliance" und der IP des virtuellen Routers, die VNet-Range(s) ebenfalls mit Next-Hop-Typ "Virtual Appliance" und der Router-IP (denn 0.0.0.0/0 erfasst nicht die VNet-Range) und die Subnet-Range mit Next-Hop-Typ "Virtual Network". Letztere ist optional - ohne sie separiert aber die pfSense auch Traffic zwischen Hosts desselben Subnets.
In der pfSense einfach das Gateway-Monitoring ausschalten.
Grüße
Richard
2
Hallo Richard,
ich habe als Gateway Monitor eine WAN Ip eingetragen und der Fehler vom Gateway ist weg. Das war nichts tragisches, aber man muss es mal finden.
Bei der Routing Tabelle ist mir noch nicht alles klar - ja ich bin kein Experte und trotzdem frage ich im Experten Forum ....
Standard Route ist klar.
VNET-Range(s) ist mir unklar, evtl habe ich da aber auch einen Fehler ....
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
In vielen Beispielen ist es aber ein Adressbereich, z.B. 10.3.0.0 der über die Maske in 2 Subnetze aufgeteilt ist.
Nach den Beispielen würde die Vnet_Range die 10.3.0.0 sein und die Subnetze wären entsprechend die Subnetze .... bin ich da auf dem Holzweg ?
Ich wüsste halt nicht was bei mir die VNETRange wäre wenn sie nicht mit dem Subnetz identisch ist.
Und In der Routing Tabelle meines LANs hat ja auch ein Routing ins 192.168.er Netz nichts verloren.
ich habe als Gateway Monitor eine WAN Ip eingetragen und der Fehler vom Gateway ist weg. Das war nichts tragisches, aber man muss es mal finden.
Bei der Routing Tabelle ist mir noch nicht alles klar - ja ich bin kein Experte und trotzdem frage ich im Experten Forum ....
Standard Route ist klar.
VNET-Range(s) ist mir unklar, evtl habe ich da aber auch einen Fehler ....
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
In vielen Beispielen ist es aber ein Adressbereich, z.B. 10.3.0.0 der über die Maske in 2 Subnetze aufgeteilt ist.
Nach den Beispielen würde die Vnet_Range die 10.3.0.0 sein und die Subnetze wären entsprechend die Subnetze .... bin ich da auf dem Holzweg ?
Ich wüsste halt nicht was bei mir die VNETRange wäre wenn sie nicht mit dem Subnetz identisch ist.
Und In der Routing Tabelle meines LANs hat ja auch ein Routing ins 192.168.er Netz nichts verloren.
Zitat von @aqui:
Ich habe IKEv2 nun auf einem Windows Client am laufen und es verbindet sich auch mit der pfsense. Leider kann ich nur die pfsense pingen und erreiche nichts im Netzwerk ....Das gehe ich mal an. Wobei Wireguard halt echt schnell und einfach ist.
Nicht immer. Zumal man dort dann immer die Fricklei mit zusätzlicher Client VPN Software hat die schlicht überflüssig ist.Ich bin der obigen Anleitung gefolgt, Lokales NMetzwerk steht auf LAN subnet
Sehr wahrscheinlich hast du ein Layer 2 Problem das es gar keine L2 Connectivity mit dem FW LAN Interface und dem Device gibt wo deine LAN Clients angeschlossen sind.
Da die FW, wie du beschreibst, virtuell ist, hast du vermutlich einen Fehler zwischen dem LAN Port der Firewall VM und dem dazu korrespondierenden vSwitch deines Hypervisors.
Ein grober Kardinalsfehler der dir zu denken geben sollte. Wenn es an solchen grundsätzlichen Dingen schon scheitert sind gravierendere Probleme damit vorprogrammiert. Weisst du ja auch alles selber...?!
Beispiele aus Virtualisierungsumgebungen findest du z.B. hier und auch hier.
Es lag nur am Monitoring des Gateways und nun leuchtet es schön grün.Da die FW, wie du beschreibst, virtuell ist, hast du vermutlich einen Fehler zwischen dem LAN Port der Firewall VM und dem dazu korrespondierenden vSwitch deines Hypervisors.
Ein grober Kardinalsfehler der dir zu denken geben sollte. Wenn es an solchen grundsätzlichen Dingen schon scheitert sind gravierendere Probleme damit vorprogrammiert. Weisst du ja auch alles selber...?!
Beispiele aus Virtualisierungsumgebungen findest du z.B. hier und auch hier.
Ich bin leider kein Experte daher frage ich und hoffe auf Hilfe.
Zitat von @tmevent:
Ich bin der obigen Anleitung gefolgt, Lokales Netzwerk steht auf LAN subnet
Auch das läuft nun ....Zitat von @aqui:
Ich habe IKEv2 nun auf einem Windows Client am laufen und es verbindet sich auch mit der pfsense. Leider kann ich nur die pfsense pingen und erreiche nichts im Netzwerk ....Das gehe ich mal an. Wobei Wireguard halt echt schnell und einfach ist.
Nicht immer. Zumal man dort dann immer die Fricklei mit zusätzlicher Client VPN Software hat die schlicht überflüssig ist.Ich bin der obigen Anleitung gefolgt, Lokales Netzwerk steht auf LAN subnet
Zitat von @tmevent:
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
Das wird nicht richtig sein, sonst würde VNet-Range dir was sagen. Du darfst generell in der pfSense keine Adressen konfigurieren, die auf Azure nicht ebenfalls konfiguriert sind.
Nach den Beispielen würde die Vnet_Range die 10.3.0.0 sein und die Subnetze wären entsprechend die Subnetze .... bin ich da auf dem Holzweg ?
Die VNet-Ranges sind grundlegende Eigenschaften des VNets, ganz oben in den Einstellungen. Du kannst in einem VNet nur Subnetze aus den VNet-Ranges erstellen. Wenn Du im Assistenten immer nur weiter klickst, wird das ein VNet mit der Range 10.0.0.0/16 angelegt. Insofern kann dann z.B. WAN 10.0.0.0/24 sein, LAN 10.0.1.0/24 etc.
192.168.0.0/24 hättest Du dem VNet zusätzlich hinzufügen müssen, wenn es das als Subnet geben soll.
In der Praxis würde man an der Firewall lediglich kleine Transitnetze, z.B. /28, erstellen, genug um ein Cluster-Paar mit Loadbalancer und ggf. ein paar sekundären IPs aufzunehmen. Andere Netze für die Workloads bleiben davon getrennt, z.B.
- WAN: 10.0.0.0/28
- (ggf. dediziertes Management-Interface: 10.0.0.16/28)
- (ggf. Cluster-Sync: 10.0.0.32/28)
- LAN: 10.0.0.48/28
- Server 1: 10.0.1.0/24
- Server 2: 10.0.2.0/24
Die Firewall braucht keine Gateway-IP in den Server-Netzen, weil auf ihre IP ohnehin per Azure-Routing verwiesen werden muss.
Routen für 0.0.0.0/0 und die VNet-Range zwingen dann allen Verkehr eines Servers-Netzes über die Firewall. Das gilt auch für Verkehr innerhalb eines Subnets, sofern man nicht wiederum den Subnet-Bereich mit dem Gateway "Virtual Network" hiervon wieder ausnimmt.
Wenn man sich das andererseits zunutze macht, ist es natürlich nicht erforderlich, Server, die man trennen will, auf unterschiedliche Subnetze zu verteilen. Das ist eher Geschmackssache, nach welcher Logik man das alles verwalten will, wieviel Last die Firewall abbekommen soll, ob man nur Regeln der virtuellen Firewall oder auch NSGs pflegen möchte...
Leider kann ich nur die pfsense pingen und erreiche nichts im Netzwerk ....
Leider bist du der Anleitung dann nicht richtig gefolgt und hast vermutlich vergessen eine entsprechende "any any" Regel auf dem IPsec Tunnel Interface zu setzen. Eine fehlende Regel dort führt zu dem Problem.Kann auch sein das wenn du Winblows Clients pingst nicht bedacht hast das in der lokalen Winblows Firewall generell das ICMP Protokoll (Ping) geblockt ist.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Ohne ein Customizing der Winblows Firewall kannst du zumindestens Windows Endgeräte nicht pingen!
Desweiteren lässt die Windows Firewall generell keinen Traffic aus fremden IP Netzen zu. Auch das musst du entsprechend customizen.
Das solltest du also auf dem Radar haben.
Vorab, Wireguard ist raus und IKEv2 läuft auch für mobile Clients.
Die VNet-Ranges sind grundlegende Eigenschaften des VNets, ganz oben in den Einstellungen. Du kannst in einem VNet nur Subnetze aus den VNet-Ranges erstellen. Wenn Du im Assistenten immer nur weiter klickst, wird das ein VNet mit der Range 10.0.0.0/16 angelegt. Insofern kann dann z.B. WAN 10.0.0.0/24 sein, LAN 10.0.1.0/24 etc.
192.168.0.0/24 hättest Du dem VNet zusätzlich hinzufügen müssen, wenn es das als Subnet geben soll.
In der Praxis würde man an der Firewall lediglich kleine Transitnetze, z.B. /28, erstellen, genug um ein Cluster-Paar mit Loadbalancer und ggf. ein paar sekundären IPs aufzunehmen. Andere Netze für die Workloads bleiben davon getrennt, z.B.
Ich habe es etwas anders und daher konnte das beim einrichten nicht passen.
WAN 192.168.0.0/24
LAN 10.3.0.0/24
Den virtuellen Adresspool der mobilen Clients unter IPSec habe ich nicht in der Routing Tabelle - sollte diese ja auch nicht betreffen.
Meine Site2Site Verbindungen habe ich in der Routinjg Tabelle.
Die Firewall braucht keine Gateway-IP in den Server-Netzen, weil auf ihre IP ohnehin per Azure-Routing verwiesen werden muss.
Routen für 0.0.0.0/0 und die VNet-Range zwingen dann allen Verkehr eines Servers-Netzes über die Firewall. Das gilt auch für Verkehr innerhalb eines Subnets, sofern man nicht wiederum den Subnet-Bereich mit dem Gateway "Virtual Network" hiervon wieder ausnimmt.
Wenn man sich das andererseits zunutze macht, ist es natürlich nicht erforderlich, Server, die man trennen will, auf unterschiedliche Subnetze zu verteilen. Das ist eher Geschmackssache, nach welcher Logik man das alles verwalten will, wieviel Last die Firewall abbekommen soll, ob man nur Regeln der virtuellen Firewall oder auch NSGs pflegen möchte...
meine Rückrouten jedoch gar nicht.
Die NSG in Azure beinhaltet nur die Standard Einstellungen.
Pf Sense Firewall sollte ebenfalls passen.
und die Routing Tabelle der pfsense:
ich setze mich später da noch dran und gehe den Beitrag von aqui hier auch noch durch.
Zitat von @c.r.s.:
Das wird nicht richtig sein, sonst würde VNet-Range dir was sagen. Du darfst generell in der pfSense keine Adressen konfigurieren, die auf Azure nicht ebenfalls konfiguriert sind.
Ok.... gefunden. Ich habe explizit nach VNet-Range gesucht, auf der Deutschen Azur Oberfläche steht natürlich Netzwerkbereich.Zitat von @tmevent:
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
Meine Pfsense hängt in 2 Netzen:
192.168.0.0/24 als WAN mit einer öffentlichen IP
10.3.0.0/24 als LAN
Das wird nicht richtig sein, sonst würde VNet-Range dir was sagen. Du darfst generell in der pfSense keine Adressen konfigurieren, die auf Azure nicht ebenfalls konfiguriert sind.
Nach den Beispielen würde die Vnet-Range die 10.3.0.0 sein und die Subnetze wären entsprechend die Subnetze .... bin ich da auf dem Holzweg ?
Die VNet-Ranges sind grundlegende Eigenschaften des VNets, ganz oben in den Einstellungen. Du kannst in einem VNet nur Subnetze aus den VNet-Ranges erstellen. Wenn Du im Assistenten immer nur weiter klickst, wird das ein VNet mit der Range 10.0.0.0/16 angelegt. Insofern kann dann z.B. WAN 10.0.0.0/24 sein, LAN 10.0.1.0/24 etc.
192.168.0.0/24 hättest Du dem VNet zusätzlich hinzufügen müssen, wenn es das als Subnet geben soll.
In der Praxis würde man an der Firewall lediglich kleine Transitnetze, z.B. /28, erstellen, genug um ein Cluster-Paar mit Loadbalancer und ggf. ein paar sekundären IPs aufzunehmen. Andere Netze für die Workloads bleiben davon getrennt, z.B.
- WAN: 10.0.0.0/28
- (ggf. dediziertes Management-Interface: 10.0.0.16/28)
- (ggf. Cluster-Sync: 10.0.0.32/28)
- LAN: 10.0.0.48/28
- Server 1: 10.0.1.0/24
- Server 2: 10.0.2.0/24
WAN 192.168.0.0/24
LAN 10.3.0.0/24
Den virtuellen Adresspool der mobilen Clients unter IPSec habe ich nicht in der Routing Tabelle - sollte diese ja auch nicht betreffen.
Meine Site2Site Verbindungen habe ich in der Routinjg Tabelle.
Die Firewall braucht keine Gateway-IP in den Server-Netzen, weil auf ihre IP ohnehin per Azure-Routing verwiesen werden muss.
Routen für 0.0.0.0/0 und die VNet-Range zwingen dann allen Verkehr eines Servers-Netzes über die Firewall. Das gilt auch für Verkehr innerhalb eines Subnets, sofern man nicht wiederum den Subnet-Bereich mit dem Gateway "Virtual Network" hiervon wieder ausnimmt.
Wenn man sich das andererseits zunutze macht, ist es natürlich nicht erforderlich, Server, die man trennen will, auf unterschiedliche Subnetze zu verteilen. Das ist eher Geschmackssache, nach welcher Logik man das alles verwalten will, wieviel Last die Firewall abbekommen soll, ob man nur Regeln der virtuellen Firewall oder auch NSGs pflegen möchte...
meine Rückrouten jedoch gar nicht.
Die NSG in Azure beinhaltet nur die Standard Einstellungen.
Pf Sense Firewall sollte ebenfalls passen.
und die Routing Tabelle der pfsense:
ich setze mich später da noch dran und gehe den Beitrag von aqui hier auch noch durch.
1Zitat von @aqui:
Es lag an der Routing Tabelle zu dem Zeitpunkt.Leider kann ich nur die pfsense pingen und erreiche nichts im Netzwerk ....
Leider bist du der Anleitung dann nicht richtig gefolgt und hast vermutlich vergessen eine entsprechende "any any" Regel auf dem IPsec Tunnel Interface zu setzen. Eine fehlende Regel dort führt zu dem Problem.Kann auch sein das wenn du Winblows Clients pingst nicht bedacht hast das in der lokalen Winblows Firewall generell das ICMP Protokoll (Ping) geblockt ist.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Ohne ein Customizing der Winblows Firewall kannst du zumindestens Windows Endgeräte nicht pingen!
Desweiteren lässt die Windows Firewall generell keinen Traffic aus fremden IP Netzen zu. Auch das musst du entsprechend customizen.
Das solltest du also auf dem Radar haben.
jepp - daran lags nichthttps://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Ohne ein Customizing der Winblows Firewall kannst du zumindestens Windows Endgeräte nicht pingen!
Desweiteren lässt die Windows Firewall generell keinen Traffic aus fremden IP Netzen zu. Auch das musst du entsprechend customizen.
Das solltest du also auf dem Radar haben.
Nach wie vor erreiche ich aus dem LAN hinter der pfsense weder IPs hinter den Tunneln, noch IPs im Internet.
Was mir gerade aufgefallen ist: der Server im 10.3.0.0/24 Netz hat als Gateway die 10.3.0.1, also vermutlich noch was im Azure Setup ... Ich habe da nur grade keine ahnung wo ich meinen pfSense Gateway eintrage. Obwohl ich die Routen ja angelegt habe (siehe oben)
Was mir gerade aufgefallen ist: der Server im 10.3.0.0/24 Netz hat als Gateway die 10.3.0.1, also vermutlich noch was im Azure Setup ... Ich habe da nur grade keine ahnung wo ich meinen pfSense Gateway eintrage. Obwohl ich die Routen ja angelegt habe (siehe oben)
Nach wie vor erreiche ich aus dem LAN hinter der pfsense weder IPs hinter den Tunneln
Dann hast du, wie immer, einen Fehler in den AllowedIPs und/oder auch in der Gateway Zuweisung.Wenn du die zu erreichenden IP netze nicht auch in den AllowedIPs einträgst werden die auch erst gar nicht in den Tunnel geroutet, egal ob ein gateway und eine Route existiert.
Ist das simple Prinzig des Cryptokey Routings bei WG.
Sieh dir nochmal in aller Ruhe das pfSense Tutorial an. Dort ist das alles haarklein aufgeführt.
Ich habe Wirequard deaktiviert und bin - bis auf das Routing Problem - aktuell mit IKEv2 schnell zum Erfolg gekommen.
1
von der pfsense erreiche ich alles (als Quelladresse LAN)
Aus den entfernten Tunneln erreiche ich mein pfsense mit dem dahinterliegenden Server
Von dem hinter der pfsense liegenden Server aus erreiche ich nichts.
Ich habe mir da irgendwas zerschossen.
Aus den entfernten Tunneln erreiche ich mein pfsense mit dem dahinterliegenden Server
Von dem hinter der pfsense liegenden Server aus erreiche ich nichts.
Ich habe mir da irgendwas zerschossen.
Zitat von @tmevent:
Ich habe es etwas anders und daher konnte das beim einrichten nicht passen.
WAN 192.168.0.0/24
LAN 10.3.0.0/24
Den virtuellen Adresspool der mobilen Clients unter IPSec habe ich nicht in der Routing Tabelle - sollte diese ja auch nicht betreffen.
Ich habe es etwas anders und daher konnte das beim einrichten nicht passen.
WAN 192.168.0.0/24
LAN 10.3.0.0/24
Den virtuellen Adresspool der mobilen Clients unter IPSec habe ich nicht in der Routing Tabelle - sollte diese ja auch nicht betreffen.
Doch, betrifft sie. Die sind aber im Azure-Routing mit 0.0.0.0/0 abgehandelt, da 0.0.0.0/0 bedeutet: "alles, außer VNet".
Die NSG in Azure beinhaltet nur die Standard Einstellungen.
Das wird das Problem sein. Das Azure-Netzwerk bildet immer die Verbindung zweier VMs, sowohl hinsichtlich des Routings als auch des Firewallings per NSG. Entsprechend muss der Pfad von der pfSense zur anderen VM in jeder Hinsicht durchlässig sein. Wenn die Route-Table korrekt ist, d.h. das "eigentliche" Routing durch die pfSense erzwingt, ist es in der Regel vertretbar, Any-Any-NSG-Regeln zu verwenden. Eine Außnahme würde man typischerweise für das oben angedeutete Management-Interface machen (Zugriff wahlweise durch VPN oder - notfalls per NSG freigeschaltet - öffentlich) , für dich momentan nicht relevant.
Ggf. kannst Du die NSG auch weglassen. Grundsätzlich sollte man aber NSGs zumindest mit Any-Any-Regeln verwenden, da die Infrastruktur so flexibler ist hinsichtlich der Nachrüstung (grober) NSG-Regeln und von Clustering (ein Public-Load-Balancer erfordert eine NSG auf dem Backend-Netz).
1bis auf das Routing Problem - aktuell mit IKEv2 schnell zum Erfolg gekommen.
👍👏Das mag ggf. am Client Setup liegen ob du da Split Tunneling oder Gateway redirect gewählt hast...zumindestens bei Winblows. Apple macht generell Gateway Redirect.
Client Routing Setup
Doch, betrifft sie. Die sind aber im Azure-Routing mit 0.0.0.0/0 abgehandelt, da 0.0.0.0/0 bedeutet: "alles, außer VNet".
Ich hatte das auf den virtuellen Adresspool bezogen für mobile Clients bei IKEv2 Verbindungen - spielt bei meinem Problem aber aktuell keine Rolle, daher kümme ich mich da später drum.Die NSG in Azure beinhaltet nur die Standard Einstellungen.
Das wird das Problem sein. Das Azure-Netzwerk bildet immer die Verbindung zweier VMs, sowohl hinsichtlich des Routings als auch des Firewallings per NSG. Entsprechend muss der Pfad von der pfSense zur anderen VM in jeder Hinsicht durchlässig sein. Wenn die Route-Table korrekt ist, d.h. das "eigentliche" Routing durch die pfSense erzwingt, ist es in der Regel vertretbar, Any-Any-NSG-Regeln zu verwenden. Eine Außnahme würde man typischerweise für das oben angedeutete Management-Interface machen (Zugriff wahlweise durch VPN oder - notfalls per NSG freigeschaltet - öffentlich) , für dich momentan nicht relevant.
Ggf. kannst Du die NSG auch weglassen. Grundsätzlich sollte man aber NSGs zumindest mit Any-Any-Regeln verwenden, da die Infrastruktur so flexibler ist hinsichtlich der Nachrüstung (grober) NSG-Regeln und von Clustering (ein Public-Load-Balancer erfordert eine NSG auf dem Backend-Netz).
Ich hatte das auch schon versucht und habe nun noch mal alles offen.
die NSGs sind an den NICs der VMs in Azure angegeben
Zitat von @aqui:
Das mag ggf. am Client Setup liegen ob du da Split Tunneling oder Gateway redirect gewählt hast...zumindestens bei Winblows. Apple macht generell Gateway Redirect.
Client Routing Setup
bis auf das Routing Problem - aktuell mit IKEv2 schnell zum Erfolg gekommen.
👍👏Das mag ggf. am Client Setup liegen ob du da Split Tunneling oder Gateway redirect gewählt hast...zumindestens bei Winblows. Apple macht generell Gateway Redirect.
Client Routing Setup
es geht aktuell nur um die site2sit Verbindungen bzw. noch grundlegender darum das ich vom Server in Azure aus nichts ausgehend erreiche.
Die Option Split Tunneling in den Clients kenne ich und nutze ich auch.
Laut Diagnose Paketmitschnitt kommt der ICMP Request an der pfsense an, unklar ist mir, warum es dein keine Antwort gibt und der einfach im nichts landet ...
die Azure Routen sollten also ok sein und ein Fehler in den pfsense routen ...
die Azure Routen sollten also ok sein und ein Fehler in den pfsense routen ...
warum es dein keine Antwort gibt und der einfach im nichts landet ...
Firewall Regel falsch oder fehlerhaft, fehlende Route oder Route ins Nirwana...da gibt es bekanntlich zig Möglichkeiten.
nsgs und route in Azure sollte ja passen - ich sehe die pakete ja
firewall regel in pfsense ... sollte auch passen denn ich sehe die pakete und sie werden nicht von der fw geblockt.
ich habe ja nur ein GW und da landen meine routen - vermutlich ist da irgendwo der Fehler ?
firewall regel in pfsense ... sollte auch passen denn ich sehe die pakete und sie werden nicht von der fw geblockt.
ich habe ja nur ein GW und da landen meine routen - vermutlich ist da irgendwo der Fehler ?
Outbound-NAT-Regeln an der WAN-Schnittstelle müssen auf der pfSense wahrscheinlich manuell erstellt werden, da sie sich zwischen zwei privaten Netzen sieht. Du musst alle Netze, aus denen Du ins Internet willst, auf die WAN-IP übersetzen.
1Zitat von @c.r.s.:
Outbound-NAT-Regeln an der WAN-Schnittstelle müssen auf der pfSense wahrscheinlich manuell erstellt werden, da sie sich zwischen zwei privaten Netzen sieht. Du musst alle Netze, aus denen Du ins Internet willst, auf die WAN-IP übersetzen.
Outbound-NAT-Regeln an der WAN-Schnittstelle müssen auf der pfSense wahrscheinlich manuell erstellt werden, da sie sich zwischen zwei privaten Netzen sieht. Du musst alle Netze, aus denen Du ins Internet willst, auf die WAN-IP übersetzen.
kannst Du mir da sagen wie die NAT Einstellungen aussehen müssen ?
Bei der Portweiterleitung hört da mein Wissen zu NAT auf.
https://www.joerg-leuschner.de/pfsense/pfsense-routing-zwischen-lan-opt- ...
Nach dieser Vorlage habe ich die NAT Regeln bearbeitet aber auch das blieb erfolglos.
Einen kleinen Schritt weiter bin ich, ein Port Forwarding in Azure war nicht gesetzt.
1Du musst alle Netze, aus denen Du ins Internet willst, auf die WAN-IP übersetzen.
Siehe dazu auch hier wenn man in einem gerouteten Umfeld ist und diese IP Netze nicht direkt an der FW angeschlossen sind:Routing Problem OPNsense
"Manuelle Erzeugung der Regeln für ausgehendes NAT" und eine Regel auf der WAN-Schnittstelle mit der NAT-Adresse "WAN Address", sonst alles "*", reicht im einfachsten Fall.
Das ist aber inzwischen etwas diffus. Port-Forwarding braucht man in dem Fall auf Azure eigentlich nicht, es ist ja kein Load-Balancer o.ä. im Spiel.
Das ist aber inzwischen etwas diffus. Port-Forwarding braucht man in dem Fall auf Azure eigentlich nicht, es ist ja kein Load-Balancer o.ä. im Spiel.
1
mit Änderungen der NAT Einstellungen komme ich leider nicht weiter
Ich habe nun ein bischen versucht die Pakete zu verfolgen(Diagnose>Paketverfolgung).
Wenn ich von meiner Azure-VM auf 8.8.8.8 pinge, sehe ich diesen Ping am LAN Port
20:41:46.674926 IP 10.3.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 1054, length 40
und am WAN Port
20:45:53.162014 IP 8.8.8.8 > 10.3.0.4: ICMP echo reply, id 1, seq 1058, length 40
Was mir unklar ist warum sehe ich den Ping nur eingehend und nicht ausgehend (oder gibt es da noch eine Option auch ausgehende Pakete zu sehen?
Da ich über Diagnose>Ping meine VM 10.3.0.4 sowohl vom LAN als auch vom WAN port aus erreiche, frage ich mich wo mein Ping verschwindet.
WAN
20:48:47.679123 IP 192.168.0.4 > 10.3.0.4: ICMP echo request, id 39016, seq 0, length 64
20:48:47.680056 IP 10.3.0.4 > 192.168.0.4: ICMP echo reply, id 39016, seq 0, length 64
LAN
nichts
Irgendwie fehlen mir da einige Daten, der ausgehende Ping an 8.8.8.8, der Ping der pfsense auf dem LAN ..... Ich bekomme da nicht do ganz ein Bild zusammen.
Ich habe nun ein bischen versucht die Pakete zu verfolgen(Diagnose>Paketverfolgung).
Wenn ich von meiner Azure-VM auf 8.8.8.8 pinge, sehe ich diesen Ping am LAN Port
20:41:46.674926 IP 10.3.0.4 > 8.8.8.8: ICMP echo request, id 1, seq 1054, length 40
und am WAN Port
20:45:53.162014 IP 8.8.8.8 > 10.3.0.4: ICMP echo reply, id 1, seq 1058, length 40
Was mir unklar ist warum sehe ich den Ping nur eingehend und nicht ausgehend (oder gibt es da noch eine Option auch ausgehende Pakete zu sehen?
Da ich über Diagnose>Ping meine VM 10.3.0.4 sowohl vom LAN als auch vom WAN port aus erreiche, frage ich mich wo mein Ping verschwindet.
WAN
20:48:47.679123 IP 192.168.0.4 > 10.3.0.4: ICMP echo request, id 39016, seq 0, length 64
20:48:47.680056 IP 10.3.0.4 > 192.168.0.4: ICMP echo reply, id 39016, seq 0, length 64
LAN
nichts
Irgendwie fehlen mir da einige Daten, der ausgehende Ping an 8.8.8.8, der Ping der pfsense auf dem LAN ..... Ich bekomme da nicht do ganz ein Bild zusammen.
Wenn es das denn nun war:
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
leider war's das nicht
