Messages

61

23.7 Legacy Series / Re: MultiWAN: Force traffic from firewall itself to specific gateway

« on: December 08, 2023, 06:17:27 am »

Hi,

just wondering: are you using the Dynamic DNS service of OPNSEnse?
There you can set the interface to watch for IP Changes. And once it realizes such a change it updates the IP on your DynDNS provider. Works smoothless here with two WANs from two different provider, too.

Or does your DynDNS provider only allow updates from exactly this IP it is updating?

Change provider.... or you might want to set a gateway only for this provider hostname...

/KNEBB

62

German - Deutsch / Re: Langsamer Traffice zwischen 2 VLANs

« on: December 07, 2023, 10:22:58 pm »

Ok, dann habe ich mich wohl getäuscht. Vielleicht liegt es aber dennoch am SMB Protokoll. Das zickt nämlich massiv rum, wenn es etwas delay im Netzwerk hat. Möglicherweise hat es gerade so geschafft, die 1Gbit auszulasten, so dass mehr Bandbreite auch nichts mehr bringt. 

Aber ich gebe zu, dass da jetzt vieles Spekulation ist- gerade SMB bin ich nicht richtig fit.

Dennoch die Frage: Du nutzt aber schon Jumboframes in Deinem Netzwerk?

Wenn Du mittels nc die volle Speed bekommst, würde ich den Fehler nicht bei deR OPNSense suchen.... einzig mal schauen, was die CPU-Auslastung während eines großen Kopiervorganges so von sich gibt...


/KNEBB

63

German - Deutsch / Re: Kein DNS

« on: December 07, 2023, 09:33:38 pm »

Eigentlich gibts nur einen Grund, Sicherheit und Anonymität ( so gut wie geht ).

Die Unbound Anfragen gehen ja direkt an die Root Server.

Der Denkanstoss kam von hier:
https://www.kuketz-blog.de/pi-hole-einrichtung-und-konfiguration-mit-unbound-adblocker-teil2/

Habt Ihr was "verdächtiges" in der unbound.conf entdecken können?

Naja, da werden ja auch vertrauenswürdige Server genannt.
Und wer garantiert, dass die Root-Server nicht aufzeichnen?
Hast Du eigentlich eine feste IP? Oder eine dynamische? Dann ist der Wiedererkennungseffekt bei öffentlichen DNS-Servern ja eh' gering....
Und wenn Du genug Forward-Server von.verschiedenen Anbietern einträgst, ist sowieso kein Profiling möglich.

Ich finde, das ist mit Kanonen auf Spatzen geschossen.
Aber gut, entscheidet natürlich jeder selbst.

Grüße
/KNEBB

64

German - Deutsch / Re: Kein DNS

« on: December 07, 2023, 08:54:33 pm »

Naja, dass auf dem ROT Stille ist, ist ja klar. Der Umbound weiß ja nicht, wo er nachfragen soll. Auch wenn er das möglicherweise wissen müsste.

Andere Frage: Gibt es einen speziellen Grund, warum Du keinen Forwarder benutzen willst? Eigentlich macht das ja nicht unbedingt Sinn, wenn Deine Kiste alles selbst auflöst....

/KNEBB

65

German - Deutsch / Re: Kein DNS

« on: December 07, 2023, 01:57:41 pm »

Stimmt, da war ich nicht ganz richtig. Grundsätzlich scheint der das zu können. Es existiert audf der OPNSense sogar eine "root.hints".

Nur ignoriert er die offenbar unter OPNSense. Schaue ich in die /var/unbound/unbound.conf, finde ich dort:

Code: [Select]

forward-zone:
    name: "."
        forward-addr: 1.1.1.1
        forward-addr: 8.8.8.8
        forward-addr: 185.90.156.222
        forward-addr: 185.90.157.222
        forward-addr: 217.237.151.51
        forward-addr: 89.233.43.71

Gibt es diese "." forward Zone bei Dir, @maclovlin? Und ist vermutlich leer?

Das sind bei mir genau die konfigurierten DNS. Der Unbound scheint (was meine Vermutung war) in OPNSense keine "top-to-bottom" Auflösung zu machen.

/KNEBB

66

German - Deutsch / Re: Langsamer Traffice zwischen 2 VLANs

« on: December 07, 2023, 01:04:07 pm »

Ach so, als Ergänzung/ Erklärung auch nochmal der Link hier.

67

German - Deutsch / Re: Langsamer Traffice zwischen 2 VLANs

« on: December 07, 2023, 12:57:41 pm »

Also vom Speed her per iperf passt es jedenfalls jetzt mal, aber über SMB kriege ich trotzdem nur die 130 MB/S :-(

Das THEORETISCHE Maximum bei 1.000Mbit/s berechnet sich wie folgt:
8bit = 1Byte --> 1.000Mbit / 8 = 125MBytes
Die Hardware ist also physikalisch in der Lage, 125MBytes/s zu übertragen. So, und jetzt kommt noch der ganze Overhead von TCP, IP, SMB etc. hinzu.

"Früher" hatten wir da mal ideale Werte von ca. 40% der theoretischen Bandbreite, also hier ca. 50MB/s bei 1Gbit Netzwerk.

Das kannst du jetzt hochrechnen auf Deine 2,5er Schnittstellen:
2.500Mbit / 8 = 312MBytes
312 * 0,4 =125MB/s

Tja, und damit liegen wir genau bei dem von Dir gemessenen Wert. Passt also alles.

Merke: Nicht alles, was man misst, kann man auch richtig interpretieren

Neben der "Pi-mal-Daumen"-Schätzung von 40% kannst Du natürlich auch noch am SMB ein wenig schrauben. Gerade SMB ist nicht unbedingt für Performanz bekannt. Vor allem, wenn es SMB1 oder SMB2 ist!
Prüfe, was bei Euch "gesprochen" wird und versuche dann zu optimieren.
Siehe u.a. auch hier.

/KNEBB

68

German - Deutsch / Re: Frage zur Firewall

« on: December 07, 2023, 12:18:36 pm »

Und es bleibt die Frage, ob Du die Regel auch in der richtigen Reihenfolge eingestellt hast. Oft passt eine Regel früher, und dann kommst Du garnicht zu der von Dir erstellten Regel.

Screenshot ist hilfreich


/KNEBB

69

German - Deutsch / Re: Kein DNS

« on: December 07, 2023, 12:17:14 pm »

- keine DNS Server eingetragen
- "Allow DNS server list to be overridden by DHCP/PPP on WAN" -> haken raus

Ich glaube, ihr habt da beide etwas übersehen.

Also: Du trägst keine DNS-Server ein UND verbietest, dass die (leere) Liste durch die PPPoE-Einstellungen überschrieben wird. as ist ads Ergebnis? Richtig, keine DNS Server.

Und wenn Du jetzt Unbound verwenden willst, geht das nicht? Woher soll der Unbound denn wissen, welche DNS er befragen soll?


Ja, ein bind kann aus einer mitgegebenen root-NS von oben herab anfangen aufzulösen. Das macht aber nur im Ausnahmefall Sinn und deshalb kann der Unbound das wohl nicht. Steht so auch in dessen Doku: "Unbound does not perform recursion itself ".  Er muss also alle Anfragen "forwarden".

Nur: wohin soll er die weiterleiten, wenn ihm keinerlei DNS-Server bekannt sind?

Ich zitiere mal aus der Hilfestellung bei den Einstellungen (Unbound -> Query Forwarding":

Code: [Select]

If "Use System Nameservers" is checked, Unbound will use the DNS servers entered in System->Settings->General or those obtained via DHCP or PPP on WAN if the "Allow DNS server list to be overridden by DHCP/PPP on WAN" is checked. Ich finde, das erklärt alles, oder?

Also:
Mache den Haken bei "Allow DNS server list to be overwritten" und dann sollte es einwandfrei funktionieren.

/KNEBB

70

German - Deutsch / Re: Nutzung /29 Subnet an OpnSense

« on: December 07, 2023, 12:04:47 pm »

Moin,

mir ist noch nicht ganz klar, wie Deine Struktur aussieht. Die hast also 8 öffentliche IPs zur Verfügung, hast diese alle an ein WAN-Interface der OPNSense gepackt, richtig?
Wofür brauchst Du die IPs? Für Server o.ä. "hinter" der OPNSense? Die haben lokale (nicht öffentliche!) IPs und werden via Portforwarding vom Internet aus erreicht?

Oder was ist das Ziel?

/KNEBB

71

German - Deutsch / Re: Web-GUI schickt Pakete auf falschem Interface raus

« on: December 07, 2023, 11:59:33 am »

Moin,

danke für den Hinweis, aber das steht auf dem normalen Wert, sollte auch funktionieren.

Komischerweise habe ich nochmal versucht das nachzustellen und es hat diesmal funktioniert! Ich hatte die Tage wenig Zeit, habe also sicher nichts geändert. Aber jetzt geht es.,

Frag' mich nicht, was das war

/KNEBB

72

23.7 Legacy Series / Re: Bug? MultiWAN sending packets on wrong interface

« on: December 07, 2023, 11:46:32 am »

Hi,

I checked this and is was on the defualt setting (unticked).

I just re-checked what was going on on my system and it turned out, meanwhile (definitely no manual change!) the packets go out on the correct interface and I can connect through both Multi-WAN IPs.

Do not ask me what was wrong when I did the capture....

/KNEBB

73

23.7 Legacy Series / Bug? MultiWAN sending packets on wrong interface

« on: December 05, 2023, 04:11:17 pm »

Hi,

I have a Multi-WAN setup an configured it according to the documentation.

Now I tried to access my OPNSense Web-GUI on the configured port from Internet (WAN), but it failed on one of the interfaces.

After checking evry related items a packe capture revealed the reason why it fails:

OPNSense answers th request on the WAN1 interface with the (correct) source IP of the WAN1 interface but sends the packet out on WAN2 which is a different ISP and thus a different IP network. The ISP then obviously drops the packet with the wrong source IP.

Here's the result of the packet capture. ROTDSLDIREKT with $DSLIP is WAN2 and ROT with $GFIP is WAN1.

Code: [Select]

Schnittstelle Zeitstempel SRC DST output
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.769841 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.942055 length 48: $GFIP.8443 > $INETPC.37507: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:37.984069 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROT igc1 2023-12-04 10:50:34.751383 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37505 > $GFIP.8443: tcp 0
ROT igc1 2023-12-04 10:50:34.879659 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37507 > $GFIP.8443: tcp 0 

Any ideas how to fix?
Or is this a bug?
BTW: I already asked in the German forum but I guess it is a very special topic so I did not get any reply.

/KNEBB

74

German - Deutsch / Re: Verbindungsabbrüche ins Internet nach 3 minuten

« on: December 04, 2023, 11:08:25 am »

denke die OPNsense will nicht das doppelt DHCP vergeben wird.

Das will kein DHVCP-Server und darf auch ausdrücklich nicht so sein. Pro NEtzwerksegment ist max. ein DHCP-Server zuständig!
(Ausnahme natürlich Cluster-Setups, aber dann sind die DHCP Server entsprechend konfiguriert)

/KNEBB

75

German - Deutsch / Web-GUI schickt Pakete auf falschem Interface raus

« on: December 04, 2023, 11:03:04 am »

Moin,

hier ist ein Multi-WAN setup. Einmal Glasfaser (feste IPv4) , einmal T-DSL (dynamische IPv4).

Ich möchte meine Web-GUI der OPNSense vom Internet erreichbar machen. Via https:// auf Port 8443. Einstellungen unter "System -> Einstellungen -> Verwaltung" im Screenshot (siehe Anlage1). Alle Schnittstellen sind aktiviert.

Auf der DSL-Adresse ($DSLIP) funktioniert das auch einwandfrei, aber auf der Glasfaser-IP ($GFIP) funktioniert es nicht. Ich bekomme dort keine Antwort.

Die Regeln auf beiden Interfaces sind identisch gesetzt (sieheScreenshots 2+3)

Gehe ich auf die Konsole der OPNSense sehe ich auch, dass auf allen Interfaces tatsächlich ein Prozess "lauscht":

Code: [Select]

root@opnsense:~ # sockstat -4 -l | grep 8443
root     lighttpd   52359 7  tcp4   *:8443                *:*

Dennoch ist der Port nicht offen:

Code: [Select]

root@inetpc:~# nmap $GFIP -p8443
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-04 10:46 CET
Nmap scan report for $GFIP
Host is up (0.026s latency).

PORT     STATE    SERVICE
8443/tcp filtered https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.92 seconds

Auf $DSLIP sieht das dagegen gut aus:

Code: [Select]

root@inetpc:~# nmap $DSLIP -p 8443
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-04 10:47 CET
Nmap scan report for host.dip0.t-ipconnect.de ($DSLIP)
Host is up (0.020s latency).

PORT     STATE SERVICE
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds

Mache ich ein Packettrace auf der $GFIP sehe ich die eingehenden Pakete, aber die ausgehenden Antwortpakete gehen über die $DSLIP mit der Absender-IP von $GFIP raus.:

Code: [Select]

  View capture
Schnittstelle Zeitstempel SRC DST output
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.769841 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.942055 length 48: $GFIP.8443 > $INETPC.37507: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:37.984069 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROT igc1 2023-12-04 10:50:34.751383 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37505 > $GFIP.8443: tcp 0
ROT igc1 2023-12-04 10:50:34.879659 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37507 > $GFIP.8443: tcp 0

Er schickt also ein Paket mit einer anderen Absender-IP über das $DSLIP Interface raus. Das wird dann vermutlich bei der Telekom irgendwie geblockt. Richtigerweise.

Ergänzung: Deaktiviere ich das Interface mit der$DSLIP, funktioniert es einwandfrei über $GFIP.

Ideen, woran das liegt?

/KNEBB