OPNsense Forum

International Forums => German - Deutsch => Topic started by: wurmloch on July 26, 2016, 09:36:32 pm

Title: Ping auf WAN nicht möglich
Post by: wurmloch on July 26, 2016, 09:36:32 pm
Problem gelöst. Nach dem Neustart der Box funktioniert es - warum auch immer. Erklären kann ich es mir nicht.


Moin,

ich bin neu bei OPNsense, habe ein bisschen Erfahrung mit IPCop und pfSense. Nun habe ich die erste OPNsense aufgesetzt (16.7.r2-amd64 nano auf kleinem APU System) und scheitere schon an der ersten Einstellung.

Ich setzte eine firewall Regel, die ICMP von überall auf WAN "diese Firewall" erlaubt, pinge die BOX von außen und bekomme keine Antwort und auch keinen Eintrag im firewall log. Die gleiche Regel auf dem IPCop und der pfSense daneben funktioniert. Aus dem LAN komme ich sauber ins Internet.
WAN: Feste öffentliche IPv4, Gateway und DNS korrekt gesetzt. IPv6 habe ich im WAN, nutze ich aber nicht und lasse ich durch die firewall blocken.

Was übersehe ich?

Über einen Tipp wäre ich dankbar.

LG, Wurmloch
Title: Re: [Gelöst] Ping auf WAN nicht möglich
Post by: franco on July 27, 2016, 10:16:15 am
Hi wurmloch,

Ich schau mal ob ich das verhalten reproduzieren kann, bisher war uns solch ein Problem noch nicht bekannt.


Grüße
Franco
Title: Re: [Doch ncht Gelöst] Ping auf WAN nicht möglich
Post by: wurmloch on July 27, 2016, 06:16:14 pm
Hallo Franko,

ich hatte mich zu früh gefreut. Ich bin nun deutlich weiter gekommen. Um das zu erklären, muss ich aber ein bisschen weiter ausholen.

Ich habe ein LAN (10.0.0.0/20), an dem ein Router "r" hängt, der 3 NICs hat:
1. NIC = LAN (10.0.0.1)
2. NIC = WAN (62.1.2.3) zum QSC-Router (62.1.2.1 / 24)
[3. NIC = WAN (195.1.2.3) zum TCOM-Router (195.1.2.1 /24)]
Das sind nicht die echten Public IPs.

Die OPNsense hängt im QSC Netz mit 62.1.2.103 am Switch zwischen der 2. NIC von "r" und dem QSC-Router, hat also eine feste public IP auf re0.
Als WAN-Gateway habe ich die 62.1.2.1 (den QSC-Router) eingetragen

Die OPNsense hat auf re1 das LAN konfiguriert (192.168.1.1/24), an dem nur ein Test-Notebook hängt. Die OPNsense ist also aus meinem "normalen" LAN 10.0.0.0/20 hinter "r" nur über die WAN Schnittstelle re0 zu erreichen.

Und genau das funktioniert nicht! Ich kann mit wireshark sehen, dass die ping Pakete von 10.0.1.21 (mein PC) via "r" zur OPNsense gelangen und auch von der OPNsense beantwortet werden. ABER die OPNsense sendet sie IMMER zurück an ihr WAN-GW, also 62.1.2.1 und nicht an den "r" (62.1.2.3)! Und genau das machen parallel betriebene IPCop (62.1.2.104) und pfSense (62.1.2.105) nicht. Die senden korrekt an "r" zurück, der ja den Weg zu meinem PC kennt.

Ich hoffe, das ist einigermaßen verständlich.

Gestern Abend hatte ich die OPNsense aus einem anderen Netz gepingt. Da kamen die ICMP requests schlicht über den QSC-Router rein und da die OPNsense immer über den QSC-Router antwortet, funktionierte es natürlich.

Das ist übrigens nicht auf ICMP beschränkt, auch TCP (zB ssh auf OPNsense) zeigt das gleiche Verhalten.

Entweder bin ich da einer großen Sache auf der Spur ;-) oder ich habe schlicht eine flasche Konfig. Allerdings habe ich in der frischen OPNsense außer Schnittstellen einrichten, Passwort ändern, 2 Firewall Regeln für ICMP und ssh allow auf WAN und mein ssh Zertifikat hinterlegen noch gar nichts anderes angefasst. Wie gesagt, ich bin newbie.


Die 3.NIC von "r" habe ich nur deshalb erwähnt, weil ich noch eine zweite OPNsense fertigmachen will, die ich entsprechend in das TCOM Netz hängen möchte, sozusagen als Reproduzierbarkeitstest. Falls es für Dich hilfreich ist, nehme ich dazu gerne eine stable Version oder was Du mir empfiehlst. Das werde ich heute nicht mehr schaffen, morgen geht's weiter.

LG, Uwe

Title: Re: Ping auf WAN nicht möglich
Post by: franco on July 27, 2016, 06:33:22 pm
Hi Uwe,

Ja, scheint etwas unschönes zu sein, aber ich weiß nicht ob es neu ist oder schon länger vorhanden. Ich habe gerade die ganzen Probleme mit dem Port Forwarding versucht nachzustellen, aber konnte auf keinem Setup ein Problem ausmachen.

Zeitkind hat gemeldet, dass es etwas mit dem setzen des Gateways zu tun hat (was ich so nicht nachvollziehen konnte), und nun sagst du es gibt ein 2. WAN... das wäre wohl eine Möglichkeit wo sich dieses Problem deutlicher manifestieren würde. :)

Blöd gefragt: was passiert wenn das zweite WAN abgestellt wird?

Wir gehen dem spätestens nächste Woche gründlich auf die Spur. Im Moment fehlt mir persönlich die Zeit zwischen Arbeit und OPNsense (zusätzlich zum 16.7er Release).


Grüße
Franco
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on July 28, 2016, 10:00:24 am
Moin,

auf den Punkt gebracht, sendet die OPNsense replies auf Anfragen, die von einem Rechner aus dem gleichen WAN subnet kommen, immer an das Standard-GW zurück und nicht direkt an den anfragenden Rechner.

Meine eingangs beschriebene Infrastruktur ist bereits vereinfacht dargestellt, da steckt in der Realität noch mehr dahinter.

> Blöd gefragt: was passiert wenn das zweite WAN abgestellt wird?

Das 2. WAN am "r" kann ich nicht abschalten, das ist unsere produktive Internet-Anbindung. Das 1. WAN ist "nur" unsere Backup Leitung, an der ich testen kann und Sachen betreiben kann, die ich nicht in mein Produktiv-Netz lassen möchte.

Ich kann das ganze Szenario auch komplett eigenständig aufbauen: Weitere Firewall[1] hinter den QSC-Router[0] (Internet), dahinter (LAN seitig) einen Switch mit zwei OPNsense[2+3], die mit den WAN-NICs somit ans "Internet" angeschlossen sind. Als Standard-GW trage ich bei beiden [2+3] die LAN-IP von [1] ein.

Wenn ich nun mit einem PC hinter [2] die [3] pinge, dann bekomme ich entweder
a) keine Antwort, weil [3] die Antworten an [1] sendet, oder
b) eine Antwort, weil ist zu doof war :-)

> Zeitkind hat gemeldet, dass es etwas mit dem setzen des Gateways zu tun hat
> (was ich so nicht nachvollziehen konnte)

Hätte ich auch vermutet.

> Wir gehen dem spätestens nächste Woche gründlich auf die Spur.

Franco, ich finde Euer Engagement fantastisch und werde bestimmt nicht hetzen :-) Auch ich habe einen Job und und und.

Falls ich noch Infos liefern kann, oder meine Teststellung verändern soll, lasst es mich einfach wissen. Am Ende kann ich zu Analysezwecken auch remote Zugriff auf das Testsystem gewähren, das ist für mich ja kein Risiko.

LG, Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on July 29, 2016, 05:35:29 pm
Moin,

ich konnte den Fehler reproduzieren :-(

Testaufbau:

IPcop 2.1.9 mit zwei NICs
WAN: öffentliche IP (195.1.2.1) im Telekom-Netz
LAN: 192.168.100.1

An diesem LAN zwei OPNsense:

OPNsense1 16.7rc2 mit 2 NICs
WAN: 192.168.100.2
LAN: 192.168.1.1
GW: 192.168.100.1

OPNsense2 16.7rc2 mit 2 NICs
WAN: 192.168.100.3
LAN: 192.168.2.1
GW: 192.168.100.1

Ping von Notebook (192.168.2.2) im LAN der OPNsense2 auf WAN der OPNsense1 (192.168.100.2).

Der Pong (ping reply) geht NICHT zu OPNsense2 zurück, sondern IMMER zum GW (IPcop 192.168.100.1) und taucht dort im Firewall-log auf.

(Die Firewall Regel, die ping auf WAN erlaubt und die Einstellung "don't block private addresses on WAN interface" sind natürlich gesetzt.)

Eben habe ich gesehen, dass die final 16.7 raus ist. Vielleicht schaffe ich es noch eine der beiden OPNsense mit dieser release neu zu installieren, aber ich vermute, dass sich an dem Ergebnis dabei nichts ändern wird.

LG,
Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on July 29, 2016, 06:14:03 pm
Das kommt mir bekannt vor:

https://forum.opnsense.org/index.php?topic=1668.msg11060#msg11060 (https://forum.opnsense.org/index.php?topic=1668.msg11060#msg11060)

Quote
3. Stellt man nun (wie ich) dann unter Interfaces/WAN ein Gateway ein - was da gar nicht hingehört, da dort nur Upstream Gateways hin sollen - geht es wieder nicht. Entfernt man das Gateway dann - geht es wieder. (Schreibt Zeitkind)

Was ist denn der Unterschied zwischen einem "gateway" und einem "upstream gateway"? Und wieso meint Zeitkind, dass das WAN Interface kein Gateway braucht? Die OPNsense müsste doch selber einscheiden können, ob sie das GW benutzt oder die Anfrage schlicht aus dem eigenen subnet kam und die Antwort ohne GW zurückgesendet werden kann? Wie gesagt, ich bin newbie, man möge mir evtl. dumme Fragen nachsehen.

VG,
Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 04, 2016, 05:59:01 pm
Hi Franko,

ist das Verhalten der von mir installierten OPNsense wirklich ein Fehler oder habe ich schlicht bei der Konfiguration etwas falsch gemacht?

Ich setzte morgen eine 16.7 mit einem supermicro (Thomas-Krenn) Blech auf, dann bin ich weg von den Alix/APU, bisher hatte ich ja nur die "16.7.r2-amd64 nano" am Start.

Lieben Gruß
Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: Zeitkind on August 05, 2016, 12:05:14 pm
Moin!

Das Problem mit den Gateways entsteht nur, wenn man "aus dem lokalen WAN" versucht zuzugreifen. Warum auch immer, aber opnsense hat auch für das WAN-Netzwerk als Gateway das nächst höhere gesetzt und kann damit mit keinen Rechnern im "lokalen WAN" kommunizieren.
Beispiel: LAN 192.168.a.b/24
WAN: 10.1.1.1/24 mit Gateway 10.1.1.254
Wenn man nun von einem 10.1.1.x-Rechner aus versucht mit dem WAN-interface zu reden, schickt opnsense alle ausgehenden (Antwort-)Pakete an die MAC des Gateways 10.1.1.254 und nicht an die MAC von 10.1.1.x. Egal ob bei ssh, ping oder portforward, es geht alles - nur werden die verlassenden Pakete falsch addressiert  - eben mit der falschen MAC. Entfernt man alle Gateways, geht ping und ssh etc. ohne Probleme.
Ich weiß nicht, was genau diesen Fehler triggert, aber man bemerkt ihn auch nur, wenn man aus einem solchen WAN-Netzwerkbereich testet - was normalerweise recht selten sein dürfte. Ich vermute, daß opnsense da irgendwelche reply-to im pf verwendet, aber kam noch nicht dazu, mich weiter damit zu beschäftigen. An sich sollte man trivial vermuten, daß Pakete für das WAN-Netzwerk einfach über die Schnittstelle WAN geroutet werden, aber da greift sich irgendwas die Pakete und schickt sie ans nächste Gateway.
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 05, 2016, 12:13:37 pm
Moin Zeitkind,

danke für Deine Antwort, das hilft mir sehr!

Leider habe ich diesen Fall öfters, also mehrere Devices im gleichen WAN "subnet" mit öffentlichen IPv4 Adressen von /24 bis /30, die miteinander kommunizieren müssen.

LG
Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: Zeitkind on August 05, 2016, 12:54:14 pm
Naja, ich auch. Irgendwelche /28 oder /29er sind ja nicht gerade selten, z.B. bei CompanyConnect etc. Bemerkt hab ich den Fehler aber beim Einrichten einer Testfirewall im LAN, wo opnsense dann sein WAN im "richtigen" LAN hatte und ich auch nach Stunden kein port forwarding hinbekam. Dank Wireshark und einem guten alten 10Mbit-Hub(! :D) konnte ich dann irgendwann die falsch adressierten Pakete sehen.
Wie gesagt, ich kann die Ursache noch nicht benennen, bin mit pf noch nicht so per Du wie mit iptables. Aber ich vermute halt, daß da eine Regel zu früh (oder falsch) greift, die was mit den Upstreamgateways zu tun hat (für lokales WAN sollte die halt nicht gelten), oder falsche reply-to gesetzt sind oder so was in der Richtung, keine Ahnung..
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 10, 2016, 05:51:08 pm
Moin,

Quote
Ich setze morgen eine 16.7 mit einem supermicro (Thomas-Krenn) Blech auf, dann bin ich weg von den Alix/APU, bisher hatte ich ja nur die "16.7.r2-amd64 nano" am Start.

Habe eben eine 16.7 an den Start gebracht, ohne Änderung des Phänomens.

Versions   OPNsense 16.7.1-amd64
FreeBSD 10.3-RELEASE-p6
OpenSSL 1.0.2h 3 May 2016

Your system is up to date.

CPU Type   Intel(R) Atom(TM) CPU D525 @ 1.80GHz (4 cores)

Gruß, Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: franco on August 11, 2016, 09:51:02 am
Moin Uwe,

Das "reply-to" ist sehr sicher schuld, welches manuell abgeschaltet werden kann für die Ping-erlauben Regel. Funktioniert es dann?

"reply-to" wird als Standard gesetzt damit im Multi-WAN Fall der Traffic wieder korrekt zurückgeht -- und jetzt kommt der Knackpunkt -- der nächste Hop muss in der Lage sein diesen korrekt weiter zu reichen.

Ich habe in lokalen Tests mit einer Easy-Box von Vodafone und einer OPNsense dahinter einen Port-Forward oder aber Ping erfolgreich ausführen können. D.h. im Standardfall *muss* der Reply-to Router dafür sorgen, dass das Paket auch wieder an das richtige Netzwerk zurückgegeben wird, was hier in einigen Fällen nicht passiert, sondern dann entweder abgewiesen wird als block oder auf das WAN des vorgeschalteten Routers geschoben wird.

Klingt das plausibel?


Grüße
Franco
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 11, 2016, 11:46:41 am
Moin Franko,

habe das kurz mit einem Kollegen besprochen, da ich mir bei dieser Aussage nicht sicher war:
Quote
D.h. im Standardfall *muss* der Reply-to Router dafür sorgen, dass das Paket auch wieder an das richtige Netzwerk zurückgegeben wird

Ich würde Deine abschließende Frage eher mit "nein" beantworten  :)

Das "richtige" Netzwerk ist hier dasselbe Netzwerk, aus dem der Router das Paket erhalten hat. Das kann man zwar machen (Stichwort "Hairpin" https://en.wikipedia.org/wiki/Hairpinning (https://en.wikipedia.org/wiki/Hairpinning)), macht aber nur Sinn wenn ein NAT im Spiel ist und Rechner A daher nicht weiß, dass Rechner B im selben Netz steht, weil er zu dessen externer IP verbindet und die halt erst vom Router in die interne übersetzt wird. Wir haben an der Stelle aber ja kein NAT.

Der "r" (siehe oben) hat das Paket glaube ich mit einem ICMP-Redirect abgewiesen, welches die OPNsense wiederum ignoriert (wobei das an sich nicht schlimm ist. Linux macht das standardmäßig ebenfalls, wenn IP-Forwarding aktiv ist ... aus Sicherheitsgründen vermutlich, da die Routen des Router richtig konfiguriert sein sollten, ohne dass es ihm von "Clients" gesagt werden muss).

So hat Dein setup ausgesehen?
Code: [Select]
Test-Client  <--[Switch]-->  OPNsense  <--[Switch]-->  easyBox
                                             |
                                             v
                                        Test-Server

==> Q: Dann bekommst Du auf einen Ping vom Test-Server auf die OPNsense eine Antwort von der OPNsense?

So sehen meine beiden Test-Setups aus:
Code: [Select]
Test-Client <--> LAN [OPNSense1] WAN <--[Switch]--> WAN [r] <--> QSC Internet
                                            |
                                            v
          Test-Client <--> LAN [OPNSense2] WAN

Code: [Select]
                                      Test-Client
                                           |
 Test-Client <--> LAN [OPNSense] WAN <--[Switch]--> LAN [IPCop] WAN <--[Switch]--> WAN [r] <--> DTAG Internet
                                           |
                                           v
          Test-Client <--> LAN [OPNSense] WAN



LG
Uwe
Title: Re: Ping auf WAN nicht möglich
Post by: Zeitkind on August 11, 2016, 12:43:34 pm
Das Problem ist doch, daß reply-to im Fall des _lokalen_ WAN-Netzwerkes wenig sinnvoll ist. Nur im Fall einer ungewöhnlichen physischen Segmentierung und Abschottung der Knoten in "lokale WAN-Untersegmente" müßte überhaupt ein Router ins Spiel kommen. Ansonsten muss das Paket einfach über die WAN-Schnittstelle raus und gut is. Bin mir nicht mal sicher, ob der nächsthöhere Router nicht einfach die Pakete verwirft, da sowohl Sender als auch Empfänger im gleichen logischen Netz sind. Stille Post spielen ist da nicht wirklich sinnreich.. ;)
Title: Re: Ping auf WAN nicht möglich
Post by: franco on August 11, 2016, 01:41:58 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: Zeitkind on August 11, 2016, 06:47:57 pm
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.
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 11, 2016, 10:42:38 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on August 17, 2016, 08:45:21 am
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
Title: Re: Ping auf WAN nicht möglich
Post by: Zeitkind on August 18, 2016, 02:03:13 am
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..
Title: "reply-to" ist tatsächlich die Ursache (Re: Ping auf WAN nicht möglich)
Post by: Werner Fischer on April 11, 2018, 03:16:44 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: franco on April 11, 2018, 05:17:54 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: wurmloch on April 11, 2018, 05:40:05 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: franco on April 11, 2018, 06:18:53 pm
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
Title: Re: Ping auf WAN nicht möglich
Post by: Werner Fischer on April 12, 2018, 11:02:47 am
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
Title: Re: Ping auf WAN nicht möglich
Post by: mimugmail on June 08, 2018, 03:08:07 pm
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 :)
Title: Re: Ping auf WAN nicht möglich
Post by: franco on June 12, 2018, 09:42:40 am
Interessant... das müsste man mal prüfen oO
Title: Re: Ping auf WAN nicht möglich
Post by: mimugmail on June 12, 2018, 10:01:54 am
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
Title: Re: Ping auf WAN nicht möglich
Post by: franco on June 12, 2018, 07:50:38 pm
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.
Title: Re: Ping auf WAN nicht möglich
Post by: mimugmail on June 12, 2018, 08:10:48 pm
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.