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
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?
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
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.
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).
> 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?
Bitte einmal einen richtigen Netzwerkplan der relevanten Teile, sowie Screenshots der Regelübersicht von den jeweiligen Schnitstellen
> 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")
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
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.
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.
Quote from: pmhausen on April 13, 2021, 01:52:57 PM
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.
Quote from: Uwe@Home on April 13, 2021, 01:09:00 PM
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
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
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.
Quote from: KHE on April 13, 2021, 03:37:46 PM
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.
Quote from: KHE on April 13, 2021, 03:37:46 PM
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...
Quote from: lewald on April 13, 2021, 03:46:27 PM
Wie sind die Gateways an den Clients nach dem DHCP durch OPNsense.
Ist da evtl. etwas auf ip vom DHCP Gateway aber fest eingetragen.
Noch ein Update dazu: nein - in den Reservierungen sind keine Gateways eingetragen (siehe "DHCP_127.png").
Als Workaround trag ich jetzt bei allen statischen Einträge zu Clients auf der anderen Seite
die MAC vom Access-Point ein... ist zwar nicht wirklich schön, funktioniert aber zumindest.