Probleme mit Richtfunk-Verbindung im LAN

[Uwe@Home]

Hallo,

seit dem Wechsel von Sophos UTM zu OPNsense kommen Pakete
aus einem via Richtfunk angebundenen Gebäude nicht mehr auf den
Clients im Hauptgebäude an. Das Netzwerk ist ganz einfach aufgebaut:

LAN (kein V-Lan / 24er Subnet)
  * Switch A
    * System A
    * Access-Point A (Mode: Access Point)
      = Richtfunk =
    * Access-Point B (Mode: Client)
    * System B
  * Switch B

Alle Clients (im Haupt- und Nebengebäude) erhielten
nach einem Neustart ihre IPs via OPNsense DHCPv4.
Access-Points und Switche wurden auch neu gestartet.

Ping von "System A" zu "System B" funktioniert.
Ping von "System B" zu "System A" funktioniert nicht.
Ping von "System B" zu "Access-Point A" funktioniert.
Ping von "System B" zu "Access-Point B" funktioniert.

Im Log der OPNsense findet man keinen verworfenen Packete.
Ich schätze, dass die Pakete, die über die Richtfunkstrecke reinkommen
schlicht größer sind und deshalb von der OPNsense ignoriert werden.
(Bisher konnte ich das nur mit Linux-Clients im Nebengebäude testen.)

Auf die schnelle hab ich im Forum nichts dazu gefunden.

Die LAN-Schnittstelle ist wie folgt konfiguriert:
Block private networks: [ ]
Block bogon networks: [ ]
MTU: 1500
MSS: (leer)
Dynamic gateway policy: [ ] This interface does not require an intermediate system to act as a gateway
IPv4 Upstream Gateway: Auto-Detect

Die Schnittstellen sind wie folgt konfiguriert:
Hardware CRC: [X] Disable hardware checksum offload
Hardware TSO: [X] Disable hardware TCP segmentation offload
Hardware LRO: [X] Disable hardware large receive offload
VLAN Hardware Filtering: Leave default
ARP Handling: [ ] Suppress ARP messages

Laut Paketmittschnitt kommt ein Ping auf der OPNsense an und hat folgende Elemente:

Frame 7: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: Tp-LinkT_49:33:52, Dst: PCEngine_55:b2:bc
Internet Protocol Version 4, Src: 192.168.5.79, Dst: 192.168.5.254
Internet Control Message Protocol

Ich schätz´, das "Ethernet II" macht hier Probleme - oder?
Was muss ich machen, damit es wieder funktioniert?

Grüße, Uwe

[Uwe@Home]

Update: Die Paketgröße scheint es nicht zu sein.

Das ICMP-Echo-Request-Paket kommt auf der OPNsense an:

Ethernet II
  Source: Tp-LinkT_49:33:52
  Destination: PCEngine_55:b2:bc
  Type: IPv4 (0x0800)

... und die Anfrage wird auch beantwortet. Das Paket sieht so aus:

Ethernet II
  Source: PCEngine_55:b2:bc
  Destination: Raspberr_52:ed:3c

Müsste die Antwort nicht auch an Tp-LinkT_49:33:52 gehen?

[Uwe@Home]

Update:

Windows-Clients und Fritz!Box im Nebengebäude (nur genutzt als TK-Anlage) haben keine Problem.
Es betrifft anscheinend nur Linux-Clients (wobei mir´s spanisch vorkommt, dass die Fritz!Box funktioniert).

Probleme gibt es konkret bei:
* Raspi
* Lancom-Switch (via Ping - Diagnostics - Seite)
* Wechselrichter

[Uwe@Home]

Update:

Mittlerweile vermute ich eher ein Routing-Problem sein.
Sobald der Traffic vom Nebengebäude über die OPNsense geht, geht nichts mehr:

Von einem Linux-Client aus dem Nebengebäude abgesetzt:

traceroute to 8.8.8.8, 30 hops max, 60 byte packets
 1  * * *
...
30  * * *

... und von einem Linux-Client im Hauptgebäude aus abgesetzt:

traceroute to 8.8.8.8, 30 hops max, 60 byte packets
 1  OPNsense (192.168.5.254)  0.742 ms  0.480 ms  0.380 ms
...
 7  dns.google ( 8.8.8.8 )  27.623 ms  27.572 ms  27.401 ms

Die Routing-Tabellen der Clients sind identisch:

Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.5.254   0.0.0.0         UG    202    0        0 eth0
192.168.5.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

Intrusion-Detection ist deaktiviert.

Tested (but did not change anything):
Interfaces => Settings => ARP Handling: [X] Suppress ARP messages
Firewall: Settings: Advanced: [ ] Automatic outbound NAT for Reflection
Firewall: Settings: Advanced: [X]  Disable automatic rules which force local services to use the assigned interface gateway.

[Maurice]

Routet oder bridged ihr über das WLAN? Bridging macht man normalerweise über WDS. Eine Konstellation mit Access Point <> Client funktioniert nur geroutet (oder als Notlösung: Pseudo-Bridge mit ARP-Proxy / NDP-Proxy).

[Uwe@Home]

> Routet oder bridged ihr über das WLAN?

Es ist kein WLAN-Kärtchen oder USB-Stick in der OPNsense selbst.
Es sind zwei Outdoor Access-Points. Einer arbeitet als Access-Point, der andere als Client.
Ich würde es als transparente Bridge bezeichnen.

Das Setup hat mit der Sophos-UTM (und vorher mit ´ner Bintec-Firewall)
über Jahre hinweg einwandfrei funktioniert.

Hab gerade die Pakete von Windows- und Linux-Systemen verglichen:

Request:
  Frame
    Windows: 74 Bytes (592 bits) / Linux: 98 Bytes (784 bits)
  IPv4
    Windows: kein Flag gesetzt / Linux: Don't fragment gesetzt
  ICMP
    Windows: 32 Bytes Länge (ohne Timestamp) / Linux: 48 Bytes (mit Timestamp)

Reply:
  Frame
    Windows: 74 Bytes (592 bits) / Linux: 98 Bytes (784 bits)
  IPv4
    Windows: kein Flag gesetzt / Linux: Don't fragment gesetzt
    Windows: Destination Address = Tp-LinkT_49:33:52 (=> Access-Point)
    Linux: Destination Address = Raspberr_52:ed:3c (=> anfragender Client)
  ICMP
    Windows: ohne Timestamp (32 Bytes Länge) / Linux: mit Timestamp (48 Bytes Länge)
    Windows: Response time = 0,088 ms / Linux = 0,154 ms

Die OPNsense schickt anscheinend die Pakete nicht mehr an die ursprüngliche
Source MAC-Adresse vom Request, sondern an die MAC-Adresse der
Destination IP-Adresse vom Request, sobald das "Don't fragment"-Flag gesetzt ist.

Hab versuchsweise folgende Option gesetzt und die OPNsense neu gestart:
Firewall: Settings: Normalization:  IP Do-Not-Fragment [X]
Das hat aber nichts geändert - hab´s wieder zurückgesetzt.

Danach hab ich versuchsweise noch folgende Option gesetzt (samt Neustart):
System: Settings: Tunables: net.inet.ip.redirect: 0 => 1
Hat auch nichts gebracht.

Unter Firewall: Settings: Advanced: Network Address Translation waren folgende Optionen noch gesetzt:
  Reflection for port forwards [X]
  Automatic outbound NAT for Reflection [X]
Die hab ich deaktiviert und wieder (nach Neustart) getestet. Hat aber auch nichts geädert.

Bei keinem Interface ist übrigens ein "upstream gateway" festgelegt.

Wie kann man der OPNsense beibringen, dass sie immer die ursprüngliche MAC-Adresse verwendet?

[lfirewall1243]

Bitte einmal einen richtigen Netzwerkplan der relevanten Teile, sowie Screenshots der Regelübersicht von den jeweiligen Schnitstellen

[Uwe@Home]

> Bitte einmal einen richtigen Netzwerkplan der relevanten Teile

Siehe "Netzwerk_LAN.png".

> sowie Screenshots der Regelübersicht von den jeweiligen Schnitstellen

Siehe "Rules_LAN.png".
Es gibt keine selbst erzeugten Floating-Regeln.

Ich hab auch zwei Bilder von den Paketen angehängt (Bilder sagen mehr als Worte  )
Request/Reply Windows-Client (keine Flags) => OK ("ICMP_203.png")
Request/Reply Linux-Client (do not fragment) => Fehler ("ICMP_79.png")

[lfirewall1243]

Und das LAN Subnet hängt an der OPNsense?
Hängt da eine Zwischennetz zwischen OPNsense und AccessPoint?

Bitte den Plan mal mit IP Netzwerken - ich blicke da noch nicht wirklich durch was da jetzt wo ist

[Uwe@Home]

Es ist wirklich so einfach - ein LAN, zwei APs, zwei Switche, zwei Clients. Kein VLAN, kein QoS, keine sonstigen Filter.

Firewall-Regeln sind egal, weil die Pakete ja beantwortet werden - also nicht ausgefiltert werden.
Sie werden von der OPNsense eben nur an das falsche Ziel geschickt.

Tausche ich die OPNsense ohne jegliche Änderung gegen Sophos UTM (oder Bintec) aus, dann funktioniert alles wieder.

Mit austauschen meine ich konkret: LAN umstecken, WAN umstecken, OPNsense aus, Sophos UTM ein.

Es ist definitiv die OPNsense, die hier Mist baut.

[Patrick M. Hausen]

Aber wenn das nicht geroutet ist sondern ein flaches LAN mit einem IP-Prefix, dann kann es ja auch kein Routing-Problem sein. Mysteriös, das ist.

[lfirewall1243]

Aber wenn das nicht geroutet ist sondern ein flaches LAN mit einem IP-Prefix, dann kann es ja auch kein Routing-Problem sein. Mysteriös, das ist.

Das denke ich mir auch gerade

Wenn es wirklich nur ein Subnetz ist, hat die OPNsense damit wenig zutun da der Traffic direkt zwischen den Geräten läuft.

Es ist definitiv die OPNsense, die hier Mist baut.

Würde ich so nicht sagen! Erstmal brauche ich noch ein paar Infos (wie schon nachgefragt) um überhaupt zu verstehen was du da für eine Situation hast, wirkt irgendwie komisch das ganze

[KHE]

Hi Uwe@Home

gibt es IP 192.168.x.79 doppelt?
Sprich hat der Raspberr_52:ed:3c auch diese IP-Adresse, genauso wie der Tp-LinkT_49:33:52 unter Linux?
Zumindest wenn die OPNsense als Router das DHCP übernimmt?

Gruß KH

[lewald]

Wie sind die Gateways an den Clients nach dem DHCP durch OPNsense.

Ist da evtl. etwas auf ip vom DHCP Gateway aber fest eingetragen.

Besonders auf System B. Was ist da wirklich aktiv?

IPconfig oder ip address in CMD oder Terminal.

[Uwe@Home]

gibt es IP 192.168.x.79 doppelt?
Sprich hat der Raspberr_52:ed:3c auch diese IP-Adresse, genauso wie der Tp-LinkT_49:33:52 unter Linux?

Nein - die IP gibt es nicht doppelt. Die meisten Clients haben einen statischen Eintrag im DHCPv4.
Das passiert auch, wenn ich vom Switch aus einen Ping absetze.
Der Switch hat das "don´t Fragment"-Bit aber nicht gesetzt.

Zumindest wenn die OPNsense als Router das DHCP übernimmt?

Vielen Dank für den Tipp! 

Bis auf den Windows-Client haben alle einen statischen Eintrag im DHCP.
Der Windows-Client bekommt eine Lease.

Die Einträge hatte ich vorab aus einer Liste aller Clients (samt Beschreibung) importiert.
In der Liste standen die echten MAC-Adressen der Clients und nicht die vom AP.

Nachdem ich den statischen Eintrag gelöscht und die ARP-Table geflusht hatte, kam der Ping
sofort an (in der ARP-Table ist jetzt der Eintrag vom Gateway - siehe "ARP_Table_79.png").

Kann man irgendwo festlegen, dass die MAC-Adresse aus dem Request genommen werden soll?
Oder kann man vielleicht irgendwo festlegen, dass die ARP-Tabelle nicht mit den statischen
Einträgen initialisiert wird?

Das würde Fehler vermeiden, wenn ein Client samt statischen Eintrag bei mir lokal
(Erst-)eingerichtet und im Anschluss hinter die AP-Bridge umgezogen wird...