4
PfSense IPSec Clients mit virtueller IP auf virtuelle IP des SBS routen
Moinsen allerseits!
Jo, das scheint ja für Fortgeschrittene zu sein...
Folgende Herausforderung:
Habe ein Kundennetz im gleichen Range wie mein Netz. (192.168.1.0/24) das ich per VPN über die PfSense fernwarten muss.
Wenn ich mich nun auf die PfSense connecte (virtuelle IP im VPN 192.168.11.0) funktioniert das mit dem Shrew-Client nur, wenn ich die 192.168.1.0 in den Policys als Range eintrage.
Doof, denn das ist ja auch mein Netz und ich will mitnichten allen Traffic für 192.168.1.0 dorthin routen. Ich will ja nur auf den SBS-2011 Server...
Das schöne ist, dass der Server auch die IP 192.168.111.1 hat, denn er ist als RAS-Server mit diesem Netz konfiguriert.
Ziel: IPSec-Einwahl auf PfSense ohne 192.168.1.0, sondern mit z.B. 192.168.1.11/24 und Routen auf 192.168.111.1 oder Einwahl mit 192.168.111.8/29 als virtuellen IP-Range, damit der Server seine 192.168.111.1 behalten kann.
Habe auf der PfSense auf dem IPSec Interface die Rules angepasst, so dass Traffic von x.x.11.0 zu x.x.111.0 erlaubt ist. Geht nicht. Keine Verbindung, wenn ich nicht x.x.1.0 als Route im Shrew setze.(!)
habe auch eine statische Route auf der PfSense gesetzt: 192.168.111.0/24 nach 192.168.1.100 (was die LAN-IP des Servers ist)
Routet aber nix aus dem VPN-Netz. Ping auf dem LAN Interface der PfSense geht.
Mein Problem ist in erster Linie die Einwahl. Keine Verbindung, wenn nicht das LAN-Netz der PfSense im Shrew in den Policys definiert ist. Da kann ich in der Phase 2 der PfSense setzen, was ich will.
Völlig egal. Aus dem virtuellen VPN-Netz wird nur ins LAN geroutet, bzw. eine Verbindung schon nur hergestellt, wenn das LAN vom Shrew gerouted wird. Unlogisch. Ist aber so.
Wo ist mein Denkfehler? Ich steh hier auf dem Schlauch...
LG
Buc
Jo, das scheint ja für Fortgeschrittene zu sein...
Folgende Herausforderung:
Habe ein Kundennetz im gleichen Range wie mein Netz. (192.168.1.0/24) das ich per VPN über die PfSense fernwarten muss.
Wenn ich mich nun auf die PfSense connecte (virtuelle IP im VPN 192.168.11.0) funktioniert das mit dem Shrew-Client nur, wenn ich die 192.168.1.0 in den Policys als Range eintrage.
Doof, denn das ist ja auch mein Netz und ich will mitnichten allen Traffic für 192.168.1.0 dorthin routen. Ich will ja nur auf den SBS-2011 Server...
Das schöne ist, dass der Server auch die IP 192.168.111.1 hat, denn er ist als RAS-Server mit diesem Netz konfiguriert.
Ziel: IPSec-Einwahl auf PfSense ohne 192.168.1.0, sondern mit z.B. 192.168.1.11/24 und Routen auf 192.168.111.1 oder Einwahl mit 192.168.111.8/29 als virtuellen IP-Range, damit der Server seine 192.168.111.1 behalten kann.
Habe auf der PfSense auf dem IPSec Interface die Rules angepasst, so dass Traffic von x.x.11.0 zu x.x.111.0 erlaubt ist. Geht nicht. Keine Verbindung, wenn ich nicht x.x.1.0 als Route im Shrew setze.(!)
habe auch eine statische Route auf der PfSense gesetzt: 192.168.111.0/24 nach 192.168.1.100 (was die LAN-IP des Servers ist)
Routet aber nix aus dem VPN-Netz. Ping auf dem LAN Interface der PfSense geht.
Mein Problem ist in erster Linie die Einwahl. Keine Verbindung, wenn nicht das LAN-Netz der PfSense im Shrew in den Policys definiert ist. Da kann ich in der Phase 2 der PfSense setzen, was ich will.
Völlig egal. Aus dem virtuellen VPN-Netz wird nur ins LAN geroutet, bzw. eine Verbindung schon nur hergestellt, wenn das LAN vom Shrew gerouted wird. Unlogisch. Ist aber so.
Wo ist mein Denkfehler? Ich steh hier auf dem Schlauch...
LG
Buc
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 359377
Url: https://administrator.de/contentid/359377
Printed on: April 19, 2024 at 07:04 o'clock
4 Comments
Latest comment
Hallo Buc,
routet der SBS denn das virtuelle Netz denn überhaupt nach aussen? Meiner spärlichen Erfahrung mit den RAS Diensten des SBS nach, sollte man darum einen guten Bogen machen. Was spricht gegen ein entsprechendes NATting?
VG
routet der SBS denn das virtuelle Netz denn überhaupt nach aussen? Meiner spärlichen Erfahrung mit den RAS Diensten des SBS nach, sollte man darum einen guten Bogen machen. Was spricht gegen ein entsprechendes NATting?
VG
Ich will ja nur auf den SBS-2011 Server...
Hast du es mal mit einem Host Routing (32 Bit Maske) versucht wenn es einzig nur der Server ist ?Denke aber das der IPsec Verbindungsaufbau wegen der doppelten IP Netze schon scheitern wird.
Ggf. ein 2tes Subnetz auf Kundenseite (pfSense) einrichten, dorthin das VPN eröffnen und dann mit einem 1:1 Host NAT ins lokale LAN auf den Server arbeiten.
Heftige Frickelei, aber könnte klappen...
Hi,
mit der virtuellen IP Adresse des RAS Servers wird es nicht funktionieren wenn du die vorgeschaltete pfSense für dich als VPN Endpunkt verwendest.
In deiner Fragestellung sehe ich ein paar Ungereimtheiten:
1. Mußt du das ganze Kundennetz oder oder nur den Server warten ?
2. Wer ist jetzt VPN Endpunkt ? die pfSense oder nur der SBS (RAS) ?
-
Wenn du nur den SBS warten mußt und die pfSense der VPN Endpunkt ist kann ich dir ein Würgaround zeigen (ist imho aber bäh..):
- Erstelle auf der pfSense auf dem LAN interface eine virtuelle IP aus einem anderen Netz (z.B. 172.16.100.254/24)
- Erstelle auf dem SBS eine zweite IP Adresse aus dem eben erstellten Netz auf dem Netzwerk Interface,(z.B. 172.16.100.1/24) kein GW (!), route 192.168.11.0 über 172.16.100.254.
- erstelle auf der pfSense und in deinem Client für die IPsec Einwahl das Zielnetz 172.176.100.0/24 in Phase 2
- passe die Regeln an.
! Du kannst auf dem SBS und in dem Netzwerk einiges kaputtmachen, z.B. kann (!) der DHCP Server plötzlich 172.16.100.1 als 1. oder 2. DNS Server a die Clients verteilen !
-
Die meiner Meinung nach einzige richtige Lösung ist:
Ändere deine Netzwerk IP-range.
Du als Dienstleister müsstest wissen: verwende nicht die üblichen default Netzwerkbereiche wie 192.168.0.0 , 1.0, 2.0,178.0 oä.
Empfehlenswert ist auch das Netzwerk des Kunden auf einen "vernünftigen" Bereich umzustellen.
bye und nen guten Rutsch
CH
mit der virtuellen IP Adresse des RAS Servers wird es nicht funktionieren wenn du die vorgeschaltete pfSense für dich als VPN Endpunkt verwendest.
In deiner Fragestellung sehe ich ein paar Ungereimtheiten:
1. Mußt du das ganze Kundennetz oder oder nur den Server warten ?
2. Wer ist jetzt VPN Endpunkt ? die pfSense oder nur der SBS (RAS) ?
-
Wenn du nur den SBS warten mußt und die pfSense der VPN Endpunkt ist kann ich dir ein Würgaround zeigen (ist imho aber bäh..):
- Erstelle auf der pfSense auf dem LAN interface eine virtuelle IP aus einem anderen Netz (z.B. 172.16.100.254/24)
- Erstelle auf dem SBS eine zweite IP Adresse aus dem eben erstellten Netz auf dem Netzwerk Interface,(z.B. 172.16.100.1/24) kein GW (!), route 192.168.11.0 über 172.16.100.254.
- erstelle auf der pfSense und in deinem Client für die IPsec Einwahl das Zielnetz 172.176.100.0/24 in Phase 2
- passe die Regeln an.
! Du kannst auf dem SBS und in dem Netzwerk einiges kaputtmachen, z.B. kann (!) der DHCP Server plötzlich 172.16.100.1 als 1. oder 2. DNS Server a die Clients verteilen !
-
Die meiner Meinung nach einzige richtige Lösung ist:
Ändere deine Netzwerk IP-range.
Du als Dienstleister müsstest wissen: verwende nicht die üblichen default Netzwerkbereiche wie 192.168.0.0 , 1.0, 2.0,178.0 oä.
Empfehlenswert ist auch das Netzwerk des Kunden auf einen "vernünftigen" Bereich umzustellen.
bye und nen guten Rutsch
CH
Danke für die Tipps Jungs!
Es will mer abber ned in de Kopp enei, wie kann nor des Rouding so schwierisch sei...
"Ändere deine Netzwerk IP-Range". Das ist die Lösung.
Leider halt auch mit einigem Aufwand verbunden.
Alles andere ist Gefrickel, ich seh's ein.
Ich als Dienstleister müsste aber wissen, dass es immer einen gibt, der es besser weiss. Tststs...
Glaub mir, ChriBo, heute würde ich das nicht mehr machen, aber gewachsene Strukturen...
Trotzdem: Interessanter Ansatz.
certified hat auch recht: Der SBS routet das erstmal nicht. Er ist nur selber auf der virtuellen IP erreichbar. Clients nicht. (Die haben ja auch den "echten" Range. Nun könnte man ja auf dem eigenen Client Routen setzen, aber... s.o.
Trotzdem war ja auch die Frage, warum der IPSec Verbindungsaufbau scheitert, wenn ich nur das virtuelle Netz eintrage. Dem sollte das schnurzpiep sein. Da könnte man noch was testen.
Guhden Rudsch erstmal! (Geändert zu V2018_1)
Buc
Es will mer abber ned in de Kopp enei, wie kann nor des Rouding so schwierisch sei...
"Ändere deine Netzwerk IP-Range". Das ist die Lösung.
Leider halt auch mit einigem Aufwand verbunden.
Alles andere ist Gefrickel, ich seh's ein.
Ich als Dienstleister müsste aber wissen, dass es immer einen gibt, der es besser weiss.
Tststs...Glaub mir, ChriBo, heute würde ich das nicht mehr machen, aber gewachsene Strukturen...
Trotzdem: Interessanter Ansatz.
certified hat auch recht: Der SBS routet das erstmal nicht. Er ist nur selber auf der virtuellen IP erreichbar. Clients nicht. (Die haben ja auch den "echten" Range. Nun könnte man ja auf dem eigenen Client Routen setzen, aber... s.o.
Trotzdem war ja auch die Frage, warum der IPSec Verbindungsaufbau scheitert, wenn ich nur das virtuelle Netz eintrage. Dem sollte das schnurzpiep sein. Da könnte man noch was testen.
Guhden Rudsch erstmal! (Geändert zu V2018_1)
Buc
