Messages

91

German - Deutsch / Re: Vlan mit Switch langsam

« on: December 17, 2021, 12:13:21 pm »

Code: [Select]

igb1 -> in Switch Port 1 untagged, out port 2 untagged -> Rechner untagged
igb2 -> in Switch Port 3 untagged, out port 4 untagged -> andere Rechner


Untagged und tagged auf sollte man nicht auf einem Interface mischen.

Ist auch nicht gemischt. igb1 ist ausschließlich LAN untagged, igb2 hat mehrere Vlans getagged.

Das was ich nicht verstehe ist, warum die Frage ob iperf oder echter Download von echten Daten über http(s) eine solche Rolle spielt.

92

German - Deutsch / Vlan mit Switch langsam

« on: December 17, 2021, 08:13:38 am »

Hallo, auch auf die Gefahr hin, dass ich hier im Forum vollkommen falsch mit meinem Problem bin hoffe ich trotzdem, einen Lösungsansatz zu erhalten:

Auf meiner Firewall habe ich neben einem Management LAN (kein Vlan) auf igb1 noch 3 Vlans auf igb2. Ein Managed Switch sorgt sich um die Verteilung der Netze. Schließe ich nun igb 1 ohne den Switch direkt an einen Rechner an, habe ich eineDownloadrate um die 900Mbit. Igb1 direkt an den Switch (Vlan1 untagged) und von dort an den Rechner verringert die Geschwindigkeit merklich. Dabei erfolgt zunächst eine geschwindigkeitszunahme beim Download auf 650-700Mbit, gefolgt von einer graduellen Abnahme auf teilweise bis zu 500Mbit, manchmal auch nur auf 600Mbit. Dieses Phänomen sehe ich sowohl bei einem TP-Link Switch, als auch bei einem Netgear Switch den ich habe. Beim TP Link Switch kann ich erkennen, dass der dort verbaute Prozessor nicht mal annähernd an seine Belastungsgrenze kommt. Im Ergebnis scheint die Tatsache, dass im Switch die Verwendung von Vlan 802.1q eingeschaltet ist, massiv die Geschwindigkeit zu beeinflussen. Und das obwohl auf Igb1 die Pakete noch nicht einmal getagged sind und der Switch außer seiner normalen Weiterleitungsfunktion nichts tun muss.

Ich kapiere es nicht?? Danke für eure Ideen...

Update: Die Kette ist: WAN - Fritzbox - Firewall - Switch - Rechner. Mit iperf komme ich auch für Server im Internet über Firewall und Switch auf knapp 800Mbit, was aber nicht für "normale echte Downloads" und Speedtests aus dem Internet zutrifft?!? Da liegen die 800 nur ohne Switch an.

93

German - Deutsch / Re: Kurze Verständnisfrage Source bei Firewall-Regeln

« on: December 03, 2021, 02:27:24 pm »

...wobei wenn der Kasper sich doof stellt und einfach das meist voreingestellte DHCP verwendet, bekommt er ohnehin automatisch die IP aus dem richtigen Subnetz. Insofern fehlt mir im Moment noch die Phantasie, warum ich jetzt alle Regeln von * auf xxxNET setzen sollte 

94

German - Deutsch / Re: Verbindung vom LAN Interface zu WAN Interface

« on: December 03, 2021, 02:05:46 pm »

Automatic outbound NAT for Reflection? Firewall-Settings-Advanced

95

German - Deutsch / Re: Kurze Verständnisfrage Source bei Firewall-Regeln

« on: December 03, 2021, 02:01:00 pm »

Aber genau das verstehe ich nicht. Am LAN Interface liegt genau ein Netzwerk an, nämlich LAN z.B. 192.168.10.0/24. Woher soll jetzt also die andere IP kommen? Dann müsste ja quasi ein Rechner am gleichen Interface hängen und (woher auch immer) eine andere IP haben, die nicht aus dem eigentlich zugedachten Subnetz stammt?

96

German - Deutsch / [Solved] Kurze Verständnisfrage Source bei Firewall-Regeln

« on: December 03, 2021, 12:44:24 pm »

Hallo,
bei der Erstellung von Firewall-Regeln habe ich üblicherweise z.B. beim LAN-Interface als Source * stehen, da ja lle Geräte im LAN unter die Regel fallen. Was bringt mir hier explizit als Source "LAN NET" anzugeben?

Danke für die Klarstellung!

97

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 30, 2021, 06:35:40 pm »

Kurze Zusammenfassung. Unbound wird nicht verwendet. Und ich habe mich gegen BIND entschieden, da dadurch in AdGuard (AG) alle Anfragen als von localhost zu kommen scheinen. Damit habe ich keinen Überblick mehr, wer was im Netzwerk macht. Da außerdem das Problem ist, dass ich DNS-Anfragen diverser LAN-Geräte warum auch immer nicht verhindern kann, ist die Möglichkeit zumindest in AG gegeben, manuell zu sperren "Nicht zugelassene Clients".

AG hat als DNS-Server und Bootstrap:

Code: [Select]

tls://1.1.1.1:853
tls://1.0.0.1:853
tls://[2606:4700:4700::1111]:853
tls://[2606:4700:4700::1001]:853
Opnsense 1:

• Port-Forward für jedes Interface zum Umschreiben der DNS Anfragen von der CARP-Adresse auf die statische IPv4 Adresse des Interface
• Ein AdGuard-Alias für alle CARP-Adressen und die IPv4 Interface Adressen
• Port Forward für jedes Interface von allen Anfragen, welche nicht vom AdGuard-Alias stammen und nicht an den AdGuard-Alias gerichtet sind, auf die die statische IPv4 Adresse des Interface (damit wird verhindert, dass Clients AdGuard umgehen)
• Entsprechende Firewall-Regeln anlegen

Opnsense 2:
Hier dasselbe, allerdings müssen die IPv4 Interface Adressen ausgetauscht werden gegen die Interfaces von Opnsense 2.

Auf allen Opnsenses bei DHCP jeweils die Interface CARP-Adresse als DNS Server angeben. Unter General-Settings habe ich die jeweilige reale LAN-Interface-Adresse noch zusätzlich als DNS-Server hinterlegt - ansonsten funktionieren DNS-Anfragen z.b. für Updates bei der Firewall nicht, die gerade im Backup-Modus ist.

Danke nochmals an den geduldigen Support 

98

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 29, 2021, 11:42:33 pm »

DNS over TLS? Kann eigentlich auch Adguard selbst, stimmt.
tls://1.1.1.1:853 z.B. als Server.

Noch eine Kuriosität. Es gibt bei mir Geräte im LAN, die habe ich für die Kommunikation nach außen gesperrt (China und so...). Allerdings schaffe ich es nicht, DNS-Anfragen an AdGuard zu unterbinden. Selbst wenn ich MAC und IP explizit im LAN-Netz sperre, gehen die DNS-Anfragen an AdGuard durch.

...wobei ich gerade feststelle, dass das mit BIND kein "Problem" mehr darstellt. Weil dann nämlich in AdGuard sämtliche Anfragen als von localhost her stammend erscheinen und überhaupt keine Unterscheidung mehr möglich ist, woher welche Anfrage kam. Also Source Host Auflösung scheidet mit BIND aus?

99

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 29, 2021, 10:47:53 pm »

  Ok, die nachfolgend beschriebene Kette ist etwas übertrieben, aber zum Testen tut's das

• Port Forward Gast Netz ...176.... Port 53 auf 127.0.0.1:53530 - drauf läuft BIND
• Bind hat als DNS Forwarder AG eingetragen, und zwar eine der CARP-Adressen .1
• AG macht Forwarding auf unbound

Ergebnis, es geht, aber laaaangsam. 2,5s Antwortzeit und mehr. Macht keinen Spaß.

100

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 29, 2021, 06:03:20 pm »

Also bei Dir läuft die DNS-Anfrage von BIND nach AG? Bei mir andersrum, nur eben mit unbound. Damit kann ich über unbound DOT machen.

101

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 29, 2021, 01:08:01 pm »

Funktioniert nicht, Outbound-Nat: igb2 Interface, source 176.2/32, NAT address 176.1, Source port 53.

Ergebnis ist, dass in tcpdump keine Antwort mehr auftaucht. Es gibt nur noch den request auf die 176.1, danach Schweigen bezüglich DNS.

102

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 29, 2021, 10:04:20 am »

PortForwarding von 176.1 auf 176.2 geht (.1 ist die Carp-Adresse, .2 die statische IP). Also DNS auf 176.1 liefert die Antwort von der richtigen IP:

Code: [Select]

igb2 09:59:26.400790 IP 192.168.176.143.51683 > 192.168.176.1.53: UDP, length 25
igb2 09:59:26.401022 IP 192.168.176.1.53 > 192.168.176.143.51683: UDP, length 52

Localhost geht nicht:

Code: [Select]

igb2 10:00:25.655542 IP 192.168.176.143.3269 > 192.168.176.1.53: UDP, length 25
igb2 10:00:25.655767 IP 192.168.176.2.53 > 192.168.176.143.3269: UDP, length 52
Da kommt die Antwort von 176.2.

Wie gesagt das ist doof, weil man damit keine Synchronisation der Firewall-Regeln, NAT Regeln zwischen HA-Firewalls machen kann. 

103

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 28, 2021, 01:26:10 pm »

Localhost geht nicht?! Muss ich unter Outbound NAT für diesen Fall noch etwas Spezielles einstellen?

Ein weiteres Problem ist, dass z.b. vom Gast interface 176.1 DNS Auf 2.1 nicht funktioniert. Ich habe testweise alle Ports vom Gast Interface auf Lan freigegeben, Ping funktioniert aber DNS funktioniert nicht. Was fehlt?

104

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 27, 2021, 12:11:05 pm »

Port Forward von der Carp-Adresse auf die feste LAN-IP hat ausgereicht. Nun tut es. Schlecht ist eben, dass auf der Backup-Firewall die Regel anders aussehen muss (Carp auf die dortige andere feste LAN-IP). Damit scheidet zukünftig ein Sync der Firewall-Regeln aus.

105

German - Deutsch / Re: Unterteilung Netzwerk - Sicherheitsaspekte

« on: November 26, 2021, 05:41:20 pm »

Ist installiert. Und tut, allerdings nicht so wie es soll. Ich habe hier (auch) testweise High Availability am Laufen, d.h. das LAN-Interface hat neben seiner normalen statischen Adresse 192.168.2.2 auch eine CARP-Adresse 192.168.2.1. AdGuard tut, wenn ich als Server die 2.2 angebe, jedoch nicht für die 2.1 (obwohl in Adguard als listening interface auch die 2.1 angegeben ist).

Code: [Select]

dig google.de @192.168.2.1
;; reply from unexpected source: 192.168.2.2#53, expected 192.168.2.1#53
Habt ihr eine Lösung dafür?