Ping auf WAN nicht möglich

[franco]

Ok, eins nach dem anderen.

Laut meiner Recherche befinden wir uns an diesem Punkt in 2010: https://redmine.pfsense.org/issues/1136

Wenn ja, dann möchte ich wissen ob das entfernen von "reply-to" aus den Regeln (oder global) das Problem zumindest als Workaround löst?

Danach können wir testen, ob etwaiger Kernel-Patch für Besserung sorgt ohne den Workaround:

https://redmine.pfsense.org/projects/pfsense/repository/freebsd-src/revisions/b6445c8ca0a452bb5b8623c7c043a948cebfe551/diff


Grüße
Franco

[Zeitkind]

Naja, das
"We may need a bit more logic when applying reply-to on an interface's rules, skipping it automatically for rules that refer to directly reachable networks."
klingt schon ziemlich nach genau diesem Problem.
Damit wir uns richtig verstehen, mal ein Schaubild rein.
http://www.mein-zeugs.de/pub/setup.png
Das war "mein Problem" aus dem IRC-channel. Fw1 und Fw2 sind Kisten mit opnsense, mein Mac ("PC1") die 192.168.1.69 und das Laptop der Port-Forwarding-Versuch. Alle Pakete von PC1 wandern via Fw2 zwar bis zum Laptop, aber die Antworten werden von Fw2 nicht an PC1 addressiert (MAC-Adresse), sondern bekommen als Empfänger-MAC die von Fw1. Fw1 kann damit natürlich nichts anfangen und verwirft die einfach. Gleiches mit ssh von PC1 auf Fw2 - Pakete kommen an, werden angenommen (Firewallregel erlaubt ssh auf WAN), aber die Pakete werden wieder an MAC von Fw1 geschickt und PC1 sieht keinerlei Antwortpakete (geswitches Netzwerk). Erst mit einem Hub (oder entsprechenden Port an einer Switch) sieht man auch da dann die Pakete rumfliegen.
Deaktiviert man auf Fw2 alle Gateways (und damit die reply-to-Regeln), geht alles (ssh und port-forwarding auf das Laptop) - aber logischerweise kein Internet.. ^^
Ich kenne pf nicht so gut, aber es müßte halt sichergestellt werden, daß lokal erreichbare Netzwerke (inkl. möglicher statischer Routen im 192.168.1.0) nicht über das nächst höhere Gateway wandern. Eigentlich müßten ja z.B. VPN-Tunnel ebenso Probleme machen, da auch hier kein Upstreamgateway beteiligt sein darf.

[wurmloch]

Hi Franco,

zunächst mal vielen Dank für Deinen Recherchen! Und Zeitkind für's Mitdenken. Ich habe mir die beiden URLs angeschaut und ... nichts verstanden.

Naja, fast nichts. Gibt es in den Quellen einen Mechanismus, der nach dem Abarbeiten der pf Regeln und evtl. statischer routings (...) analysiert, ob das eingegangene Paket aus dem gleichen subnet kommt und dann den Weg der Antwort bestimmt (direkt oder via gateway)? Vereinfacht dargestellt ;-)

Ich würde auf meinen Testsensen die Veränderung einstellen und testen, falls das hilft.

Eine meiner opnsense hat jetzt 2 WANs. Bei der könnte ich zusätzlich eine Konfig mit openvpn road warriers einrichten und dazu ein openvpn net2net zu einer anderen opnsense (alles im selben WAN subnet), damit der Test ein bisschen komplexer wird. Eine opnsense mit 2 WANs hatte ich bisher noch nie im Einsatz. Hier im Forum gibt es ja einige Fragen zu "VPN über das eine WAN und E-Mail und Surfen über das andere WAN". FInde ich spannend.

Ich könnte auch mit einer dritten opnsense eine ipsec net2net Kopplung einrichten, um auch das abzudecken. Einen portforward auf einen webserver im LAN hinter einer opnsense sollte ich auch hinbekommen. Solch ein Szenario könnte ich am Wochenende bauen.

Morgen bekomme ich eine neue PC Engines APU.2C4 mit 16GB Data Power mSATA SSD, auf der möchte ich eh eine aktuelle opnsense Installation versuchen. Damit hätte ich ausreichend HW am Start und müsste nichts virtualisieren.

Falls es einen Unterschied macht, kann die eine oder andere opnsense eine statische oder auch eine dynamische IP auf der WAN Seite bekommen, dann wäre auch DHCP auf WAN abgedeckt.

VG
Uwe

[wurmloch]

Moin,

gestern Abend eine neue Erkenntnis gewonnen:

Eine aktuelle opnsense in mein home LAN gehängt und das WAN interface auf DHCP gestellt, ergibt Folgendes (mit den entsprechenden FW rules):

Ping auf WAN (192.168.10.239) von PC (192.168.10.100) wird jetzt beantwortet. Warum?
Bei ssh auf WAN werden die Antworten weiterhin an das GW (192.168.10.1) gesendet.

Als Gegencheck: Statische WAN config ohne GW auf der opnsense erlaubt den ssh Zugriff, aber kein Zugriff auf zB forum.opnsense.org, bei gesetztem GW wieder das eingangs des threads beschriebene Verhalten.

LG
Wurmloch

[Zeitkind]

Hmm.. ICMP spielt da eventuell eine Extrawurst, da ICMP redirects i.d.R. beachtet werden. Dann müßte man aber trotzdem immer erst mal falsch addressierte (i.e. falsche MAC) ICMP-Packete am nächsten Router sehen - und ein entsprechenes Geh-wo-anders-lang-Packet vom Router an den opnsense-Router intern.
Auch was reply-to mit ICMP so anstellt.. hmm..

[Werner Fischer]

Hallo Franco,

ich bin soeben auch auf das Problem gestoßen, dass ich WAN-seitig ein normalen /24 Netz habe (10.1.102.*) und ich nach Erstellung einer entsprechenden Firewall-Regel dennoch keine Antwort auf Pings von anderen Rechnern im 10.1.102.* Netz auf die OPNsense bekommen habe.

Du hattest dazu in diesem Thread geschrieben:
> Moin Uwe,
> Das "reply-to" ist sehr sicher schuld, welches manuell abgeschaltet werden kann für die Ping-erlauben Regel. Funktioniert es dann?

Deine Vermutung kann ich nun hiermit bestätigen. Anbei siehst du den Screenshot wie OPNsense das Echo Reply auf das Default Gateway zurückschickt (anstelle es an die MAC des Senders zu schicken).

Nachdem ich bei der entsprechenden Firewall-Regel nach Klick bei den "Advanced Options" auf "Show/Hide" die Checkbox bei "disable reply-to" aktiviert habe, hat der Ping funktioniert.

Schöne Grüße,
Werner

[franco]

Hallo Werner,

Ah, ja, das passiert aber wirklich nur beim lokalen Test aus dem angeschlossenen WAN wenn der Gateway die Pings nicht wieder zurück gibt ans interne Netz. Dann landen die nämlich im Internet.


Grüsse
Franco

[wurmloch]

Hi,

noch mal zur Klarheit. Ich hatte diese Diskussion eröffnet, da ich auf der WAN Seite ein öffentliches Class C Netz nutze und sich dort mehrere Geräte befinden.
1.1.1.1 Router ISP
1.1.1.2 WAN Interface der opnsense mit Einstellung "WAN-GW = 1.1.1.1"
1.1.1.3 Ein anderer Rechner
1.1.1.4 Ein weiterer anderer Rechner

Wenn einer der Rechner Pakete (ICMP, TCP-ssh, ...) an 1.1.1.2 opnsense schickt, gehen die Antworten zurück an 1.1.1.1 Router ISP. Der kann aber damit nichts anfangen. Ich kann also die opnsense weder pingen, noch eine ssh Sitzung eröffnen.

Das ist schon doof.

Gruß
Uwe

[franco]

Hi Uwe,

Na, ja, hat der Nutzer ein Multi-WAN und Reply-To ist nicht aktiv, dann kann es sonst passieren dass eingehende Verbindungen auf dem falschen WAN Interface wieder herausgegeben werden. Ist auch irgendwie doof.


Grüsse
Franco

[Werner Fischer]

Danke nochmal für die Info Franco 

Ich habe es bei uns im Wiki nun auch dokumentiert:

https://www.thomas-krenn.com/de/wiki/OPNsense_von_Rechner_im_Layer_2_WAN_Netzwerk_ansprechen

Schöne Grüße,
Werner

[mimugmail]

Servus, ich war jetzt auch davon betroffen. Die Lösung ist in der Interface config das Upstream Gateway zu entfernen, ein Standard Gateway über System - Gateways muss aber existieren, dann klappt's auch ohne reply-to

[franco]

Interessant... das müsste man mal prüfen oO

[mimugmail]

In der Tat. Wenn du ein Upstream im Interface einträgst, schickt er alle Pakete die auf dem Interface addressiert werden an das Gateway, egal ob es ne andere Route oder Standardgateway gibt. Meine Vermutung irgendwas mit route-to im pf, muss ich testen wenn ich wieder im Büro bin

[franco]

Moment, das würde aber bedeuten alle die jemals den Fehler gemeldet haben hatten statisches IPv4 und dann zusätzlich den Gateway gesetzt, obwohl er nur hätte erstellt werden müssen? Falls ja klingt das nach einem Fall für UX Tweaks.

[mimugmail]

Kann ich dir noch nicht sagen. Die Kollegen haben auf dem WAN ne zweite Route zu einem anderen Gateway gesetzt und er hat die Pakete trotzdem immer ans Default geschickt. Erst nachdem Upstream Gateway aus dem Interface gelöscht wurde ging es. Ist ja auch eher untypisch auf dem WAN unterschiedliche Gateways zu haben.