[Sammelthread] pfSense & OPNsense (Firewall- und Routing-Appliance)

  • Ersteller Gelöschtes Mitglied 63700
  • Erstellt am
Mac_leod schrieb:
Nur zur Info: ich bin dann zu diesem Shop gegangen und hab hier die IPU445 bestellt.
Für mich privat auch gleich noch eine kleine^^
Zum Vergrößern anklicken....
Sollte es nicht SFP+ werden?

Auch wenn es jetzt vielleicht schon zu spät ist. Ich werfe mal das hier in den Raum:

Läuft bei mir seit einem halben Jahr als OpnSene problemlos. Aber ist halt privat. Ob man so ein Chinaböller beim Kunden verbauen möchte ist vielleicht nochmal ein anderes Thema.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hab mich gegen SFP+ entschieden, weil die Aruba Switche darunter jeweils 4 Ports SFP+ haben.
Also die pf im eigenen Home Lab in Betrieb zu nehmen, darauf freu ich mich tierisch.
 
Bin mal gespannt, ob der i7-4500U wirklich sparsammer ist als der N100.
TDP 15W gegen 6W ist klar, der Verkäufer meint aber unterm Strich zieht der i7 weniger Saft als die 10 Jahre jüngere CPU.
 
Ich würd dagegen wetten.
Und selbst wenn es es ähnlich viel oder sogar 1-2W weniger sind hätte ich mich für die aktuellere Hardware entschieden.
 
Das Design von diesen N-sowieso ist ja auch nicht wirklich neu und sie sind nicht wirklich effizient, sie sind nur verdammt schwach und verbrauchen deswegen nicht viel. Wem diese Leistung reicht, der darf halt zugreifen. Als Appliance gehen sie halt durch.
 
Zuletzt bearbeitet:
Hi

Habe eine E3-1281 v3 in meiner opnsense. Wenn ich mit dem normalen Intel MC starte, habe ich etwa 6800 im Down- und >5000 Mbit/s im Upstream. Aktiviere ich die Erweiterung "Intel CPU Microcode" bekomme ichim Downstream ca 6000 und im Upstream gerade mal noch 2000 Mbit/s.

Kann das jemand bestätigen? Nutzt Ihr die Microcode Updates bei einer Installation auf Blech?

Gruss und danke
Beitrag automatisch zusammengeführt:

Hmm, keine Ahnung, ob meine Hardware zu warm-, oder mein Provider schlechte Laune hat. Jetzt flutscht auch mit MC Update:


MC.PNG
 
Zuletzt bearbeitet:
Oder deine Gegenstelle kann nicht genug liefern. Wenn die mit 10G angeschlossen ist, und noch weitere Clients parallel bedienen muss ?
 
Guten Morgen,
ganz kurioses Phänomen. Ich hab 2x OPNsense als Inter-VLAN Router im HA laufen
O1: 192.168.211.45/24
O2: 192.168.211.46/24
CARP: 192.168.211.252/24 (<-- die ist bei den Clients als Gateway eingetragen)

Andere Seite
O1: 10.0.30.4/29
O2: 10.0.30.5/29
CARP: 10.0.30.6/29

Jetzt nutze ich NTP, eigentlich schon immer und bekomme jetzt gesagt, dass NTP sich im Netz 192.168.211.0/24 nicht abfragen lässt.

Also Test (CLient: 192.168.211.14)
Code: 
C:\Windows\system32>w32tm /stripchart /computer:192.168.211.252 /dataonly /samples:2
192.168.211.252 wird verfolgt [192.168.211.252:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:19:36.
08:19:36, Fehler: 0x800705B4
08:19:39, Fehler: 0x800705B4

C:\Windows\system32>w32tm /stripchart /computer:192.168.211.45 /dataonly /samples:2
192.168.211.45 wird verfolgt [192.168.211.45:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:24:23.
08:24:23, Fehler: 0x800705B4
08:24:26, Fehler: 0x800705B4
jetzt wirds kurios:
Code: 
C:\Windows\system32>w32tm /stripchart /computer:192.168.211.46 /dataonly /samples:2
192.168.211.46 wird verfolgt [192.168.211.46:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:24:31.
08:24:31, -1249.3570432s
08:24:33, -1249.3695011s

Ich hab mal auf chrony gewechselt (wollte ich eh) aber kein Unterschied.
Im Live-Log sehe ich die Anfragen, es wird auch nichts geblockt.
Auf der OPNSense SSH Konsole kann ich auch sehen O2 kriegt Anfrage und sendet Antwort, O1 kriegt nur Anfrage:
Code: 
root@O1:~ # tcpdump -n -i igb1 port 123
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:21:07.482118 IP 192.168.211.14.55438 > 192.168.211.45.123: NTPv1, Client, length 48
08:21:10.502381 IP 192.168.211.14.55439 > 192.168.211.45.123: NTPv1, Client, length 48

Code: 
root@O2:~ # tcpdump -n -i igb1 port 123
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:21:13.209793 IP 192.168.211.14.60424 > 192.168.211.46.123: NTPv1, Client, length 48
08:21:13.209887 IP 192.168.211.46.123 > 192.168.211.14.60424: NTPv1, Server, length 48
08:21:15.215298 IP 192.168.211.14.60425 > 192.168.211.46.123: NTPv1, Client, length 48
08:21:15.215388 IP 192.168.211.46.123 > 192.168.211.14.60425: NTPv1, Server, length 48

Zusammenfassend: Firewall O1 gibt keine NTP Antworten und es scheint weder ein Dienst, noch ein Paketfilter-Problem zu sein
Die gleiche (synchronisierte) Konfig auf O2 geht.

Jemand eine Idee?
 
Zuletzt bearbeitet:
andrer250282 schrieb:
Guten Morgen,
ganz kurioses Phänomen. Ich hab 2x OPNsense als Inter-VLAN Router im HA laufen
O1: 192.168.211.45/24
O2: 192.168.211.46/24
CARP: 192.168.211.252/24 (<-- die ist bei den Clients als Gateway eingetragen)

Andere Seite
O1: 10.0.30.4/29
O2: 10.0.30.5/29
CARP: 10.0.30.6/29

Jetzt nutze ich NTP, eigentlich schon immer und bekomme jetzt gesagt, dass NTP sich im Netz 192.168.211.0/24 nicht abfragen lässt.

Also Test (CLient: 192.168.211.14)
Code: 
C:\Windows\system32>w32tm /stripchart /computer:192.168.211.252 /dataonly /samples:2
192.168.211.252 wird verfolgt [192.168.211.252:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:19:36.
08:19:36, Fehler: 0x800705B4
08:19:39, Fehler: 0x800705B4

C:\Windows\system32>w32tm /stripchart /computer:192.168.211.45 /dataonly /samples:2
192.168.211.45 wird verfolgt [192.168.211.45:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:24:23.
08:24:23, Fehler: 0x800705B4
08:24:26, Fehler: 0x800705B4
jetzt wirds kurios:
Code: 
C:\Windows\system32>w32tm /stripchart /computer:192.168.211.46 /dataonly /samples:2
192.168.211.46 wird verfolgt [192.168.211.46:123].
2 Proben werden gesammelt.
Es ist 01.07.2025 08:24:31.
08:24:31, -1249.3570432s
08:24:33, -1249.3695011s

Ich hab mal auf chrony gewechselt (wollte ich eh) aber kein Unterschied.
Im Live-Log sehe ich die Anfragen, es wird auch nichts geblockt.
Auf der OPNSense SSH Konsole kann ich auch sehen O2 kriegt Anfrage und sendet Antwort, O1 kriegt nur Anfrage:
Code: 
root@O1:~ # tcpdump -n -i igb1 port 123
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:21:07.482118 IP 192.168.211.14.55438 > 192.168.211.45.123: NTPv1, Client, length 48
08:21:10.502381 IP 192.168.211.14.55439 > 192.168.211.45.123: NTPv1, Client, length 48

Code: 
root@O2:~ # tcpdump -n -i igb1 port 123
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:21:13.209793 IP 192.168.211.14.60424 > 192.168.211.46.123: NTPv1, Client, length 48
08:21:13.209887 IP 192.168.211.46.123 > 192.168.211.14.60424: NTPv1, Server, length 48
08:21:15.215298 IP 192.168.211.14.60425 > 192.168.211.46.123: NTPv1, Client, length 48
08:21:15.215388 IP 192.168.211.46.123 > 192.168.211.14.60425: NTPv1, Server, length 48

Zusammenfassend: Firewall O1 gibt keine NTP Antworten und es scheint weder ein Dienst, noch ein Paketfilter-Problem zu sein
Die gleiche (synchronisierte) Konfig auf O2 geht.

Jemand eine Idee?
Zum Vergrößern anklicken....
Okay, ich antworte mir selbst...
Es gab einen Unterschied zwischen O1 und O2: auf O2 ist Hardware Offloading deaktiviert.
In O1 deaktiviert: Zack geht.

2 Tage und viele graue Haare hat mich das gekostet.
 
Habe es gestern auch mal aufgespielt. Seither habe ich dauernd Verbindungsabbrüche. Sieht man z.B. beim Dongle Server, muss die Dongles dauernd neu verbinden. Manchmal verliere ich nur einen Dongle, manchmal alle.

Kann das wer bestätigen?
 
Habe gestern auch meine OPNSense auf den aktuellsten Stand gebracht. Alles scheint weiterhin korrekt zu funktionieren 👌
Komme irgendwo von Patchlevel April
 
Habe 25.7 vor 4 Tagen installiert, keine Probleme bisher. Läuft bis auf das DynDNS-Widget Problemlos. DynDNS funktioniert aber dennoch
 
Dann trau ich mich heute ev. auch mal drüber.
;-)
 
AliManali schrieb:
Habe es gestern auch mal aufgespielt. Seither habe ich dauernd Verbindungsabbrüche. Sieht man z.B. beim Dongle Server, muss die Dongles dauernd neu verbinden. Manchmal verliere ich nur einen Dongle, manchmal alle.

Kann das wer bestätigen?
Zum Vergrößern anklicken....
Nope, aber definiere Verbindungsabbrüche, zum DNS, Linkdowns oder was?
 
Ne, keine Linkdowns. Aber einzelne Dienste verlieren die Verbindung. So z.B. mein Dongleserver, da sind die Clients plötzlich weg. Heute auch mal all meine Clients zum Gameserver. Die Adapter waren aber nach wie vor verbunden, die VMRC blieben auch online. Aber halt alle Gameclients flogen raus. Das kann ich irgendwie gar nicht gebrauchen. Das muss stabil laufen. Die Clients – sowohl Gameserver wie auch Dongles – laufen auf verschiedenen Interfaces/Subnets.

Ob das nun wirklich an der Sense liegt, ist nicht ganz klar. Die ist halt direkt verbunden, mit dem Server, den Clients und dem Dongleserver. Der ESXi wird getagged angefahren, direkte Strippe. Aber scheint schon an dem Update zu liegen, vorher lief alles mehr oder weniger stable.
 
Anmelden, um zu antworten.

Ähnliche Themen

spyfly
  • Artikel
[User-Review] Synology ActiveProtect Appliance DP320 im Lesertest
Antworten
4
Aufrufe
628
maxblank
M
F
Neuer PfSense / Opnsense Router bzw. Mainboard, stromsparend, ECC RAM fähig, PCiex für Connect-X 4 Netzerkkarte, gesucht
Antworten
12
Aufrufe
1K
Zyxx
Z
Man-in-Black
  • Artikel
[User-Review] Die Synology DP320 ActiveProtect Appliance im Lesertest
Antworten
13
Aufrufe
1K
Man-in-Black
Man-in-Black
T
  • Frage / Lösungssuche
[Ungelöst] Hilfe bei der Konfiguration von pfSense hinter einer FritzBox (NetCologne)
Antworten
5
Aufrufe
1K
Zeitmangel
Z
L
Welche NVME für Proxmox/Firewall
Antworten
11
Aufrufe
1K
loaded
L
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh