Ping auf WAN nicht möglich

[wurmloch]

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

[franco]

Hi wurmloch,

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


Grüße
Franco

[wurmloch]

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

[franco]

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

[wurmloch]

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

[wurmloch]

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

[wurmloch]

Das kommt mir bekannt vor:

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

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

[wurmloch]

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

[Zeitkind]

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.

[wurmloch]

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

[Zeitkind]

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

[wurmloch]

Moin,

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

[franco]

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

[wurmloch]

Moin Franko,

habe das kurz mit einem Kollegen besprochen, da ich mir bei dieser Aussage nicht sicher war:

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), 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 Expand


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 Expand


Test-Client <--> LAN [OPNSense1] WAN <--[Switch]--> WAN [r] <--> QSC Internet
                                            |
                                            v
          Test-Client <--> LAN [OPNSense2] WAN

Code Select Expand


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



LG
Uwe

[Zeitkind]

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.. ;)