Internet Zugriff von LAN aus
-
Hallo zusammen
Ich habe einen pFSense VM mit öffentlicher IP und einem LAN Netz. Die WAN IP wird per DHCP zugeteilt und ich kann auch von der pFSense auf das Internet zugreifen (Prüfen auf Updates, Ping auf IP und Domänen, traceroute usw ...)
Nun habe ich eine weiter VM erstellt mit Debian Linux und konfiguriere die IP Adresse manuell auf 172.16.3.11/24. Die pFSense ist unter 172.16.3.2 per ping erreichbar, auch das WebGui funktioniert problemlos. Wenn ich jetzt einen ping auf 8.8.8.8 vom Debian Client mach, erhalte ich Antwort. Wenn ich im Terminal „host google.com“ eingebe erhalte ich alle Informationen der Google Domain. Soweit so gut!
Wenn ich jetzt den Firefox starte und www. google.com eingebe, lädt er längere Zeit und bricht dann mit einem TimeOut ab.
Was habe ich bereits versucht:
- Neuinstallation bzw Factory Reset
- keine Block Regel in Firewall > Lan
- keine Block Regeln in Firewll > WAN
- Traffic Shaper is keiner aktiviert bzw konfiguriert
- Traceroute von pFSense (LaN) auf IP/Domäne funktioniert
- Diverse Suchen im Internet und diesem Forum blieben erfolglos
Irgendwo habe ich einen Knopf und hoffe jemand hier kann mir helfen!
Thx!
N3tzzw3rg76
-
Hallo,
das sieht nach asymmetrischem Routing aus.
Ist das Default-Gateway auf dem Client auf die pfSense gestellt?
Gibt es in dem Netz 172.16.3.11/24 noch ein weiteres Gateway?
Ist das Outbound NAT aktiviert (Diagnostic > NAT > Outbound) und gibt es da eine Regel für das LAN.
Geht die pfSense ihrerseits über ein weiteres internes Gateway ins Internet?
-
Hallo
Wow die Antwort ging ja schnell :)
Also das Default Gateway auf dem Client ist auf die PFSense gesetzt (172.16.3.2).
Der Outbount NAT ist auf "Automatisch" gesetzt und hat auch die folgenden Regeln hinterlegt:
127.0.0/8 und 172.16.3.0/24 - Quellort * - Ziel * - Zielport * NAT Adresse: WAN Adresse
(Die Regel wurde automatisch erstellt)
Der Server steht bei Hetzner und hat eine fixe IP Adresse. Die PFSense wird an einer anderen IP Adresse betrieben und diese wird auf die erste IP Adresse geroutet.
Gruss
-
@sohei said in Internet Zugriff von LAN aus:
Die PFSense wird an einer anderen IP Adresse betrieben und diese wird auf die erste IP Adresse geroutet.
Welche andere Adresse? Und was ist die erste Adresse?
Ein Überblick über das Netzwerk wäre essentiell für die Fehlersuche. Vielleicht kannst du eine Skizze anfertigen.
Wie oben erwähnt, ich gehe von einem asymmetrischen Routing in deinem Netzwerk aus.
Das kann mittels Diagnostic > Packet Capture bestätigt oder widerlegt werden.
Löse erst auf dem Client www.google.com auf und setze die zurückgegebene IP als Host-Adresse ein. Als Interface LAN auswählen und das Capture starten. Dann versuche am Client www.google.com aufzurufen, stoppe nach dem Timeout das Capture und sieh dir die Pakete an. Ich vermute, es sind nur Paket Richtung www.google.com zu finden, aber keine Antworten.
Selbiges kannst du noch am WAN machen.
Die Captures wären auch hier interessant. -
Also, ich versuche mal das so zu erklären:
Proxmox Server: 95.a.b.214/26 ----- pfSense: 95.a.b.200/26 ----- LAN: 172.16.3.2/24 ----- Clients
Wenn ich den Packet Capture starte, dann erhalte ich überhaupt keine Anzeige ... egal ob LAN oder WAN ausgewählt :(
-
@sohei said in Internet Zugriff von LAN aus:
Wenn ich den Packet Capture starte, dann erhalte ich überhaupt keine Anzeige ... egal ob LAN oder WAN ausgewählt :(
Da sollten aber am LAN Pakete ankommen, wenn das
@sohei said in Internet Zugriff von LAN aus:
Also das Default Gateway auf dem Client ist auf die PFSense gesetzt (172.16.3.2).
gegeben ist. Ansonsten würde ich das Problem im virtuellen Netzwerk des Proxmox suchen.
Allerdings passt das Ganze wieder nicht mit dem
@sohei said in Internet Zugriff von LAN aus:Die pFSense ist unter 172.16.3.2 per ping erreichbar, auch das WebGui funktioniert problemlos.
zusammen.
Wenn der Client mit der pfSense am LAN kommunizieren kann und die pfSense LAN IP als Default Gateway eingestellt ist, müssen Pakete des Clients, die für eine IP außerhalb seines eigenen Netzes bestimmt sind am LAN der pfSense ankommen, es sei denn Proxmox macht sonst was damit. -
Au Mann ... ich dreh hier noch am Rad .. ;) ...
Ich kann die öffentliche IP Adresse der pfSense vom Client aus pingen und auch den Proxmox Server bzw das Gateway des Proxmox Servers. Auch IP Adressen sind möglich, was inzwischen nicht mehr funktioniert ist die DNS Auflösung. Ich habe ein wenig herum gespielt und dann die pfSense auf "Factory Reset" gesetzt. Starte jetzt somit auf einer grünen Wiese. Die IP Adresse am Client habe ich per Manuell gesetzt auf 172.16.3.11/24 und Gateway bzw DNS auf 172.16.3.2 (pfSense). Ein Zugriff auf die Weboberfläche von pfSense ist auch möglich.
Wenn ich eine Linux Live CD mounte und dann dieser Live CD als Netzwerkkarte die öffentliche IP Adresse der pfSense gebe, habe ich sofort Zugriff auf Internet und Co - ein Routing Problem von Proxmox kann ich in diesem Fall ausschliessen.
Wenn ich auf der Weboberfläche der pfSense einen DNS Lookup und einen Traceroute ausführe dann sieht hier auch alles normal aus.
So wie ich das sehe blockiert die pfSense den kompletten Traffic vom Lan Netzwerk nach aussen ausser ICMP Requests. Die Outbound NAT ist (standardmässig) auf Auto gesetzt. Die Firewall Regeln unter LAN sind auch wie bereits vorher beschrieben.
-
@sohei said in Internet Zugriff von LAN aus:
So wie ich das sehe blockiert die pfSense den kompletten Traffic vom Lan Netzwerk nach aussen ausser ICMP Requests.
Ein asymmetrisches Routing Problem (wie bereits zu Anfang vermutet) wirkt sich ebenso aus.
ICMP Pakete sind stateless. Demnach ist es egal, ob es das Request-Paket eine andere Route nimmt als das Response-Paket.
Anders bei TCP. Hier akzeptiert die pfSense (Statefull Firewall) nur Pakete, für die es bereits eine Verbindung gibt und möchte diese auch lückenlos haben, bzw. nur ein SYN-Paket für eine neue Verbindung.@sohei said in Internet Zugriff von LAN aus:
Die Outbound NAT ist (standardmässig) auf Auto gesetzt. Die Firewall Regeln unter LAN sind auch wie bereits vorher beschrieben.
Standardmäßig erlaubt pfSense vom LAN alles nach außen und das Outbound NAT ist so eingestellt, dass Pakete die WAN-IP als Quell-IP erhalten, wenn sie die pfSense Richtung Internet verlassen.
Wie oben geschrieben, wenn der Client die pfSense als Standard-Gateway verwendet, müssen Verbindungsversuche des Clients ins Internet mit Paket Capture am LAN erfasst werden können, auch ICMP. Und ich vermute, dass da nur Pakete einer Richtung zu sehen sind.
-
OK ... so ... und jetzt bin ich komplett verwirrt ...
Da ich ja immer noch das Problem bei der pfSense vermutet habe, habe ich begonnen im Hintergrund die Infrastruktur aufzubauen (Sofern möglich ohne Internet). Dabei habe ich nun einen Windows 10 Client installiert - und gleich wie beim Linux Client - diesen die IP Adresse manuell eingetragen. Und ZACK ... ich habe Internet Zugriff ... selbes Subnetz, selbe pfSense Konfiguration und Firewall ... ich glaube ich spinne ...
Also Fakt ist: Ein Windows Client kann per DHCP oder manueller IP im Internet surfen, wenn ich einen Linux Client oder Server betreibe dann nicht ... der einzige Unterschied dabei ist die Netzwerkkarte: Unter Windows wird die Intel E1000 Netzwerkkarte verwendet unter Linux die VirtIO Netzwerkkarte ...
-
So, ich habe das problem gefunden. Es war keine Fehlkonfiguration der Firewall und/oder Route, sondern das Problem liegt an der VIRTIO Unterstützung von pfSense. Im Google gibt es hunderte Einträge dazu. Durch das Wechseln vom VIRTIO Netzwerk Treiber auf Intel E1000 bzw Realtek RTL8139 Treiber ist nun alles so, wie es sein muss.
Vielen Dank auf jeden Fall für Deine Hilfe!!
-
Ich denke, es liegt eher daran, dass du die Installationsanleitung nicht bis ganz unten gelesen hast:
https://docs.netgate.com/pfsense/en/latest/virtualization/virtualizing-pfsense-with-proxmox.html
Configuring pfSense to work with Proxmox VirtIO
Die Sache mit dem "hardware checksum offload" ist hier von Interesse.
Normalerweise sind die Probleme aber deutlich weitreichender, sind diese Einstellungen nicht gemacht.
-
tja .. da hast Du mich natürlich auf "frischer tat" ertappt ... bedienungssanleitungen waren noch nie meine Stärke :(
Aber danke auf jeden fall ... so wie es aussieht läuft es jetzt ... thx!!