Topics

[wollte ich testen]

Hallo zusammen,

ich verwende OPNsense auf einem PC-Engines APU1C4.

Vor der Installation von OPNsense-19.7-OpenSSL-serial-amd64.img wollte ich testen ob es bootet.
Dazu habe ich es per USB-Stick gebootet.

Dieser einfache boot hat ohne irgendeine Interaktion meine produktive Konfiguration auf der HD zerstört!

Beobachte ich den boot jetzt auf der seriellen Konsole sehe ich statt korrektem Hostnamen und Version 18.x nur noch:
*** OPNsense.localdomain: OPNsense 16.7 (amd64/OpenSSL) ***
WAN (re1)       ->
LAN (re0)       -> v4: 192.168.1.1/24
FreeBSD/amd64 (OPNsense.localdomain) (ttyu0)
login:

Hintergrund für den Test waren erwartete BIOS-Probleme in Kombination mit FreeBSD 11.2.

The problem stems from a BIOS bug that is triggered in FreeBSD 11.2, but not in FreeBSD 11.1.

Keiner der Logins funktioniert (meine nicht, installer:opnsense nicht).
Ja, ich habe ein aktuelles Backup. Aber ist das expected behavior!?
Vinz

f48027041b37e1c8243d1c808911278d0a49542cc0e6d1f310de4a16b9f58ee6  OPNsense-19.7-OpenSSL-serial-amd64.img

[OPNsense 16.7.11_1-amd64]

Hallo zusammen,

ich verwende OPNsense 16.7.11_1-amd64 auf einem PC-Engines APU1C4 mit zwei WiFi-Karten WLE200NX.

Das funktioniert einwandfrei im Wifi-Standard 802.11g. Hat aber wie erwartet nur einen Durchsatz von 20 Mbits/sec.
Sobald ich aber umstelle auf 802.11ng "verschwindet" das WLAN.

Soweit ich bisher rausgefunden habe, sollte die WLAN-Karte im Modus 802.11n unter FreeBSD 10.3 keine Probleme bereiten.

An was kann das liegen, bzw wie könnte ich weiter debuggen?
Vinz

System-Log bei funktionierendem 802.11g
Dec 22 11:44:28    configd.py: [...für Forum entfernt...] Reloading filter
Dec 22 11:44:27    configd.py: [...für Forum entfernt...] updating dyndns opt3
Dec 22 11:44:19    kernel: ath1: ath_reset: concurrent reset! Danger!
Dec 22 11:44:19    kernel: ath1: ath_reset_grablock: warning, recursive reset path!
Dec 22 11:44:19    kernel: ath1: ath_reset_grablock: didn't finish after 10 iterations

System-Log bei NICHT funktionierendem 802.11ng
Dec 22 11:27:25    configd.py: [...für Forum entfernt...] Reloading filter
Dec 22 11:27:24    configd.py: [...für Forum entfernt...] updating dyndns opt3
Dec 22 11:27:17    kernel: ath1_wlan1: ieee80211_new_state_locked: pending RUN -> SCAN transition lost
Dec 22 11:27:17    kernel: ath1: ath_chan_set: concurrent reset! Danger!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: warning, recursive reset path!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: didn't finish after 10 iterations
Dec 22 11:27:17    kernel: ath1: ath_chan_set: concurrent reset! Danger!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: warning, recursive reset path!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: didn't finish after 10 iterations
Dec 22 11:27:17    kernel: ath1: ath_chan_set: concurrent reset! Danger!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: warning, recursive reset path!
Dec 22 11:27:17    kernel: ath1: ath_reset_grablock: didn't finish after 10 iterations

[Source/Destination:]

Hallo, ich bin neu hier und verstehe das Firewall Regelwerk noch nicht ganz.

Source/Destination:

   
• This Firewall
     Was bedeutet das? 127.0.0.1/8 oder alle [IFACE] Adressen?
• [IFACE] address
     Das ist das statisch definierte oder per DHCP zugewiesene Adresse dieses Interfaces. Könnten es auch mehrere sein? Sinnvoll bei allen Regeln nur für lokale Services auf der Firewall?
• [IFACE] net
     Siehe address, aber das ganze Subnet.
     Macht das Subnet als Regel-Source überhaupt Sinn? Es ist ja durch das Subnet eh gegeben?
     Ausser bei Zugriffen per externem port-forwarding auf das [WAN] Interface (Unterscheidet Quelle WAN-net oder Internet).

Firewall: Rules: Reihenfolge:

   
• Werden die Floating Regeln oder die Interfaces zuerst bearbeitet? Ich vermute Floating.
• Wenn eine Floating-Regel mit Aktion zutrifft (allow, reject, block), werden dann die Interfaces-Regeln gar nicht mehr durchlaufen!?
  Das wiederspricht meinem Netfilter-Kopf :-)

Floating Rules

   
• Grundregel: alles erlaubt, bzw. keine Aktion.
• Regeln werden von oben nach unten abgearbeitet. Bei einem Treffer wird die Aktion erstmal nur verändert.
• Auslösen der Aktion sofort, nur wenn Quick (action immediately) aktiv.
• Wenn Regeln zugetroffen haben (allow, reject, block), so gelten diese endgültig! Dann keine Bearbeitung der Interface-Regeln mehr. Stimmt das??
• Also: Weiter mit den Interface-Regeln nur dann, wenn hier keine Regel zugetroffen hat. Stimmt das??

Interfaces [IFACE] Rules

   
• Grundregel: Alles blockiert (nicht rejected)?
• Regeln werden für alle Pakete durchlaufen, die in Floating nicht "gematcht" haben -
• UND dann initial von aussen auf dieses [IFACE] auftreffen. Also Zugriff auf die Firewall oder Forwarding durch die Firewall.
• Regeln werden von oben nach unten abgearbeitet.
• Erster Match löst Aktion aus und bricht ab.
• Wieso gibt es den Schalter Quick (action immediately) hier nicht?

Firewall: NAT: Outbound:
Mode "Automatic outbound NAT rule genertion".
Ich sehe nur Regeln für mein LAN-Subnetz, wo sind WLAN und DMZ? Wieso funktioniert der Outbound von WLAN und DMZ?

[OPNsense Announcements]

I wanted to subscribe the RSS-Feed of  OPNsense Announcements but didn't find a link, so...
For example if you like to subscribe to Announcements use (watch board#):

https://forum.opnsense.org/index.php?action=.xml;type=rss;board=11.0

Forum-dudes should make this available as direct link in the boards. 8)