fishrain
Goto Top

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 ?

Content-Key: 91241753344

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

Printed on: May 26, 2024 at 04:05 o'clock

Member: Avoton
Avoton Apr 17, 2024 at 04:48:08 (UTC)
Goto Top
Moin,

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

Gruß,
Avoton
Member: fishrain
fishrain Apr 17, 2024 at 05:41:01 (UTC)
Goto Top
ping von der pfsense-LAN-Schnittstelle zu den VMs funktioniert in beide Richtungen
Member: Avoton
Avoton Apr 17, 2024 at 06:02:06 (UTC)
Goto Top
Das ist klar, ich meine von deinem VPN Client, wenn das VPN verbunden ist ;)
Member: commodity
commodity Apr 17, 2024 at 06:18:55 (UTC)
Goto Top
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
Member: fishrain
fishrain Apr 17, 2024 at 06:34:54 (UTC)
Goto Top
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?
Member: radiogugu
radiogugu Apr 17, 2024 updated at 06:39:49 (UTC)
Goto Top
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.

20240417_001

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
Member: commodity
commodity Apr 17, 2024 at 06:58:21 (UTC)
Goto Top
Sorry, oben das war der Link zur FW-Regel.
Hier der zur korrekten Handbuch-Seite (mit dem Bild, das Kollege @radiogugu schon eingestellt hat) face-smile

Viele Grüße, commodity
Member: aqui
aqui Apr 17, 2024 at 07:06:23 (UTC)
Goto Top
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.
Member: commodity
commodity Apr 17, 2024 at 07:12:41 (UTC)
Goto Top
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
Member: aqui
aqui Apr 17, 2024 at 07:16:50 (UTC)
Goto Top
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... 🧐
Member: commodity
commodity Apr 17, 2024 at 07:36:25 (UTC)
Goto Top
tl;dr face-big-smile

Viele Grüße, commodity
Member: fishrain
fishrain Apr 17, 2024 updated at 11:19:02 (UTC)
Goto Top
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 ....
Member: aqui
aqui Apr 17, 2024 updated at 12:37:12 (UTC)
Goto Top
scheint doch mit dem VPN zu tun haben ....
So ist es und leider machst du keinerlei hilfreiche Angaben zu deinen Troubleshooting Schritten! face-sad
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! face-sad

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!)
task
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.
vpninfo
Wichtig wäre auch noch zu wissen ob du Split Tunneling im VPN machst oder ein Gateway Redirect.
opt

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. face-sad

Ist das alles ebenfalls korrekt dann kann es nur noch an einem falschen Regelwerk liegen. face-sad
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!!
Member: fishrain
fishrain Apr 17, 2024 updated at 20:34:58 (UTC)
Goto Top
Also der Tunnel kommt schon zustande und ist aktiv - wird auch so in der oberen Taskleiste angezeigt

bildschirmfoto 2024-04-17 um 21.04.15

bildschirmfoto 2024-04-17 um 21.04.26


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

bildschirmfoto 2024-04-17 um 21.19.48

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

bildschirmfoto 2024-04-17 um 21.06.04

bildschirmfoto 2024-04-17 um 21.06.13

bildschirmfoto 2024-04-17 um 21.06.22
Member: aqui
Solution aqui Apr 18, 2024 updated at 10:40:19 (UTC)
Goto Top
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"!
netlist

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?
Member: commodity
commodity Apr 18, 2024 updated at 11:54:00 (UTC)
Goto Top
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
Member: fishrain
fishrain Apr 18, 2024 at 12:08:44 (UTC)
Goto Top
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 !!!!!!!
Member: aqui
aqui Apr 18, 2024 updated at 13:59:34 (UTC)
Goto Top
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. face-sad
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"? face-sad
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...
Member: fishrain
fishrain Apr 18, 2024 at 20:23:36 (UTC)
Goto Top
Was sagt ein netstat -f inet -nr auf dem Mac wenn der L2TP Tunnel aktiv ist??

bildschirmfoto 2024-04-18 um 22.17.16


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

Ja funktioniert

bildschirmfoto 2024-04-18 um 13.45.00

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

Nein der Haken ist gesetzt gewesen
Member: aqui
aqui Apr 19, 2024 updated at 09:58:53 (UTC)
Goto Top
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?! face-wink
Case closed