PfSense und openVPN Bridge mit einer Netzwerkkarte
Hallo,
ich möchte gerne ine Bridged VPN netzwerk aufbauen auf einem pfsense, was wiederum auf einem Virtuellen XenServer im Netz (192.168.1.0/24) läuft.
Ich habe nur eine Netzwerkarte an dieser VM, die IP ist: 192.168.1.10 (WAN)
Verbindung zu dem Server klappt einwandfrei, nur leider kann ich die Clients in dem netz nicht anpingen. Dachte mir, dass ich iwie den WAN Interface mit dem TAP Device bridgen kann, aber leider hab ich da nen Denkfehler iwie un das gesamte system ist dann nicht mehr zu erreichen. Ich lese immer dass man noch ein LAN interface erstellen sollte, aber ich bestze nur eine Netzwerkkarte, die an das Heimnetz angeschlossen ist.
Geht mein Vorhaben überhaupt, mit nur einer echten Netzwerkkarte?
Danke für eure Hilfe
ich möchte gerne ine Bridged VPN netzwerk aufbauen auf einem pfsense, was wiederum auf einem Virtuellen XenServer im Netz (192.168.1.0/24) läuft.
Ich habe nur eine Netzwerkarte an dieser VM, die IP ist: 192.168.1.10 (WAN)
Verbindung zu dem Server klappt einwandfrei, nur leider kann ich die Clients in dem netz nicht anpingen. Dachte mir, dass ich iwie den WAN Interface mit dem TAP Device bridgen kann, aber leider hab ich da nen Denkfehler iwie un das gesamte system ist dann nicht mehr zu erreichen. Ich lese immer dass man noch ein LAN interface erstellen sollte, aber ich bestze nur eine Netzwerkkarte, die an das Heimnetz angeschlossen ist.
Geht mein Vorhaben überhaupt, mit nur einer echten Netzwerkkarte?
Danke für eure Hilfe
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 324081
Url: https://administrator.de/forum/pfsense-und-openvpn-bridge-mit-einer-netzwerkkarte-324081.html
Ausgedruckt am: 04.04.2025 um 12:04 Uhr
28 Kommentare
Neuester Kommentar
Bridging im VPN ist generell keine gute Idee und man kann dir nur dringenst abraten ! Auch die OpenVPN Doku selber rät aus gutem Grund davon ab !
Gibt es einen triftigen Grund warum du Bridging machen musst ??
Wenn nein solltest du immer klassisches Routing vorziehen.
Normal hängt man das interne Netz des Hypervisors wo alle VMs draufliegen mit einem vSwitch an den lokalen LAN Port der pfSense (sofern diese auch als VM rennt) und der WAN Port der pfSense wird im Hypervisor auf dessen physischen Ethernet Port (NIC) gebridged.
So sähe ein klassisches Standardszenario aus !
Zu dem Thema Firewall in einer VM muss man wohl nichts mehr sagen hier, aber du weisst sicher was du da tust.
Eine Netzwerkkarte ist generell kein Problem oder meinst du damit das du die pfSense nur einbeinig angeschlossen hast ??
Eine kleine Skizze wäre hilfreich.
Ansonsten sind alle deine ToDos hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
bzw. das Bridging:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
Gibt es einen triftigen Grund warum du Bridging machen musst ??
Wenn nein solltest du immer klassisches Routing vorziehen.
nur leider kann ich die Clients in dem netz nicht anpingen.
Dein Netzwerk Design ist etwas verwirrend und nicht schlüssig beschrieben.Normal hängt man das interne Netz des Hypervisors wo alle VMs draufliegen mit einem vSwitch an den lokalen LAN Port der pfSense (sofern diese auch als VM rennt) und der WAN Port der pfSense wird im Hypervisor auf dessen physischen Ethernet Port (NIC) gebridged.
So sähe ein klassisches Standardszenario aus !
Zu dem Thema Firewall in einer VM muss man wohl nichts mehr sagen hier, aber du weisst sicher was du da tust.
Eine Netzwerkkarte ist generell kein Problem oder meinst du damit das du die pfSense nur einbeinig angeschlossen hast ??
Eine kleine Skizze wäre hilfreich.
Ansonsten sind alle deine ToDos hier beschrieben:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
bzw. das Bridging:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76 ...
Zb für wake on lan oder zb wenn ich andere protokolle nutzen möchte wie samba etc
Das ist Unsinn für Samba braucht man kein Broadcastsing das ist routebar !Genau diese Broadcasts belasten dir den Tunnel und seine Performance. Überlege dir das also gut.
Ansonsten ist die Routed Konfig soweit OK.
Für alle Clients auf die du zugreifen willst die die pfSense NICHT als default Gateway haben musst du zwingend eine statische Route auf das interne OVPN Netzwerk 10.16.16.0 /24 eintragen. Vergiss das nicht.
Dieser Thread beschreibt das:
Server in Subnetz über VPN Router erreichen
Nicht denken sondern nachdenken !! Bzw. mal das Tutorial hier lesen !
Das Push Kommando injiziert beim Tunnelsession Aufbau das lokale LAN Netz am Server in die Client Routing Tabelle, damit der das Netzwerk auch findet und weiss das er das in den Tunnel routen muss und nicht zum Provider !
Ein route print bei Winblows Clients zeigt dir das auch bei aktivem Tunnel !
Du hast auch den Thread nicht richtg gelesen !! Es geht um das interne Netz des VPNs !!!
Das können Endgeräte die aus dem VPN angesprochen werden und ein anderes Gateway haben logischerweise nicht kennen.
Steht ja auch alles in der Erklärung zum zitierten Thread...wenn man den denn mal liest
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html
Die pfSense hat aber auch eine Option um WoL Paket lokal zu senden ! Doku lesen !
https://doc.pfsense.org/index.php/Wake_on_LAN
Das Push Kommando injiziert beim Tunnelsession Aufbau das lokale LAN Netz am Server in die Client Routing Tabelle, damit der das Netzwerk auch findet und weiss das er das in den Tunnel routen muss und nicht zum Provider !
Ein route print bei Winblows Clients zeigt dir das auch bei aktivem Tunnel !
statischen Route auf die ganzen Clients finde ich doch ein wenig umständlich
Macht ja auch kein normaler Mensch bzw. Netzwerker....!Du hast auch den Thread nicht richtg gelesen !! Es geht um das interne Netz des VPNs !!!
Das können Endgeräte die aus dem VPN angesprochen werden und ein anderes Gateway haben logischerweise nicht kennen.
Steht ja auch alles in der Erklärung zum zitierten Thread...wenn man den denn mal liest
Ein WOL Rundruf auf die Clients im Netz ist auch mit Routing möglich?
Bedingt...https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html
Die pfSense hat aber auch eine Option um WoL Paket lokal zu senden ! Doku lesen !
https://doc.pfsense.org/index.php/Wake_on_LAN
Pfsense hat ein Interface mit der IP 192.168.1.10
LAN oder WAN Port der pfSense ??Von einem anderen standort (internes netz 192.168.22.0/24 GW: 192.168.22.1) möchte ich gern darauf dann per vpn zugreifen.
Das ist ja kein Problem wenn OVPN richtig eingerichtet ist. Ein simpler Standard.Probelatisch ist hier eher die (sorry) dümmliche Wahl der 192.168.1.0er netzwerk Adresse für das lokale LAN.
Siehe dazu auch hier:
VPNs einrichten mit PPTP
hat allerdings auf dem dashboard ein icon das normalerweise für die LAN interfaces gebnutzt wird.
Das kann nicht sein und zeigt eher das das eben KEIN WAN Port ist sondern du es falsch konfiguriert hast.Letztlich aber egal, denn ob du per WAN oder LAN zugreifst spielt keine Rolle.
Beim WAN Port sind halt die FW Hürden erheblich größer, da dieser Port natürlich durch entsprechende Regeln logischerweise gesichert ist, ist ja der Internet Port.
In einer Kaskade müsste hier der Haken bei Block RFC 1918 networks entfernt werden und im Regelwerk zuerst als erste Regel der Zugriff von UDP 1194 (OVPN Default Port) auf die Interface IP erlaubt werden.
Nunja, das eintragen der routen hat nichts gebracht, bzw ich habs wohl komplett falsch gemacht
Hast du vermutlich !! Nur so ist das zu erklären, denn das ist ein simples Standard design.Die Routen müssen natürlich auf dem Internet Router eingetragen werden, sprich also dem Gerät was die Endgeräte als default Gateway eingetragen haben !!
Siehe HIER !
Auf der pfSense muss nur ein Default Gateway eingetragen werden.
Das Traceroute Kommando (tracert) oder pathping sind hier deine Helfer zum Troubleshooting. Da wo es kneift ist auch der Fehler.
Sinnvoll zum Checken:
- Wird der VPN Tunnel fehlerfrei aufgebaut ?? Hier mal Log vom VPN Client und von der pfSense posten
- Mit route print auf dem Client bei aktivem Tunnel mal checken ob die Routing Tabelle korrekt ist
- Traceroute und Ping Test zum Endgerät
Sieht gut aus ! Tunnel und Client melden das der VPN Tunnel korrekt aufgebaut ist. Da stimmt alles.
Das ist jetz nur noch Routing oder Firewall oder beides in Kombination.
Das Gerät .1.10 was du anpingst ist das ein Winblows Rechner ??
Bedenke das dort in der lokalen Windows Firewall ab Win7 und höher ICMP (Ping und Traceroute) per Default geblockt wird !!
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Das musst du erst freigeben.
Falls dieser angepingte Rechner ein anderes Default Gateway hat als der OpenVPN Server MUSST du auf dem Gateway eine statische Route auf das interne VPN IP Netz 10.16.16.0 /24 eintragen mit next Hop auf den VPN Server !!
Entsprechend natürlich auch eine Firewall Regel für dieses Netz wenn du nicht eine any to any Regel definiert hast ?!
Das ist jetz nur noch Routing oder Firewall oder beides in Kombination.
Das Gerät .1.10 was du anpingst ist das ein Winblows Rechner ??
Bedenke das dort in der lokalen Windows Firewall ab Win7 und höher ICMP (Ping und Traceroute) per Default geblockt wird !!
https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
Das musst du erst freigeben.
Falls dieser angepingte Rechner ein anderes Default Gateway hat als der OpenVPN Server MUSST du auf dem Gateway eine statische Route auf das interne VPN IP Netz 10.16.16.0 /24 eintragen mit next Hop auf den VPN Server !!
Entsprechend natürlich auch eine Firewall Regel für dieses Netz wenn du nicht eine any to any Regel definiert hast ?!
Das hört sich dann nach einem MTU Problem auf der VPN Vertbindung an !! Hast du die entsprechend angepasst ??
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Also...zwingend die Tunnel MTU anpassen !
http://wohnzimmerhostblogger.de/archives/1563-OpenVPN-und-MTU-1500.html
Also...zwingend die Tunnel MTU anpassen !
Sinnvoll wäre mal einen Durchsatztest zu machen mit NetIO was so durch den Tunnel geht und wie der sich unter Belastung verhält:
http://www.ars.de/ars/ars.nsf/docs/netio
http://www.nwlab.net/art/netio/netio.html
Einmal mit TCP und einmal mit UDP Frames.
http://www.ars.de/ars/ars.nsf/docs/netio
http://www.nwlab.net/art/netio/netio.html
Einmal mit TCP und einmal mit UDP Frames.
Das Thema MTU sagt dir was ?? Scheinbar wohl nicht wie deine Fragestellung leider vermuten lässt.
PPPoE Encapsulierung und UDP VPN Encapsulierung nagen an der 1500 Byte Paketsize. Die Netto Size muss also weitaus kleiner sein das mit dem Overlay nicht die 1500er Größe gesprengt wird und der Router fragmentieren müsste.
Lies dir bitte das Wiki zum Thema MTU und MSS durch ! Oder hier findest du auch eine Erklärung:
http://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
PPPoE Encapsulierung und UDP VPN Encapsulierung nagen an der 1500 Byte Paketsize. Die Netto Size muss also weitaus kleiner sein das mit dem Overlay nicht die 1500er Größe gesprengt wird und der Router fragmentieren müsste.
Lies dir bitte das Wiki zum Thema MTU und MSS durch ! Oder hier findest du auch eine Erklärung:
http://www.cisco.com/c/en/us/support/docs/long-reach-ethernet-lre-digit ...
Möglich das die MTU Path Negotiation bei deiner Linux Distro deaktiviert ist oder sowas. Das müsste man mal mit einem Wireshark Trace ansehen.
Wenn bei gleicher Konstellation mit dem XAMP rennt dann ist auch nicht die MTU das Problem...oder nur zweitrangig.
Wie gesagt, da hilft dann nur ein genauer Trace des Packet Flows um das rauszubekommen.
Klingt aber schon etwas ungewöhnlich.
Kannst du nochmal einen HTTP Server ohne Konfig und Install austesten wie den HFS Webserver:
http://www.rejetto.com/hfs/
Der rennt direkt von einem Stick etc.
Verhält der sich auch so oder rennt das damit ?
Wenn bei gleicher Konstellation mit dem XAMP rennt dann ist auch nicht die MTU das Problem...oder nur zweitrangig.
Wie gesagt, da hilft dann nur ein genauer Trace des Packet Flows um das rauszubekommen.
Klingt aber schon etwas ungewöhnlich.
Kannst du nochmal einen HTTP Server ohne Konfig und Install austesten wie den HFS Webserver:
http://www.rejetto.com/hfs/
Der rennt direkt von einem Stick etc.
Verhält der sich auch so oder rennt das damit ?
Klasse, Glückwunsch !

Bitte dann auch:
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.
Lösung brachte ein deaktivieren der offload einstellungen
Oha...darauf muss man erstmal kommen. Besser also wie üblich die Firewall auf einem eigenen Blech betreiben Bitte dann auch:
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.