Jump to content

s.k.

Members
  • Gesamte Inhalte

    399
  • Registriert seit

  • Letzter Besuch

Beiträge erstellt von s.k.

  1. Ich sehe nur einen und der war der hinsichtlich VPN Connections. Aber ok, wenn das schon alle sind? Ansonsten erklärs mir doch genauer, damit ich hier nicht "dumm" sterben muß.

    Es geht mir nicht nur um das Thema VPN-Verbindungen, sondern allgemein um die Kopplung mit Netzen Dritter (Vertragspartner, Behörden etc.). Was macht man, wenn sich die Adressräume der Zielnetze untereinander oder auch mit eigenen IP-Netzen überschneiden? Man manipuliert die Namensauflösung und macht Destination-NAT sowie ggf. auch Source-NAT. Eigentlich simple Konfigurationen werden so unnötig kompliziert und dokumentationsbedürftig! Zumal das Ganze an seine Grenzen stößt, wenn NAT-unfriendly Protokolle zum Einsatz kommen (also insbesondere solche, die im Payload die Original-IPs mit übertragen). Wenig lustig ist soetwas auch, wenn man mehrere Wege zu den Fremdnetzen hat und daher eigentlich mit dynamischen Routingsprotokollen arbeiten möchte. Diese Sorgen hätte man nicht, wenn alle beteiligten Netze überschneidungsfrei - also eindeutig - adressiert wären. Im Small-Business-Umfeld mag das ja selten ein Problem sein - für andere hingegen schon.

     

    Ich sprach nicht von Servern, also bitte nicht den Sachverhalt verdrehen.

    Ja ich habe zu Deinen Gunsten bereits angenommen, dass Du nicht Clients, sondern Server meinst. Andersrum wäre das noch abstruser!

    Zur Erinnerung:

    Auf meinen Hinweis hin, dass es aufgrund des oben genannten Grundes vorteilhaft wäre, auch im LAN weltweit eindeutige IP-Adressen zu verwenden, hattest Du eingewandt, dass dies "zwangsläufig zu Split-DNS" führt.

    Mir erschließt sich jedoch nicht, inwieweit das eine das andere zwingend bedingt bzw. warum dies das Erfordernis einer Split-DNS-Konfiguration gegenüber den jetzigen Anwendungsfällen erhöhen sollte.

    Split-DNS ist regelmäßig dann erforderlich, wenn man mind. 2 DNS-Zonen mit unterschiedlichen Inhalten aber gleichem Namensraum benötigt. Dafür gibt es insbesondere zwei Gründe:

    1) gleiche Namen müssen in unterschiedliche IP-Adressen aufgelöst werden

    2) in einer Zone soll nur eine Teilmenge der anderen Zone enthalten sein (id.R. aufgrund von Geheimhaltungserwägungen)

     

    Also bei mir heißen die Server im "Allgemeinen" intern anders als extern (und ich spreche Server im Allgemeinen per DNS Namen an und merk mir nicht die IP ).

    Ist das bei dir nicht so? Von Clients mal abgesehen, da ich die nicht nach extern stelle.

    Das ist bei den von mir betreuten Netzen auch so - zumal interne Systeme (wie der Name schon sagt) ohnehin nicht (direkt) öffentlich erreichbar sind. Aber was hat das mit der hier behandelten Frage zu tun?

    Die Kernfrage war:

    Warum ist Deiner Meinung nach über die jetzigen Anwendungsfälle hinaus zwingend Split-DNS erforderlich, wenn man im LAN weltweit eindeutige Adressen verwendet?

     

    Gruß

    sk

  2. Exakt das gleiche unsinnige Argument hatte ich bereits vor mehreren Jahren von einem internen Systemadministrator gehört. Die Folge war dann, dass die Buchhaltung kein Onlinebanking der Vereins- und Westbank aufrufen konnte, weil zufällig genau die das gleiche Netz nutzten.
    Wo bitte steht denn im Eröffnungsposting, dass der Admin fremde Adressen verwendet?

    Nirgends! In Juristenkreisen nennt man soetwas eine Sachverhaltsquetsche...

     

     

    Welchen denn genau? ;)
    Wo ich handfeste Vorteile sehe, habe ich in meinem ersten Posting erwähnt.

     

     

    Der einzige Vorteil wäre, dass ich meinen Client direkt mit public IP von extern ansprechen könnte, aber wer will das schon, bzw. welche Dienste bietet so ein Client denn normalerweise nach extern an?
    Deshalb hatte ich dieses "Argument" ja gerade nicht angeführt.

     

     

    Ich mein im Endeffekt führt das zwangsläufig zu Split-DNS
    Dass Server intern wie extern unter der selben IP-Adresse zu erreichen wären, führt Deiner Meinung nach zu Split-DNS?

    Seltsame Argumentation! Darüber solltest Du vielleicht nochmal genauer nachdenken... ;)

     

     

    Gruß

    sk

  3. Hi,

     

    Vor einigen Jahren wurde ich einmal zu einem derartigen Fall gerufen. Da wollte ein Mailserver partout mit einem Rechner von HP kommunizieren, weil er glaubte im gleichen Netz wie der Rechner von HP zu sein ;)
    Es gibt immer wieder Admins, die aus purer Unwissenheit im LAN öffentliche IP-Adressen verwenden, die ihnen nicht gehören. Hierauf deutet im vorliegenden Fall aber nichts hin.

     

     

    Warum setzt ein Unternehmen mit ca 60 Clients öffentliche IP Adressen für "normale Clients"ein.

    Laut dem Admin (mit einem arroganten Lächeln) sei dies sicherer als Private IPs zu verwenden. Er sei nicht so dumm wie die anderen

    Wenn das "seine" Adressen sind, spricht nichts dagegen. NAT und "private" IP-Adressen sind doch schließlich nur eine Krücke aufgrund der Adressknappheit bei IPv4!

    Es hat seinen Charme, auch im internen Netz weltweit exklusive und eindeutige IP-Adressen zu verwenden. Bei IPv6 wird auch wieder so gearbeitet werden. Gerade wenn man häufig Netze von Dritten anbinden muss, geht einem das Hinundhergenatte ziemlich auf die Mozartkugeln. Nur kommt man aus dieser Nummer solange nicht vollständig raus, bis jeder Beteiligte exklusive Adressen im LAN verwendet.

    Wenn dem Admin bzw. dem Unternehmen für die tatsächtlichen und angenommenen Vorteile die damit verbundenen Kosten Wert sind, ist das ihre Sache. Einen Sicherheitsgewinn (aber auch einen Sicherheitsverlust) kann ich hierin jedoch nicht entdecken. Jedes vernünftige Sicherheitskonzept sieht ohnehin vor, dass weder von WAN nach LAN noch von LAN nach WAN eine direkte Kommunikation möglich ist. Nach der reinen Lehre läuft das immer über dualhomed ALGs.

     

     

    der Admin greift auch nicht über VPN auf die Server / Netzwerk zu, sondern über Teamviewer......
    Scheint wirklich ein besonders schlauer zu sein. :rolleyes:

     

     

    Gruß

    sk

  4. Wenn ich ein tracert zum Beispiel auf web.de mache dann steht ein von diesen statischen Adressen immer nach der internen IP von unserem Router. Geh ich da richtig in der Annahme das eine unserer statischen Adressen irgendwo extern liegt und alle Internetanfragen darüber geleitet werden?
    Ja das wird der Router sein, den Euch der Providers hingestellt hat. Du wirst auch keine 7 öffentlichen IP-Adressen haben. Vermutlich hast Du ein /29-Netz. Dabei bleiben nach Abzug von Netzwerk-und Broadcast-Adresse noch 6 Hostadressen. Davon der Providerrouter abgezogen bleiben noch 5 freie IP-Adressen zu Eurer Verwendung.

     

    Gruß

    Steffen

  5. Hallo,

     

    Du nimmst einfach Accesspoints mit Multi-SSID und VLAN-Unterstützung (eine passende Wired-Infrastruktur mit VLAN-Switches und Firewall setze ich als gegeben voraus).

    Bei der Anzahl der APs würde ich zudem eine zentral administrierbare Lösung wählen. Wenns sehr preisgünstig sein muss: ZyXEL NWA-3160 - die verwenden wir auch in unseren Schulen.

     

    Gruß

    sk

  6. Es sind nicht nur einzelne Ports, die weitergeleitet werden müssten, sondern ganze Protokolle wie z.B. ESP.

     

    Rein vom bisher Gesagten sehe ich aber ohnehin keinen Grund für einen zweistufigen Firewallaufbau. Das Szenario kann man auch mit einer "mehrbeinigen" Firewall lösen.

     

    Mein Vorschlag wäre folgender:

    1) Die pfSense entfällt. Die Zywall steht dann direkt im Internet.

    2) Auf der ZW weisst Du mind. einen der Inside-Ports per Port-Role der Zone "DMZ" zu. Hieran schließt Du den Accesspoint und/oder den Switch aus der bisherigen DMZ an.

    3) Das Firewallregelwerk der Zywall wird so konfiguriert, dass man von der DMZ nur ins WAN kann.

    4) Auf der Zywall wird ein VPN-Tunnel definiert, der sowohl auf dem DMZ- als auch auf dem WAN-Interface erreichbar ist. Der VPN-Aufbau von der DMZ aufs WAN-Interface könnte auch funktionieren, ist aber möglicherweise etwas tricky in der Einrichtung (NAT loopback).

    5) Wenn man die Zywall als DNS-Server für die DMZ verwendet, könnte man über eine Manipulation der Namensauflösung auf der ZW sogar dafür sorgen, dass auf dem Client lediglich _eine_ VPN-Config erforderlich ist, die sowohl in der DMZ als auch vom WAN aus funktioniert (vorausgesetzt, Du sprichst die Firewall beim Tunnelaufbau über einen Hostnamen an).

     

    Das gleiche sollte auch mit der pfSense funktionieren. pfSense hat sogar ein paar nette Features (z.B. taggt VLANs, SSL-VPN, Captive Portal), welche die doch schon recht recht betagte Zywall 5 nicht hat. Allerdings hatten m.W. zumindest führere Versionen von pfSense Probleme bei IPSec-VPNs mit dynamischen Endpunkten. Wenn ein zweitstufiger Firewallaufbau beibehalten werden soll, würde ich deshalb die Zywall als Front- und die pfSense als Backend-Firewall verwenden.

     

    Gruß

    sk

  7. Das Problem tritt wirklich periodisch auf (mindestens 2-3 Mal pro Tag, morgens und abends um ca. 8 und 16 Uhr). Dann schiessen die offenen Sessions auf der Firewall auf das Maximum per host (1024) und das Internet funktioniert zeitweise nicht mehr, da der Server nicht mehr Antwortet.
    Der Internetzugriff dürfte nicht mehr funktionieren, weil die Zywall u.a. die (neuen) DNS-Anfragen des Servers zu den externen DNS-Servern blockt, sobald die maximale Anzahl der Sessions pro Host erreicht sind. Die Zywall tut halt, was sie gemäß Konfig tun soll. Überlastet ist sie nicht.

    Ich kann Dir leider auch nicht sagen, warum der Server diesen Traffic generiert und wie Du dies unterbinden kannst. Jedoch kannst Du die Symptome kaschieren, indem Du diesen Traffic einfach an der Firewall abweist.

     

    Gruß

    sk

  8. Also, den genauen Typen des Routers kann ich bereits angeben: Typ = Zyxel Prestige P-660 Router

    :mad:

     

    Verzeichnislisting vom internationalen FTP-Server:

    P-660H-61

    P-660H-63

    P-660H-67

    P-660H-D1

    P-660H-D3

    P-660H-T1

    P-660H-T1_v2

    P-660H-T1_v3s

    P-660H-T3_v2

    P-660HN-F1

    P-660HN-F1A

    P-660HN-F1Z

    P-660HN-F3Z

    P-660HN-T1A

    P-660HN-T1H

    P-660HW-61

    P-660HW-63

    P-660HW-67

    P-660HW-D1

    P-660HW-D1_v2

    P-660HW-D3

    P-660HW-T1

    P-660HW-T1_v2

    P-660HW-T1_v3

    P-660HW-T3

    P-660HW-T3_v2

    P-660HW-T3_v3

    P-660HWP-D1

    P-660HWP-D3

    P-660M-63

    P-660M-67

    P-660N-T1A

    P-660R-61

    P-660R-61C

    P-660R-63C

    P-660R-67C

    P-660R-D1

    P-660R-D3

    P-660R-T1

    P-660R-T1_v2

    P-660R-T1_v3

    P-660R-T3

    P-660R-T3_v2

    P-660R-T3_v3

    P-660RU-T1

    P-660RU-T1_v2

    P-660RU-T1_v3

    P-660RU-T1_v3s

    P-660RU-T3

    P-660RU-T3_v2

    P-660RU-T3_v3

    P-660W-T1_v2

     

    Nur mal so als "Wink mit dem Zaunpfahl". Und da fehlen noch diverse lokalisierte und gebrandete Geräte...

     

    Aber versuche es erst mal mit der Anleitung. Vermutlich hat sich das Problem dann schon erledigt.

  9. Hallo,

     

    Bridgekonfiguration siehe KB-1437: Umstellung eines Prestige der 6xx-Serie zu einer Bridge - Studerus AG, ZyXEL Generalvertretung

     

    Wenn das nicht funktioniert, bitte die genaue Firmwareversion posten, denn es gibt gefühlte 5 Mio "Spielarten" der 600er Serie einschließlich diverser gebrandeter Providergeräte.

    Einige davon können übrigens auch selbst als VPN-Endpunkt fungieren...

     

    Gruß

    sk

×
×
  • Neu erstellen...