16.04.2024, aktualisiert um 22:59:48 Uhr

1605

Probleme mit RDP über VPN-Zugang zur pfSense

hallo

ich hab eine virtuelle Testumgebung mit Virtualbox etabliert. pfSense als VM - die WAN-Seite ist der Host (ein Mac auf dem Virtualbox installiert ist) mit 192.168.178.X - auf der LAN-Seite zwei Windows-VMs im Subnetz 192.168.0.X

Das ganze dient zum testen und kennenlernen der pfSense bevor sie evtl. in einer Produktivumgebung als Firewall zum Einsatz kommt.

Mit dem wirklich hervorragenden Tutorial von aqui (PfSense VPN mit L2TP (IPsec) Protokoll für mobile Nutzer) habe ich den VPN-Zugang zur pfSense eingerichtet. Verbindung vom Mac zur pfSense per VPN klappt einwandfrei. Auch auf der pfSense kann man ja in Status --> IPsec sehen dass eine VPN-Verbindung zustande kommt.

Auch habe ich wie im Tutorial die 3 Regeln erstellt damit per VPN traffic durch die FW geht.

Nun wollte ich bei etablierter VPN-Verbindung zur pfSense mit der macOS MS Remote Desktop einen Zugang per RDP auf eine der VMs (Win-11-PC) im LAN herstellen (z.b. 192.168.0.86). Geht nicht !

Firewall auf der VM ist deaktiviert - Remote Desktop-Feature natürlich aktiviert.

Zunächst dachte ich es muss noch der Traffic über Port 3389 auf der pfSense am Tunnel-Interface mit einer Regel erlaubt werden - aber mit den beiden Regeln an den Tunnel-Ports (allow any) müsste das ja gar nicht notwendig sein ....

Hat jemand eine Idee wie ich den Fehler noch eingrenzen kann ?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 91241753344

Url: https://administrator.de/contentid/91241753344

Ausgedruckt am: 22.11.2024 um 07:11 Uhr

20 Kommentare

Neuester Kommentar

Moin,

Wie sieht es denn mit Ping & co aus? Funktionieren die?

Gruß,
Avoton

ping von der pfsense-LAN-Schnittstelle zu den VMs funktioniert in beide Richtungen

Das ist klar, ich meine von deinem VPN Client, wenn das VPN verbunden ist ;)

RFC1918-Haken gesetzt?
https://docs.netgate.com/pfsense/en/latest/recipes/rfc1918-egress.html

if the WAN IP address is from the RFC 1918 range, do NOT block this traffic from exiting the WAN

Viele Grüße, commodity

Das ist klar, ich meine von deinem VPN Client, wenn das VPN verbunden ist ;)

Ping vom Mac (VPN Client) zur VM geht nicht !

RFC1918-Haken gesetzt?

ähem....damit hab ich mich noch nicht auseinander gesetzt...wo werden diese einstellungen gemacht?

Zitat von @fishrain:

RFC1918-Haken gesetzt?

ähem....damit hab ich mich noch nicht auseinander gesetzt...wo werden diese einstellungen gemacht?

Moin.

Am WAN Interface auf der PFSense.

Standardmäßig wird alles geblockt, was aus den privaten Netzbereichen (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16) kommt.

Gruß
Marc

Sorry, oben das war der Link zur FW-Regel.
Hier der zur korrekten Handbuch-Seite (mit dem Bild, das Kollege @radiogugu schon eingestellt hat)

Viele Grüße, commodity

Ping vom Mac (VPN Client) zur VM geht nicht !

Wie sieht es denn mit einem Ping vom Mac Client zur IP des pfSense LAN Interfaces aus?? Klappt das denn?? Das würde ja zumindestens verifizieren das dein VPN sauber rennt.
Sorry, aber solche banalen Ping und Traceroute Tests macht doch auch ein Laie immer zuerst um die IP Connectivity wasserdicht zu checken.

Sollte der Ping auf das Firewall LAN Interface klappen aber nicht zu PM hast du vermutlich nicht bedacht das das ICMP Protokoll (Ping) unter Windows generell deaktiviert ist und erst aktiviert werden muss.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...
Wichtig ist das das LAN Interface vom VPN Client pingbar ist. Bevor das nicht klappt musst du nicht weitermachen.

Wichtig ist das das LAN Interface vom VPN Client pingbar ist.

Ergänzung:
Was zB nicht funktioniert, wenn RFC1918 geblockt wird.

Viele Grüße, commodity

Das ist richtig!
Das IKEv2 VPN Tutorial geht ja explizit auf so eine Kaskaden Installation ein und beschreibt diese ToDos im Detail.
Vermutlich hat der TO das mal wieder übersehen... 🧐

tl;dr

Viele Grüße, commodity

Wie sieht es denn mit einem Ping vom Mac Client zur IP des pfSense LAN Interfaces aus?? Klappt das denn?? Das würde ja zumindestens verifizieren das dein VPN sauber rennt.

Funktioniert nicht !

RFC1918 wird nicht geblockt (kein Haken gesetzt)

scheint doch mit dem VPN zu tun haben ....

scheint doch mit dem VPN zu tun haben ....

So ist es und leider machst du keinerlei hilfreiche Angaben zu deinen Troubleshooting Schritten!

Entweder kommt also dein Tunnel gar nicht erst zustande (falsche Adressierung etc.) oder eine Firewall Regel fehlt, ist fehlerhaft oder falsch. Da wir diese Daten alle nicht kennen können wir hier auch nur kristallkugeln!

Was Ersteres anbetrifft wäre wichtig zu wissen ob der Mac einen aktiven Tunnel in der Taskleiste anzeigt?
(Dazu in den Systemeinstellungen - Kontrollzentrum bei VPN auf "In der Taskleiste anzeigen" setzen!)

In den Systemeinstellungen kannst du dann unter "i" bei deiner VPN Verbindung sehen ob der Tunnel aktiv ist und welche Client IP Adresse der Mac im VPN von der pfSense bekommen hat.

Wichtig wäre auch noch zu wissen ob du Split Tunneling im VPN machst oder ein Gateway Redirect.

Wenn das alles korrekt ist und dein Mac eine korrekte VPN Client IP von der pfSense nach deiner konfigurierten Vorgabe ("Remote Adress Range") bekommen hat, ist das VPN per se OK.
Hier solltest du nochmal genau deine VPN Adressierung von Server IP und Client Adress Range überprüfen ab diese Einstellungen die geforderten Kriterien erfüllt:

Der IP Adressbereich des L2TP VPNs (Server IP und Range) dürfen sich keinesfalls mit anderen IP Netzen der pfSense und des gesamten Netzes überschneiden!
Server IP und Client Adress Range müssen in unterschiedlichen IP Netzen liegen!

Ein Punkt der häufig falsch gemacht wird und zu dem du leider keinerlei Angaben machst.

Ist das alles ebenfalls korrekt dann kann es nur noch an einem falschen Regelwerk liegen.

Hier wäre es dann für ein zieführendes Troubleshooting wichtig deine Einstellungen zu kennen (Screenshot) wie sie auch HIER im Tutorial abgebildet sind!!

Also der Tunnel kommt schon zustande und ist aktiv - wird auch so in der oberen Taskleiste angezeigt

Server IP und Client Adress Range müssen in unterschiedlichen IP Netzen liegen!

mit Server IP meinst du die IP-Adresse des WAN-Interface? nicht die L2TP-Server IP-Adresse in folgenden Screenshot (hier 100.93.10.1). Das WAN Interface hat die 192.168.178.171...liegt also nicht im gleichen Netz

Somit kann es nur noch an den Rules liegen ...obwohl ich alles so gemacht hab wie im Tutorial

mit Server IP meinst du die IP-Adresse des WAN-Interface?

Nein, damit war schon die IP des L2TP Servers gemeint im L2TP Setup.
Das hast du aber richtig gemacht, das dein Server ja die 100.93.10.1 hat was ja getrennt von der Client Range ist.
Die Nutzung von IP Adressen aus dem RFC 6598 Shared Address Bereich sollte kein Problem darstellen sofern du keinen DS-Lite Anschluss irgendwo nutzt. Das ist also alles OK. Ruleset ist auch OK.
Das VPN ist also soweit OK

Was sagt ein netstat -f inet -nr auf dem Mac wenn der L2TP Tunnel aktiv ist??
Dein lokales LAN Interface deiner pfSense liegt ja im 192.168.0.0 /24 Netzwerk folglich müsstest du bei einem aktiven L2TP VPN Tunnel in der o.a. Routing Tabelle sehen das dieses Subnet an das ppp0 Interface gesendet wird. Ist das der Fall?
Dafür ist essentiell wichtig das der Haken "Provide network list to clients" unbedingt gesetzt ist im pfSense Setup "Mobile Clients"!

Mache nochmal 2 Tests:

Bei aktivem Tunnel kannst du die L2TP Server IP 100.93.10.1 anpingen?
Wenn du im VPN Setup den Slider "Gesamten Verkehr über VPN senden" setzt und den Tunnel neu aufbaust kannst du dann das pfSense LAN Interface im 192.168.0.0er Netz pingen?

Ich bin mit den Senses ja schon eine Weile nicht mehr am Werkeln, aber braucht es nicht auch eine allow-rule auf dem LAN-Interface, damit der Ping (Echo Reply) überhaupt zurück geht?
Wenn ja: Dann fehlt oben noch ein Screenshot davon.

Viele Grüße, commodity

Wenn du im VPN Setup den Slider "Gesamten Verkehr über VPN senden" setzt und den Tunnel neu aufbaust kannst du dann das pfSense LAN Interface im 192.168.0.0er Netz pingen?

Bingo !!! Das war der richtige Tipp! Nach setzen des Sliders "Gesamten Verkehr über VPN senden" funktioniert ping auf LAN-Interface und natürlich auch die RDP-Verbindung zu den VMs

Thanks a lot !!!!!!!

aber braucht es nicht auch eine allow-rule auf dem LAN-Interface, damit der Ping (Echo Reply) überhaupt zurück geht?

Nein, das lokale LAN Interface hat immer per Default eine "Scheunentorregel" die generell alles erlaubt egal ob IP, ICMP (Ping) oder was auch immer.
Natürlich nur so lange der TO diese Default Regel nicht irgendwie verändert hat...was wir jetzt mal nicht hoffen?!

Bingo !!! Das war der richtige Tipp!

Jein!
Er zeigt eher das du einen Fehler beim VPN Setup gemacht hast.

Normalerweise sollte der L2TP Server eine Netzwerkliste der remoten Netze an den VPN Client (Mac) senden und so diese spezifischen lokalen Netze dann an den Client dynamisch propagiert. (Split Tunnel Mode)
So wird effektiv nur das in den VPN Tunnel geroutet, was zu den remoten IP Netzen geht bzw. dessen Zieladressen hat. Alles andere wird lokal abgefrühstückt.
Die deutlich sinnvollere Alternative wenn man performante VPNs betreiben will, weil so nur das in den Tunnel geht was remote relevant ist.
Der Slider setzt das VPN in den Gateway Redirect Mode, sprich ALLES, auch dein gesamter Internet Traffic usw. geht über den Tunnel und dann am Ziel (pfSense) ins Internet. Dieses deutliche Mehr an Traffic belastet dann auch das VPN erheblich zu Lasten der VPN Gesamtperformance.
Fazit:
Besser nochmal genau suchen WO du den Konfig Fehler im L2TP Setup gemacht hast! Sehr wahrscheinlich fehlt der o.a. Haken bei der "List of accessible networks"?

Hilfreich wäre dazu auch der netstat -f inet -nr Output gewesen und das Resultat des Ping Versuches...aber nundenn. Gutes Troubleshooting sieht anders aus...

Was sagt ein netstat -f inet -nr auf dem Mac wenn der L2TP Tunnel aktiv ist??

Bei aktivem Tunnel kannst du die L2TP Server IP 100.93.10.1 anpingen?

Ja funktioniert

Sehr wahrscheinlich fehlt der o.a. Haken bei der "List of accessible networks"?

Nein der Haken ist gesetzt gewesen

Mmmhhh... Da wird ja nur die 192.168.0.1 propagiert. Zumindestens DIE sollte dann aber auch im Split Tunneling Mode pingbar sein?!
Zum Vergleich mal eine Beispiel was das ganze 10er Netz in den L2TP Tunnel routet:

user@MacBook ~ % netstat -f inet -nr
Routing tables

Internet:
Destination        Gateway            Flags               Netif Expire
default            192.168.1.254      UGScg                 en0       
default            link#18            UCSIg                ppp0       
10                 ppp0               USc                  ppp0       
127                127.0.0.1          UCS                   lo0       
127.0.0.1          127.0.0.1          UH                    lo0      

Du könntest testweise einmal den Haken bei "List of accessible networks" entfernen!
Möglich das die pfSense dann von sich aus ein Gateway Redirect an den Client schickt. Wäre nochmal einen Test wert.

Aber letztlich ja auch egal... Who cares wenn es auch so funktioniert?!