Netzwerkverkehr auf pppoe0 ohne WAN-Regel

[MenschAergereDichNicht]

Hallo,

ich versuche gerade einem Problem mit Wireguard über PPPoE und IPv6 auch die Schliche zu kommen.

In dem Zusammenhang habe ich aus Testgründen die WAN-Regel für den Wireguard-Port deaktiviert. Mein Erwartungswert war, dass dann sämtlicher Traffic zu diesem Port geblockt werden müsste.
Wenn ich mit tcpdump auf dem PPPoE-Interface lausche und mit dem Handy eine Wireguard-Verbindung aufbaue, sehe ich jedoch eingehende UDP-Pakete... .

Dazu habe ich folgende Fragen:

1) Ist mein Verständnis der Firewall verkehrt? Blockt die *vor* dem Interface oder irgendwo weiter unten im Stack?
2) Gibt es eine implizite Konfiguration, die diesem Port auf WAN Durchlass gewährt? (ich sehe nichts in den automatisch angelegten Regeln)
3) Ich gehe davon aus, dass für PPPoE diejenigen Regeln greifen, die für das "WAN"-Interface konfiguriert wurden. Für PPPoE und das darunter liegende VLAN-Interface gibt es keine eigenen Rule-Sets. Richtig?
4) Was kann ich machen, um herauszufinden, warum der Verkehr durchkommt? Auch über z.B. "pfctl -sr" auf der Kommandozeile finde ich keinen Hinweis.

[Patrick M. Hausen]

Auch von der Firewall verworfene Pakete kommen erst einmal zu Deiner Schnittstelle rein, so dass Du sie mit tcpdump siehst ... die Firewall kann sich das Paket erst angucken, nachdem es empfangen wurde. Und es dann verwerfen.

[MenschAergereDichNicht]

Ok. Danke. Das beruhigt  :D

[MenschAergereDichNicht]

(nur am Rande und offtopic weil es mich interessiert)

Ich verstehe nicht ganz was "tcpdump" anders macht, als z.B. irgend eine andere Software die sich zu dem Interface verbindet.

Liegt das an dem Verbindungstyp (Raw-Socket vs TCP oder UDP)?

Das würde bedeuten, dass sämtliche Software die sich per RAW-Socket an ein Interface bindet, die Firewall umgeht?

[MenschAergereDichNicht]

Mich irritiert folgendes:

Code Select Expand


tcpdump -i pppoe0 -v 'udp port 51820'

11:56:10.154486 IP6 (flowlabel 0x7dbda, hlim 47, next-header UDP (17) payload length: 156) aaaa:bbb:cccc:dddd:eeee:ffff:gggg:hhhh.51820 > zeus.localdomain.51820: [udp sum ok] UDP, length 148
11:56:10.159561 IP6 (hlim 63, next-header UDP (17) payload length: 100) zeus.localdomain.51820 > aaaa:bbb:cccc:dddd:eeee:ffff:gggg:hhhh.51820: [bad udp cksum 0x6f51 -> 0xe13f!] UDP, length 92
11:56:15.269635 IP6 (flowlabel 0x7dbda, hlim 47, next-header UDP (17) payload length: 156) aaaa:bbb:cccc:dddd:eeee:ffff:gggg:hhhh.51820 > zeus.localdomain.51820: [udp sum ok] UDP, length 148
11:56:15.274872 IP6 (hlim 63, next-header UDP (17) payload length: 100) zeus.localdomain.51820 > aaaa:bbb:cccc:dddd:eeee:ffff:gggg:hhhh.51820: [bad udp cksum 0x6f51 -> 0x8214!] UDP, length 92


Diese Ausgabe bekomme ich auch dann, wenn die WAN-Regel für den Wireguard-Traffic deaktiviert ist (ich dachte vorher, dass nur der eingehende Teil zu sähen wäre. Das lag wohl an dem deaktivierten Wireguard-Dienst.).

[Patrick M. Hausen]

Ich verstehe nicht ganz was "tcpdump" anders macht, als z.B. irgend eine andere Software die sich zu dem Interface verbindet.

tcpdump verbindet sich nicht mit dem Interface. tcpdump gibt Dir roh alle Pakete aus, die über das Interface rein oder raus gehen - ganz unten auf der Treiber-Ebene. Das hat nichts mit Firewall umgehen zu tun - die Pakete müssen ja vom Kabel zur Netzwerkkarte rein, damit die Firewall sehen kann, von wo nach wo, welche Ports etc. pp. Und dann kann die Firewall entscheiden, ob das Paket rein darf oder nicht.

Das Modul, das hier benutzt wird, heißt Berkeley Paket Filter (bpf). tcpdump bekommt eine Kopie von jedem Paket auf dem Draht.

Eine Anwendung, die einen Raw Socket aufmacht, kommt dagegen nach der Firewall, da sie das Socket-API benutzt.

[MenschAergereDichNicht]

Ok. Danke. Mir war nicht ganz klar auf welcher Ebene tcpdump die Daten abgreift.

Aber folgendes sehe ich hier bei mir:

- Ich habe die WAN-Regel für Wireguard deaktiviert
- Wenn ich zur Überprüfung

Code Select Expand

pfctl -sr | grep "pass in" ausführe, finde ich genau zwei "pass in" Regeln auf dem pppoe0 Interface:
   

Code Select Expand


pass in log quick on pppoe0 inet6 proto udp from fe80::/10 port = dhcpv6-client to fe80::/10 port = dhcpv6-client keep state
pass in log quick on pppoe0 proto udp from any port = dhcpv6-server to any port = dhcpv6-client keep state


Nach meinem Verständnis hat das nichts mir Wireguard zu tun und demzufolge sollte der Verkehr geblockt werden.

Wenn ich in dieser Situation einen Dump mache, während ein Wireguard-Client versucht eine Verbindung aufzubauen, sehe ich das Ergebnis aus meinem vorherigen Post (d.h. entgegen meiner vorherigen Behauptung gibt es eine Antwort!).
Offenbar hatte ich vorhin als noch keine Antwort kam, einfach den Wireguard-Dienst nicht aktiviert (ich probiere gerade viel aus).

Also mit aktiviertem Wireguard-Dienst und deaktivierter Regel kommt eine Antwort (mit der falschen Checksumme).

Ich hacke nur deshalb so darauf herum, weil ich versuche zu verstehen wer da wie antwortet. Bzw. wie der Wireguard-Stack aufgebaut ist.


Nachträgliche Korrektur:

Wenn ich die WAN-Regel deaktiviere ohne den Wireguard-Service neu zu starten, verhält es sich wie beschrieben (d.h. Antwort kommt durch). Nach einem Neustart des Dienstes ist das nicht mehr der Fall... . Ist halt etwas verwirrend wenn man viel ausprobiert.

[Patrick M. Hausen]

Die pf Firewall ist stateful. Wenn Du an den Regeln was änderst, aber da noch ein Dienst aktiv ist und die Pakete noch fließen, dann bleibt der "State" erhalten. Bis Du den Dienst neu startest, kurzzeitig keine Pakete mehr fließen und der "State" nach einem Timeout rausgeworfen wird.

Mit dem Wireguard musst Du halt nochmal gucken, ob der Dienst vielleicht automatisch eine Firewall-Regel baut, so wie IPsec das auch tut. Das weiß ich gerade nicht auswendig. Also Dienst starten und mit pfctl nochmal nachsehen ...

[MenschAergereDichNicht]

Ok. Danke für die Hilfe. Soweit ist mir das jetzt alles klar.

Ich drehe gerade jeden Stein um, um herauszufinden wo die falsche Checksumme herkommt.

[Patrick M. Hausen]

Die hast Du bei tcpdump gerne mal als false positive - also die Tatsache, dass der BPF aktiviert wird, um tcpdump zu benutzen, erzeugt die Checksum-Fehler.

https://sokratisg.net/2012/04/01/udp-tcp-checksum-errors-from-tcpdump-nic-hardware-offloading/

[MenschAergereDichNicht]

Ja. In Zusammenhang mit dem Hardware Offload.

Das habe ich deswegen inzwischen  deaktiviert (siehe anderer Thread: https://forum.opnsense.org/index.php?topic=25828.0).

[Patrick M. Hausen]

Ja, aber auch sonst kann es sein, dass tcpdump das Paket abgreift bevor die Prüfsumme berechnet ist. Das ist mehr oder weniger normal.

[MenschAergereDichNicht]

Danke für den Hinweis. Dann muss ich evtl. in eine andere Richtung suchen.

Mein Haupt-Problem ist ja, dass die Antwort-Pakete beim Wireguard Handshake in tcpdump zu sehen sind (die mit dem Checksummenfehler) aber beim Client nicht ankommen.

Meine Vermutung war, dass das durch den Checksummenfehler kommt (Paket wird irgendwo verworfen, weil es nicht korrekt ist).

Wenn aber der angezeigte Fehler nicht unbedingt tatsächlich vorhanden ist, muss ich nach einer anderen Ursache suchen.